THE GOLD STANDARD OF INFORMATION · SPECIALIST STUDY
Explain an RDF conclusion without pretending every reasoner speaks the same proof language
An RDF conclusion may be reproducible under a named entailment regime while its proof trace remains processor-specific. The gold standard separates semantic entailment from explanation format, records justification graphs and rule applications, tests minimality honestly, and exports enough context for another system to verify rather than merely display the explanation.
This guide belongs to the Information subject guide, the Gold Standard of Education, and the How X Works learning library. Choose a reading route, work the examples, then use the transfer checks to test whether the method survives a changed context.
Choose a reading route
Build the foundations · chapters 1–2
Apply the core method · chapters 3–5
Test evidence and alternatives · chapters 6–7
Handle limits and disagreement · chapters 8–9
Transfer and govern · chapters 10
The whole problem at a glance
| Layer | Question | Portable evidence |
|---|---|---|
| Entailment | Does the premise support the conclusion? | Graphs, regime and result |
| Derivation | Which rule applications produced it? | Versioned rule steps |
| Justification | Which asserted statements are sufficient? | Support subgraph |
| Explanation | What should a reader see? | Selected path plus limits |
A readable explanation may omit alternatives; a proof vocabulary may encode steps without proving the source data true.
CHAPTER 1 OF 10 · Build the foundations
1. Separate entailment from proof representation
Core idea. RDF semantics defines when one graph entails another; it does not require every processor to emit the same proof object.
Method. Name premise graph, conclusion graph, dataset boundary, entailment regime, processor and completion state before serialising a trace.
Worked example. A reasoner derives Ada a Person from Ada a Teacher and Teacher subClassOf Person. The entailment can be checked even if two engines use different internal rule names.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. A valid conclusion can have many derivations, and an implementation may be sound without exposing any proof API.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 1 is complete only when the claimed result survives that review.
Misconception to avoid. The proof vocabulary is the semantics. It is only a representation of evidence about a semantic check.
Practical evidence check
- Ask a second engine to verify the conclusion from the retained premise graph.
- Return to chapter contents
CHAPTER 2 OF 10 · Build the foundations
2. Define a proof vocabulary as a versioned contract
Core idea. A proof vocabulary needs explicit classes and properties for conclusions, premises, rule applications, agents, software versions and status.
Method. Publish term IRIs, ranges, cardinality expectations, ordering rules and conformance examples; distinguish required fields from convenient annotations.
Worked example. A step links one conclusion quad to two premise quads, an RDFS rule identifier and the processor build that applied it.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. RDF alone permits open-world extension, so consumers cannot assume missing fields are errors unless a separate profile or SHACL shape says so.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 2 is complete only when the claimed result survives that review.
Misconception to avoid. Using the same namespace guarantees interoperability. Shared IRIs help only when profiles and meanings also align.
Practical evidence check
- Round-trip a proof through two serializers and validate it against the published profile.
- Return to chapter contents
CHAPTER 3 OF 10 · Apply the core method
3. Model justification graphs without erasing dataset boundaries
Core idea. A justification graph is a sufficient support set for one conclusion under a named regime, not merely every nearby triple.
Method. Retain default versus named graph position, blank-node scope, asserted-versus-derived status and vocabulary version for every support item.
Worked example. A type conclusion depends on one assertion in graph G and one schema edge in graph S; flattening them into an unnamed graph loses source boundaries.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. Quoted or copied triples may no longer carry the authority, licence or temporal scope of their original graph.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 3 is complete only when the claimed result survives that review.
Misconception to avoid. A set of triples is not automatically a faithful dataset slice when graph names and provenance affect use.
Practical evidence check
- Reconstruct the original quad positions from the exported justification.
- Return to chapter contents
CHAPTER 4 OF 10 · Apply the core method
4. Distinguish minimal, minimum and preferred explanations
Core idea. Subset-minimal means no retained support can be deleted while preserving the conclusion; minimum asks for the smallest support by a chosen cost; preferred adds a ranking policy.
Method. State the minimality notion, cost function, search limit and tie handling. Test each claimed subset-minimal justification by deletion.
Worked example. Two independent subclass paths support Ada a Person. Each path can be subset-minimal; the engine prefers the one with fewer schema edges without claiming uniqueness.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. Finding all minimal justifications can be computationally expensive, and a bounded search may miss alternatives.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 4 is complete only when the claimed result survives that review.
Misconception to avoid. Minimal means uniquely best. Several incomparable minimal explanations can coexist.
Practical evidence check
- Delete every support item in turn and report whether the conclusion survives.
- Return to chapter contents
CHAPTER 5 OF 10 · Apply the core method
5. Represent rule applications and intermediate conclusions
Core idea. Stepwise proofs can expose how a conclusion was reached, while support-only explanations can be smaller and more implementation-neutral.
Method. Use stable rule-family identifiers where possible, keep intermediate terms in scope, and mark optimised or macro steps that compress several inferences.
Worked example. One engine records two subclass steps; another uses a precomputed transitive edge. Both justify the same conclusion but produce different proof trees.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. Internal optimisations may not map cleanly to a public rule calculus; forcing detail can fabricate a trace the engine never used.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 5 is complete only when the claimed result survives that review.
Misconception to avoid. A longer proof is more trustworthy. Trust depends on checkability, sound rules and inputs, not step count.
Practical evidence check
- Verify every step locally and the final conclusion independently.
- Return to chapter contents
Worked explanation comparison
| Record | Included | What remains open |
|---|---|---|
| Conclusion | ex:Ada a ex:Person | Application meaning |
| Support graph | Ada a Teacher; Teacher subClassOf Person | Whether support is minimal |
| Rule step | RDFS subclass propagation | Processor rule identifier |
| Portable check | Re-run under named RDFS profile | Equivalent proof shape |
Another conforming reasoner may reach the same conclusion through a different derivation.
CHAPTER 6 OF 10 · Test evidence and alternatives
6. Use PROV-O for lineage without calling it a proof calculus
Core idea. PROV-O can describe entities, activities, agents and derivation, but provenance alone does not encode the logical validity of an entailment.
Method. Link proof generation to input graphs, software, time and responsible agent, while keeping rule semantics in the proof profile.
Worked example. A prov:Activity generated a justification file from dataset version 7 using reasoner build 42; the rule steps remain separate proof entities.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. A provenance link such as prov:wasDerivedFrom is intentionally broad and does not prove logical consequence.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 6 is complete only when the claimed result survives that review.
Misconception to avoid. Complete provenance proves correctness. It records lineage; correctness still requires semantic and implementation checks.
Practical evidence check
- Trace one conclusion from source graph through activity to explanation, then validate its rule steps.
- Return to chapter contents
CHAPTER 7 OF 10 · Test evidence and alternatives
7. Use SHACL reports as constraint evidence, not entailment proofs
Core idea. SHACL validation reports are RDF graphs describing constraint results. They can be provenance-linked, but they answer a validation question rather than an RDF entailment question.
Method. Record shapes graph, data graph, processor, validation options, focus nodes and result path; never merge pass/fail status into a logical proof claim.
Worked example. A SHACL result reports a missing required email while RDFS still entails the node is a Person. Both records are useful and neither replaces the other.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. A conforms=true result is scoped to the supplied shapes and data; it does not certify completeness outside them.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 7 is complete only when the claimed result survives that review.
Misconception to avoid. A validation report is a proof that the data are true. It is evidence that declared constraints were evaluated.
Practical evidence check
- Change one shape and explain why the report changes while the RDF entailment need not.
- Return to chapter contents
CHAPTER 8 OF 10 · Handle limits and disagreement
8. Negotiate explanation portability across systems
Core idea. Portable explanations need a semantic core, declared extensions and graceful handling of unknown terms.
Method. Define mandatory conclusion, support, regime and status fields; permit extension graphs; retain original records when translating; expose unsupported constructs.
Worked example. System B imports System A’s support graph and reruns the entailment, but displays its own rule trace because it cannot interpret A’s optimisation vocabulary.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. Translation can preserve conclusion verification while losing ordering, cost, confidence or presentation intent.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 8 is complete only when the claimed result survives that review.
Misconception to avoid. Portability means identical files and identical user interfaces. It more often means reproducible claims with declared loss.
Practical evidence check
- Create a capability matrix and test import, re-verification and loss reporting.
- Return to chapter contents
Explanation governance
| Risk | Signal | Response |
|---|---|---|
| Hidden premise | Unlinked source triple | Completeness audit |
| False minimality | Alternative support removed | Deletion tests |
| Vocabulary drift | Unknown proof predicates | Profile negotiation |
| Sensitive trace | Protected source exposed | Layered redaction |
Redaction must not turn a checkable explanation into a misleading one.
CHAPTER 9 OF 10 · Handle limits and disagreement
9. Protect sensitive sources and resist explanation attacks
Core idea. Proof traces can reveal protected graphs, identifiers, rule thresholds or query structure; hostile inputs can also trigger justification explosion.
Method. Apply access control at support-item level, cap search and output, sign status records, and return redacted or incomplete states explicitly.
Worked example. A public explanation names the rule family and conclusion but withholds a witness-protection source; an authorised reviewer receives the full support graph.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. Redaction may make public verification impossible. Say so instead of presenting a complete-looking trace.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 9 is complete only when the claimed result survives that review.
Misconception to avoid. More explanation is always safer. It can leak sensitive data or amplify denial-of-service costs.
Practical evidence check
- Test a symmetric graph, many alternative justifications and one protected premise.
- Return to chapter contents
CHAPTER 10 OF 10 · Transfer and govern
10. Govern explanation records through change and correction
Core idea. A proof is tied to graph versions, rule profiles and processor behaviour; later change can invalidate the conclusion or only its chosen explanation.
Method. Store dependency indexes, invalidate affected records, preserve superseded explanations, and propagate correction to downstream decisions.
Worked example. Removing one subclass edge invalidates the preferred proof, but a second path still entails the conclusion; the record changes without deleting the supported claim.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. Cached explanations can outlive source authority, and minimality may change after any premise or rule update.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 10 is complete only when the claimed result survives that review.
Misconception to avoid. A stable conclusion needs no explanation refresh. Its support, source authority or preferred path may have changed.
Practical evidence check
- Replay a correction and confirm that every dependent explanation and decision is revisited.
- Return to chapter contents
Build the specialist decision record
For “The Gold Standard of Information | RDF Proof Vocabularies, Justification Graphs, Minimal Explanations and Explanation Portability”, begin with one bounded decision rather than an abstract claim. Name the affected people, data or institutions; the time window; the authority for acting; and the conclusion the method is allowed to support.
Preserve source material before interpretation. Record definitions, exclusions, transformations and the person responsible for each judgement. A reviewer should be able to separate an observed fact from an inferred result, a policy choice and a presentation shortcut.
Work one ordinary case in full. Show the input, every material rule or calculation, the output and the action that follows. Then write what the same evidence would mean under the simplest credible alternative method.
Keep an explicit unresolved state. Missing, protected, conflicting or unevaluated information must not become zero, false, consent or absence merely because a form expects one value.
Finish the record with a claim ledger. For every sentence that could drive action, identify its supporting source, inferential step, confidence or legal status, intended reader and expiry condition. This keeps descriptive evidence, formal consequence, professional judgement and institutional authority from collapsing into one impressive-looking conclusion.
Run the boundary-case audit
Select a case near the method’s domain edge: a missing input, a disputed definition, an endpoint, a sparse group, a resource limit or a legal deadline. Boundary cases reveal the contract that routine examples can conceal.
Change one assumption at a time and retain every output. Mark what stays stable, what reverses and what becomes undefined. If several assumptions move together, report that dependence instead of attributing the change to one convenient cause.
Search deliberately for a counterexample to the strongest claim. A method that works on the published illustration can still fail under a permitted input, an alternative grouping, a changed unit or an inaccessible evidence pathway.
Translate the counterexample into plain language: who would receive a different decision, what evidence would be hidden, and which safeguard or narrower claim repairs the problem.
Include an adversarial but plausible case. Let a missing group, ambiguous identifier, extreme weight, conflicting rule or urgent deadline interact with normal system incentives. The aim is not theatrical failure; it is to learn whether ordinary pressure makes the method conceal uncertainty, shift burden or reward a misleading shortcut.
Test independent reproduction
Give a reviewer the bounded inputs, public method contract and permitted access, but not the desired answer. Ask them to reproduce the result and identify every place where judgement, local knowledge or unavailable evidence was required.
Compare the reviewer’s intermediate states, not only the final number or label. Matching outputs can hide different denominators, inference paths, missing-data treatments or authorities that will diverge on the next case.
Where reproduction fails, classify the cause: ambiguous definition, undocumented transformation, incompatible implementation, inaccessible source, calculation error or legitimate alternative interpretation. Each class needs a different remedy.
Retain the disagreement and resolution. A corrected record should show what changed, why it changed and which prior outputs or decisions must be revisited.
Run the reproduction on a changed but structurally similar case after the first discrepancy is repaired. A method is not transferable merely because its authors can explain the original example. The new case tests whether the public contract carries the reasoning or whether hidden expertise is still doing essential work.
Design correction, challenge and remedy
Assign a visible route for correcting inputs, challenging assumptions and reviewing the application of the method. Technical accuracy without a usable remedy leaves the affected person carrying an error they cannot contest.
Separate urgent live-case repair from later system learning. A current decision may need pause, reassignment, fresh evidence or a human review before the organisation finishes its longer investigation.
Protect confidential and privileged material during review, but do not use confidentiality as a reason for unrecorded authority. Layer public explanation, protected oversight and individual reasons according to lawful access.
Verify that correction reaches cached results, derived records, dashboards and future decisions. Closing a complaint is not enough if the old conclusion continues to travel.
Measure remedy from the affected person’s position. A revised database row is useful, but it is incomplete when a hearing, service allocation, published claim or downstream model still relies on the old result. Record notification, restored opportunity, compensation or procedural repair where the governing framework provides it.
Set review and retirement triggers
Review after a change in definitions, population, law, source access, measurement scale, software, vocabulary or incentives. A stable formula can become invalid when the world or the meaning of its inputs changes.
Monitor leading signals as well as final outcomes: coverage gaps, timeouts, overrides, complaints, disagreement, missingness and boundary frequency. These often reveal failure before a headline metric moves.
Predefine thresholds for recalibration, suspension and retirement. Do not force a method to answer after its assumptions fail merely because replacing it is inconvenient.
At retirement, preserve the versioned contract, evidence, known limitations and migration decision. State which historic results remain interpretable and which require warning, restatement or withdrawal.
Schedule one prospective review before confidence fades or controversy forces it. Assign named owners for evidence, implementation and rights impact, and invite at least one reviewer outside the design team. The review should be able to narrow the claim, change the method or stop use without requiring proof of catastrophic failure.
Questions readers ask
Does RDF 1.2 define one standard proof vocabulary?
- No. It defines semantic conditions; explanation formats need their own declared contracts.
What is a minimal justification?
- A sufficient support set with no removable member under a stated regime.
Can two valid proofs look different?
- Yes; optimisation and rule calculi can differ.
Is PROV-O a proof language?
- It records provenance, not logical validity by itself.
Can SHACL reports be linked to proof records?
- Yes, while preserving the difference between validation and entailment.
What makes an explanation portable?
- Checkable graphs, named semantics, declared vocabulary profiles and explicit loss.
Practise, verify and continue
Choose one consequential case. Reproduce the complete method, work one ordinary and one boundary case, test the strongest rival explanation, and state the evidence that would reverse or suspend the result. Build an evidence pack containing original inputs, definitions, calculations or rule steps, alternatives rejected, uncertainty, reviewer comments and the final action. Give the pack to a reader who did not design the method. Ask that reader to reproduce the result, identify one missing assumption and construct a case that would make the method return unresolved. Revise the public explanation only after the evidence pack and the operational process agree.
Move the method into an education or public-service setting. Keep the reasoning structure while replacing domain authority, population, privacy, evidence and correction routes. Start with a low-stakes historical example, then compare the specialist method with a transparent baseline. Check whether the same people, records and decisions remain inside scope; whether the scale or vocabulary still means the same thing; and whether a person affected by error can understand and challenge it. Pilot under human review, record reversals and burden, and stop the transfer if the formal resemblance hides a different ethical or legal problem.
Related eduKate reading
RDF 1.2 datatype entailment and implementation profiles
RDF change sets, graph diffs and auditable updates
RDF 1.2 triple terms, annotations and provenance boundaries
SHACL validation reports and constraint evidence
Authoritative sources and scope
W3C, RDF 1.2 Semantics
W3C, PROV-O: The PROV Ontology
W3C, SHACL 1.2 Core
W3C, RDF 1.2 Test Cases
This article is standards and information-governance education. RDF 1.2, SHACL 1.2 drafts and implementations can evolve. Examples are original teaching cases. A proof or justification record does not establish source truth, completeness, authority or application fitness. Declare the regime, dataset, vocabulary profile, processor, limits, redactions and correction path.