FORRT Research

Mirror published CiTO citations into Wikidata — as a batch for a human to submit. Run it after `verify_chain` is green, to make the chain's typed citation ("this replication confirms / qualifies / disputes that paper") visible in Wikidata and Scholia. Pass the CiTO nanopub URIs, or `published_path` (a `nanopubs/PUBLISHED.md`) to take every CiTO nanopub in the ledger. It writes nothing to Wikidata. It returns `quickstatements` — a batch that adds, on the replication's item, "cites work" (P2860) → the original, with "has goal" (P3712) → the CiTO intent, referenced by "nanopublication identifier" (P12545) → the CiTO nanopub — plus a per-work report. Show the researcher the report; they submit the batch at https://quickstatements.toolforge.org with their own Wikidata account. Never submit it on their behalf. Items are looked up by DOI and ORCID first and created only when missing; a replication is one item per Zenodo concept DOI, not one per version. Items are created from the Zenodo record's title, so a repository-slug title ("my-replication-repo") should be fixed on Zenodo first. `pending` lists citations to works this same batch creates: re-run after submitting.

The FORRT chain(s) reachable from a published nanopub URI, as a compact projection you can actually read. Call this to see an existing chain — before starting a replication (what has already been done?), when extending someone else's chain, or to inspect your own after publishing. The raw Science Live constellation is ~330 KB for one chain, of which ~95 % is a depth-5 neighbourhood of UNRELATED chains reachable through shared links (on the marine-heatwave chain, 64 of 98 nodes are other studies' AIDA statements). This returns the chains, the apex CiTO, any Research Synthesis, and the Quote/Question anchors attributable to this paper — and drops the rest, reporting how much it dropped under `neighbourhood`. Read `citedPaper` rather than assuming: the API's own top-level `paperDoi` is a frequency vote across the whole walk and can name a neighbour's paper, so this derives the paper from the chain's CiTO citation and sets `disagreesWithReported` when the two differ. `stepsPresent` legitimately omits steps: a CiTO at the apex of the constellation is hoisted out of its chain, and Quote/AIDA anchors are often not enumerated. Missing does not mean unpublished.

The unprojected `/np/constellation` response, including every node and edge. For debugging the graph itself or investigating an upstream data problem. Prefer `constellation` for normal use: this is very large (~330 KB for a single chain) and most of it belongs to other studies. Lower `depth` to shrink the walk.

Which chain steps and vocabularies this server can look up. Cheap, offline, and no network. Call it first if you are unsure what to pass to `template_fields` or `vocabulary`.

What has already been claimed about a paper — the starting point for new work, whether that work is a replication or a fresh study. Given any published nanopub URI in a constellation, returns one entry per completed chain: the claim type, what was tested (`scope`), how (`method`), what was done differently (`deviations`), the verdict and confidence, and — the field to read most carefully — `limitations`, where the previous authors stated in their own signed words what their study did NOT cover. Use it to avoid duplicating an existing replication, to choose a CiTO relation relative to prior work (`extends` / `qualifies` / `disputes`), and to find the part of a claim still open. Cite what you find; do not re-derive it — a published chain step is a record with a URI, not a result to recompute.

Does this DOI resolve, and to what? Call it on every DOI destined for a nanopub field, `CITATION.cff`, or a CiTO citation. `resolves: false` means the DOI is not registered — do not publish it, however well-formed it looks. A well-formed DOI is not a real one, and a fabricated one is indistinguishable from a genuine one until something asks the registry. On success it returns the registered title, authors, year, container and type, so you can confirm it is the paper you mean rather than merely a paper that exists. Accepts bare (`10.…`), URL, or `doi:`-prefixed forms.

The exact form fields of one FORRT chain step, from the live template. Call this BEFORE drafting any nanopub field. A nanopub template *is* the schema for its step, so this is what makes "never invent a field name" a lookup rather than a rule you have to remember: it returns the real field ids, prompts, whether each is required or repeatable, the length/format constraints (`regex`, `prefix`, `datatype` — where the Quote template's character cap actually lives), and, for choice fields, the allowed values. `step` accepts `05_outcome`, `05`, or `outcome`. Known steps: 01_quote, 01_pico, 01_pcc, 02_aida, 03_claim, 04_study, 05_outcome, 06_citation, 07_research_software, 08_synthesis. Check `source`: `live` means fetched from the nanopub network just now; `bundled-snapshot` means the network was unavailable and these are vendored values that may be stale. `driftedFromSnapshot: true` means the template was superseded upstream — the live values win, and this package needs re-vendoring.

Check `nanopubs/chain-draft.json` before handing it to the chain wizard. Run this at the end of Phase 5b, after `pixi run build-chain-draft` and BEFORE pushing the file and opening the wizard URL. `readyForWizard` is true only when nothing came back as an error. This file — not the markdown drafts — is what the wizard pre-fills each step from, and therefore what a human reviews and signs. `validate_draft` checks the authoring input; this checks the artifact. What it catches that reading the file cannot: - a **superseded `template_uri`**, which is invisible in the JSON but makes the wizard pre-fill the old form. Re-run build-chain-draft to fix; - a `prefill` key that is neither a template field nor a known platform form-field — the wizard silently drops it; - a complex field in the wrong shape: `06_citation.st02` must be `[{cites, cited}]` with at least one entry, and `04_study.disciplineSelection` is a single object, NOT an array; - a required field that is neither prefilled nor carried forward; - values violating the template's own regex (the Quote's 500-character cap lives there), an invalid vocabulary term, a malformed date, an unresolved `{{TOKEN}}`, or a DOI that does not resolve; - a `carry_forward` edge that runs backwards through the chain. Fields the wizard fills itself are exempt, not reported missing: `02_aida` has no `project`, `03_claim` no `aida`, `04_study` no `claim`, because each is carried forward from the step published before it.

Check one drafted nanopub against its template and the real world. Run this on every draft before publishing. It is the pre-flight checklist in `docs/forrt-form-fields.md`, actually executed: field ids checked against the live template, choice values against the template's own enumeration, length caps against its regex, DOIs against the registry, Wikidata QIDs against Wikidata. `publishable` is true only when there are no errors. Severities: error would publish something false, or be rejected by the form warning a human should look, but it may be intentional info checked and fine, or deliberately not checked Three placeholder conventions are distinguished, because only one is a problem: `«URI of step 05 …»` is a back-reference the chain wizard fills (info); `{{ZENODO_VERSION_DOI}}` is a release-time token the release workflow substitutes (warning — confirm the release ran); anything else still standing in for a value is an error. `step` is inferred from the filename (`05_outcome.md`); pass it explicitly for a file named otherwise. A draft whose required fields are nearly all empty is reported once as an unfilled skeleton rather than field by field.

Check every draft in a `nanopubs/drafts/` directory at once. The whole-chain pre-flight: run it before starting Phase 5b, and again before announcing. Returns per-draft results plus totals, with `publishable` true only when no draft has an error. Note what it cannot see: values a draft puts in prose or a markdown table rather than behind a `<!-- field: … -->` marker are reported as `coverage` warnings, not as missing. The CiTO step's citation list is the known case.

Check an RO-Crate before it is released or deposited (e.g. in ROHub). `path` is the crate's directory (usually the repository root) or its `ro-crate-metadata.json`. Run it after `pixi run -e rocrate build-rocrate` and before `deposit-rohub`; it is the same check the template's CI runs. Two layers: - `passed`/`issues`: rocrate-validator against `profile` (default ro-crate-1.2) at `level` (REQUIRED, RECOMMENDED or OPTIONAL). Each issue names the check, its message and the offending entity — relay them verbatim. `metadata_only=True` skips the checks that the listed files exist (for a crate whose data are not checked out). The first run fetches the RO-Crate JSON-LD context (then cached); `offline=True` needs that cache. - `fdo_checks`/`fdo_ready`: what a replication crate needs beyond the specification to work as a FAIR Digital Object — a persistent identifier, a licence, the workflow as mainEntity, a community FAIR Implementation Profile in conformsTo, the FORRT chain in subjectOf, and no ro-crate-metadata.json among its parts (ROHub reserves that name). Advisory: they do not change `passed`; each failing check says how to fix it. Never hand-edit ro-crate-metadata.json to make it pass: it is generated by scripts/build_rocrate.py — fix the source (CITATION.cff, the ledger, rocrate.json) and rebuild.

Verify a published FORRT chain. Run this before announcing it anywhere. Point it at a `nanopubs/PUBLISHED.md` ledger (or the directory holding one). Read-only: it never edits, retracts or supersedes — a failing row is for a human to act on. `green` is true only when nothing failed. What it checks: - every required step (01-06) has a URI in the ledger; - every URI is really published — present in the constellation, or, for the upstream anchors the walk does not reach, served as RDF by the `w3id.org/np/` resolver; - the Outcome's repository resolves (a Zenodo **version** DOI is the expected value — it pins the archived state, where a GitHub URL would be a moving target); - every DOI the chain cites resolves; - **the CiTO relation agrees with the Outcome's verdict** — Validated implies confirms, PartiallySupported implies qualifies, Contradicted implies disputes. A mismatch means the Outcome and the Citation disagree about what the replication found, which is the failure most worth catching before anyone reads the chain. Only the ledger's own Outcome and CiTO are judged: the relation→target pairs come from the step-06 TriG, and the relation that counts is the one on the paper the Quote quotes. Other chains the walk reached (several chains often cite the same paper) are listed as `neighbours`, never judged. A step reported as "not enumerated by the walk but its TriG resolves" is fine, not a warning: the constellation legitimately stops short of Quote, AIDA and Claim. `mode` — `auto` (default), `replication`, `reproduction` or `new_research`. It changes only what is REQUIRED. Research that starts from scratch has no existing work to cite, so no CiTO step and no cited DOI are expected, and `auto` infers that from the absence of a published step 06. Everything else is checked identically in all three. Reproduction and replication verify the same way; pass one explicitly only to make the wording match your study…

Prove that a candidate quotation is really in a source PDF, before it is published as verbatim. Call this on EVERY quotation destined for a Quote-with-comment nanopub. You choose which sentence carries the paper's claim — that is judgement. This decides whether the sentence is admissible, and that is not: it is a string search, and anyone can re-run it and get the same answer. Returns a graded verdict with the page, character offsets and the file's SHA-256 as evidence: exact byte-identical to the extracted page text normalized matched after whitespace / ligature / typographic punctuation / line-break-hyphen repair extraction_tolerant additionally ignored hyphens and punctuation spacing not_found NOT in this PDF — do not publish it as a quotation A tier below `exact` is normal and not a warning about your quotation: PDF extraction inserts line breaks and drops hyphens (a real published FORRT quotation matches only at `extraction_tolerant`, because pypdf reads "35-year" as "35year"). Every tier canonicalises formatting only — never words, digits or order — so an altered number still fails at every tier. Read `matched_text` before publishing. On `not_found`, `closest.text_in_pdf` shows what the paper says where it nearly matched. A one-digit change scores ~0.91 similarity and is still `not_found`: high similarity is not a pass.

The allowed values of a FORRT controlled vocabulary, from its template. Use it whenever a draft needs a claim type, a study type, a validation status, a confidence level, or a CiTO relation. Every term comes from the real restricted-choice field on the real template (or the value-list nanopub it points at), so a value returned here is one the form will actually accept — and nothing else is. Names: claim_type, study_type, validation_status, confidence_level, cito_relation, pico_question_type. Three worth reading before you draft: - `study_type` carries the Reproduction vs Replication distinction (same data + same methods, vs different data and/or methods, or both). - `validation_status` is the Outcome verdict. Pick it from the evidence, not from what would be a nicer result; a contradicted replication is publishable and an overclaimed one is not. - `pico_question_type` is PICO-only, deliberately. Step 01 has three alternative anchors and they are not variants of one form: a PCC question has NO type field, and a Quote-with-comment has neither a type nor a label. Call `template_fields` on the anchor you are actually using (01_quote, 01_pico or 01_pcc) rather than assuming they match.

Find real Wikidata items for a term, and type-check them. Call it for every Wikidata topic or keyword destined for a nanopub field. It returns candidates with their descriptions and real P31/P279 types; it deliberately does NOT choose one, because picking the right sense of an ambiguous label is a judgement. What it guarantees is that the QID you publish exists and is what you say it is. Pass `expected_type` as a QID (e.g. `Q16521` taxon, `Q11862829` academic discipline) and each candidate is marked `typeMatches` from its actual statements. Candidates are annotated, never filtered — a near miss is often the informative result. Searching "Bombus" with `Q16521`, for instance, returns the insect genus as a match and the album of the same name as not. A zero-candidate result means leave the field empty or try another label. Never fall back to a QID from memory.