The prescribed GEO lookup returns zero for every paper this project has ever resolved, including the one it was written from
also called db=gds PMID query broken · elink pubmed to gds · GEO provenance route correction
The recipe this project wrote down for finding a paper's deposited data does not work. Asking the data repository for a paper by its PubMed number returns nothing - for all twenty-six papers tested, including the one the recipe was originally written from. A different call returns the answer.
The same thing, for a scientist
`concept-resolving-an-unstated-system-from-geo` prescribes a three-call route whose first step is *"esearch db=gds on the paper's distinctive method name, its first author, or its title words"*, and the beat brief operationalised it as `esearch db=gds&term=<PMID>[PMID]`. **That query returns zero records for all 26 papers this beat tested** [E1]. Including PMID **37679565** - the CRISPR-ChIP paper whose four GEO series (GSE192562, GSE192561, GSE192555, GSE192544) the same concept entry documents in detail. The route returns zero for the paper it was written from [E1]. The field is not populated. `esearch db=gds&term=37679565` without the tag returns `Wrong UID 37679565` - the bare number is parsed as a GDS UID, not a PubMed identifier. **`elink dbfrom=pubmed&db=gds&id=<PMID>`** returns `pubmed_gds` links correctly: all four series for 37679565, and series for eight further PMIDs in the worklist [E2]. Two further route findings of the same kind. **`elink dbfrom=pubmed` to `sra`, `biosample` and `bioproject` returned zero for every one of the 26 papers** - including PMID 42418681, which has GSE337426, and PMID 26766589, which has E-MTAB-3322. That linkage is unusable as evidence of absence [E2]. And **`elink` to `gds` itself under-reports**: six of this beat's sixteen resolutions rest on accessions found only in a paper's data-availability statement - GSE186711, GSE150483, GSE181829, GSE260456, GSE260742, GSE337426 and E-MTAB-3322 - for which `elink` returned no GEO link at all [E3].
The corrected route
1. elink dbfrom=pubmed&db=gds&id=<PMID>&retmode=json
-> linksets[].linksetdbs[] where dbto == gds -> UIDs
200xxxxxx = GSE<xxxxxx> (strip leading zeros)
300xxxxxx = GSM, 100xxxxx = GPL
2. AND, not or: fetch the full text and read the data-availability statement.
regex \b(GSE\d{4,7}|E-MTAB-\d+|PXD\d{6}|PRJNA\d+|SRP\d+|phs\d{6})\b
- six of sixteen resolutions came only from here
3. esearch db=gds on topic terms ONLY as a last resort, and attribute by
acc.cgi?acc=<GSE>&targ=self -> !Series_pubmed_id, !Series_contributor
never by topic match (see the GSE200059 near-miss)
4. acc.cgi?acc=<GSE>&targ=gsm&form=text&view=brief for the per-sample records
Step 2 is the substantive addition. The original concept entry treats the deposition as the escape hatch when the full text is unreachable; in practice the full text is often the only way to find the deposition, so the two routes are complementary rather than alternatives. Where the full text is unreachable and elink is silent, as for six of the eight bounded failures, there is nothing left.
Three blind negatives, and the shape they share
| Query | Returned | True answer |
|---|---|---|
db=gds term=<PMID>[PMID] | 0 for 26/26 | at least 9 have GEO series |
elink pubmed->sra/biosample/bioproject | 0 for 26/26 | at least 2 have depositions reachable by other routes |
elink pubmed->gds | 9 of 26 | at least 15 of 26 have a deposition |
All three are clean, round, consistent negatives - the exact signature the standing brief says to distrust. The first two return a perfect zero across an entire worklist, which reads as a strong finding and is a dead endpoint. The third returns a plausible-looking partial, which is more insidious: an agent using elink alone would have reported eight bounded failures as fifteen and a resolution rate of 37.5% instead of 66.7%, and nothing in the output would have looked wrong.
The only thing that caught any of it was checking against a case whose answer was already on record.
| script | scratchpad Q18b: run_pipeline.py (term query), run_elink.py (elink), pmc_run.py (data-availability sweep) |
|---|---|
| status | run |
| result summary | term=<PMID>[PMID] in db=gds returns 0 for 26/26 including the documented case. elink pubmed->gds works but under-reports, returning 9 of at least 15. elink pubmed->sra/biosample/bioproject returns 0 for 26/26 and is unusable. Six of sixteen resolutions came only from data-availability statements. |
| correction owed | concept-resolving-an-unstated-system-from-geo, data.route step (i) |
inputs
[ "26 worklist PMIDs", "NCBI esearch/elink db=gds", "GEO acc.cgi", "PMC full texts" ]
counts — the numbers behind the chart
{
"pmids_tested": 26,
"term_query_hits": 0,
"elink_gds_hits": 9,
"elink_sra_biosample_bioproject_hits": 0,
"resolutions_from_elink_only": 3,
"resolutions_from_data_availability_only": 6,
"resolutions_from_fulltext_only": 3,
"resolutions_from_keyword_search": 1,
"rate_if_elink_only_pct": 37.5,
"rate_achieved_pct": 66.7
}corrected route
[ "elink dbfrom=pubmed&db=gds&id=<PMID>", "regex the full text's data-availability statement for GSE/E-MTAB/PXD/PRJNA/SRP/phs", "esearch db=gds on topic terms only as a last resort, attributed by !Series_pubmed_id", "acc.cgi?acc=<GSE>&targ=gsm&form=text&view=brief for per-sample records" ]
- A documented route that silently returns nothing is worse than no route, because it converts a question into a confident negative and an agent following the written procedure has no signal that anything went wrong.
- This project's own concept entry has been prescribing the failing step since cycle 49, so any beat that followed it between then and now recorded false absences that nobody would have reason to revisit.
- The corrected route depends on reading the full text to find accessions, which means the papers most in need of the deposition route - the unreadable ones - are exactly the papers for which it works worst.
- Is the PMID field genuinely unindexed in db=gds, or populated only for a subset of series? A control across a large random PMID sample would answer it and this beat did not run one.
- Do the elink pubmed-to-gds tables fill in over time? Several of the missing links are for 2024-2026 depositions, which would suggest lag rather than absence.
- E1established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.database
The query esearch db=gds with term=<PMID>[PMID] returns zero records for all 26 papers in the unstated-system worklist, including PMID 37679565, whose four GEO series are documented in this graph; the same query without the field tag returns the warning 'Wrong UID 37679565'.
NCBI esearch db=gds field query for 37679565[PMID], run against the Entrez Programming Utilities · NCBI Entrez Programming Utilities 2026What this evidence cannot show
Run on 2026-09-19 from a single network location. The response is a well-formed esearchresult with count 0 and an outputmessage of 'No items found' - not an error - so nothing in the response signals a broken query. Whether the PMID field is unindexed in db=gds or simply not populated for these records was not determined; either way the query is unusable. A control query on 'GSE192562' in the same database returned 68 records, confirming the database itself is reachable.
Evidence that argues against this (1)
- The concept entry's own wording is 'esearch db=gds on the paper's distinctive method name, its first author, or its title words', which is a topic search and not a PMID search - so the original prescription was not what failed here, but it fails differently, by returning other people's studies, as the GSE200059 near-miss shows. Gilan O et al. 2023
- E2established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.database
elink dbfrom=pubmed&db=gds returns the correct pubmed_gds links, giving all four series for PMID 37679565 and series for nine PMIDs in the worklist, whereas elink from pubmed to sra, biosample and bioproject returns zero for all 26 papers including PMID 42418681 (GSE337426) and PMID 26766589 (E-MTAB-3322).
NCBI elink dbfrom=pubmed&db=gds for PMID 37679565 and elink to sra, biosample and bioproject across the worklist · NCBI Entrez Programming Utilities 2026What this evidence cannot show
Run on 2026-09-19. The SRA/BioSample/BioProject result is a negative about linkage, not about the existence of those records: an SRA study certainly exists behind every GEO sequencing series here, so the zero reflects the pubmed-to-sra link table rather than the data. A GEO series is also not the only deposition type; ArrayExpress and PRIDE are outside elink entirely by construction.
Evidence that argues against this (1)
- Because elink to gds itself under-reports by six of sixteen, elink is not a replacement for the broken query so much as a better first call; treating an elink zero as proof of no deposition would reproduce the same class of error at a lower rate. Neville D et al. 2026
- E3established confidence 5 of 5: Multiple independent lines of evidence; treated as settled in the field.dataset
Six of this beat's sixteen resolutions rest on accessions discoverable only from a paper's data-availability statement - GSE186711, GSE150483, GSE181829, GSE260456, GSE260742, GSE337426 and E-MTAB-3322 - none of which elink dbfrom=pubmed&db=gds returned for its PMID.
A Molecular Switch between Mammalian MLL Complexes Dictates Response to Menin-MLL Inhibition (GSE186711) · GEO submitters · NCBI Gene Expression Omnibus 2023What this evidence cannot show
Established on 2026-09-19 by comparing the elink result for each PMID against a regular-expression sweep for accession patterns over the recovered full text. GSE337426 is a partial exception: it was found by GEO keyword search rather than from full text, because that paper's text is unreadable - which is why it is counted here as not-from-elink rather than as from-data-availability. The sweep pattern is recorded in the enumeration entry.
Evidence that argues against this (1)
- The discovery asymmetry cuts the other way for very recent papers: GSE337426 was submitted two months before this beat ran, and elink tables lag deposition, so some of these gaps may close with time rather than being permanent. Bröchtel S et al. 2026
the worklist's resolution rate depends on the corrected lookup route
step (i) of this concept's documented route returns zero for all 26 papers tested, including the one it was written from
the spot-check case: four known series, zero returned by the prescribed query
the corrected route needs the full text to find accessions, so unreadable papers fail twice