Tracking: RDF 1.2 support

[domel]

Goal and compatibility model

Track a staged implementation of RDF 1.2 support in RDFLib while preserving existing RDF 1.1 behavior.

The compatibility boundary is explicit:

• existing parser and serializer identifiers retain their RDF 1.1 behavior;
• RDF 1.2 syntax support is introduced through explicit RDF 1.2 plugins;
• existing serializers fail clearly when an RDF 1.2-only term cannot be represented, rather than emitting new syntax or losing information;
• each core model change remains independently reviewable and keeps existing RDFLib behavior unchanged outside its documented additions.

Why this is split into multiple pull requests

RDF 1.2 support touches several largely independent parts of RDFLib: the core term model, Literal semantics, blank-node-aware utilities, graph canonicalization, concrete syntax parsers/serializers, and Turtle/TriG reification syntax.

This work is intentionally split into smaller pull requests because RDFLib's contribution guidelines explicitly prefer smaller changes that can be reviewed and merged independently. The split also reduces regression risk and makes it possible to validate backwards compatibility after each stage.

In particular:

• TripleTerm and directional language-tagged strings change different parts of the core data model and can be reviewed independently;
• canonicalization/isomorphism is algorithmically high-risk and should not be bundled with basic term construction;
• N-Triples/N-Quads support is substantially simpler than Turtle/TriG support and provides an earlier end-to-end validation of the RDF 1.2 model;
• Turtle/TriG TripleTerm parsing can be reviewed separately from reified-triple and annotation syntactic sugar;
• existing RDF 1.1 parser and serializer behavior can be regression-tested after every incremental merge.

The goal is one coherent RDF 1.2 milestone implemented through a sequence of small, reviewable, backwards-compatible pull requests rather than one large change set.

Relationship to PR #3447

PR #3447 is an important starting point and contains several good design ideas that this plan intends to preserve, including TripleTerm(Node), structural TripleTerm equality/hashing, nested triple terms, rdf:reifies, a Literal(..., direction=...) API, and awareness that blank-node-sensitive operations must recurse into triple terms.

This implementation plan differs in scope and architecture in several ways:

1. The work is split into small, dependency-aware PRs instead of one large PR.
2. TripleTerm is designed as a truly immutable term because RDFLib stores use RDF terms as dictionary/set keys.
3. TripleTerm and directional language-tagged strings are separate core PRs, allowing independent review and parallel progress.
4. rdfs:Proposition is added together with rdf:reifies.
5. Recursive triple-term traversal is centralized in shared internal helpers instead of being reimplemented independently across modules.
6. Literal.direction is propagated through all relevant Literal semantics, including eq(), deterministic ordering, normalization/reconstruction, repr, and pickling, not only __eq__, __hash__, and rendering.
7. Canonicalization/isomorphism is isolated into its own high-risk PR with dedicated embedded-blank-node tests rather than bundled with unrelated core changes.
8. Graph.reify() and CBD changes are not part of the minimum core API.
9. util.from_n3() does not gain a separate ad-hoc recursive RDF 1.2 tokenizer; parser logic belongs in the actual syntax parsers.
10. Existing RDF 1.1 parser/serializer identifiers keep their current behavior. RDF 1.2 syntax is introduced through explicit RDF 1.2 plugins.
11. Existing serializers must not silently emit RDF 1.2 syntax or drop directional metadata; unsupported RDF 1.2 terms must fail clearly.
12. Turtle 1.2 triple terms (<<( ... )>>) are kept semantically distinct from reified triples (<< ... >>) and annotation blocks ({| ... |}).
13. VERSION handling and W3C RDF 1.2 conformance tests are part of the planned end-to-end implementation.

This is an incremental, review-oriented continuation of the RDF 1.2 work started in #3447, with a stronger compatibility boundary and smaller merge units.

Implementation tracking

Core model

• Add RDF 1.2 TripleTerm core model #3525 RDF 1.2 TripleTerm core model — open

  • immutable TripleTerm
  • nesting
  • structural equality, hashing, and deterministic ordering
  • rdf:reifies
  • rdfs:Proposition
  • Graph, Store, and NodePickler integration
  • RDF 1.1 serializer safety guards

• Add RDF 1.2 directional language-tagged strings #3526 RDF 1.2 directional language-tagged strings — open

  • Literal(..., direction="ltr"|"rtl")
  • rdf:dirLangString
  • equality, hashing, value comparison, and deterministic ordering
  • normalization, reconstruction, repr, and pickling
  • RDF 1.1 serializer safety guards

Core utilities

• PR 3: Triple-term-aware blank-node utilities and canonicalization
  • shared recursive term utilities
  • skolemization and de-skolemization
  • canonicalization, isomorphism, and graph diff

Concrete RDF 1.2 syntaxes

• PR 4: N-Triples 1.2 and N-Quads 1.2

  • nt12 and nquads12
  • triple terms
  • directional language-tagged strings
  • VERSION "1.2"
  • W3C RDF 1.2 tests

• PR 5: Turtle 1.2 and TriG 1.2 core syntax

  • turtle12 and trig12
  • triple terms <<( ... )>>
  • directional language-tagged strings
  • VERSION and @version
  • W3C RDF 1.2 tests

• PR 6: Turtle/TriG RDF 1.2 reification syntax

  • reified triples << s p o >>
  • explicit reifiers
  • annotation blocks {| ... |}
  • W3C RDF 1.2 tests

Later or separate considerations

• RDF/XML 1.2 directional language support
• media type version=1.2 dispatch
• Triple-term-aware CBD
• optional convenience reification API
• from_n3() RDF 1.2 integration
• additional persistent Store compatibility
• SPARQL support
• documentation and examples beyond per-PR minimums

Dependencies

PR	Scope	Depends on	May be reviewed in parallel with
PR 1	TripleTerm core	—	PR 2
PR 2	dirLangString core	—	PR 1
PR 3	recursive utilities and canonicalization	PR 1	late PR 2 work
PR 4	N-Triples/N-Quads 1.2	PR 1 + PR 2	PR 5 after dependencies merge
PR 5	Turtle/TriG 1.2 core syntax	PR 1 + PR 2	PR 4
PR 6	Turtle/TriG reification syntax	PR 5	—

PR 1 and PR 2 are independent branches based directly on main. PRs 3–6 should be proposed against main after their required dependencies have merged, so reviews do not include unrelated predecessor diffs.

Specifications and test suites

• RDF 1.2 Concepts and Abstract Syntax
• RDF 1.2 Schema
• RDF 1.2 Turtle
• RDF 1.2 TriG
• RDF 1.2 N-Triples
• RDF 1.2 N-Quads
• W3C RDF 1.2 test suites

[domel]

I have also almost finished PR3, but I will wait for the green light on PR1 and PR2.