FORRT Research

org.sciencelive4all由 sciencelive4all.org 发布v0.2.0更新于 Oct 26, 2026

Produce verifiable FORRT nanopublication chains: grounded quote checks and Science Live projections.

概览

AI 生成的概览

本地 MCP 服务器,帮助助手起草、校验并核实 FORRT 纳米出版物链,用于重复研究与复现研究。

可以做什么
  • 读取已发布链:紧凑的 constellation 投影、用于调试的原始图,以及汇总既有链主张的 prior_work。
  • 查询模式:各链步骤的模板字段、受控词表(主张类型、研究类型、验证状态、置信度、CiTO 关系、问题类型)以及支持的 schema 列表。
  • 核对真实数据:在源 PDF 中验证引文、解析 DOI、查找并类型检查 Wikidata 条目。
  • 校验草稿:单条纳米出版物草稿、整个草稿目录、供向导使用的 chain-draft 文件,以及入库前的 RO-Crate。
  • 依据台账核实已发布链,并生成把 CiTO 引用镜像到 Wikidata 的 QuickStatements 批次。
适用场景
适合正在产出 FORRT 纳米出版物链(复现、重复或从零开始的研究)的研究者与助手:在签署前核对字段名、词表术语、引文、DOI 与 QID,并在发布后核实整条链。它不检索文献,也不为重复研究目标排序。
运行要求
以 Python 包形式在本地通过 stdio 运行(pipx install forrt-research-mcp)。需要访问 Science Live API 的网络,基址由 SCIENCELIVE_API_BASE 设置(默认生产环境)。SCIENCELIVE_API_KEY 可选,因为 constellation 端点是公开读取。引文核对需要本地 PDF 文件;首次 RO-Crate 校验会下载并缓存 JSON-LD 上下文。
安装前请注意
对已发布内容只读:verify_chain 从不编辑、撤回或取代,cito_to_wikidata 从不编辑 Wikidata,只返回批次供人工用自己的账号审阅并提交。草稿与链校验仅报告问题。引文核对会读取本地 PDF 并把引文文本发送到 API;constellation 与 prior_work 调用会把纳米出版物 URI 发送到 Science Live 端点。若提供 SCIENCELIVE_API_KEY,它属于机密。

安装

在 SourceWeft 中

  1. 打开 控制台中的 FORRT Research,将其添加到工作区。
  2. 为需要使用其工具的对话启用该服务。

Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。

其他 MCP 客户端

参照 仓库 中的启动说明。

README

forrt-research-mcp

[DOI] [PyPI]

An MCP server for producing verifiable FORRT nanopublication chains — the tools a researcher needs while doing the work, not while looking for it. It serves all three shapes of study on the same rails: reproduction, replication, and research that starts from scratch.

It is the third of three servers that compose:

ServerQuestion it answers
OpenAIRE MCPWhat is in the literature?
replication-radarWhat is worth replicating, and has it been done?
forrt-research-mcpHow do I produce a chain that is correct and verifiable?

Built for the workflow in forrt-replication-template, but it needs nothing from that repo — any agent can call it.

Scope: reproduction, replication, and research from scratch

All three work here, and they use the same chain:

anchor → AIDA → Claim → Study → Outcome → CiTO

Step 01 is one of three anchors, and they are not variants of one form. Which anchor fits is independent of whether the study is a reproduction, a replication or original research:

AnchorRequired fieldsNotes
01_quote Quote-with-commentpaper, quotation, commentno type, no label. quotation is capped at 500 characters and comment at 800 — in the template's own regex, not in prose
01_pico PICO questionlabel, description, type, + P/I/C/O descriptionsthe only anchor with a question-type vocabulary (5 terms)
01_pcc PCC questionlabel, description, + P/C/C descriptionsno type field at all

The three share no field ids whatsoever, so call template_fields on the anchor you are actually using rather than assuming they match. The pico_question_type vocabulary is named for PICO deliberately: a PCC question has no type to look up.

verify_quote applies to the Quote anchor only — and that is the one anchor with a dedicated tool, because a quotation is the one field whose correctness can be proved rather than reviewed.

constellation and prior_work surface a question anchor with its framework, label, full question text and its framework's components — PICO's population / intervention / comparator / outcome, PCC's population / concept / context. Question nodes keep all of that in a question object and leave their top-level label empty, so anything reading them like a quote returns nothing. Tested against two real published question nanopubs.

For a study starting from scratch, the Claim is your own hypothesis, derived from your own question or from the work you are building on. The FORRT Claim template's source is optional, so it needs no external paper — and the Claim-before-Study order then reads as pre-registration, not as a mismatch. verify_chain takes a mode (auto / replication / reproduction / new_research) that changes only what is required: from-scratch research has no existing work to cite, so no CiTO step and no cited DOI are expected.

The one place the templates still assume an original is the study_type vocabulary on 04_study, whose three terms are all replication-flavoured (Replication Study, Reproduction Study, or both). There is no term for an original study testing its own claim. Three field prompts read oddly too — scope and methodology say "is reproduced/replicated", and the Outcome's conclusion says "about the original claim" — but they are only wording; validationStatus (validated / partially supported / contradicted / inconclusive / not tested) describes testing your own hypothesis perfectly well.

So closing the gap is plausibly one added vocabulary term and three reworded prompts, not a new template family. When that lands, this server picks it up with no code change: template_fields and vocabulary fetch live, and driftedFromSnapshot flags the supersession so the vendored copy gets re-cut.

A note on using "Reproduction Study" for from-scratch work. It is a reasonable workaround while the vocabulary lacks a better term, but the template means the replication-science sense — "direct reproduction: same methodology, same tools", i.e. re-running someone else's analysis — not the RSE sense of "my work is reproducible". Downstream consumers read it the first way: replication-radar's verdict overlay and verified_claims will present the study as verification of an existing claim.

Why a server and not a prompt

Two jobs here look like reasoning but are not, and doing them in an agent loop makes them unreproducible and expensive:

1. Reading a published chain. /np/constellation walks the FORRT citation graph bidirectionally and returns everything it reaches. For a single marine-heatwave chain that is 330 KB, 98 nodes and 1012 edges — of which 64 nodes are AIDA statements belonging to entirely different studies. Handing that to an agent burns its context and invites it to reason over another paper's claims. constellation returns the same chain in ~16 KB (4.7 %).

2. Checking a quotation is real. A FORRT Quote nanopub must be verbatim. That is a string search, not a judgement — so it should be a tool that cannot be talked out of its answer, and that anyone can re-run to get the same result.

What it does not do

It does not search papers (that is the OpenAIRE MCP), rank replication targets (that is replication-radar), or write nanopub content. It also does not extract claims: choosing which sentence carries a paper's headline claim is a judgement, and wrapping a judgement in a tool would not make it reproducible — a model behind a tool boundary is exactly as non-deterministic as one in the agent loop. The division this server is built around:

The model proposesThis server disposes
Which sentence is the claimWhether that sentence is in the PDF, where, under what SHA-256
How to phrase the AIDAWhat fields the template actually has, and their caps
Which claim type or CiTO relation appliesWhich values the form will actually accept
Which Wikidata topic is meantWhether that QID exists and is of the right type
Which paper to citeWhether that DOI resolves, and to what
Whether to extend or dispute prior workWhat prior chains already claimed

Install

bash
pipx install forrt-research-mcpclaude mcp add forrt-research -s user -- forrt-research-mcp

User-scoped (-s user) so it is available in every session and folder, and does not clash with a per-repo config. For other agents, the stdio command is forrt-research-mcp.

bash
# optionalexport SCIENCELIVE_API_BASE="https://api.sciencelive4all.org"  # default (production)export SCIENCELIVE_API_KEY="sl_…"   # /np/constellation is a public read

The default base is production. To test against the dev deployment, set SCIENCELIVE_API_BASE=https://api-dev.sciencelive4all.org. A constellation that nobody has requested recently can take ~60 s to build; after that it is cached for 4 h and returns in well under a second.

Tools

verify_quote(pdf_path, quotation)

Proves a candidate quotation is in a source PDF before it is published as verbatim. Returns a graded verdict with page, character offsets and the file's SHA-256:

VerdictMeaning
exactbyte-identical to the extracted page text
normalizedmatched after whitespace / ligature / typographic punctuation / line-break-hyphen repair
extraction_tolerantadditionally ignored hyphens and punctuation spacing
whitespace_insensitiveadditionally deleted every space — for text layers that break words apart
not_foundnot in this PDF — do not publish it

Every tier canonicalises formatting only — never words, digits or order. A quotation with one digit changed scores ~0.91 similarity against the source and is still not_found; on a miss, closest.text_in_pdf shows what the paper actually says there.

A tier below exact is normal. PDF extraction inserts line breaks, loses hyphens, and sometimes breaks words apart entirely:

  • the quotation published in the real marine-heatwave chain matches only at extraction_tolerant, because pypdf reads the paper's 35-year as 35year and (p < as ( p <;
  • Hundhausen et al. 2024 renders its own abstract as CP en semble, largest c hanges, prec ipitation — spaces inside words, which no punctuation rule can undo. That needs whitespace_insensitive, which deletes every space and therefore does not verify word boundaries; it declines to run below 40 characters, where two short texts could collide.

"Character-for-character" is not literally achievable against extracted PDF text, which is why the result is graded rather than boolean.

Words split across a line break (convection-\npermitting) are rejoined at the normalized tier. A suspended hyphen (15- and 30-minute) is deliberately NOT rejoined — the rule requires a line break, because joining those would corrupt the text.

constellation(uri, depth=5, max_nodes=80)

The FORRT chain(s) reachable from a published nanopub URI, projected to agent-size: chains with their steps in chain order, the apex CiTO, any Research Synthesis, and the Quote/Question anchors attributable to this paper.

Read citedPaper, not the API's top-level paperDoi — see Upstream quirks below.

stepsPresent legitimately omits steps: a CiTO at the apex of a constellation is hoisted out of its chain, and Quote/AIDA anchors are often not enumerated. Missing does not mean unpublished.

prior_work(uri)

What has already been claimed about a paper — the starting point for new work, replication or otherwise. Per completed chain: claim type, scope, method, deviations, verdict, confidence, repository, and limitations.

limitations is the field to read most carefully. It is where previous authors stated, in signed and immutable words, what their study did not cover — which is often exactly where the next study begins. In the marine-heatwave chain it records that the paper's better-known 54 % headline describes a different analysis over a different period and was not tested.

constellation_raw(uri, …)

The unprojected response, for debugging the graph or an upstream data problem. Large; prefer constellation.

template_fields(step, live=True) · vocabulary(name, live=True) · list_schemas()

A nanopub template is the schema for its chain step, so these turn "never invent a field name" and "never invent a claim type" from rules an agent has to remember into a lookup that can only return real values.

template_fields returns the real field ids, prompts, required/repeatable flags, and the regex / prefix / datatype constraints — which is where the Quote template's character cap actually lives, rather than in a hand-written doc that drifts. step accepts 05_outcome, 05, or outcome.

vocabulary returns the allowed values of a controlled vocabulary, taken from the real restricted-choice field:

NameFromTerms
claim_type03_claim.forrtType7
study_type04_study.type3 — the Reproduction vs Replication distinction
validation_status05_outcome.validationStatus5
confidence_level05_outcome.confidenceLevel5
cito_relation06_citation.cites43, via a separate value-list nanopub
question_type01_pico.type5

Both fetch live by default and fall back to a bundled snapshot when the network is unavailable — always reporting which was used, and setting driftedFromSnapshot when the upstream template has been superseded. A drifted result means the live values win and this package needs re-vendoring; it is a loud, reviewable event rather than slow silent divergence.

cito_relation is the one vocabulary that cannot be resolved offline: it lives in a separate value-list nanopub. Offline it returns source: "unavailable-offline" with a warning rather than an empty list, because an empty list reads as "no valid values."

verify_chain(published_path, repo_url="")

The final check before announcing a chain. Point it at a nanopubs/PUBLISHED.md ledger; green is true only when nothing failed. Read-only — it never edits, retracts or supersedes.

CheckWhat it means
ledgerevery required step (01–06) has a URI
reachableevery URI is really published
repositorythe Outcome's archived version DOI resolves
cited-doievery DOI the chain cites resolves
verdict-relationthe CiTO relation agrees with the Outcome's verdict
cito-citing-workthe ledger's CiTO cites from the ledger's Outcome
neighboursother chains the walk reached — context only, never judged

That last one is the failure most worth catching: Validated implies confirms, PartiallySupported implies qualifies, Contradicted implies disputes. A mismatch means the Outcome and the Citation disagree about what the replication actually found — a chain that cites confirms for a paper it contradicted is worse than no chain at all.

Only the ledger's own Outcome and CiTO are judged. Published work is a network: chains citing the same paper turn up in the same walk, and one CiTO cites several works (confirms the paper, usesMethodIn a method, citesAsDataSource data). So the relation→target pairs are read from the ledger's step-06 TriG, and the verdict is checked against the relation on the paper the Quote (step 01) quotes. Other chains are listed as neighbours. If the check cannot be made, it says so with a warn rather than skipping it.

A constellation alone cannot verify a chain, which is why this does not try. On both real chains the walk stops short of the upstream anchors, so anything it does not enumerate is checked by fetching its TriG from the bare w3id.org/np/ resolver — the /sciencelive/np/ form serves an HTML viewer that answers 200 and would pass a status-only check while serving no nanopub. A row reading "not enumerated by the walk but its TriG resolves" is a pass, not a warning.

The Outcome's repository is expected to be a Zenodo version DOI, not a GitHub URL: a version DOI pins the archived state the outcome was computed from, where github.com/ORG/REPO is a moving target. Both are accepted; a DOI is checked by resolving it, a URL by comparing it to repo_url.

Both published chains verify green, matching the hand-run verification recorded in marine-heatwave's ledger.

validate_chain_draft(path)

Checks nanopubs/chain-draft.json — the artifact that actually gets published — before it is handed to the Science Live chain wizard. Run it at the end of Phase 5b, after pixi run build-chain-draft and before pushing the file and opening the wizard URL.

The markdown drafts are the authoring format; build_chain_draft.py turns them plus CITATION.cff and the templates into this file, which the wizard pre-fills each step from and a human reviews and signs. validate_draft checks the input; this checks the artifact.

What it catches that reading the file cannot:

  • a superseded template_uri — invisible in the JSON, but it makes the wizard pre-fill the old form;
  • a prefill key that is neither a template field nor a known platform form-field, which the wizard silently drops;
  • 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 (the one asymmetry in the contract);
  • a required field neither prefilled nor carried forward;
  • a value over the template's own cap, an invalid vocabulary term, a malformed date, an unresolved {{TOKEN}}, or a DOI that does not resolve;
  • a carry_forward edge running backwards through the chain.

Fields the wizard fills itself are exempt rather than reported missing: 02_aida has no project, 03_claim no aida, 04_study no claim.

Both of this project's real chain drafts validate clean, and 13 deliberate mutations of one are each caught.

validate_draft(path) · validate_drafts(directory)

The pre-flight checklist in docs/forrt-form-fields.md, actually executed. One call checks a drafted nanopub end to end: field ids against the live template, choice values against its enumeration, length caps against its regex, DOIs against the registry, QIDs against Wikidata. publishable is true only when nothing came back as an error.

This is the composition the other tools exist for — individually they answer "is this value real?", together they answer "is this draft publishable, and if not, exactly where is it wrong?"

Three placeholder conventions, and only one is a problem. Getting this wrong made the checker useless on real drafts, so each is handled explicitly:

In a draftMeaningSeverity
«URI of step 05 …»back-reference; the chain wizard fills it from the published stepinfo
{{ZENODO_VERSION_DOI}}release-time token; the release workflow substitutes itwarning
anything else standing in for a valuegenuinely unfillederror

A draft whose required fields are nearly all empty is reported once as an unfilled skeleton — "it has not been drafted yet" — rather than as a wall of per-field errors.

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, never as missing. The CiTO step's citation list is the known case: cites and cited live in a table in both repos checked.

Validated against two real published chains (marine-heatwave and Sado estuary): all six published steps pass in both, with the only remaining flags being an unpublished step 07 and the release tokens above.

resolve_doi(doi)

Does this DOI resolve, and to what? resolves: false means it is not registered — a well-formed DOI is not a real one, and a fabricated one is indistinguishable from a genuine one until something asks the registry. Returns the registered title, authors, year and container so you can confirm it is the paper you meant, not merely a paper that exists. Accepts bare, URL, and doi: forms. A 5xx is reported as transient rather than as a bad DOI.

wikidata_lookup(query, expected_type="", limit=5)

Real Wikidata candidates for a term, with their actual P31/P279 types. Pass expected_type as a QID and each candidate is marked typeMatches.

Checked against the ten Wikidata terms in this project's published chains — the QIDs build_chain_draft.py resolved and signed — it returns the published QID at rank 1 for all ten (marine heatwave, sea surface temperature, climate change, time series analysis, chlorophyll a, remote sensing, estuary, Sentinel-2, water quality, atmospheric correction).

It deliberately does not choose — picking the right sense of an ambiguous label is a judgement. Searching Bombus with Q16521 (taxon) returns the insect genus as a match and the album of the same name as not, which is exactly the failure worth catching before a QID gets signed into a nanopub. Candidates are annotated, never filtered: a near miss is often the informative result. Zero candidates means leave the field empty — never fall back to a QID from memory.

cito_to_wikidata(cito_uris=None, published_path="")

Makes a published typed citation ("this replication confirms that paper") visible in Wikidata and Scholia. Wikidata already models CiTO: "cites work" (P2860) with the qualifier "has goal" (P3712) set to one of 48 citation-intent items, each of which has an exact match (P2888) to its CiTO URI — so the mapping is read from Wikidata at run time, never copied here (a copy would go stale without saying so; if Wikidata cannot be reached the tool says so). The statement is referenced with "nanopublication identifier" (P12545) in the https://w3id.org/np/<id> form, which Scholia counts as an annotation defined in a nanopublication.

It never edits Wikidata. It returns a QuickStatements batch and a per-work report; a person reviews them and submits the batch at https://quickstatements.toolforge.org with their own account. Also available as a command:

bash
forrt-wikidata-cito --published nanopubs/PUBLISHED.md --out wikidata

What it guarantees:

  • items are looked up by DOI (and authors by ORCID) and created only when missing;
  • one item per work: Zenodo versions are grouped under their concept DOI, so two versions of one deposit do not become two replications;
  • idempotent: citations already in Wikidata are skipped; a citation to a work created by the same batch is listed as pending and added on the next run;
  • every fact on a new item (type, title, DOI, date, authors) cites the Zenodo record it was read from: Wikidata is a secondary knowledge base, and the citation itself cites its nanopublication;
  • the description is short prose ("reproduction or replication study by ()"), keeping identifiers in statements where they belong.

Items are created from the Zenodo record's title: fix a repository-slug title on Zenodo before submitting.

validate_rocrate(path, profile="ro-crate-1.2", level="REQUIRED", metadata_only=False, offline=False)

Checks a replication's ro-crate-metadata.json before it is released or deposited in ROHub, with the same validator the template's CI runs (rocrate-validator). path is the crate's directory or its metadata file.

  • passed / issues — the specification check against profile at level (REQUIRED, RECOMMENDED, OPTIONAL); each issue names the check, its message and the offending entity. metadata_only=True skips the checks that listed files exist, for a crate whose data are not checked out. The first run fetches the RO-Crate JSON-LD context and caches it; offline=True relies on that cache.
  • fdo_checks / fdo_ready — what a 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 never change passed — and each failing check says how to fix it.

The crate is generated by the template's scripts/build_rocrate.py: fix its sources (CITATION.cff, nanopubs/PUBLISHED.md, rocrate.json) and rebuild, never hand-edit the file to make it pass.

Upstream quirks this handles

Found by probing live data rather than reading the API contract, and each one is pinned by a test against a real recorded payload (two constellations, from unrelated studies):

  1. Cloudflare rejects urllib's default User-Agent. The API runs on Cloudflare Workers, whose bot protection answers Python-urllib/3.x with HTTP 403 — same URI, same key, 200 under any normal agent. Every request this client makes sets an explicit User-Agent. Do the same in your own client; no hermetic test can catch it.
  2. paperDoi can name the wrong paper. It is chosen by frequency across the whole walk, so a neighbouring study's Quote nanopubs can outvote the chain's own citation. On the marine-heatwave chain it reports the LifeWatch ERIC paper (4 unrelated quotes) instead of Oliver et al. 2018, which the chain's CiTO actually cites — and it names the same wrong paper from the unrelated Sado-estuary entry point, so this is systemic, not one bad record. citedPaper derives the paper from the CiTO and sets disagreesWithReported when the two differ.
  3. The walk stops short, and missing does not mean unpublished. Two real chains enumerated [Claim, Study, Outcome] and [Study, Outcome, CiTO], while the Quote, AIDA and Claim nanopubs listed in those repos' PUBLISHED.md were published and merely unreachable. stepsNotEnumerated reports the gap. A constellation alone cannot verify a complete chain — fetch those URIs' TriG directly.
  4. quote.quotedText comes back empty on nanopubs using the current quote template. The text survives in label and in two untagged excerpts — the quotation and the annotator's comment, in no guaranteed order. We match them against the label stem rather than assuming a position, and report the recovery in text_source.
  5. The apex CiTO is hoisted out of chains[].steps[] to top level.
  6. The /sciencelive/np/ URI form serves an HTML viewer that answers 200, so a status-only reachability check passes even when no nanopub is served. We normalise to the bare w3id.org/np/ resolver and assert the body is RDF.

Checking against every real artefact

The test suite is hermetic: it pins behaviour against recorded data, which prevents regressions but cannot discover a wrong premise. Every serious bug in this server was a wrong premise, and each surfaced only when the tools met real data they had not seen. So "have we tested comprehensively?" is not a judgement call here — it is a computation with a visible denominator:

bash
python scripts/check_corpus.py /path/to/your/study/repos

It discovers every repository with a nanopubs/ directory, runs the applicable tools against each artefact, and prints what passed out of what was found. Findings are not automatically failures — an empty required field is a true statement about a draft. What it exits non-zero for is a crash or a parse failure, because those mean a tool could not read a real artefact at all.

The denominator is only as good as what is on disk. A chain that is not under that root is not covered, and a green run does not say otherwise.

Development

bash
pip install -e '.[dev]'pytest

All 287 tests are hermetic and need no network, no API key, and no live service: the constellation fixtures are real recorded /np/constellation responses, quote tests build minimal PDFs in-process that reproduce the extraction artifacts deliberately, and the template/DOI/Wikidata tests stub HTTP with recorded payloads. The suite stays green through an upstream outage.

The bundled template snapshot under src/forrt_research_mcp/data/ is vendored from ScienceLiveHub/forrt-replication-template, as is template_spec.py. Re-vendor when template_fields reports driftedFromSnapshot.

License

MIT — see LICENSE.

来源:README.md,提交 65b5880

工具

15

constellation

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.

输入参数uri必填depthmax_nodes

prior_work

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.

输入参数uri必填

verify_quote

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.

输入参数pdf_path必填quotation必填

constellation_raw

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.

输入参数uri必填depthmax_nodes

template_fields

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.

输入参数livestep必填

vocabulary

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.

输入参数livename必填

list_schemas

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`.

无需输入参数。

resolve_doi

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.

输入参数doi必填

wikidata_lookup

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.

输入参数limitquery必填expected_type

validate_draft

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.

输入参数livepath必填step

validate_drafts

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.

输入参数livedirectory必填

verify_chain

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 thr

输入参数moderepo_urlpublished_path必填

validate_chain_draft

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.

输入参数livepath必填

cito_to_wikidata

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.

输入参数cito_urispublished_path

validate_rocrate

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.

输入参数path必填levelofflineprofilemetadata_only

版本历史

2
  1. v0.2.0最新Oct 25, 2026
  2. v0.1.2Sep 21, 2026

评分

已满足适用检查项的 90%

该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。

  • 近 30 天内可连通25 分
  • 已声明认证方式10 分

    请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。

  • 已列出工具必需15 分
  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分