Most real knowledge graph questions are not just "is this true?" but "according to whom, since when, and how sure are we?". A supplier relationship came from a contract system; a diagnosis came from a coded record; a link between two companies was extracted by a language model with some confidence. In classic RDF, attaching that context to a single fact meant reification patterns that were verbose, inconsistent between teams and awkward to query.
What RDF 1.2 adds
RDF 1.2 introduces triple terms: an RDF triple that can itself appear as a term inside another triple1. To say something about a statement, you use a reifying triple, whose predicate is rdf:reifies and whose object is the triple term; the reifier then carries whatever metadata you need1. This standardises ideas first explored in the RDF-star community work4.
In Turtle 1.2's annotation syntax, a fact and its metadata can be written together, along these lines:
:acme :supplies :globex {| :source :contractSystem ;
:since "2024-03-01"^^xsd:date ;
:confidence 0.92 |} .The base fact remains an ordinary triple that existing queries can use, while the annotation hangs off a reifier that refers to it.
The RDF 1.2 Concepts specification reached Candidate Recommendation on 7 April 20262, part of a wider set of RDF 1.2 and SPARQL 1.2 specifications from the working group. SPARQL 1.2 adds the matching query support3. Check the current W3C status before committing production systems to it.
Why it matters for enterprise graphs
| Need | Before RDF 1.2 | With RDF 1.2 |
|---|---|---|
| Provenance per fact | Named graphs or custom reification patterns | Standard reifier with source metadata |
| Time validity | Extra intermediate nodes | Annotations on the statement itself |
| AI-extracted facts with confidence | Separate staging graphs | Confidence and model version on each fact |
| Interchange between tools | Vendor-specific RDF-star variants | One standard model and syntax |
The AI case is the most pressing. When a model extracts relationships from documents for GraphRAG or entity resolution, every new edge should carry where it came from, which model produced it and how confident it was, so curators can review and agents can weigh it.
A fact without provenance is a liability in an enterprise graph. RDF 1.2 makes the responsible way to store facts also the standard way.
RDF 1.2 and property graphs
Property graph databases have always allowed properties on edges, and they now have an international query language standard, ISO/IEC 39075 GQL5. Edge properties were one of the main reasons teams chose property graphs over RDF. RDF 1.2 narrows that gap with statement-level metadata, while RDF keeps its strengths: global identifiers, ontologies and validation with SHACL, and taxonomies in SKOS.
The choice is still about workload and ecosystem, as discussed in ontology vs knowledge graph vs semantic layer. What changes is that "we need properties on relationships" is no longer a reason on its own to leave RDF.
How I'd adopt it
- Check tool support. Triple stores, parsers and SHACL engines adopt new specifications at different speeds; test the features you need in your own stack.
- Define a provenance vocabulary before modelling: source system, extraction method, model version, confidence, validity period.
- Annotate new facts first, especially AI-extracted ones, rather than migrating everything at once.
- Keep base triples queryable, so existing applications keep working while new ones use annotations.
- Write shapes for annotations, so required provenance is validated, not just encouraged.
How I can help
I design ontology and knowledge graph programmes where every fact can be traced and trusted, including graphs that AI systems both read from and write to. See ontology and knowledge graphs, or analyse your challenge and bring the result to a call.
- 1
- 2
- 3
- 4RDF-star and SPARQL-star (Community Group report)W3C RDF-DEV Community Group
- 5