Research Graph

What this graph is

The Panta Rhei Research Program publishes alongside the formal machinery used to check it. The Research Graph is the layer that connects every monograph, paper, note, dossier, person, repository, and dataset to the persistent identifiers that describe them — DOIs, ORCIDs, OSF nodes, GitHub repositories, and Wikidata Q-items where they exist.

The graph has three public surfaces:

1. Machine-readable metadata — JSON-LD on every page, emitted according to the page’s type (ScholarlyArticle on Hinge Papers, Book on Monographs, Person on Founders, CollectionPage on this page).
2. Human-visible identifiers — right-rail identifier boxes on publication, person, program, and software pages.
3. This page — the central overview of every entity in the graph and the authority layers used to describe it.

Authority layers used

External authority registries used (or deprecated) by the program are listed in the Authority layers table below. The doctrine guiding which registries get used is from IA §10.4: Wikidata is an authority layer, not a navigation menu. The website remains the Observatory layer; the local research graph remains the control layer; Wikidata Q-items are public authority nodes used where they are appropriate, notable, referenced, and stable.

For ordinary website pages — Construction Spine steps, internal registry items, FAQ, About this Site, Colophon, UI surfaces — local IDs are preferred and no external Q-item is sought.

Local Panta Rhei IDs

Every entity in the graph carries a stable local identifier in the namespace prrp: (Panta Rhei Research Program). The pattern, per IA §10.5, is:

prrp:program:panta-rhei
prrp:person:thorsten-fuchs
prrp:person:anna-sophie-fuchs
prrp:publication:book-i
prrp:publication:paper-hyperfactorization-theorem
prrp:publication:note-semantic-space-has-a-shape
prrp:publication:dossier-construction-spine
prrp:software:taulib
prrp:website:observatory
prrp:registry:item:...
prrp:page:...

Local IDs are stable across renames, redirects, and class migrations (W7 will migrate publication classes; the local IDs stay).

How identifiers appear on pages

On a publication page (Monograph, Hinge Paper, Research Note, Dossier), the right rail carries an identifier box listing every persistent identifier the entity has: DOI, ORCID(s) of the authors, OSF node where applicable, GitHub repository where applicable, Wikidata Q-item where minted. The boxes are uniform — the same box on every publication page, the same order, the same icon set.

W6b is the wave that ships these per-page identifier boxes. This page (W6a) is the central authority layer; W6b makes that layer visible on every entity page.

JSON-LD and structured metadata

Every page emits JSON-LD structured data per the page-type registry (_data/page_types.yml, shipped in W1). The registry maps each page type to a Schema.org type:

The JSON-LD pipeline lives in _includes/seo-jsonld.html. Author Persons (both founders, both with ORCIDs) and the publisher Organization (the program) are emitted as nested objects on every page that has them.

SPARQL examples

Once the program’s entities have Wikidata Q-items, the graph becomes queryable via SPARQL. A representative query (illustrative — Q-items will be added as they are minted):

# Find all publications authored by Thorsten Fuchs that have a DOI
SELECT ?work ?workLabel ?doi WHERE {
  ?work wdt:P50 wd:Qxxxxxxxx ;       # author: Thorsten Fuchs (Q-item pending)
        wdt:P356 ?doi .              # property: DOI
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}

Until Q-items are minted, the same query is answered locally from this graph’s manifest (see Manifest download below).

Manifest download

The full graph is available as a downloadable manifest in two formats:

• YAML (canonical, hand-maintained): /_data/research_graph.yml (GitHub source)
• JSON (generated, machine-friendly): /assets/research-graph.json (build-time projection)

The YAML manifest is the source of truth; the JSON projection regenerates on every site build. Both contain the same data — entities + authority_layers — and are licensed under the same CC BY 4.0 terms as the rest of the site content.

Correction policy for identifiers

If you find an incorrect identifier, an outdated DOI, a mis-attributed ORCID, or a missing reference, please open an issue on the site repository or use the Contact page. Identifier corrections are taken seriously — a wrong DOI breaks citation tooling.

When a correction lands, the canonical YAML manifest is updated in the same commit; the JSON projection regenerates on the next build; downstream JSON-LD on every affected page picks up the new value automatically.