Found closing #259.
just validate-references annotates a failed snippet match with:
[ERROR] Text part not found as substring: 'Syntrophobacter fumaroxidans MPOB T (DSM 10017) was
cultivated under anoxic conditions in basal medium as described previously'
(note: only abstract available for PMID:29611893, full text may contain this excerpt)
The full text was cached. references_cache/PMID_29611893.md is 80,454 bytes and carries the ===== OPEN-ACCESS FULL TEXT marker. The phrase is in it, one word different:
| record |
cache |
...MPOB T (DSM 10017) was cultivated... |
...MPOBT (DSM 10017) was cultivated... |
Type-strain superscript T, collapsed into the preceding word by the PDF/XML extractor — the documented RENDERING class the validate-references recipe comment already warns about.
Why the wording matters
"only abstract available" is a claim about the cache. What the validator actually knows is "I could not match this snippet". Those are different, and the first one sends the reader to cache-fulltext looking for a gap that does not exist. It cost me a full canary cycle on #259 — I ran cache_fulltext.py against that PMID expecting to fix something, and got full text already cached.
It is also the inverse of the trap recorded in this repo's own working notes: an abstract-only cache can hide the real results, so run cache-fulltext before calling a reference misattributed. Here the cache is fine and the message implies otherwise.
Suggested wording
Distinguish the two cases the validator can actually tell apart:
- cache file has no full-text marker → "only the abstract is cached for PMID:X; run
just cache-fulltext PMID:X" (the current message, but only when true)
- cache file has the marker → "not found in the cached full text; if the quote is faithful this is likely a PDF/XML extraction artefact (see RENDERING in the justfile), not a bad snippet"
The second is the actionable one, because the correct response is to leave the snippet alone.
Scope
Upstream, in linkml-reference-validator — the note is emitted by the tool rather than by anything in this repo. Related: #466 established that the validator does genuinely check EvidenceItem snippets, and #347 covers snippets that are paraphrases rather than quotes, which is the other reason a match fails and is worth telling apart from this one.
Found closing #259.
just validate-referencesannotates a failed snippet match with:The full text was cached.
references_cache/PMID_29611893.mdis 80,454 bytes and carries the===== OPEN-ACCESS FULL TEXTmarker. The phrase is in it, one word different:...MPOB T (DSM 10017) was cultivated......MPOBT (DSM 10017) was cultivated...Type-strain superscript T, collapsed into the preceding word by the PDF/XML extractor — the documented RENDERING class the
validate-referencesrecipe comment already warns about.Why the wording matters
"only abstract available" is a claim about the cache. What the validator actually knows is "I could not match this snippet". Those are different, and the first one sends the reader to
cache-fulltextlooking for a gap that does not exist. It cost me a full canary cycle on #259 — I rancache_fulltext.pyagainst that PMID expecting to fix something, and gotfull text already cached.It is also the inverse of the trap recorded in this repo's own working notes: an abstract-only cache can hide the real results, so run cache-fulltext before calling a reference misattributed. Here the cache is fine and the message implies otherwise.
Suggested wording
Distinguish the two cases the validator can actually tell apart:
just cache-fulltext PMID:X" (the current message, but only when true)The second is the actionable one, because the correct response is to leave the snippet alone.
Scope
Upstream, in
linkml-reference-validator— the note is emitted by the tool rather than by anything in this repo. Related: #466 established that the validator does genuinely checkEvidenceItemsnippets, and #347 covers snippets that are paraphrases rather than quotes, which is the other reason a match fails and is worth telling apart from this one.