Reified triples and compound triple form syntax.

[afs]

Turtle 1.1 has two syntax forms that generate multiple triples on parsing, blankNodePropertyList (e.g. [ :p 123 ; :q "abc" ]) and collection (e.g. ("A" "B" "X")).

The grammar productions subject and object allow collections, the object production also allows blankNodePropertyList (a blankNodePropertyList in the subject position is handled in production triples.

The syntax for reified triples in Turtle 1.2 uses subject and object (editors working draft of 12 September 2024).

    reifiedTriple         ::= '<<' (subject | reifiedTriple) verb object reifier? '>>'

allows collections in the subject position, and allows collections and blankNodePropertyList in the object position.

A reified triple declaration such as:

    << :s :p [ :q1 "A" ; :q2 "B" ] >> .

generates

    _:b0    :q1     "A";
            :q2     "B" .
    _:b1    rdf:reifies  <<( :s :p _:b0 )>> .

The triples from the blankNodePropertyList structure are in the set of triples of the graph. They are not reified. The blank node for the [ ...] is in the reified triple.

PR #70 address this by having productions rtSubject and rtObject for subject and object position in reified triples, and defines them to include only "single triple" possibilities (c.f. the existing ttSubject and ttObject`).

A similar situation exists for annotation syntax except that blankNodePropertyList triples are meant to be in the set of triples of the graph, so there is no effect.

The only confusing factor is that the reification of the annotation only includes the blank node subject of the blankNodePropertyList or collection, not the compound form triples.This is not fixable in any practical way but does not add make additional assertions into the graph.

[gkellogg]

By that logic, it would seem you'd need to restrict reifiedTriple from being included as well, as it also can generate a blank node.

<< :s :p << :s1 :p1 :o1 >> >> .

generates

_:b0 rdf:reifies <<(:s1 :p1 :o1)>> .
_:b1 rdf:reifies <<( :s :p _:b0)>> .

Similar for a reifiedTriple in the subject position.

[afs]

Suppose for illustration, :name is an inverse functional property:

    << :s1 :p1 [ :name "Finley" ; :DoB "2024-05-01" ] >> .
    << :s2 :p2 [ :name "Finley" ; :DoB "2024-03-09" ] >> .

gives:

    _:b0   rdf:reifies   <<( :s1 :p1 _:b1 )>> .
    _:b2   rdf:reifies   <<( :s2 :p2 _:b3 )>> .
    _:b1   :name "Finley" ;  :DoB "2024-05-01" .
    _:b2   :name "Finley" ;  :DoB "2024-03-09" .

In the case of nested reifiedTriple, yes, there is some extra naming. It is safe in the sense that it does not assert ":s1 :p1 :o1".