@HolgerKnublauch added support for reification for SHACL to DASH a while ago. It's described in the DASH Reification Support for SHACL document. Two new properties are introduced: dash:reifiableBy is similar to sh:node. It points to one or more node shapes. The reified statements must conform to these node shapes. dash:reificationRequired marks the shapes for the reified statements as required.

I adapted the example of the document a little bit, covering the handling of the identifier (reifier):

Data graph with asserted triple and triple term:

# asserted triple
ex:Bob ex:age 23 .

# reified triples with syntactic sugar
<<ex:Bob ex:age 23>> 
  ex:date "2019-12-05"^^xsd:date ;
  ex:author ex:Claire .

The data graph without syntactic sugar shows how the identifier (reifier) is linked to the triple term:

# asserted triple
ex:Bob ex:age 23 .

# reified triples expanded to triple term
_:id rdf:reifies <<( ex:Bob ex:age 23 )>> .
_:id ex:date "2019-12-05"^^xsd:date .
_:id ex:author ex:Claire .

Here is the part of the shape graph that links from the ex:age property to the node shape for the reified triples:

ex:PersonShape-age a sh:PropertyShape ;
  sh:path ex:age ;
  dash:reifiableBy ex:ProvenanceShape .

ex:ProvenanceShape a sh:NodeShape .

dash:reifiableBy changes the focus node to reifier based on the logic described in this SPARQL query:

SELECT ?reifier WHERE {
  ?focusNode sh:path ?p.
  ?focusNode ?p ?o.

  BIND(tripleTerm(?focusNode, ?p, ?o) AS ?tt)

  ?reifier rdf:reifies ?tt.
}

We start with ex:Bob as the focus node in the ex:PersonShape-age property shape. dash:reifiableBy would trigger the logic in the SPARQL query. After that, the next focus node would be _:id. At the same time, we would also switch to the node shape ex:ProvenanceShape.

A missing piece is a way to navigate into a triple term when the triple is not asserted. There is no starting point to traverse to _:id without the asserted statement ex:Bob ex:age 23. Does anyone have a idea or proposal how this could be done?

Are there other existing implementations or proposals for reification in SHACL?

I'm using the DASH reification support regularly. I would support adding reification support as defined in DASH.

While the DASH Reification Support for SHACL is from the time of the RDF-star CG, it shows the << >> in the way that RDF 1.2 defines it.

"Triple terms" are triples. They are called "triple terms" because of their role as RDF terms.
SHACL node shapes will apply naturally.

It is possible to give a name to the reifier (blank node or IRI):

<<ex:Bob ex:age 23 ~:refiier123>>  .

is shorthand for the triple:

:refiier123 rdf:reifies <<( ex:Bob ex:age 23 )>> .

It is possible to assert a triple and have a reifying triple for it:

  ex:Bob ex:age 23  ~_:MyLabel .

which is

  ex:Bob ex:age 23 .
  _:MyLabel rdf:reifies <<( ex:Bob ex:age 23 )>> .

"Annotation Syntax" which both asserts a triple and has data about that triple is carried over into RDF 1.2:

ex:Bob ex:age 23 {| 
      ex:date "2019-12-05"^^xsd:date .
      ex:author ex:Claire 
|}.

which is in triples:

  ex:Bob ex:age 23 .
  _:genId rdf:reifies <<( ex:Bob ex:age 23 )>> .
  _:genId ex:date "2019-12-05"^^xsd:date .
  _:genId ex:author ex:Claire .
|}.

An annotation block can have a explicit reifier and there can be several annotation blocks for the same triple.

(None of this is completely finalized in RDF 1.2 yet - the WG welcomes comments.)

SPARQL has the same syntax forms as Turtle. In addition, there are SPARQL functions

• TRIPLE(?s, ?p, ?o)
• SUBJECT, PREDICATE, OBJECT
• isTRIPLE

What might be of interest to SHACL users is the section in RDF Concepts:
"Interoperability between RDF Classic and RDF Full"

"Full" is all RDF 1.2, "Classic" is RDF 1.2 without triple terms and probably will be renamed "Basic".
There is a defined transformation: https://w3c.github.io/rdf-concepts/spec/index.html#section-classic-full-interop

There should be a sh:nodeKind for triple terms (the <<( :s :p :o )>> above).

Adding the Or variants possibly isn't necessary - there would be a lot of URIs! - especially if sh:nodeKind is able to take a node expression.

A missing piece is a way to navigate into a triple term when the triple is not asserted. There is no starting point to traverse to _:id without the asserted statement ex:Bob ex:age 23. Does anyone have a idea or proposal how this could be done?

More precisely, what I meant by that:

sh:targetSubjectsOf combined with ex:age can be used to find the asserted triple. Then, dash:reifiableBy can be used to navigate to the reified triples. But if there is no asserted triple, that's not possible. There is no target to match for parts of the triple term equal to this SPARQL query:

SELECT * WHERE {
    <<?this ex:age ?other>> ?p ?o
}

Even sh:targetNode with the full triple term without variables would not work, as the triple term is in the object position.

I am cautious about adding new kinds of targets because (1) we now have node expressions and (2) when do we stop adding use case targets but it might be necessary here.

There is no target to match for parts of the triple term equal to this SPARQL query:

SPARQL-based targets could be used - presumably these will become sh:targetNode expression.

It is as if we have a two parts here - find all triple terms (new target), then efficiently filter that list down.

    sh:targetTripleTerms tripleTermSelector

where tripleTermSelector is a property shape to apply to the triple of the triple term.

Data Shapes WG needs to liaise with the RDF and SPARQL WG because RDF 1.2 isn't published yet so timing w.r.t data-shapes phase 1 needs clarifying.

@afs can you give an example of how such a tripleTermSelector shape would look like? How would that shape match to a non-asserted triple?

That's how a Node Expression for sh:targetNode could look like:

[
  sh:targetNode [
    sh:reifierMatch [
      sh:subject ex:Bob;
      sh:predicate ex:age
    ]
  ]
]

Reifiers can be found:

[ 
    sh:targetSubjectsOf rdf:reifies .
    . . .
]

sh:tripleTermMatch would be an better name.

Wider point: the sh:targetSubjectsOf rdf:reifies could be a very broad selection.

Is there a way to have additional conditions (for any target selection) for better selection? Jumping to SPARQL is a big jump and is a replacement of any existing target selection. A sort of dynamic sh:targetNodes and also sh:targetSubjectsOf (and other targets) together.

From the telecon 2025-04-28:

Turtle has syntax:

<< ex:s ex:p ex:o >> ex:q "some value".

this looks like the RDF-star CG proposal but isn't - this is intentional because many uses of RDF-star CG are in fact about what RDF.1.2 calls occurences - uses of the triple, not the triple itself.

In RDF 1.2, it is the two triples:

_:r ex:q "some value".
_:r rdf:reifies <<( ex:s ex:p ex:o )>> 

See #368 (comment)