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".

[niklasl]

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.

I've been back and forth on this for some time. Sometimes you may want to reify the full "chunk", sometimes not. I think the way it is solved here for blank nodes here is balanced. If you need to reify e.g all of:

<bob> :knows [a :Person ; :name "Alice" ] .

it is readily possible to "tag" each statement with the reifier through the named annotation syntax:

<bob> :knows [a :Person  ~ _:r1 ; :name "Alice"  ~ _:r1 ] ~ _:r1 .

It could be argued that you want that to happen automatically; but the converse argument is that it would be too powerful and implicit, and easy to get wrong (and that in order to reify just the relation, you'd have to name the bnode in those cases).

For collections, it is more complicated. The affordance of list syntax is different, and the blank cons tree is a technical detail. Example 3 in w3c/rdf-ucr#26 illustrates this.

(I think this line of reasoning goes equally for annotation and occurrence notation. But it should be noted that the ergonomics is quite different for occurrence notation. Whereas annotations work well with—and cater for—the regular grouping by subject common in Turtle data, for unasserted triples, the syntax we have caters for neither grouping on subject nor reifier. It is rooted on each single triple. Declaration style makes it a bit easier to visually group on either, albeit both require repeating the identifier.)

[rat10]

I think this:
<< :s :p [ :q1 "A" ; :q2 "B" ] >> .
should be forbidden. A reifier term is composed of one triple, not of a set of triples. (*)

This here:
<bob> :knows [a :Person ~ _:r1 ; :name "Alice" ~ _:r1 ] ~ _:r1 .
is possible and it reifies the whole set of triples, not only the list.

If each of the list items were to be annotated, the following should suffice:
<bob> :knows [a :Person ~ _:r1 ; :name "Alice" ~ _:r1 ] .
i.e. there is not necessarily a need to include <bob> :knows _:b.. (**)

If the list itself is to be annotated my best bet would be this:
<bob> :knows _:b ~ _:r2 . _:r2 rdf:object [ a ex:ExampleList ] .

(*) In my little syntax draft I made a suggestion for syntactic sugar to express a reifier consisting of multiple triples, i.e. a many-to-many reifier.
(**) IMO a forEach "operator" to explicitly annotate e.g. all members of a list instead of the list itself (or 'in toto') would be useful, but I guess that's out of scope for this WG. It was present in RDF 1999, but didn't make it into RDF 1.0. We survived so far without, but IMO it would be a useful addition.

[gkellogg]

I think this: << :s :p [ :q1 "A" ; :q2 "B" ] >> . should be forbidden. A reifier term is composed of one triple, not of a set of triples. (*)

[26]	reifiedTriple	::=	'<<' rtSubject verb rtObject reifier? '>>'
[27]	rtSubject	::=	iri | BlankNode | reifiedTriple
[28]	rtObject	::=	iri | BlankNode | literal | tripleTerm | reifiedTriple

This is forbidden, according to the current Turtle Grammar.

This here: <bob> :knows [a :Person ~ _:r1 ; :name "Alice" ~ _:r1 ] ~ _:r1 . is possible and it reifies the whole set of triples, not only the list.