THE GOLD STANDARD OF INFORMATION · SPECIALIST STUDY
Preserve what changed, why it changed and which dataset state the change actually reached
An RDF graph after an update may look correct while hiding which triples were removed, which blank nodes were addressed, which preconditions were assumed and who authorised the change. A reliable update path separates intent, patch, execution, resulting state and provenance so another reader can inspect the transition without treating a final snapshot as the whole story.
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 | Evidence |
|---|---|---|
| Before state | Which exact graph or dataset version was targeted? | Identifier, snapshot and digest |
| Change intent | What was meant to be added, removed or transformed? | Reviewed request and rationale |
| Patch execution | Which operations ran under which preconditions? | Patch, transaction and response record |
| After state | Did the intended state result without unintended change? | New snapshot, diff and validation |
A patch that applied successfully can still encode the wrong intent. Transport, syntax, state transition and policy approval need separate checks.
CHAPTER 1 OF 10 · Build the foundations
1. Define the exact update object
Core idea. An update can target one RDF graph, several named graphs or an entire graph store. The boundary determines which triples, graph names and invariants belong to the transition. The important discipline is to name the object being assessed, the boundary around it and the kind of conclusion the evidence can support. Without those three choices, technical vocabulary creates confidence without creating a checkable claim.
Method. Declare the target graph or dataset, version, endpoint, access scope and invariant before writing operations. Refuse an update when the target state cannot be identified. Write the procedure before looking at the preferred result, retain intermediate evidence and record who can challenge each assumption. A method becomes reusable when another reader can repeat the steps, locate disagreements and understand why a different answer emerged.
Worked example. A correction applies only to the named graph for the October release, leaving the archival September graph untouched. The example is deliberately small enough to inspect. Its purpose is not to imitate every real case but to expose the decision rule, the evidence it consumes and the point at which judgement enters.
Changed-context transfer. The same correction in a union default graph may reach several source graphs unless the operation names the intended graph. Keep the underlying principle while changing the actors, incentives or data. If the conclusion survives only because the original labels were familiar, the learner has memorised a case rather than acquired a transferable method.
Limits. Virtual graphs and inferred triples may not be directly writable. Product behaviour must be tested and documented. A responsible conclusion therefore states what remains unknown, what evidence could reverse it and when the analysis must be repeated. Precision about limits is part of the result, not a disclaimer added after it.
Misconception to avoid. An endpoint URL uniquely identifies the update object. A service can expose many graphs and changing views. Test the tempting shortcut against a counterexample and ask which stakeholder bears the cost when it fails. The correction should alter the workflow, not merely add cautious wording.
Practical evidence check
- Ask the system to enumerate the intended graph and a sentinel triple before accepting the patch.
- Return to chapter contents
CHAPTER 2 OF 10 · Build the foundations
2. Separate a graph diff from change intent
Core idea. A diff describes additions and deletions between two states, while intent explains why the change should happen and which invariants it must preserve. The same diff can arise from different decisions. The important discipline is to name the object being assessed, the boundary around it and the kind of conclusion the evidence can support. Without those three choices, technical vocabulary creates confidence without creating a checkable claim.
Method. Keep a reviewed change request beside the machine patch. State the affected entity, reason, authority, expected outcome and reversal condition. Write the procedure before looking at the preferred result, retain intermediate evidence and record who can challenge each assumption. A method becomes reusable when another reader can repeat the steps, locate disagreements and understand why a different answer emerged.
Worked example. Replacing one level code follows an authorised school record correction rather than a bulk normalization job. The triple change is identical; responsibility is not. The example is deliberately small enough to inspect. Its purpose is not to imitate every real case but to expose the decision rule, the evidence it consumes and the point at which judgement enters.
Changed-context transfer. A migration rewrites IRIs without changing domain meaning. Intent distinguishes identity-policy change from factual correction. Keep the underlying principle while changing the actors, incentives or data. If the conclusion survives only because the original labels were familiar, the learner has memorised a case rather than acquired a transferable method.
Limits. Intent records can contain sensitive personal or security information and require proportionate access controls. A responsible conclusion therefore states what remains unknown, what evidence could reverse it and when the analysis must be repeated. Precision about limits is part of the result, not a disclaimer added after it.
Misconception to avoid. The final triples explain the change. They show state, not necessarily rationale, authority or process. Test the tempting shortcut against a counterexample and ask which stakeholder bears the cost when it fails. The correction should alter the workflow, not merely add cautious wording.
Practical evidence check
- Give the diff to a reviewer and require them to recover the approved purpose; if they cannot, preserve a separate intent record.
- Return to chapter contents
CHAPTER 3 OF 10 · Apply the core method
3. Choose a patch language for the required scope
Core idea. SPARQL 1.1 Update supports graph-store operations and pattern-based modifications, while LD Patch offers a constrained patch format for an RDF source. Capability, atomicity and blank-node behaviour differ. The important discipline is to name the object being assessed, the boundary around it and the kind of conclusion the evidence can support. Without those three choices, technical vocabulary creates confidence without creating a checkable claim.
Method. Select the smallest language that expresses the change, validate syntax, declare media type and version, and document unsupported operations. Write the procedure before looking at the preferred result, retain intermediate evidence and record who can challenge each assumption. A method becomes reusable when another reader can repeat the steps, locate disagreements and understand why a different answer emerged.
Worked example. A simple resource correction uses LD Patch DeleteExisting and Add so a missing expected triple fails visibly. The example is deliberately small enough to inspect. Its purpose is not to imitate every real case but to expose the decision rule, the evidence it consumes and the point at which judgement enters.
Changed-context transfer. A dataset-wide transformation uses SPARQL DELETE/INSERT WHERE inside a controlled transaction because several named graphs must change consistently. Keep the underlying principle while changing the actors, incentives or data. If the conclusion survives only because the original labels were familiar, the learner has memorised a case rather than acquired a transferable method.
Limits. Specifications do not guarantee identical vendor transaction or authorization behaviour. A responsible conclusion therefore states what remains unknown, what evidence could reverse it and when the analysis must be repeated. Precision about limits is part of the result, not a disclaimer added after it.
Misconception to avoid. All RDF patch formats are interchangeable text encodings. Their operation models and failure conditions differ. Test the tempting shortcut against a counterexample and ask which stakeholder bears the cost when it fails. The correction should alter the workflow, not merely add cautious wording.
Practical evidence check
- Execute conformance fixtures for add, guarded delete, missing precondition and multi-graph scope before production use.
- Return to chapter contents
CHAPTER 4 OF 10 · Apply the core method
4. Use preconditions to detect stale state
Core idea. A patch prepared against version A can be unsafe after another writer creates version B. Preconditions convert hidden concurrency into an explicit conflict rather than silently overwriting newer work. The important discipline is to name the object being assessed, the boundary around it and the kind of conclusion the evidence can support. Without those three choices, technical vocabulary creates confidence without creating a checkable claim.
Method. Use an entity tag, digest, version IRI, transaction snapshot or required triple. Reject mismatches and rebuild the change against the fresh state. Write the procedure before looking at the preferred result, retain intermediate evidence and record who can challenge each assumption. A method becomes reusable when another reader can repeat the steps, locate disagreements and understand why a different answer emerged.
Worked example. The correction expects the old G2 triple. If another process already changed it to G1, DeleteExisting fails and a reviewer resolves the conflict. The example is deliberately small enough to inspect. Its purpose is not to imitate every real case but to expose the decision rule, the evidence it consumes and the point at which judgement enters.
Changed-context transfer. A catalogue patch checks the release identifier rather than every changed triple, because the whole release is the concurrency unit. Keep the underlying principle while changing the actors, incentives or data. If the conclusion survives only because the original labels were familiar, the learner has memorised a case rather than acquired a transferable method.
Limits. Weak preconditions can pass despite relevant change; overly broad ones can create unnecessary conflicts. A responsible conclusion therefore states what remains unknown, what evidence could reverse it and when the analysis must be repeated. Precision about limits is part of the result, not a disclaimer added after it.
Misconception to avoid. Last write wins is harmless for factual graphs. It can erase a valid correction and destroy accountability. Test the tempting shortcut against a counterexample and ask which stakeholder bears the cost when it fails. The correction should alter the workflow, not merely add cautious wording.
Practical evidence check
- Simulate two writers from one base state and confirm the second cannot commit without examining the first result.
- Return to chapter contents
CHAPTER 5 OF 10 · Apply the core method
5. Treat blank nodes as local, unstable handles
Core idea. Blank-node labels are local to a serialization or processing scope. A later patch cannot safely assume that _:b1 still identifies the same resource. The important discipline is to name the object being assessed, the boundary around it and the kind of conclusion the evidence can support. Without those three choices, technical vocabulary creates confidence without creating a checkable claim.
Method. Prefer stable IRIs for independently updateable entities, or use guarded graph patterns that uniquely select a structure. Reject ambiguous matches. Write the procedure before looking at the preferred result, retain intermediate evidence and record who can challenge each assumption. A method becomes reusable when another reader can repeat the steps, locate disagreements and understand why a different answer emerged.
Worked example. A postal address is a blank node. The patch matches the student, address predicate and postcode, then changes one street literal only when exactly one structure qualifies. The example is deliberately small enough to inspect. Its purpose is not to imitate every real case but to expose the decision rule, the evidence it consumes and the point at which judgement enters.
Changed-context transfer. A canonicalised snapshot can support comparison, but canonical blank-node labels are still tied to the selected dataset and algorithm contract. Keep the underlying principle while changing the actors, incentives or data. If the conclusion survives only because the original labels were familiar, the learner has memorised a case rather than acquired a transferable method.
Limits. Skolemization changes identifiers and requires governance. Pattern matching can be expensive or non-unique. A responsible conclusion therefore states what remains unknown, what evidence could reverse it and when the analysis must be repeated. Precision about limits is part of the result, not a disclaimer added after it.
Misconception to avoid. A readable blank-node label is a persistent database key. Its apparent meaning has no general cross-document authority. Test the tempting shortcut against a counterexample and ask which stakeholder bears the cost when it fails. The correction should alter the workflow, not merely add cautious wording.
Practical evidence check
- Reload the graph through a parser that renames blank nodes and verify that the guarded patch still targets exactly one structure.
- Return to chapter contents
Worked enrolment-code correction
| Step | Graph evidence | Control |
|---|---|---|
| Observe | ex:student7 ex:level ex:G2 | Versioned before snapshot |
| Request | Replace G2 with G3 after authorised review | Ticket and reviewer |
| Patch | Delete old triple; add new triple | Precondition that old triple exists |
| Verify | G3 present, G2 absent, unrelated count unchanged | Targeted ASK queries and digest |
| Record | Link before, patch, activity and after | PROV-O transition record |
The worked case uses an IRI-addressable triple. Blank-node updates require additional care because local labels are not durable cross-document identifiers.
CHAPTER 6 OF 10 · Test evidence and alternatives
6. Preview pattern-based updates before execution
Core idea. DELETE/INSERT WHERE derives concrete changes from query bindings. A broad or surprising binding can affect far more triples than the author expected. The important discipline is to name the object being assessed, the boundary around it and the kind of conclusion the evidence can support. Without those three choices, technical vocabulary creates confidence without creating a checkable claim.
Method. Run the WHERE clause as SELECT, inspect counts and examples, set a maximum affected scope, and require explicit graph clauses. Retain the preview with the approval. Write the procedure before looking at the preferred result, retain intermediate evidence and record who can challenge each assumption. A method becomes reusable when another reader can repeat the steps, locate disagreements and understand why a different answer emerged.
Worked example. A normalization intended for one class binds subclasses and archived graphs. Preview reveals ten thousand rows instead of one hundred and stops the run. The example is deliberately small enough to inspect. Its purpose is not to imitate every real case but to expose the decision rule, the evidence it consumes and the point at which judgement enters.
Changed-context transfer. A streaming system cannot freeze every input, so it records a transaction snapshot and validates counts inside that boundary. Keep the underlying principle while changing the actors, incentives or data. If the conclusion survives only because the original labels were familiar, the learner has memorised a case rather than acquired a transferable method.
Limits. A preview can differ from execution if the dataset changes between them. Transactions or version checks remain necessary. A responsible conclusion therefore states what remains unknown, what evidence could reverse it and when the analysis must be repeated. Precision about limits is part of the result, not a disclaimer added after it.
Misconception to avoid. A syntactically valid update is safe enough to run. Syntax says little about binding scope or policy. Test the tempting shortcut against a counterexample and ask which stakeholder bears the cost when it fails. The correction should alter the workflow, not merely add cautious wording.
Practical evidence check
- Compare preview bindings with executed additions and deletions; investigate every unexplained difference.
- Return to chapter contents
CHAPTER 7 OF 10 · Test evidence and alternatives
7. Make the transition atomic or explicitly recoverable
Core idea. Readers should not observe a half-applied logical change when its operations must stand together. Where atomic transactions are unavailable, recovery and temporary inconsistency must be designed openly. The important discipline is to name the object being assessed, the boundary around it and the kind of conclusion the evidence can support. Without those three choices, technical vocabulary creates confidence without creating a checkable claim.
Method. Group operations in a transaction, validate before commit, and define retry idempotency. Otherwise stage a new version and switch a pointer only after verification. Write the procedure before looking at the preferred result, retain intermediate evidence and record who can challenge each assumption. A method becomes reusable when another reader can repeat the steps, locate disagreements and understand why a different answer emerged.
Worked example. A two-graph release is written to staging graphs, checked, then exposed through one release pointer, preventing mixed versions. The example is deliberately small enough to inspect. Its purpose is not to imitate every real case but to expose the decision rule, the evidence it consumes and the point at which judgement enters.
Changed-context transfer. A remote HTTP workflow cannot join the local transaction. It uses an outbox, idempotency key and compensating action with separate status. Keep the underlying principle while changing the actors, incentives or data. If the conclusion survives only because the original labels were familiar, the learner has memorised a case rather than acquired a transferable method.
Limits. External notifications and caches may escape rollback. Recovery may restore data but not erase every side effect. A responsible conclusion therefore states what remains unknown, what evidence could reverse it and when the analysis must be repeated. Precision about limits is part of the result, not a disclaimer added after it.
Misconception to avoid. Reversing every INSERT and DELETE always restores history. Concurrent changes and generated effects can make a mechanical inverse destructive. Test the tempting shortcut against a counterexample and ask which stakeholder bears the cost when it fails. The correction should alter the workflow, not merely add cautious wording.
Practical evidence check
- Interrupt execution after each step in a test environment and prove that readers see either a valid old state or a valid recoverable state.
- Return to chapter contents
CHAPTER 8 OF 10 · Handle limits and disagreement
8. Record update provenance without confusing it with truth
Core idea. A provenance record can connect before state, patch activity, agent, software, time and after state. It supports accountability but does not prove the corrected assertion is true. The important discipline is to name the object being assessed, the boundary around it and the kind of conclusion the evidence can support. Without those three choices, technical vocabulary creates confidence without creating a checkable claim.
Method. Use PROV-O entities for snapshots and patch artifacts, an activity for execution, agents for authorisation and association, and derivation links for the resulting state. Write the procedure before looking at the preferred result, retain intermediate evidence and record who can challenge each assumption. A method becomes reusable when another reader can repeat the steps, locate disagreements and understand why a different answer emerged.
Worked example. The after graph is attributed to the publication system, while the correction decision is associated with an authorised reviewer and supporting source. The example is deliberately small enough to inspect. Its purpose is not to imitate every real case but to expose the decision rule, the evidence it consumes and the point at which judgement enters.
Changed-context transfer. An automated cleanup has a software agent and policy owner even when no person clicks each run. Keep the underlying principle while changing the actors, incentives or data. If the conclusion survives only because the original labels were familiar, the learner has memorised a case rather than acquired a transferable method.
Limits. Provenance can be incomplete or misleading and may reveal identities or internal systems. A responsible conclusion therefore states what remains unknown, what evidence could reverse it and when the analysis must be repeated. Precision about limits is part of the result, not a disclaimer added after it.
Misconception to avoid. A signed patch proves the new fact. It proves a signature relation, not domain truth or legitimate authority by itself. Test the tempting shortcut against a counterexample and ask which stakeholder bears the cost when it fails. The correction should alter the workflow, not merely add cautious wording.
Practical evidence check
- Trace one changed triple through source evidence, approval, patch, execution, validation and publication, naming the claim supported at each layer.
- Return to chapter contents
Patch failure map
| Failure | Risk | Safer response |
|---|---|---|
| Stale base state | Patch overwrites a newer change | Use entity tags, version tokens or explicit preconditions |
| Broad DELETE WHERE | Unintended triples disappear | Preview bindings and constrain graph and subject |
| Blank-node mismatch | Patch addresses the wrong local node | Use stable identifiers or pattern-based guarded matching |
| Partial multi-step execution | Dataset stops between intended states | Use transactions or compensating recovery with audit |
Rollback is not always a perfect inverse. External side effects, generated identifiers and concurrent changes can make compensation the honest remedy.
CHAPTER 9 OF 10 · Handle limits and disagreement
9. Verify the after state and unintended change
Core idea. Successful execution means the server accepted operations. Verification must check intended additions, intended removals, invariants, unrelated regions and downstream indexes or caches. The important discipline is to name the object being assessed, the boundary around it and the kind of conclusion the evidence can support. Without those three choices, technical vocabulary creates confidence without creating a checkable claim.
Method. Run targeted ASK queries, SHACL or domain constraints, counts, canonical digests where appropriate and sampled negative checks. Compare the actual diff with the approved diff. Write the procedure before looking at the preferred result, retain intermediate evidence and record who can challenge each assumption. A method becomes reusable when another reader can repeat the steps, locate disagreements and understand why a different answer emerged.
Worked example. The new G3 triple exists and the G2 triple is absent, but a constraint also confirms each student has exactly one current level. The example is deliberately small enough to inspect. Its purpose is not to imitate every real case but to expose the decision rule, the evidence it consumes and the point at which judgement enters.
Changed-context transfer. A schema migration legitimately changes many triples. Validation uses declared invariants and a reviewed change envelope rather than expecting a tiny diff. Keep the underlying principle while changing the actors, incentives or data. If the conclusion survives only because the original labels were familiar, the learner has memorised a case rather than acquired a transferable method.
Limits. Inference and asynchronous indexing can delay visible consistency. Verification must state which layer and time it checked. A responsible conclusion therefore states what remains unknown, what evidence could reverse it and when the analysis must be repeated. Precision about limits is part of the result, not a disclaimer added after it.
Misconception to avoid. No error response means the update is correct. Servers can apply a valid but unintended operation perfectly. Test the tempting shortcut against a counterexample and ask which stakeholder bears the cost when it fails. The correction should alter the workflow, not merely add cautious wording.
Practical evidence check
- Inject one unintended neighbouring deletion in a test patch and confirm the verification suite catches it.
- Return to chapter contents
CHAPTER 10 OF 10 · Transfer and govern
10. Publish versions, correction routes and retention rules
Core idea. Auditable updates need discoverable versions and correction links while respecting privacy, licence, retention and security obligations. Not every intermediate state should be public forever. The important discipline is to name the object being assessed, the boundary around it and the kind of conclusion the evidence can support. Without those three choices, technical vocabulary creates confidence without creating a checkable claim.
Method. Publish stable release identifiers, human change notes, machine patches where safe, integrity evidence and a route to report errors. Govern protected logs separately. Write the procedure before looking at the preferred result, retain intermediate evidence and record who can challenge each assumption. A method becomes reusable when another reader can repeat the steps, locate disagreements and understand why a different answer emerged.
Worked example. A public dataset exposes monthly snapshots and change summaries, while a restricted audit log retains personal correction evidence. The example is deliberately small enough to inspect. Its purpose is not to imitate every real case but to expose the decision rule, the evidence it consumes and the point at which judgement enters.
Changed-context transfer. A safety graph needs rapid correction and clear supersession, but the withdrawn value remains available only to authorised investigators. Keep the underlying principle while changing the actors, incentives or data. If the conclusion survives only because the original labels were familiar, the learner has memorised a case rather than acquired a transferable method.
Limits. Immutable copies can preserve harmful or personal data. Deletion duties and public accountability may pull in different directions. A responsible conclusion therefore states what remains unknown, what evidence could reverse it and when the analysis must be repeated. Precision about limits is part of the result, not a disclaimer added after it.
Misconception to avoid. Maximum transparency means publishing every patch and identity. Proportionate transparency preserves scrutiny without creating new harm. Test the tempting shortcut against a counterexample and ask which stakeholder bears the cost when it fails. The correction should alter the workflow, not merely add cautious wording.
Practical evidence check
- Ask an independent reader to find the current version, its predecessor, the reason for change, verification result and correction channel.
- Return to chapter contents
Build a RDF-update evidence worksheet
State the decision, unit of analysis, time horizon and affected people before collecting evidence. Separate observations from interpretations and interpretations from recommendations. Record data provenance, missingness and incentives that could distort reporting.
For every important claim, add a rival explanation and one observation that would favour it. Give uncertainty a visible place instead of hiding it inside a single score. Assign an owner and review date to assumptions that may change.
Run the worksheet with someone who did not design the analysis. Ask them to reconstruct the conclusion and identify where judgement entered. Revise any step that depends on private intuition or undefined terminology.
Finish with an action table: act now, monitor, investigate or stop. Link each action to evidence and a reversal condition so the method supports learning rather than defending the first answer.
Design a changed-context transfer check
Rewrite the case with a different scale, institution and distribution of power while preserving the underlying structure. Predict which parts of the method should remain stable and which require new evidence.
Remove one convenient data source and add one conflicting stakeholder account. Re-run the reasoning. If the answer changes, explain whether the change reflects better evidence, a different value choice or an unstable method.
Switch the time horizon. A decision that looks efficient this week may weaken resilience over years, while a long-run benefit may impose an unacceptable immediate burden. Report both rather than averaging them away.
Ask a reviewer to produce a counterexample. A transfer check passes when the method reveals why the new case differs, not when it mechanically produces the same conclusion.
Audit the reasoning and the record
Preserve source versions, transformations, thresholds, exclusions and decision notes. A final chart without its lineage cannot be independently checked and may conceal silent changes.
Trace one favourable and one unfavourable case from raw evidence to recommendation. Confirm that identical rules were applied and that exceptions were authorised, explained and reviewable.
Interview affected users about how the process works in practice. Formal policy may differ from operational reality, especially when time pressure, inaccessible interfaces or asymmetric power limit challenge.
Publish a proportionate account of method, limits, ownership and remedy. Protect sensitive data while ensuring that confidentiality is not used to block legitimate scrutiny.
Turn findings into accountable action
Assign every recommendation to a named role with authority, resources and a deadline. Distinguish mitigation from remedy: reducing future risk does not repair harm already caused.
Choose leading indicators that reveal drift early and outcome indicators that show whether people actually benefited. Disaggregate results where averages can hide concentrated burden.
Create an escalation rule for new evidence, missed thresholds and recurring complaints. Independent review should be available when the original decision maker has an incentive to defend the system.
Close the loop by publishing what changed, what did not and why. Re-open the analysis after material changes instead of treating one successful review as permanent certification.
Questions readers ask
Is a graph diff enough to explain an update?
- No. It shows additions and deletions, not necessarily purpose, authority, preconditions or validation.
Can blank-node labels be used in later patches?
- Not safely as durable identifiers; use stable IRIs or guarded structural matching.
Why preview a SPARQL Update?
- The WHERE clause may bind more or different resources than expected.
Does a successful HTTP response prove correctness?
- No. It proves protocol-level acceptance, not that the intended state and invariants resulted.
Is rollback always the inverse patch?
- No. Concurrent changes and external side effects can require compensating recovery.
What should update provenance include?
- Before state, patch, execution activity, agents, software, time, after state and verification.
Practise, verify and continue
Create two versions of a small named graph. Write one guarded patch, preview its bindings, apply it under a version precondition, compare the actual diff, validate one invariant and build a provenance record linking the before state, patch activity and after state.
Move the method to configuration data, curriculum metadata or a knowledge graph. Preserve bounded state, explicit intent, guarded execution, after-state checks, provenance and remedy while changing the patch technology.
Related eduKate reading
SPARQL named graphs and reproducible query evidence
PROV-O entities, activities, agents and derivations
RDF dataset canonicalisation and verifiable graphs
SHACL validation reports and constraint evidence
Data citation, versioned queries and reproducible subsets
Authoritative sources and scope
W3C, SPARQL 1.1 Update
W3C, SPARQL 1.1 Graph Store HTTP Protocol
W3C, Linked Data Patch Format
W3C, RDF 1.1 Concepts and Abstract Syntax
W3C, PROV-O: The PROV Ontology
This article is an educational guide to update evidence, not a security certification or product-specific transaction manual. W3C specifications define languages and models; servers differ in authorization, isolation, transactions, inference, blank-node handling, quotas and recovery. The examples are original. Production systems should test exact versions, constrain affected scope, protect credentials and personal data, preserve authorised records, and rehearse failure. A valid patch can encode an invalid policy decision. Truth, integrity, authority, successful execution and lawful processing therefore require distinct evidence.