Support for RDF 1.2 triple terms (without asserted triple)

[bergos]

PR #368 covers the use case with asserted triples. But we haven't decided yet how to deal with targets for reifiers that don't have an asserted triple. SPARQL and Node Expressions could be used, but we may want to support these use cases in the core specification out-of-the-box. Examples and use cases should be collected for further discussions.

Example data without asserted triple:

# asserted triple is not present in the graph!
# 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 .

[recalcitrantsupplant]

Here's a potential extension:

Example 1:

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

ex:TripleTermValidationShape sh:targetObjectsOf rdf:reifies ;
    sh:reifiedSubject [
        sh:nodeKind sh:IRI ;
    ] ;
    sh:reifiedPredicate [
        sh:in ( ex:age ex:height ) ;
    ] ;
    sh:reifiedObject [
        sh:datatype xsd:integer ;
        sh:minInclusive 0 ;
    ] .

Example 2 with nested triple terms:

<< ex:Bob ex:age 23 >> ex:confidence 0.9 .
_:s rdf:reifies << << ex:Bob ex:age 23 >> ex:confidence 0.9 >> .

ex:ConfidenceShape sh:targetObjectsOf rdf:reifies ;
    sh:reifiedSubject ex:InnerTripleShape ;
    sh:reifiedPredicate [
        sh:hasValue ex:confidence ;
    ] ;
    sh:reifiedObject [
        sh:datatype xsd:decimal ;
        sh:minInclusive 0.0 ;
        sh:maxInclusive 1.0 ;
    ] .

ex:InnerTripleShape sh:reifiedSubject [
        sh:nodeKind sh:IRI ;
    ] ;
    sh:reifiedPredicate [
        sh:hasValue ex:age ;
    ] ;
    sh:reifiedObject [
        sh:datatype xsd:integer ;
    ] .

So sh:reifiedSubject, sh:reifiedPredicate, sh:reifiedObject would be functionally similar to sh:property (I think not sub properties though). The shapes would be similar to property shapes, without the need for sh:path, with the value node being explicit from the property used. I don't believe the triple term would need to be materialised or put into the data graph (or any other new triple term related graph).

Targeting via sh:targetObjectsOf rdf:reifies could potentially be quite broad.

[bergos]

Here is a list of possible use cases for reification in SHACL with proposals on how SHACL could be extended to cover it.

The following example data graph is used for all use cases:

ex:age a rdf:Property ;
  ex:version 1 .

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

# reifier refering to a reifier
# << << ex:Bob ex:age 23 >> ex:author ex:Claire >> .
_:id2 rdf:reifies <<( _:id ex:author ex:Claire )>> .
_:id2 ex:login "Claire321" .

Targets

Triple term

One may want to define a target for a triple term to reach the reifier based on a pattern for the triple term. A new target sh:targetTripleTerm would be introduced with a blank node object value that can be used to define a triple pattern with the properties sh:subject, sh:predicate, and sh:object. The following example would match all triple terms with the predicate ex:age like <<( ex:Bob ex:age 23 )>> in our example data.

ex:shape a sh:NodeShape ;
  sh:targetTripleTerm [
    # sh:subject ex:Bob
    sh:predicate ex:age
    # sh:object 23
  ];
  sh:property [
    sh:path ( [sh:inversePath rdf:reifies] ex:date );
  ].

Is reifier

Selecting only subjects that are/aren't reifiers could be another requirement. The target filter would be extended with an additional property sh:targetReifier. If it's true, only reifiers will be selected, reifiers would be excluded if it's false. The following example would match the _:id target as it's a reifier.

ex:shape a sh:NodeShape ;
  sh:targetSubjectsOf ex:author ;
  sh:targetReifier true;
  sh:property [
    sh:path ex:date ;
  ].

Traverse

All parts of a triple term could be useful for further traversing a path. This is not possible with the existing property path tools.

Traverse out of a triple term

The sh:triplePartOut path would allow traversing out of any triple part if the focus node is a triple term. The object must be one of the triple parts (sh:Subject, sh:Predicate, or sh:Object). The following example would start at the <<( ex:Bob ex:age 23 )>> triple term and traverse into ex:age, and next to the value of ex:version.

ex:shape a sh:NodeShape ;
  sh:targetTripleTerm [
    sh:subject ex:Bob
  ];
  sh:property [
    sh:path ([sh:triplePartOut sh:Predicate] ex:version) ;
    sh:in (1 2)
  ].

Traverse into a triple term

The sh:triplePartInpath would allow traversing into a triple term. The object must be one of the triple parts (sh:Subject, sh:Predicate, or sh:Object). Additional parts of the triple term can be matched with sh:subject, sh:predicate, or sh:object. The following example would start at ex:Claire, traverse into the triple term <<( _:id ex:author ex:Claire )>>, to the reifier _:id2, and last to the value of ex:login.

ex:shape a sh:NodeShape ;
  sh:targetObjectsOf ex:author ;
  sh:property [
    sh:path ([sh:triplePartIn sh:Object; sh:predicate ex:author] [sh:inverse rdf:reifies] ex:login) ;
    sh:in ("Claire321")
  ].

Is reifier constraint

The count of rdf:reifies triples can be used to check if a focus node is a reifier. A short hand constraint sh:isReifier could be defined. The object must be a boolean.

ex:shape a sh:NodeShape ;
  sh:targetSubjectsOf ex:author ;
  sh:isReifier true.

@recalcitrantsupplant My proposal for traversing covers your use case. I favor the sh:path solution because that would keep sh:path the main tool for traversing and it could be used in a sequence to without the shape overhead.

[afs]

<< ex:Bob ex:age 23 >> ex:confidence 0.9 .
_:s rdf:reifies << << ex:Bob ex:age 23 >> ex:confidence 0.9 >> .

is the triples:

_:b0    rdf:reifies   <<( ex:Bob ex:age 23 )>>;
        ex:confidence  0.9 .
_:b1    rdf:reifies  <<( ex:Bob ex:age 23 )>> .
_:b2    rdf:reifies  <<( _:b1 ex:confidence 0.9 )>> .
_:b3    rdf:reifies  _:b2 .

-- no nesting
-- the object of rdf:reifies should be a triple term.

Did you mean:

<< ex:Bob ex:age 23 >> ex:confidence 0.9 .
_:s rdf:reifies <<( << ex:Bob ex:age 23 >> ex:confidence 0.9 )>> .

but that gets into trouble because << >> is compound

<< ex:Bob ex:age 23 >> ex:confidence 0.9 .

is the 2 triples

_:r rdf:reifies  <<( ex:Bob ex:age 23 )>> .
_:r ex:confidence 0.9 .

and can't be inside <<( ... )>>.

You can write:

##<< ex:Bob ex:age 23 >> ex:confidence 0.9 .
_:r rdf:reifies  <<( ex:Bob ex:age 23 )>> .
_:r ex:confidence 0.9 .

## One reifier, _:s, two triples.
_:s rdf:reifies <<( _:r rdf:reifies  <<( ex:Bob ex:age 23 )>> )>> .
_:s rdf:reifies <<( _:r ex:confidence 0.9 )>> .

[recalcitrantsupplant]

Thanks Andy, I was intending to have nesting like << << ex:Bob ex:age 23 >> ex:confidence 0.9 >> ex:version 2 .
So:

_:r rdf:reifies  <<( ex:Bob ex:age 23 )>> .
_:r ex:confidence 0.9 .

_:s rdf:reifies <<( _:r rdf:reifies  <<( ex:Bob ex:age 23 )>> )>> .
_:s rdf:reifies <<( _:r ex:confidence 0.9 )>> .
_:s ex:version 2 .

@recalcitrantsupplant My proposal for traversing covers your use case. I favor the sh:path solution because that would keep sh:path the main tool for traversing and it could be used in a sequence to without the shape overhead.

Yes I think your proposal is better for that reason + being able to go in/out. The pattern matching within paths is not intuitive for me but I can't see a better option.

[HolgerKnublauch]

What about the suggestion by @PapoutsoglouE in the meeting this week: that SHACL Core does not have to cover all scenarios when a reasonable alternative already exists in SHACL-SPARQL? In particular, it sounds like SPARQL could be combined with a sh:targetNode expression.

In my personal opinion, reification on existing triples will be much more common than on unasserted triples.

[afs]

Thanks Andy, I was intending to have nesting like << << ex:Bob ex:age 23 >> ex:confidence 0.9 >> ex:version 2 . So:

Each << >> becomes a bnode to use in further triples, and also generates a rdf:reifies triple.

<< << ex:Bob ex:age 23 >> ex:confidence 0.9 >> ex:version 2 .` 

is in triples:

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

_:b1    rdf:reifies  <<( _:b0 ex:confidence 0.9 )>>;
        ex:version   2 .

with a blank node for the ex:confidence. No nesting (of triple terms).

Nesting can happen but it will (the WG believes) be rare because data talks about someone else use of a triple, not the abstract triple.

FWIW There is an online service that parses Turtle syntax and outputs N-triples: https://www.sparql.org/data-validator.html

[afs]

What about the suggestion by @PapoutsoglouE in the meeting this week: that SHACL Core does not have to cover all scenarios when a reasonable alternative already exists in SHACL-SPARQL? In particular, it sounds like SPARQL could be combined with a sh:targetNode expression.

Which scenarios are we talking about here? The minutes do not say which.
Once SHACL Core goes to REC, there is much less chance to change it.
We have to cover known use case but also provide for future use cases that arise after publication.

So it seems to me that the WG should at least know what the operations needed are, then decide where they go. e.g. sh:nodeKind.
Earlier, the WG was quite enthusiastic to avoid depending on SPARQL.

In my personal opinion, reification on existing triples will be much more common than on unasserted triples.

Quite likely but not uniformly. A situation that refers to triples elsewhere (unasserted triples) is likely to have that pattern throughout the data.

[bergos]

Even though I collected all the use cases, I don't have a strong opinion on whether to add it to the core or if we accept that node expressions are required. While working on the examples, I reflected on how it could be implemented with node expressions. sh:targetNode and sh:values should provide everything needed to implement the use cases with node expressions. The functions would have a similar structure to the proposals I made for core. Support for triple term path in sh:path would probably look cleaner than the same logic with node expression and sh:values.

What's missing from my point of view:

• Feedback on which features are requested and the prio for it.
• Volunteers who would add the features to the spec and write tests for it.

I'm happy to help once we have answers for these points, but I can't do it entirely alone as there are also other things on my to-do list.

[afs]

Slides from the public presentation by Niklas Lindström about RDF 1.2 reification

https://niklasl.github.io/rdf-docs/presentations/RDF12-Lotico-2026-06/

[afs]

Here are some basic validation tasks that I think are reasonable to expect (in #300 or #379)

1. Triples with property rdf:reifies must have an object that is a triple term.
2. Triples with an annotation of :added must also be asserted.
3. Triples with annotation :deleted true must not be asserted.
4. All triples with property :xyz must have a reifier
5. All triples with property :xyz must have an annotation that includes exactly one :added and one :date
6. Annotations involving :abc only apply to triples with property :xyz
7. Only triples with property :xyz can have a reifier
8. Only triples with property :xyz can have a reifier, and it must a IRI
9. Only triples with property :xyz can have an annotation
10. Triples with property :xyz must not have an annotation (they can have a reifier)

[bergos]

I've created a new issue #407 for 1. to extend the list of options for sh:nodeKind. That must be added in core and can't be added later with SPARQL or node expressions. I think core covers all other use cases as it is right now.