where are triple terms allowed

[pfps]

Some recent documents only show triple terms in object positions. But several use cases have what would be triple terms in subject positions.

https://github.com/w3c/rdf-ucr/wiki/Capturing-triple-origin-in-SPARQL-star
https://github.com/w3c/rdf-ucr/wiki/Describing-a-Union-of-Changes-to-a-Named-Graph
https://github.com/w3c/rdf-ucr/wiki/RDF-star-for-CIDOC-CRM-events
https://github.com/w3c/rdf-ucr/wiki/RDF-star-for-contextualizing-historical-assertions
https://github.com/w3c/rdf-ucr/wiki/RDF-star-for-labelled-property-graphs
https://github.com/w3c/rdf-ucr/wiki/RDF%E2%80%90star-for-Wikidata

[afs]

I am confused: looking the use cases, they seem to be about (named) occurrences, often annotation syntax.

Please could we have an example of the use of a triple term in the subject position?

To pick one of the UC:

<< <7d5d0d651caa> :subject <semantics> >> :suggestedBy <classifyer> .

I would have thought that was an occurrence .

(this comment in no way is an opinion about whether they should be / should not be allowed)

[pfps]

Yes, these should probably now be occurrences, which could result in them not requiring triple terms as subjects.

[TallTed]

I see now that the seeking-consensus table only includes TRIPLE_TERM in the object position. (I also see that it doesn't include OCCURRENCE at all.)

I feel strongly that this is an error, and that TRIPLE_TERM should also be allowed in the subject position. It certainly breaks with my intuition of how TRIPLE_TERM should be handled.

Perhaps we now need an option 3b (treating the existing option 3 as 3a)?

Why is the same markup, << <7d5d0d651caa> :subject <semantics> >>, in —

<< <7d5d0d651caa> :subject <semantics> >> :suggestedBy <classifyer> .

— an OCCURRENCE, while in —

<classifyer> :suggested << <7d5d0d651caa> :subject <semantics> >>.

— it's a TRIPLE_TERM?

I would like to know why people feel that TRIPLE_TERM should not be allowed in the subject position — i.e., what would this (be likely to) break? Is this restriction an optimization to avoid an anticipated performance hit, before that hit has been realized through implementation experimentation?

[gkellogg]

Use cases are satisfied using Occurrences, not Triple Terms. A Triple Term exists as the object of a triple relating the occurrence to the triple term via rdf:nameOf (or suitable replacement). There is no use case for using a Triple Term in the subject position. Ideally, we could have an option where a Triple Term isn't necessary at all, but it is necessary to describe what triple an occurrence is for.

The fact that this point keeps getting either confused, or misunderstood, may not bode well for the general design, as without thorough rationale, these issues will keep coming up in the wider community.

[hartig]

@TallTed

Why is the same markup, << <7d5d0d651caa> :subject <semantics> >>, in —

<< <7d5d0d651caa> :subject <semantics> >> :suggestedBy <classifyer> .

— an OCCURRENCE, while in —

<classifyer> :suggested << <7d5d0d651caa> :subject <semantics> >>.

— it's a TRIPLE_TERM?

It is not. Instead, in both cases it is an occurrence.

... and in both cases it is syntactic sugar that expands to a triple with a corresponding triple term in the object position and rdf:nameOf as predicate (or some other suitable IRI—it is still under discussion what this predicate IRI should be).

That is, the first of your examples is a shorthand notation for the following two triples (written in the abstract syntax as defined in PR #78, assuming b is a fresh blank node and all the other components are properly expanded IRIs).

( b,  rdf:nameOf,  (<7d5d0d651caa>, :subject, <semantics>) )
( b,  :suggestedBy,  <classifyer> )

Note that the object of rdf:nameOf triple is a triple term.

Your second example expands to the following two triples.

( b,  rdf:nameOf,  (<7d5d0d651caa>, :subject, <semantics>) )
( <classifyer>,  :suggestedBy,  b )

Note that in both cases the rdf:nameOf triple is the same.

Now you may also ask how these pairs of triples would look like in N-Triples format or in Turtle. The currently-considered markup for triple terms when written in these formats is <<( ... )>>. Hence, for your first example, this would look as follows (where _:xyz is just a randomly picked blank node identifier for the blank node b).

_:xyz   rdf:nameOf    <<( <7d5d0d651caa> :subject <semantics> )>> .
_:xyz   :suggestedBy  <classifyer> .

And for your second example:

_:xyz          rdf:nameOf     <<( <7d5d0d651caa> :subject <semantics> )>> .
<classifyer>   :suggestedBy   _:xyz.

[afs]

It seems from the comments discussion above, all use cases work using occurrences.

As this came up in the telecon of 2024-03-07 for follow-up, to move this forward, can we establish a example.

@TallTed, do we have a counter-example to idea that "all use cases work using occurrences", where a triple term is used, not triple occurrence, in the subject position. Even better, where an occurrence can not be used.

@pfps, are you still happy with your comment

Yes, these should probably now be occurrences, which could result in them not requiring triple terms as subjects.

[TallTed]

@afs

@TallTed, do we have a counter-example to idea that "all use cases work using occurrences", where a triple term is used, not triple occurrence, in the subject position. Even better, where an occurrence can not be used.

I don't have such a counter-example.

Partly, because I still do not understand what the definitions of triple term and triple occurrence are; hence, do not understand what the difference(s) between these definitions might be; hence, cannot say what use cases might be (un)satisfied by either in any position.

To date, the only difference I'm aware of between the definitions is simply that a triple term (recently a/k/a rdf:triple) is defined to be forbidden to be an rdf:subject. I do not know the reason for this forbiddance.

[gkellogg]

The RDF-star use cases are satisfied using the reification triples, of which triple term is a component. A well formed RDF-star graph will have a triple term only being the object in a triple which also uses the rdf:reifies predicate and an IRI or Blank Node subject. Triple Term is necessary to create an atomic term which contains everything about that triple. The reification is an identified reference to a triple term. Using a triple term outside of this "macro" (or equivalent expansion) is not well formed and has no use case.

[afs]

@Gregg

Using a triple term outside of this "macro" (or equivalent expansion) is not well formed and has no use case.

Agreed. We are focusing on the "reification well-formed" (= RWF.) case.

@TallTed

I do not know the reason for this forbiddance.

(no advocacy summary of how we got here follows ...)

RWF gives a formal account of the meaning of occurrences (possible usage of a triple in a graph).

The use cases the working group is addressing are covered by "reification well-formed".

The RDF data model (RDF abstract syntax) does not enforced the well-formed condition,
e.g. a single triple :e rdf:reifies <<( :s :p :o )>> is a legal RDF graph. It is legal as N-triples.

Currently, the state is that the proposed RDF data model does not allow triple terms in the subject position. That was the outcome of discussions prior to the introductionof RWF. It wasn't necessary to allow triple terms in the subject position and the group wished to encourage/emphasise the use of "occurrences" (new form reification) as tokens.

There is some opinion within the working group that triple terms in the subject position should be allowed. See, for example, the RDF Abstract syntax (the RDF data model) in RWF. It does not affect the reification well-formed condition.

The RDF collections (lists) situation is similar but with the difference that lists are given by vocabulary. They are not mentioned in the RDF data model, or "RDF Concepts". Non-well-formed lists are very rare in my experience - they mainly come up in making sure Turtle/Trig writers can cope with data with non-well-formed lists, not in data in the wild.