THE GOLD STANDARD OF INFORMATION · SPECIALIST STUDY
Know when two RDF literals mean the same value without being the same term
RDF stores literals as carefully defined terms, not as untyped display strings. A literal carries a lexical form and either a datatype IRI, a language tag, or—in RDF 1.2—a language tag plus base direction. Some datatypes allow different spellings for the same value, while term identity can still preserve those spellings. Reliable exchange therefore needs two questions: are these the same RDF term, and do they denote equal values under a declared datatype and comparison rule?
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 | Typical operation |
|---|---|---|
| Lexical form | Which Unicode character sequence was written? | Character-for-character comparison |
| RDF term | Do lexical form, datatype, language and direction meet the term-equality rule? | sameTerm or exact graph comparison |
| Datatype value | Do valid lexical forms map to the same value? | Datatype-aware equality |
| Application match | May a search or workflow treat them as equivalent? | Declared normalization, collation or policy |
Do not use a broad application match as a silent substitute for RDF term identity. Record which layer answered the question and preserve the original term.
CHAPTER 1 OF 10 · Build the foundations
1. Separate characters, terms, values and matches
Core idea. A lexical form is a Unicode string. The complete RDF literal also records a datatype IRI or language information, and RDF term identity follows the full term construction. A recognized datatype may map several lexical forms to one value, while an application may define an even broader match. These layers answer different questions and support different evidence claims.
Method. Write every comparison as four columns: source characters, RDF term components, datatype mapping and application purpose. Choose the narrowest relation that satisfies the decision. Preserve both terms when a value comparison says equal but lexical provenance, signatures, display or round-trip fidelity still matters.
Worked example. The literals “1”^^xsd:integer and “01”^^xsd:integer are not the same RDF term because the lexical forms differ. If both are valid, XML Schema maps them to the integer value one. A numeric filter can treat their values as equal while an audit can still report that the source spellings changed.
Changed-context transfer. Move the method to dates. Two dateTime literals can denote the same instant after timezone processing yet carry different lexical zones. A scheduling calculation may compare instants, while a records system keeps the submitted offset because it explains how the event was recorded.
Limits. Datatype support varies, lexical-to-value mapping can fail, and equality is not defined uniformly across every datatype pair. Do not extrapolate one numeric example to language strings, XML literals, custom datatypes or ill-typed data.
Misconception to avoid. If two literals display the same text, they are the same RDF term. Display often hides datatypes, Unicode sequences, language-tag case and direction, so visual identity is weak evidence.
Practical evidence check
- For ten literals, name the comparison layer used by storage, graph diff, query, display, search and audit; flag every place where one layer is being mistaken for another.
- Return to chapter contents
CHAPTER 2 OF 10 · Build the foundations
2. Treat the lexical form as evidence, not decoration
Core idea. The lexical form is the character sequence recorded in the RDF term. It may preserve leading zeros, explicit signs, timezone spelling, decimal scale or a source system’s exact label. Even when datatype semantics collapse several forms to one value, the form can remain important for provenance, user intent and faithful export.
Method. Capture the source lexical form before transformation, parse under an explicit datatype, and record any canonical or display form separately. When rewriting is allowed, state the rule, reason, software version and reversible path. Never present an automatically rewritten form as the source text.
Worked example. A measurement arrives as “01.00”^^xsd:decimal. Calculation uses decimal one, but the ingest record keeps “01.00” because the submitting instrument emitted fixed-width fields. Replacing it with “1” would preserve value yet weaken evidence about the source format and a possible instrument fault.
Changed-context transfer. In multilingual labels, punctuation and spacing may look cosmetic but be part of the recorded string. Search can trim or fold a derived index while the RDF graph retains the exact lexical form for export and correction.
Limits. Preserving every form does not mean every form is valid or useful. A profile can reject prohibited lexical forms, but the rejection should be explicit and should not silently coerce malformed evidence into a plausible value.
Misconception to avoid. Datatype canonicalization is harmless cleanup. It can break signatures, hashes, source fidelity, display expectations and applications that compare RDF terms exactly.
Practical evidence check
- Take one import that rewrites numbers or dates and prove which downstream decisions need values, which need original terms and how a reviewer can see the transformation.
- Return to chapter contents
CHAPTER 3 OF 10 · Apply the core method
3. Use datatype lexical spaces and value spaces correctly
Core idea. A datatype defines a lexical space, a value space and a mapping from valid lexical representations to values. The datatype IRI names that contract. RDF processors may recognize some datatypes and leave others uninterpreted; the graph can still contain a typed literal even when a consumer cannot compute its value.
Method. Validate lexical membership only against the intended datatype version. Distinguish an unsupported datatype from an invalid lexical form. Keep parser errors, datatype registry choices and timezone or precision rules visible, then test both accepted and rejected fixtures.
Worked example. “true”^^xsd:boolean and “1”^^xsd:boolean are different RDF terms but map to the same boolean value under XML Schema. By contrast, “yes”^^xsd:boolean is not in that lexical space. A system must not quietly convert “yes” to true and claim RDF datatype conformance.
Changed-context transfer. For a domain datatype such as a versioned identifier, publish the lexical grammar, value interpretation and equality rule. Consumers that do not recognize it can preserve the term without pretending to validate its business meaning.
Limits. Datatype maps can be partial, custom datatypes can be poorly specified, and floating-point values introduce exceptional cases. Equality and ordering may be undefined or surprising at boundaries.
Misconception to avoid. A datatype IRI guarantees every client shares its implementation. The IRI identifies a contract; deployment, version and conformance still need evidence.
Practical evidence check
- Build a fixture with two synonymous valid forms, one invalid form, one unsupported datatype and one boundary value; compare parser, validator and query behaviour.
- Return to chapter contents
CHAPTER 4 OF 10 · Apply the core method
4. Apply RDF 1.2 language-tag identity rules
Core idea. Language-tagged strings combine a lexical form and a language tag. RDF 1.2 removes an earlier ambiguity by making tags case-insensitively unique for literal identity: tags that differ only by case do not create different literals when the lexical form is the same. Implementations still need a consistent stored or displayed form.
Method. Validate tags against the applicable BCP 47 syntax and profile, compare tag subtags without case sensitivity where RDF 1.2 requires, and retain source spelling only as separate provenance if it matters. Do not translate, stem or collapse regional subtags as part of RDF identity.
Worked example. “colour”@en-GB and “colour”@EN-gb identify the same RDF 1.2 language-tagged literal. “colour”@en and “colour”@en-GB remain different terms because the tags contain different subtag sequences, even if a search policy chooses to match both under an English language range.
Changed-context transfer. Transfer to script subtags: a label tagged sr-Latn is not silently identical to sr-Cyrl merely because both are Serbian. A translation or transliteration relationship should be modelled explicitly, and the original label should remain available.
Limits. A valid tag does not prove the text is actually written in that language, and language-range matching is not literal identity. Human review may be needed for mis-tagged or mixed-language content.
Misconception to avoid. Language tags are decorative metadata that can be lowercased or dropped at export. They participate in the language-tagged value and affect matching, speech, fallback and accessibility.
Practical evidence check
- Create labels that vary tag case, region, script and lexical form one component at a time; test term identity, language-range filtering and user-interface fallback separately.
- Return to chapter contents
CHAPTER 5 OF 10 · Apply the core method
5. Keep ordinary and directional language strings distinct
Core idea. RDF 1.2 directional language-tagged strings add a base-direction component to the lexical form and language tag. Direction participates in the value and term identity. An ordinary language-tagged literal is not automatically the same term as a directional literal that happens to render similarly.
Method. Represent text, language and base direction as separate fields through storage, query and API layers. Use exact comparison for graph operations and a documented projection for older clients. When direction is unavailable, preserve absence instead of inventing a default as source evidence.
Worked example. An Arabic label recorded as text plus ar plus rtl differs from the same text recorded only as @ar. A modern interface may render both right-to-left through heuristics, but only the first asserts base direction. A downgrade must report that the third component was lost.
Changed-context transfer. In a bilingual spreadsheet, use explicit language and direction columns instead of inserting invisible bidirectional controls into the text. A later RDF importer can reconstruct the intended term and audit the transformation.
Limits. Direction is not alignment, script or a complete Unicode layout instruction. Client support may lag the specification, so term preservation and accessible rendering require separate tests.
Misconception to avoid. If two labels look the same in a browser, dropping direction is lossless. Visual coincidence in one host context does not establish RDF identity or reliable display elsewhere.
Practical evidence check
- Trace one directional label through Turtle, a store, SPARQL results, JSON, an editor and write-back; compare all three components at each boundary.
- Return to chapter contents
Worked literal comparison matrix
| Literal pair | Term identity | Value comparison |
|---|---|---|
| “1”^^xsd:integer and “01”^^xsd:integer | Different lexical forms, so different RDF terms | Both map to integer one |
| “chat”@en and “chat”@EN | RDF 1.2 treats language tags case-insensitively for literal identity | Same language-tagged value |
| “é” and an e plus combining acute | Different character sequences unless explicitly normalized | Application-dependent; RDF does not silently normalize |
| “1.0”^^xsd:decimal and “1.00”^^xsd:decimal | Different terms | Same decimal value |
Results depend on valid lexical forms and supported datatypes. An implementation must not invent a datatype value for an ill-typed literal.
CHAPTER 6 OF 10 · Test evidence and alternatives
6. Normalize Unicode only under an explicit application rule
Core idea. RDF lexical forms are Unicode strings, and visually identical text can use different code-point sequences. RDF term identity does not grant permission to apply Unicode normalization silently. Normalization can be valuable for search or profile validation, but it creates a derived representation governed by a named form and version.
Method. Retain original code points, generate a normalized search key such as NFC only where justified, and record the algorithm and Unicode version. Test characters whose compatibility normalization changes meaning or presentation, and keep security review separate from linguistic equivalence.
Worked example. One label uses precomposed “é”; another uses e plus a combining acute. They may render alike yet are different lexical forms. A search index can normalize both to improve recall while the RDF graph and a forensic export keep the originals.
Changed-context transfer. For identifiers, compatibility normalization can be more dangerous than for free text because width, mathematical and presentation distinctions may be intentional. Use profile-specific rules and show users what will be compared.
Limits. Normalization does not solve confusables, mixed scripts, language identification or all canonical-equivalence problems. Unicode evolves, and clients can render the same sequence differently.
Misconception to avoid. NFC is part of RDF literal equality. It is not a universal RDF identity step; applying it changes the lexical form unless the profile explicitly defines a derived view.
Practical evidence check
- Compare precomposed, decomposed, compatibility and confusable fixtures; prove that search gains do not overwrite the canonical source graph.
- Return to chapter contents
CHAPTER 7 OF 10 · Test evidence and alternatives
7. Choose sameTerm, value equality and search matching deliberately
Core idea. SPARQL and application APIs expose more than one comparison. sameTerm tests RDF-term identity, while the equals operator can perform datatype-aware value comparison or raise type errors. Full-text search, collation and language filtering add separate relations. Query design must name the one the decision needs.
Method. Write paired tests for sameTerm, =, DISTINCT, grouping, ordering and joins. Include invalid and unsupported datatypes. Return original terms with any normalized key so a user can see what matched, and document how errors or incomparable values are handled.
Worked example. A query joining identifiers stored as “1”^^xsd:integer and “01”^^xsd:integer fails under sameTerm but can match under numeric value equality. If the join is for invoice identity, the broader match may be unsafe; if it sums quantities, numeric equality may be appropriate.
Changed-context transfer. For language search, a case-folded text match can return several tags and directions. The interface groups candidates without asserting that their RDF terms are identical.
Limits. SPARQL implementations and extension functions can differ, especially for custom datatypes and collations. A query that works on one engine is not proof of portable semantics.
Misconception to avoid. Use = whenever users mean “the same.” Equality is purpose-dependent: term, value, identifier, record, label and search equivalence are not one relation.
Practical evidence check
- Run the comparison suite on two deployed engines and record every result, error and ordering difference before promising interoperability.
- Return to chapter contents
CHAPTER 8 OF 10 · Handle limits and disagreement
8. Separate graph canonicalisation from literal canonicalisation
Core idea. RDF dataset canonicalisation stabilizes blank-node labels and quad ordering for a selected dataset. It does not generally rewrite literal lexical forms to datatype canonical representations. A canonical dataset digest can therefore preserve the distinction between different RDF terms that denote equal datatype values.
Method. Define the transformation stack in order: parse, profile validation, optional semantic projection, dataset canonicalisation, serialization and hashing. Give every derived view a distinct identifier and prevent a value-normalized view from masquerading as the asserted graph.
Worked example. Two datasets differ only by integer lexical forms “1” and “01”. They can be value-equivalent for a calculation yet produce different canonical RDF bytes because the literals are different terms. A separate normalized analytical view may converge, but its digest answers a different question.
Changed-context transfer. In data warehousing, a conformed numeric column can support aggregation while the RDF preservation layer keeps submitted terms. Link the views with transformation provenance rather than declaring one universal canonical form.
Limits. Entailment, datatype reasoning and custom rewrite rules can be expensive, incomplete or non-monotonic across versions. Hashes remain meaningful only when the exact view and algorithm are named.
Misconception to avoid. Canonical RDF makes all semantically equal literals byte-identical. Dataset canonicalisation addresses structural serialization, not every possible theory of semantic equivalence.
Practical evidence check
- Create one fixture for blank-node renaming and another for equal-valued different literals; confirm the first digest matches and the second remains distinct under the asserted-dataset contract.
- Return to chapter contents
Interoperability evidence ladder
| Test | What it proves | What it does not prove |
|---|---|---|
| Parse and round-trip | The processor preserves the selected term components | All consumers implement the same datatype semantics |
| sameTerm and graph comparison | Exact RDF-term distinctions survive | Values are unequal in every application |
| Datatype-aware equality | Recognized datatype values compare as expected | Original lexical evidence can be discarded |
| Search normalization test | A documented application match works | The match is RDF identity or universally safe |
A successful search test is not a graph-isomorphism test, and a canonical graph digest is not a licence to rewrite lexical forms.
CHAPTER 9 OF 10 · Handle limits and disagreement
9. Build a literal interoperability profile and test suite
Core idea. Interoperability requires more than syntax acceptance. A profile should state supported datatypes, lexical validation, language-tag handling, direction, Unicode policy, comparison operations, error treatment, serialization and downgrade behaviour. Conformance fixtures make those choices observable.
Method. Publish positive, negative and round-trip cases. Test term identity and value operations independently. Include case-only language tags, multiple valid lexical forms, invalid forms, unsupported datatype IRIs, directional strings, Unicode variants and lossy formats. Report every downgrade.
Worked example. A catalogue profile supports xsd:string, boolean, integer, decimal, date and language tags. CSV export cannot preserve datatype and direction in one cell, so it emits structured companion columns and refuses re-import as authoritative unless all fields are present.
Changed-context transfer. A research archive can use a broader datatype set but may choose preservation over evaluation. It must still prove that unknown typed literals survive byte-for-byte through migration.
Limits. Profiles can overconstrain legitimate RDF or become obsolete. Version them, publish change notes and include an extension path rather than treating current implementation limits as permanent semantic law.
Misconception to avoid. A parser’s unit tests are an interoperability profile. Unit tests reveal one implementation; a profile also defines shared obligations, errors, versions and evidence across systems.
Practical evidence check
- Exchange the same fixture pack with a second producer and consumer; compare not only successful parses but warnings, errors, exact terms and write-back results.
- Return to chapter contents
CHAPTER 10 OF 10 · Transfer and govern
10. Govern transformations so meaning can be challenged
Core idea. Literal processing is an accountable information pipeline. Users need to know when software preserved a term, rejected it, parsed a value, normalized a search key or rewrote a canonical view. Provenance and correction routes keep helpful automation from becoming invisible semantic authority.
Method. Record source, asserted term, transformation, software version, derived result, reason, time and reviewer. Provide a diff that shows lexical, datatype, language and direction changes. Let responsible users correct source mappings and rebuild derived indexes without deleting history.
Worked example. A migration lowercases language tags and canonicalizes booleans. The release notes identify that tag case does not change RDF 1.2 identity while boolean lexical rewrites do change terms. The preserved source graph lets auditors reproduce both the old and new views.
Changed-context transfer. In a classroom dataset, a student can test “01” and “1” through exact and value comparisons. The same method transfers to production governance: name the relation, preserve evidence and explain the consequence.
Limits. Provenance can expose sensitive source text or user identifiers, so access, minimisation and retention matter. A complete log is not automatically a proportionate public log.
Misconception to avoid. Once a value is parsed, the original term has no further use. Original terms may be needed for signatures, disputes, export, display, debugging and proof of what was received.
Practical evidence check
- Select one transformation in the pipeline and demonstrate source preservation, declared semantics, reproducibility, correction, access control and a safe rollback.
- Return to chapter contents
Build a literal comparison worksheet
For each candidate pair, record code points, lexical form, datatype or language components, validity and recognized datatype semantics. Do not begin with a single yes-or-no equality column.
Add separate results for RDF term identity, datatype value equality, ordering, language-range match, normalized search and application identity. State which operation or specification produced each result.
Include an explanation of consequences: graph diff, DISTINCT, join, display, signature, deduplication and correction can legitimately use different relations.
Review every broad match for false merges and every narrow match for missed discovery. Preserve the original terms so the policy can change without destroying evidence.
Design a reversible normalization pipeline
Freeze the asserted RDF input and assign it a fixity value before rewriting. Define each derived view—Unicode-normalized search, datatype-canonical analytics or display formatting—separately.
Version transformation code, datatype libraries, Unicode data and language-tag rules. A library upgrade can change output even when the source graph is unchanged.
Produce term-level diffs and counts by transformation reason. Unexpected changes should block release rather than become silent cleanup.
Let a reviewer trace every derived literal back to its asserted term and regenerate the view. Reversibility is an operational test, not a promise in documentation.
Audit equality at system boundaries
List databases, RDF stores, APIs, query engines, caches, CSV exports, search services and interfaces. For each boundary, name the literal components carried and the equality operation applied.
Test a fixture where only one component changes at a time. Include lexical spelling, datatype IRI, tag case, tag subtag, base direction and Unicode sequence.
Mark every lossy boundary and prevent it from writing back to the authoritative graph without reconstruction evidence. Provide warnings that users can understand.
Repeat the audit after upgrades, because a processor can add RDF 1.2 support while a client library or result serializer still drops the new component.
Create a migration and dispute register
Record every planned rewrite, affected predicates, rationale, legal or scientific significance, test evidence, owner and rollback route. Separate identity-preserving changes from value-preserving but term-changing changes.
Invite domain experts to review mappings where lexical form carries meaning. A numeric engineer, linguist and archivist may see different risks in the same rewrite.
Track disputes and corrected assumptions. Do not force ambiguous cases into a universal normal form merely to complete a migration count.
Close a migration only when authoritative RDF, derived views, indexes, exports, signatures and documentation agree on the new contract and unresolved exceptions remain visible.
Questions readers ask
Can two different RDF literals have the same datatype value?
- Yes. Different valid lexical forms can map to the same datatype value while remaining different RDF terms.
Does RDF automatically normalize Unicode?
- No. Applications may create normalized derived views, but they should preserve the asserted lexical form and name the rule.
Are @en and @EN different language tags in RDF 1.2 literal identity?
- No. RDF 1.2 treats language-tag case insensitively for identity when the lexical form is the same.
Is SPARQL sameTerm the same as the equals operator?
- No. sameTerm tests RDF-term identity; equals can perform datatype-aware value comparison and can encounter type errors.
Does canonicalising an RDF dataset canonicalise numeric lexical forms?
- Not generally. Dataset canonicalisation stabilizes blank-node labelling and serialization while preserving literal terms.
Should a migration replace every literal with a canonical lexical form?
- Only under an explicit, reviewed profile. Such rewrites can change RDF terms and affect provenance, signatures and exact comparisons.
Practise, verify and continue
Create a twelve-row fixture containing equal-valued numeric spellings, a malformed boolean, an unsupported datatype, language tags that differ by case and subtag, a directional label, NFC and decomposed Unicode, and two custom identifiers. Predict sameTerm, value equality, search match and round-trip results, then test them on the actual stack.
Move the worksheet from RDF to a spreadsheet import or research data pipeline. Identify which cells need exact source preservation, which need typed calculation, which need normalized discovery and which must remain disputed rather than merged.
Related eduKate reading
RDF 1.2 directional language-tagged strings and base direction
RDF dataset canonicalisation, blank-node labelling and verifiable graphs
RDF 1.2 triple terms, reification and provenance boundaries
SPARQL named graphs, dataset boundaries and query reproducibility
SHACL validation reports and constraint evidence
Authoritative sources and scope
W3C, RDF 1.2 Concepts and Abstract Data Model
W3C, RDF 1.2 Semantics
W3C, SPARQL 1.2 Query Language
W3C, XML Schema Definition Language 1.1 Part 2: Datatypes
W3C, RDF Dataset Canonicalization
This article explains data-model and interoperability principles; it is not a substitute for the current normative specifications, a product conformance statement or legal records advice. RDF 1.2 documents and implementations can have different maturity and support. Test deployed parser, query, serializer and client versions. Preserve asserted terms before normalization, distinguish unsupported from invalid datatypes, and report lossy projections. Examples are original teaching fixtures. Security review should address Unicode confusables, hostile lexical forms, resource limits and unsafe coercion without excluding legitimate multilingual text. A gold-standard pipeline names the comparison relation, preserves source evidence, versions its rules, makes errors visible and lets people challenge a transformation.