THE GOLD STANDARD OF INFORMATION · SPECIALIST STUDY
Make a digital identifier carry verifiable evidence about its artifact
A location tells you where to ask for an artifact. A Trusty URI can also encode a module identifier and hash expression derived from the artifact so a verifier can test whether retrieved content matches the identifier. Nanopublications use this pattern to make small research claims immutable, citable and replicable while keeping assertion, provenance and publication information distinct.
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 |
|---|---|---|
| Identifier | What module and hash expression are declared? | A parseable Trusty URI artifact code |
| Artifact transformation | Which bytes or graph representation are hashed? | A reproducible normalization procedure |
| Verification | Does recomputation match the embedded digest? | A pass or fail for content integrity |
| Publication network | Can the immutable artifact be found and cited? | Replicas, indexes and provenance links |
A verified digest supports an integrity claim. It does not establish truth, completeness, authorship authority or permanent availability.
CHAPTER 1 OF 10 · Build the foundations
1. Separate location, name and content commitment
Core idea. HTTP URIs are often dereferenceable locations, while a content-addressed code commits to a particular artifact representation. Trusty URIs combine a familiar URI with an artifact code without making the network location permanent. 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. Define the artifact, its media or RDF model, the resolver location and the verification module as separate fields. Treat redirects and mirrors as discovery mechanisms rather than identity evidence. 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 nanopublication is copied from one server to three mirrors. Each URL path differs, but the Trusty URI artifact code remains the same and each copy verifies. 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. Move the files to an offline archive. Verification can still work on a local copy even though HTTP retrieval changes, showing why location and content commitment are distinct. 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 stable hash cannot guarantee that any resolver remains online or that the chosen representation captures every intended meaning. 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 Trusty URI is permanent because it uses HTTPS. Transport security and persistence are different properties. 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
- Take one identifier and label the location, artifact code, module identifier, digest and retrieval route.
- Return to chapter contents
CHAPTER 2 OF 10 · Build the foundations
2. Read the artifact code as module plus hash expression
Core idea. The artifact code identifies the module and carries a digest encoded for use inside a URI. The module defines how content is transformed, hashed and checked; the digest alone does not define the verification contract. 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. Parse the module identifier before processing content, reject unsupported or malformed codes, and apply only the normative algorithm for that module. Preserve the full code rather than guessing from length. 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. An RA-prefixed code indicates an RDF module in the original Trusty URI design, whereas a byte-file module follows a different transformation. Applying the wrong procedure produces a meaningless mismatch. 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. Introduce a future module with another hash or representation. Old verifiers should fail clearly as unsupported rather than silently applying a familiar algorithm. 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. Module registries and implementations can age. Long-term use requires preserving specifications, test vectors and software, not only the identifiers. 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 base64-looking suffixes can be verified the same way. Encoding shape does not replace an algorithm identifier. 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
- Feed a malformed module code to the verifier and confirm it produces an explicit error rather than a false negative or fallback.
- Return to chapter contents
CHAPTER 3 OF 10 · Apply the core method
3. Canonicalise graph content before hashing
Core idea. RDF graphs and datasets admit different serializations and blank-node labels. A graph-oriented module must establish a deterministic representation so equivalent permitted inputs produce the same digest. 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. Follow the module’s statement ordering, blank-node handling, placeholder and encoding rules exactly. Record parser context, supported RDF features and any error before hashing. 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. Two TriG files reorder quads and rename blank nodes. The module transformation yields the same hash input, so both verify against one artifact code. 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. Change a literal datatype or named-graph assignment. The transformed graph changes and verification fails even if the displayed prose looks similar. 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. Canonicalisation establishes representation stability under its contract; it does not prove semantic equivalence under every ontology or inference regime. 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. Alphabetically sorting source lines is enough. Surface syntax contains prefixes, relative IRIs and local blank-node labels that need model-aware handling. 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
- Retain the canonical input for a small test case and independently recompute its digest with a second implementation.
- Return to chapter contents
CHAPTER 4 OF 10 · Apply the core method
4. Handle self-reference without circular guessing
Core idea. An artifact may contain its own Trusty URI, apparently requiring the hash before the content and the content before the hash. The module resolves this by defining a placeholder or normalization for the artifact code during hashing. 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. Construct the pre-artifact form, apply the exact placeholder rule at every permitted self-reference, hash it, insert the code and verify by repeating the same transformation. 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 nanopublication names its assertion graph using its final Trusty URI. During hashing, the code position is normalized; after insertion, recomputation returns the same digest. 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. Add an unrecognized occurrence of the code inside a literal. Whether it is replaced depends on the normative module, not a developer’s intuition about self-reference. 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. Poor implementations may replace too broadly or too narrowly. Conformance tests need adversarial strings and multiple occurrences. 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. Self-reference proves that the artifact authored itself. It only shows that the identifier and content satisfy the transformation rule. 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
- Create a fixture with legitimate and look-alike code occurrences, then confirm only normative positions affect preprocessing.
- Return to chapter contents
CHAPTER 5 OF 10 · Apply the core method
5. Model a nanopublication as four linked graphs
Core idea. A nanopublication typically separates assertion, provenance and publication information and links them through a head graph. This makes a small claim citable while preserving who asserted it, how it was derived and how the nanopublication was published. 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. Validate graph roles and links before trusting the package. Keep claim-level provenance distinct from publication-level authorship, timestamps, signatures or rights. 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. An assertion says a measured relation exists; its provenance cites the dataset and method; publication information names the nanopublication creator; the head connects all three. 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 retraction or correction should publish a new immutable nanopublication that links to the earlier one instead of editing the earlier bytes. 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. The four-graph pattern can still contain vague, incomplete or misleading provenance. Structure makes questions addressable; it does not guarantee good answers. 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 publication-information author necessarily made the scientific assertion. Those roles can differ and must not be collapsed. 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
- Select a live nanopublication and trace each head link, then state which agent is responsible for each graph-level claim.
- Return to chapter contents
Worked self-reference example
| Step | Operation | Reason |
|---|---|---|
| Prepare | Place a placeholder where the artifact code will appear | The final identifier is not known yet |
| Transform | Apply the module’s defined preprocessing or RDF normalization | Every verifier needs the same hash input |
| Hash | Compute the digest and encode the artifact code | The code commits to transformed content |
| Insert | Replace the placeholder with the artifact code | The artifact can cite its own Trusty URI |
| Verify | Remove or normalize the self-reference as specified and recompute | Matching output confirms the declared integrity relation |
Do not invent a placeholder rule. Use the exact module specification and record its version.
CHAPTER 6 OF 10 · Test evidence and alternatives
6. Verify before indexing, citing or computing
Core idea. Verification should occur at the trust boundary: when content enters a cache, index, analysis or evidence bundle. A later check cannot undo decisions already made from corrupted input. 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. Parse the Trusty URI, retrieve or receive the artifact, apply the module transformation, compare the digest, then validate required structure and policy before use. Log failures without serving unverified content as equivalent. 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 research index receives two copies from different servers. Both match the artifact code, so it stores one content identity with two retrieval sources. 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 mirror returns HTML error text at the artifact URL. Content-type and module processing fail before the page can contaminate the graph index. 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. Verification consumes CPU and can face maliciously complex graph inputs. Bound resources and return explicit indeterminate outcomes. 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 successful HTTP response means the artifact is valid. Networks deliver bytes; verification evaluates the declared integrity relation. 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 artifact from network receipt to index insertion and prove that no unverified path bypasses the gate.
- Return to chapter contents
CHAPTER 7 OF 10 · Test evidence and alternatives
7. Add signatures and authority as separate layers
Core idea. A hash binds content to an identifier but does not identify an accountable signer. Digital signatures can add key-based authorship evidence, while institutional authority and claim truth require further governance and domain evidence. 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. Define the signed object, canonicalization, algorithm, proof purpose, key resolution and revocation policy. Verify the content hash first, then the signature and the signer’s authority for the claimed role. 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 laboratory signs a verified nanopublication. The signature validates under its research key, and an institutional directory confirms the key’s role at publication time. 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 key is later rotated. Historical verification needs archived key status and timestamps rather than treating current key absence as proof of forgery. 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. Key compromise, delegation and revocation complicate long-lived evidence. Cryptographic validity is necessary but not sufficient for institutional attribution. 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 embedded hash is already a signature. A digest has no secret signing operation and by itself names no agent. 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
- For one signed artifact, document content verification, signature verification, key control, role authority and temporal status as five separate results.
- Return to chapter contents
CHAPTER 8 OF 10 · Handle limits and disagreement
8. Use immutability with versioning, not silent edits
Core idea. Immutable publication means an artifact with a Trusty URI does not change under that identifier. Knowledge can still evolve through new artifacts that cite, supersede, correct or retract earlier ones. 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 a new artifact for every material change, link it with explicit relations, preserve the old artifact and maintain indexes that expose version history and current recommendations. 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 unit error is found in an assertion. The publisher issues a corrected nanopublication, links it as a correction and marks the earlier identifier in a retraction or update index. 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 spelling correction outside the hashed artifact may not require a new identity; a changed assertion or provenance graph does. Define material boundaries in advance. 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. Indexes that label the latest version are mutable services and need their own governance, availability and audit trail. 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. Immutability forbids correction. It forbids rewriting history under one identifier; it supports correction through linked history. 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
- Follow a supersession chain and confirm that a reader arriving at any version can discover the correction and its reason.
- Return to chapter contents
Claim ladder for immutable artifacts
| Observation | Supported claim | Unsupported leap |
|---|---|---|
| Hash matches | Retrieved content matches the Trusty URI under the named module | The claim is scientifically true |
| Signature also verifies | A key holder signed the defined input | The key holder had legitimate authority |
| Replicas agree | Multiple servers return the same verified artifact | The artifact will always remain available |
| Provenance is linked | A provenance graph is available and integrity-checked | The provenance account is complete or unbiased |
Use separate evidence for integrity, authorship, authority, truth, completeness and preservation.
CHAPTER 9 OF 10 · Handle limits and disagreement
9. Replicate content and preserve verification capability
Core idea. Content-addressed artifacts can be replicated because any copy can be checked against the identifier. Preservation also requires discovery, storage diversity, format knowledge, specifications and working verification tools. 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. Maintain independent replicas, verify on ingest and periodically, archive module specifications and test vectors, monitor resolver health and export indexes in open formats. 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. Three nanopublication servers hold one artifact. One disappears and another corrupts a file; the third verifies, allowing repair without changing identity. 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. Move the corpus to cold storage with no public resolver. Integrity remains checkable, but discoverability and timely access decline, so preservation is only partial. 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. Identical replicas can share the same systemic vulnerability or institutional funding risk. Independence matters as much as copy count. 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 hash eliminates the need for backups. It detects mismatch but cannot reconstruct missing content. 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 loss of one resolver and one corrupted replica; confirm that the artifact can still be found, verified and restored.
- Return to chapter contents
CHAPTER 10 OF 10 · Transfer and govern
10. Govern privacy, harmful permanence and depublication
Core idea. Immutable, widely replicated artifacts can conflict with privacy, consent, safety and legitimate correction. Technical permanence must be paired with publication minimisation, access design and accountable policies. 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. Review personal and sensitive data before publication, prefer references or protected stores where appropriate, document lawful and ethical basis, and define response processes for harmful material. 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 nanopublication contains a direct personal identifier in provenance. Replication makes removal difficult, so the safer design is to publish a privacy-preserving reference and keep identifiable evidence under controlled access. 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. For public-domain measurements without personal risk, broad replication may be desirable. The governance choice changes with harm, not with enthusiasm for one architecture. 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. No depublication mechanism can guarantee deletion from independent copies. Policies must be honest about residual risk and available remedies. 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. Immutability is always ethically superior because it prevents censorship. Permanence can also preserve error, exposure and abuse. 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
- Run a prepublication harm review and document why each field must be immutable and public rather than mutable, restricted or omitted.
- Return to chapter contents
Build a Trusty URI 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 Trusty URI the same as an ordinary checksum URL?
- It is more specific: an artifact code includes a module identifier whose specification defines the transformation and verification procedure.
Does verification prove the assertion is true?
- No. It proves a defined content-integrity relation. Truth needs domain evidence and reasoning.
Can an immutable nanopublication be corrected?
- Yes, by publishing a new immutable artifact linked as a correction, update or retraction while preserving history.
Why separate assertion and provenance?
- They answer different questions: what is claimed and how that claim was derived.
Do replicas need the same URL?
- No. Their retrieved artifact can be verified against the same content commitment even when locations differ.
What is the largest risk?
- Confusing integrity with truth or permanence with availability, and publishing sensitive information that cannot be reliably withdrawn.
Practise, verify and continue
Build a tiny nanopublication with one assertion, one provenance record and publication information. Generate its Trusty URI using a conforming tool, copy it to a second location, verify both copies, then issue a linked correction without changing the original.
Apply the same reasoning to a software bill of materials or policy evidence bundle. Identify the canonical representation, content commitment, signer, discovery index, version links and privacy limits.
Related eduKate reading
RDF dataset canonicalisation, blank-node labelling and verifiable graphs
Data Quality Vocabulary measurements and conformance evidence
SHACL validation reports and constraint evidence
Signposting, link relations and repository discovery
Authoritative sources and scope
Kuhn and Dumontier, Trusty URIs: Verifiable, Immutable, and Permanent Digital Artifacts for Linked Data
Kuhn and Dumontier, Making Digital Artifacts on the Web Verifiable and Reliable
Trusty URI specification repository
Nanopublication guidelines working draft
Nanopublications: introduction and resources
This article explains the architecture and verification logic rather than certifying a particular implementation. Module rules, RDF support, cryptographic choices and network services can change, so production systems should preserve the exact specification and test vectors they use. The original examples are teaching cases. Security review should consider malformed identifiers, resource exhaustion, parser differences, key compromise, privacy, harmful permanence and resolver failure. Verification results should be reported as bounded claims: content match, signature validity, authority evidence, provenance completeness and scientific truth require distinct checks. Long-term preservation needs artifacts, indexes, open formats, independent replicas, specifications and runnable verification software. Publication governance should minimise sensitive data before replication and provide transparent correction, retraction and remedy paths while acknowledging that independent copies may remain.