THE GOLD STANDARD OF INFORMATION · SPECIALIST STUDY
Make the same RDF meaning produce the same comparison surface
RDF deliberately separates meaning from surface syntax. That flexibility helps data travel across Turtle, JSON-LD, TriG and N-Quads, yet it complicates byte-level comparison when blank nodes have local labels and triples can appear in any order. Canonicalisation builds a stable representation of one dataset so hashes, caches, evidence bundles and some cryptographic proofs can be checked without pretending that a hash proves every semantic claim.
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 identity model · chapters 1–2
Follow RDFC-1.0 · chapters 3–5
Hash and verify carefully · chapters 6–7
Protect the workflow · chapters 8–9
Transfer and govern · chapters 10
The whole problem at a glance
| Layer | Question | Evidence produced |
|---|---|---|
| RDF dataset | Which default and named graphs, terms and quads are in scope? | A precisely bounded set of quads |
| Canonical labelling | Can blank nodes receive deterministic identifiers for this dataset? | A canonical identifier map |
| Canonical serialization | Can every quad be written and ordered predictably? | Canonical N-Quads bytes |
| Digest or proof | Did protected bytes change, and who controlled the verification method? | A hash comparison or cryptographic verification result |
A successful step does not silently prove the next one. Dataset equality, canonical bytes, digest equality, signature validity and truth are different claims.
CHAPTER 1 OF 10 · Build the identity model
1. Start with RDF meaning, not a file format
Core idea. An RDF graph is a set of triples and an RDF dataset contains a default graph plus zero or more named graphs. Order is not part of the abstract model, and several syntaxes can represent the same structure. A file comparison therefore answers a narrower question than a dataset comparison.
Method. Parse both inputs under explicit syntax and base-IRI rules, freeze the resulting dataset boundary, and compare terms and quads. Record whether empty named graphs, generalized RDF features or RDF-star terms are supported, because an implementation that silently drops a feature changes the object being compared.
Worked example. One publisher sends Turtle and another sends JSON-LD. Their bytes and line order differ, but parsing yields the same IRIs, literal datatypes and blank-node relationships. Canonicalisation works after this normalization boundary, not by alphabetically sorting the original files.
Changed-context transfer. Change the base IRI in a relative-IRI document. The same characters can now expand to different IRIs, so identical source text no longer guarantees the same graph. The dataset boundary must include parsing context and document loader behaviour.
Limits. Canonicalisation does not resolve semantic entailment. Two datasets can support equivalent inferences under a vocabulary while containing different explicit quads. Decide whether the application compares asserted datasets, an entailment closure or another defined view.
Misconception to avoid. Sorting Turtle statements is canonicalisation. It is not: prefixes, blank-node property lists, collections, lexical forms and parser context can change the bytes without changing the abstract graph.
Practical evidence check
- Write the exact comparison object in one sentence and list every parser option that can change it.
- Return to chapter contents
CHAPTER 2 OF 10 · Build the identity model
2. Treat blank-node labels as local handles
Core idea. A blank node denotes a resource without a globally assigned IRI. Labels such as _:b0 are serialization-scoped identifiers, not portable names. Renaming every blank node consistently can leave the RDF graph isomorphic, which is why ordinary string comparison fails.
Method. Build a bijective mapping test: IRIs and literals must map to themselves, blank nodes may map to blank nodes, and every mapped triple or quad must exist in the other dataset. Canonicalisation seeks one deterministic labelling so the expensive search does not have to be repeated for every comparison.
Worked example. Dataset A uses _:aliceAddress and Dataset B uses _:z7 for the same address structure. The descriptive label in A feels meaningful but has no cross-document authority. If all connected predicates and values align under a consistent mapping, the graphs may still be isomorphic.
Changed-context transfer. Move the blank node into a named graph or share it across two graphs. A graph-by-graph labelling strategy can miss those cross-graph connections; a dataset algorithm must consider the full quad context.
Limits. Blank nodes do not provide secrecy, ephemerality or legal anonymity. Neighbourhood structure can still identify a person or record, and a canonical label can make repeated structure easier to correlate.
Misconception to avoid. Skolemizing every blank node with a random IRI automatically preserves meaning and interoperability. Skolemization changes identifiers and requires governance; random issuance does not create a shared canonical choice.
Practical evidence check
- For each blank node, list the graphs and adjacent quads that constrain its identity; reject any comparison that only sees one graph when the node is shared.
- Return to chapter contents
CHAPTER 3 OF 10 · Follow RDFC-1.0
3. Initialize RDFC-1.0 with a fixed contract
Core idea. RDFC-1.0 canonically labels an RDF dataset, writes canonical N-Quads and orders the lines by Unicode code point. The algorithm is deterministic only when its input dataset, options, hash function and error handling are the same. Version the complete contract.
Method. Create immutable input state, an issuer for canonical identifiers, temporary issuers for candidate paths, and maps from computed hashes to blank nodes. Normalize quads according to the specification before any hash is calculated. Preserve errors rather than substituting an implementation-specific fallback.
Worked example. Two services both advertise “RDF canonicalization,” but one uses an older URDNA2015 implementation with permissive parsing and the other uses RDFC-1.0 with strict errors. Matching results on one dataset do not establish general interoperability.
Changed-context transfer. Change the chosen hash algorithm where the specification permits an option. Every downstream digest and canonical label can change, even though the RDF meaning does not. Algorithm identifiers belong in evidence records.
Limits. A canonical algorithm is not automatically safe for unbounded hostile input. Highly symmetric graphs can drive expensive path exploration, and implementations need documented limits without returning a false successful result.
Misconception to avoid. Determinism means every implementation will accept every input. It means conforming implementations should agree for supported valid inputs under the same contract; validation and resource failures remain possible.
Practical evidence check
- Record algorithm version, hash choice, parser version, dataset size, blank-node count, execution limit and whether the run completed without warnings.
- Return to chapter contents
CHAPTER 4 OF 10 · Follow RDFC-1.0
4. Use first-degree hashes to separate easy cases
Core idea. A first-degree hash captures the immediate quads touching one blank node while replacing that node and its neighbours with defined placeholders. Blank nodes with unique first-degree hashes can receive canonical identifiers early, reducing later search.
Method. For one blank node, collect every containing quad, serialize each with the target placeholder conventions, sort those strings, concatenate them and hash the result. Group blank nodes by the resulting digest and issue canonical identifiers only when the group is unambiguous under the normative steps.
Worked example. A blank node for an address has predicates street, postcode and country, while another has name and role. Their neighbourhood strings differ, so their first-degree hashes separate them without recursive comparison.
Changed-context transfer. Make two addresses structurally identical except for local labels. Their first-degree hashes collide by design. The collision says the first-degree view is insufficient, not that the hash function failed.
Limits. A digest collision in cryptography and a structural tie in first-degree processing are different events. Most ties arise because the normalized neighbourhood descriptions are identical, not because SHA-256 found two different inputs with the same digest.
Misconception to avoid. Unique-looking application labels may be used in the hash. They must not be, because labels are precisely the unstable input the algorithm is replacing.
Practical evidence check
- Recompute one first-degree hash from retained normalized strings and confirm that line sorting, placeholders and encoding match the specification.
- Return to chapter contents
CHAPTER 5 OF 10 · Follow RDFC-1.0
5. Resolve symmetric neighbourhoods with n-degree paths
Core idea. When several blank nodes share a first-degree hash, the algorithm explores relationships to other blank nodes, issues temporary identifiers and compares candidate paths. Deterministic ordering across those paths lets a canonical choice emerge even in symmetrical structures.
Method. For every tied node, hash related blank nodes by position and predicate context, group relations, explore permutations in lexical order, and prune a path once it cannot beat the best known path. Carry a temporary issuer with each candidate so repeated references remain consistent.
Worked example. In a two-node cycle, each node has the same first-degree view. Traversing the relation in both directions yields candidate paths with temporary identifiers. Lexical comparison chooses the same path convention for isomorphic inputs, producing consistent canonical labels.
Changed-context transfer. Add a third indistinguishable node to the cycle. The permutation space grows, and a safe implementation may hit a configured complexity limit. The correct outcome is a clear failure, not a partially canonical output.
Limits. N-degree recursion can be computationally expensive and must be defended against dataset-poisoning patterns. Limits should be deterministic enough for operational predictability and visible enough that callers do not mistake refusal for non-isomorphism.
Misconception to avoid. Recursive hashing makes blank nodes globally meaningful. It only assigns canonical identifiers within the selected dataset and algorithm run; the identifiers are not enduring real-world names.
Practical evidence check
- Use deliberately symmetric test vectors, compare two independent conforming implementations and verify that limit failures are surfaced rather than cached as valid results.
- Return to chapter contents
Worked symmetric blank-node example
| Stage | Observation | What follows |
|---|---|---|
| Input A | _:a knows _:b; _:b knows _:a | Local labels describe a two-node cycle |
| Input B | _:x knows _:y; _:y knows _:x | Different labels can express an isomorphic cycle |
| First-degree hashes | Both nodes have the same local pattern | First-degree evidence cannot yet distinguish them |
| N-degree processing | Permutations of related paths are compared | A deterministic issued order can break the tie |
| Output | Canonical labels replace local labels | Both inputs can yield the same ordered canonical quads |
The example is conceptual. Exact hashes depend on the normative serialization and hash choices in RDFC-1.0.
CHAPTER 6 OF 10 · Hash and verify carefully
6. Serialize canonical N-Quads and hash bytes deliberately
Core idea. Canonical labels solve one source of instability. Canonical N-Quads then fixes term spelling, escapes, whitespace and line layout, and the canonicalization algorithm places the lines in code-point order. Only after those steps is there a stable byte sequence to hash.
Method. Encode the canonical output in UTF-8 exactly as specified, retain or recompute an algorithm identifier, and apply the selected cryptographic digest. State whether the digest covers canonical RDF bytes, the original file bytes, a package manifest or all three.
Worked example. A repository computes SHA-256 over canonical N-Quads and records it in a manifest. A consumer canonicalises its received dataset with the same contract and obtains the same digest. That supports dataset integrity across syntax changes, not preservation of the original Turtle comments or layout.
Changed-context transfer. Now the repository wants bit-preservation for legal deposit. The RDF digest is insufficient because comments and formatting can change without changing the dataset. Add a separate file digest and name both objects explicitly.
Limits. Canonical N-Quads cannot serialize the existence of an empty named graph in RDF 1.1-style models, so an application that treats empty graph presence as significant needs an additional representation or policy.
Misconception to avoid. One hash should be used as a universal identity for meaning, file and provenance. These are different layers and deserve different identifiers or typed digest claims.
Practical evidence check
- Round-trip a known dataset through two syntaxes, confirm equal canonical digests, then confirm that changing one literal datatype changes the digest.
- Return to chapter contents
CHAPTER 7 OF 10 · Hash and verify carefully
7. Separate digests, signatures and authority
Core idea. A digest detects change relative to an expected value delivered through a trusted channel. A digital signature or Data Integrity proof adds a verification method and proof purpose. Neither mechanism establishes that the claims are true, complete, lawful or authorised for the relying decision.
Method. Verify the transformation, proof configuration, canonical bytes, digest, signature and key status in that order. Bind domain, purpose, time and expected controller through application policy. Preserve the evidence that says which document loader and contexts were used.
Worked example. A credential proof verifies cryptographically, but its issuer is not accredited for the claimed qualification. The bytes are intact and the key signature is valid; the application must still reject the claim under its authority policy.
Changed-context transfer. Change the proof purpose from assertion to authentication. The same key and dataset may be valid for one purpose and invalid for another. Cryptographic success must not erase a purpose mismatch.
Limits. Keys can be compromised or revoked, contexts can change, and signature suites can age. Long-term validation may require timestamping, archived verification material and an explicit trust framework.
Misconception to avoid. Signature valid means statement true. It means the protected input and proof validate under a method; truth remains an evidential and institutional question.
Practical evidence check
- For one accepted proof, produce a trace showing controller, verification method, proof purpose, canonicalization suite, digest suite, key-status check and policy rule.
- Return to chapter contents
CHAPTER 8 OF 10 · Protect the workflow
8. Control loaders, contexts and transformation boundaries
Core idea. JSON-LD processing can retrieve remote contexts that affect how keys expand into IRIs. If a context changes between signing and verification, the produced RDF can change or processing can fail. A verifiable graph workflow must govern dependencies as carefully as it governs keys.
Method. Pin context URLs to approved immutable content, cache verified copies, restrict network retrieval, set size and redirect limits, and record content digests. Treat base IRIs, generalized RDF options and RDF direction handling as part of the transformation contract.
Worked example. A signed JSON-LD document uses a context URL that later redirects to changed content. A verifier that follows the live redirect constructs different RDF and rejects the proof. An archived context and digest explain the difference and support reproducible verification.
Changed-context transfer. Move the workflow into an offline archive. Network access is unavailable, so a manifest of contexts and parser resources becomes a required part of the evidence package rather than an optimization.
Limits. Dependency pinning improves reproducibility but does not make a malicious context safe. Review semantic mappings and vocabulary authority; a perfectly pinned harmful transform remains harmful.
Misconception to avoid. The signed JSON text alone contains everything needed to reproduce its RDF. In JSON-LD, context and document-loader behaviour can be essential external inputs.
Practical evidence check
- Disable network retrieval in a test environment and verify that every accepted document can be transformed using only declared, integrity-checked dependencies.
- Return to chapter contents
Verification claim ladder
| Result | Supported statement | Unsupported leap |
|---|---|---|
| Canonical bytes match | The selected datasets canonicalised to the same bytes under the same algorithm and options | The source files were identical |
| Digest matches expected value | The canonical bytes match that digest, subject to the hash and channel | The data are true or complete |
| Signature verifies | The verification method validates a proof over the transformed input | The signer had authority for every claim |
| Schema and provenance checks pass | Declared constraints and recorded lineage meet the checks performed | No hidden omission, hostile context or policy breach exists |
Verification is strongest when transformation, algorithm version, proof purpose, key control and application policy are all explicit.
CHAPTER 9 OF 10 · Protect the workflow
9. Defend against ambiguity, poisoning and resource abuse
Core idea. Canonicalisation processes complex graph structure and may sit before expensive cryptographic operations. Attackers can exploit huge inputs, deep symmetry, pathological Unicode, duplicate-like quads or parser differentials. Security depends on rejecting ambiguous or excessive work predictably.
Method. Set limits for bytes, quads, blank nodes, recursion, permutations, wall time and memory; validate encoding; use maintained parsers; log failures without echoing sensitive data; and never fall back to hashing an uncanonicalized representation under the same identifier.
Worked example. A service receives a compact JSON-LD document that expands into millions of quads and a symmetric blank-node subgraph. The gateway stops expansion at the declared limit and returns a typed failure. It does not emit a digest that downstream systems might accept as canonical.
Changed-context transfer. Shift from an interactive API to a controlled research deposit. Larger limits may be reasonable, but isolation, quotas, deterministic builds and an audit record remain necessary because the trust boundary changed, not the algorithm.
Limits. Any limit can reject a legitimate dataset. Publish the profile, support a reviewed high-capacity path and keep failure distinct from inequality. Silent truncation is unacceptable.
Misconception to avoid. A cryptographic hash neutralizes denial-of-service risk. Hashing is usually cheap; constructing the canonical input can be the dominant and attacker-controlled cost.
Practical evidence check
- Run a corpus of valid, invalid, highly symmetric and oversized datasets; require consistent success, typed rejection and bounded resource use.
- Return to chapter contents
CHAPTER 10 OF 10 · Transfer and govern
10. Govern canonical identifiers as evidence, not ontology
Core idea. Canonical blank-node identifiers are products of a dataset and algorithm, not permanent identifiers for real entities. They are excellent for comparison traces and proof transformations but fragile as business keys when the dataset is edited or expanded.
Method. Keep source identifiers, canonical labels, content digests, package identifiers and provenance activities in separate fields. Version manifests, record software and options, and design cache invalidation around the exact canonicalization contract.
Worked example. A c14n label _:c14n3 is stored as a database key. Adding an unrelated symmetric subgraph changes canonical issuance and breaks references. Replacing that key with an application IRI or governed local identifier restores stable lifecycle semantics.
Changed-context transfer. Use canonical digests for deduplicating immutable snapshots. For living records, use versioned entity identifiers plus per-version digests so change is visible without pretending each snapshot is the enduring thing.
Limits. Content-addressed identifiers create self-reference problems when the identifier appears inside the content being hashed. Solve this only with a defined scheme, indirection or placeholder protocol; ad hoc deletion rules destroy interoperability.
Misconception to avoid. A canonical label is a trustworthy global name. It is deterministic only inside its defined calculation and may change when the dataset changes.
Practical evidence check
- Audit one implementation from source dataset to manifest, canonical bytes, digest, provenance activity and relying decision; confirm that each identifier has a declared scope and lifecycle.
- Return to chapter contents
Build a reproducible verification dossier
Record the original syntax, media type, base IRI, retrieval time and file digest before parsing. Then record the parser, RDF version, JSON-LD options, contexts and any transformations. This preserves both the source object and the abstract dataset path.
Store the RDFC-1.0 algorithm identifier, hash choice, implementation version, limits, canonical N-Quads digest and completion status. Where disclosure permits, retain canonical bytes or a secure pointer to them so a later reviewer can reproduce the digest rather than trust a screenshot.
For proofs, add controller, verification method, key material or resolver evidence, proof purpose, created time, key-status check and application policy. A cryptographic pass without this policy context is incomplete evidence.
End with the exact claim accepted: dataset equivalence, package integrity, proof validity or institutional authority. The dossier should make it impossible to replace one claim with a stronger-sounding one after the fact.
Diagnose a digest mismatch without guessing
Start at the outside. Compare media type, retrieved bytes and file digest. If files differ but canonical dataset digests match, the difference may be syntax, whitespace or comments. If dataset digests differ, move inward to parsed quads.
Diff canonical N-Quads lines, not the original source. Classify changes as term, literal, graph-name or blank-node-neighbourhood differences. A different datatype or language tag can be easy to miss visually yet is a genuine RDF-term change.
If only blank-node labels and order appear different, verify that both implementations completed the same algorithm and hash profile. Use conformance vectors and symmetric cases before claiming an algorithm defect.
Check loaders and contexts last but carefully: redirects, cached contexts, base IRIs and version announcements can explain a structural difference. Preserve the diagnosis as provenance rather than overwriting the earlier artifact.
Design a minimal interoperable canonicalisation profile
Name accepted RDF syntaxes and versions, parsing rules, base-IRI handling and forbidden or unsupported features. State whether empty named graphs matter and how they are represented outside canonical N-Quads if necessary.
Require RDFC-1.0, a named digest algorithm, UTF-8 output and explicit resource limits. Include expected error codes so two services agree not only on successful bytes but also on unsafe input handling.
Publish test vectors covering simple blank nodes, shared nodes across graphs, symmetry, Unicode, literals, relative IRIs, malformed inputs and limit cases. Run them in continuous integration for every parser or library update.
Version the profile independently from application policy. A proof suite can depend on a specific profile version, while a repository may adopt a newer profile for future deposits without silently changing historic identifiers.
Know when not to canonicalise
If the requirement is bit-level preservation of one file, hash the file. Canonicalising RDF intentionally discards formatting distinctions and cannot prove the archived bytes are unchanged.
If application entities need durable identifiers, assign governed IRIs or identifiers. Canonical blank-node labels are not a substitute for identity management, reconciliation or provenance.
If the requirement is semantic equivalence under an ontology, define and compute the relevant closure or query outcomes. Dataset isomorphism does not automatically capture inference, inconsistency handling or closed-world constraints.
If a simple trusted pipeline never crosses syntax or blank-node boundaries, canonicalisation may add cost without decision value. Use it when its explicit comparison surface solves a real interoperability or verification problem.
Questions readers ask
Does canonicalisation prove two RDF files are identical?
- No. It can show that selected parsed datasets produce the same canonical representation under the same contract. The original file bytes, comments and formatting may differ.
Are canonical blank-node identifiers permanent?
- No. They are deterministic outputs for a particular dataset and algorithm profile, and may change when the dataset changes.
Why not hash JSON-LD directly?
- A direct file hash is useful for byte integrity. It will change when semantically equivalent JSON-LD is rearranged, whereas RDF canonicalisation targets the parsed dataset.
Does a valid signature prove the claims are true?
- No. It proves a cryptographic relationship to protected input under a verification method. Authority, truth, completeness and policy acceptance are separate checks.
Can each named graph be canonicalised separately?
- Not safely in general. Blank nodes can be shared across graphs or used as graph names, so dataset context matters.
What should happen when a complexity limit is reached?
- Return a typed failure and no canonical result. Never truncate, partially label or silently fall back to a different representation.
Practise, verify and continue
Create two small RDF datasets with different blank-node labels and triple order. Write their quads, predict which nodes separate under first-degree hashing, identify any symmetric tie, and specify the exact bytes you would hash after canonicalisation.
Now add a remote JSON-LD context, an empty named graph and a content-addressed identifier inside the dataset. Explain which new dependencies and representation limits enter the contract, and which claims can no longer be made from one digest alone.
Related eduKate reading
SHACL validation reports, shapes graphs and constraint evidence
RO-Crate metadata, contextual entities and portable research objects
Content negotiation by profile and representation selection
Signposting, linksets, profiles and repository discovery
Authoritative sources and scope
W3C RDF Dataset Canonicalization (RDFC-1.0)
W3C RDF 1.2 Concepts and Abstract Data Model
W3C RDF 1.2 N-Quads
W3C Verifiable Credential Data Integrity 1.0
W3C RDF Dataset Canonicalization explainer and use cases
The examples are original teaching cases. They explain information modelling and verification boundaries, not a security guarantee for any deployment. Implementers should follow the normative specifications, current conformance tests and their own threat model.