MIRA

MIRA defines fourteen classes and thirty properties. For a claim graph the load-bearing ones are the node types — Claim, Evidence, Question, Study, Protocol, SourceDocument — and three classes imported from a Discourse Graphs base schema that govern relations: AbstractRelationDef, RelationDef and RelationInstance.

Relations are reified. An edge is a node carrying source and destination, typed by a relation declaration. It is not a predicate on a claim: supports and opposes sit on an Argument mixin that neither Claim nor Evidence mixes in, and every generated node shape is sh:closed, so an inline relation is rejected.

The vocabulary is extensible. AbstractRelationDef names a relation type; RelationDef binds its domain and range. The abstract root carries no supporting or opposing commitment, which is what allows a relation that is neither — a boundary condition, a deductive step — to be declared rather than forced into supports.

Every Claim addresses a Question. A claim tree has no such node, so one is derived from each hypothesis and flagged haak:autoDerived; the gap report lists all 37 for review.

MIRA is a draft — bibo:status status:draft, no tags or releases. This corpus pins commit 483f0b21480c, vendored under vendor/ so validation is reproducible offline. Note that the JSON-LD context is served from purl.org/mira-science/mira.jsonld; the GitHub Pages copy is stale and retypes Study as Protocol.

Paper-level scope. 3 relations of 916 target the paper as a whole rather than another claim. scopes has mira:Claim as its range and MIRA has no paper-level node, so no edge is emitted and no target is invented. Each paper’s gap report names them.

Inverse relations. 48 derived-from relations are declared with owl:inverseOf and emitted in one direction only, which is MIRA’s own practice. Both directions are recoverable from the forward edge and the declaration; nothing is lost.

Verification. 197 records state which code was run, against which deposited file, at which commit, and what value came out beside the published one. MIRA has no node type for any of it — observationBase records what a claim rests on, not whether anyone recomputed it.

Stance. MIRA cannot record that a paper considered a proposition and rejected it. An alternative explanation exported as a mira:Claim therefore reads as one the paper asserts; the rules-out edge gives a reader the direction of the argument but not the paper’s position.

Both of the last two are additive — neither requires changing anything MIRA already does — and both travel in the extended export under a haak: namespace pending a decision upstream.

Against the pinned shapes, these exports produce 0 violations attributable to this encoding. The 187 that remain come from one constraint in MIRA’s generated shapes that no document can satisfy: gen-shacl renders mira:addresses and mira:sourceDocument with an sh:in list of slot names beside an sh:class and sh:nodeKind sh:BlankNodeOrIRI, so each shape requires an IRI and then requires that IRI to be one of two strings.

A four-node document using only MIRA’s own terms fails identically. It ships as docs/schema-mapping/mira-sh-in-bug.jsonld so the distinction between a schema fault and an encoding fault can be checked rather than asserted.

python3 scripts/validate_mira.py

The script reproduces the upstream fault first and refuses to classify anything if that proof stops behaving as documented, then splits every violation into upstream or ours and exits non-zero if any is ours.