rozak-2026-neurovascular-dl — what each format carries
24 claims, 129 typed relations between them.
One source, three targets. Each row is a relation type the paper’s claim tree uses; each column is what became of it.
| Relation | In the tree | MIRA | OXA | Discourse Graphs |
|---|---|---|---|---|
scopes | 42 | cg:scopes, neutral | kept | dropped |
confirms | 17 | cg:confirms, under mira:supports | kept | kept |
tests | 13 | cg:tests, neutral | kept | kept |
validates | 11 | cg:validates, under mira:supports | kept | kept |
supports | 10 | cg:supports, under mira:supports | kept | kept |
requires | 10 | cg:requires, neutral | kept | dropped |
enables-method | 9 | cg:enables-method, neutral | kept | dropped |
dissociates-with | 4 | cg:dissociates-with, neutral | kept | dropped |
entails | 4 | cg:entails, neutral | kept | dropped |
extends | 4 | cg:extends, under mira:supports | kept | kept |
derived-from | 4 | — | kept | dropped |
rules-out | 1 | cg:rules-out, under mira:opposes | kept | kept |
What MIRA has no predicate for — and what happens instead
82 of 129 relations (64%) are neither support nor opposition. They are not dropped and not flattened. MIRA imports a Discourse Graphs base schema in which relations are definable, and its AbstractRelationDef is a neutral root — it carries no supporting or opposing commitment — so each is declared in the document with a domain, a range and a description, and the edges are typed by that declaration.
cg:scopes(42) — a scope constraint governs another claim’s validitycg:requires(10) — a claim depends on another holdingcg:enables-method(9) — a result makes a downstream method possiblecg:dissociates-with(4) — the source and target jointly establish a dissociation — two claims whose difference across a condition, region, population or measure is itself the finding, neither bearing on the other’s truth (symmetric)cg:entails(4) — a hypothesis entails its prediction — the deductive stepcg:derived-from(4) — a prediction derived from its hypothesis (inverse of entails)
Declaring them under mira:supports would have been worse than dropping them: it would assert that a boundary condition is evidence for the claim it limits, which reverses the meaning.
What a reader who knows only core MIRA sees
Every relation keeps its own type — nothing is flattened into supports. 43 of the 125 edges are declared under mira:supports or mira:opposes, so a reader that follows only those two still gets their direction; the reason the edge was drawn is in the declaration rather than lost.
scopes(42) — neutralconfirms(17) — undermira:supportstests(13) — neutralvalidates(11) — undermira:supportssupports(10) — undermira:supportsrequires(10) — neutralenables-method(9) — neutraldissociates-with(4) — neutralentails(4) — neutralextends(4) — undermira:supportsrules-out(1) — undermira:opposes
What MIRA genuinely cannot carry
4 derived-from relations are not emitted as edges. This is not loss: derived-from is declared owl:inverseOf entails, and MIRA never materialises the reverse direction — its own 942-node demo graph emits no inverse edges either. A reader recovers each one from the forward edge and the declaration.
Beyond those, nothing. Every relation in this paper reaches the export, either as an edge or as the declared inverse of one.
What no format carries
Verification — that a claim was checked, by what code, against what deposited data, with what result beside the published value. None of the three has a node for it.
This paper’s records: 16 unattempted, 3 verified.
Generated by scripts/formats_report.py from the files in exports/, not from the converters’ mapping tables — a table says what a converter intends, the export says what it did.