Discourse Graphs

sketch

Questions, Claims, Evidence and Sources, with formal OWL semantics. We emit it for every paper and have never written the mapping down.

No mapping document · exporter at extract/scripts/export_discourse_graphs.py

The thinnest tab here. We emit Discourse Graphs JSON-LD for every paper, and the mapping that produces it has never been written down — it exists only in export_discourse_graphs.py. What follows is read off that code, which is not the same as having read the ontology and decided.

What it requires

Four node types — Question, Claim, Evidence, Source — with formal OWL semantics and a JSON-LD serialisation. It was designed for knowledge built by hand from reading, which is why a Question is central: a discourse graph starts from what somebody wanted to know.

How a claim tree maps onto it

Read from the exporter.

Our roleDG type
hypothesis, prediction, synthesis, interpretation dg:Claim
empirical, control dg:Evidence
scope, methodological dg:Evidence, qualified
literature-context dg:Source

Relations map to dg:supports and dg:opposedBy where they can; the rest carry a CiTO or claimrel: IRI as a typed annotation. Stance travels as haak:stance, in our own namespace — Discourse Graphs has no term for the posture a paper takes toward a proposition, and minting one under dg: would assert a term the ontology does not define.

Does it validate

Not attempted. The ontology has formal OWL semantics, so it could be — this is a gap in our effort rather than in the format.

What it cannot carry

Verification, as everywhere. And the Question-centred model fits a graph built by someone reading with a question in mind; a graph induced from a finished paper has to manufacture the question, which is the same objection that applies to MIRA.

What we would ask its authors