Add processor state, term constructor, and triple constructors. Change reifiedTriple to reifingTriple.

[gkellogg]

... for annotationBlock, tripleTerm, and reifier.

Also, extract the annotationBlock production from the annotation production.

---

Preview | Diff

[gkellogg]

Source lines 1764-1768 may still need work — I'm not sure what "set from" means, compared to "set to" and "taken from". This part of the doc may become clearer with walk-through examples, with real values — and may need that help for readers other than me, too.

I'd like to get some input from @afs before making more changes, as I believe the original style for processor events may be his invention. We have not previously given examples of how to parse documents, and I don't think it makes sense to do so now. My guess is that most parsers tend to do their own thing and not strictly follow these rules, but they're needed to express the intention for how to turn Turtle into the Abstract Syntax.

[TallTed]

Rather than 17 (or more) suggestions, one comment:

reifing should be reifying, in all cases, matching the case of the existing occurence.

[gkellogg]

Rather than 17 (or more) suggestions, one comment:

reifing should be reifying, in all cases, matching the case of the existing occurence.

Fixed! Brain fart in search/replace.

[hartig]

I am skeptical about the change of reifiedTriple to reifyingTriple.

I understand that expressions accepted by this production are meant to be parsed into a reifying triple (using the term "reifying triple" here as per the current definition in PR https://github.com/w3c/rdf-concepts/pull/98). But conceptually, at least for me, such an expression is something else than a reifying triple, and calling such an expression a "reifying triple" may be a source for confusion.

For instance, the expression

<< ex:bob  foaf:knows  ex:alice >>

matches the production. If we were to refer to this expression as a "reifying triple", I guess many users would assume that the triple (ex:bob, foaf:knows, ex:alice) is the one that we refer to as being "reifying", but it is not. Instead, the reifying triple is the one that this expression expands to; namely:

_:b rdf:reifies <<( ex:bob  foaf:knows  ex:alice )>> .

As a separate but related comment, I think that replacing the term "reified triple" by "reifying triple" as currently done in this PR -- namely, in the first two sentences of Section 2.10 -- is wrong. I created two separate review comments for these two sentences (comment 1 and comment 2).

[gkellogg]

As a separate but related comment, I think that replacing the term "reified triple" by "reifying triple" as currently done in this PR -- namely, in the first two sentences of Section 2.10 -- is wrong. I created two separate review comments for these two sentences (comment 1 and comment 2).

I disagree, but I'm open to alternatives. We need the concept reifying triple, and the reifyingTriple production does result in the spelled out form, so seems appropriate to me.

[TallTed]

I am taking this thread out of the context of any single suggestion, because it will get lost there (as have previous conversations).

We need the concepts of both a Reifying Triple and a Reified Triple.

These are distinct.

We have been talking about both for quite some time, and still we have gone back-and-forth with identifying the same thing as being an instance of one of these concepts and then the other.

A Reifying Triple is a triple that has a predicate of rdf:reifies.

A Reified Triple is the object of a triple that has a predicate of rdf:reifies.

<< ex:bob foaf:knows ex:alice >> might be read has having left out the optional ~ :reifier (and what seems to me to be an optional but necessarily implied .) following ex:alice, making this the complete expression:

<< ex:bob foaf:knows ex:alice ~ [] . >>

That's sugar for the actual reifying triple, which is

[] rdf:reifies <<( ex:bob foaf:knows ex:alice . )>> .

That reifies the now-reified triple,

ex:bob foaf:knows ex:alice .

I hope that's all clear....

[gkellogg]

A Reified Triple is the object of a triple that has a predicate of rdf:reifies.

We call that a Triple Term.

<< ex:bob foaf:knows ex:alice >> might be read has having left out the optional ~ :reifier (and what seems to me to be an optional but necessarily implied .) following ex:alice, making this the complete expression:

<< ex:bob foaf:knows ex:alice ~ [] . >>

The following are equivalent:

• << ex:bob foaf:knows ex:lice >>
• << ex:bob foaf:knows ex:lice ~ >>
• << ex:bob foaf:knows ex:lice ~ [] >>

They are all the same as [] rdf:reifies <<( ex:bob foaf:knows ex:lice )>> .

Note that the reifiedTriple (or whatever we finally settle on) production does not include the . in the grammar.

[TallTed]

A Reified Triple is the object of a triple that has a predicate of rdf:reifies.

We call that a Triple Term.

In other words, "we call the object of a triple that has a predicate of rdf:reifies a Triple Term" instead of calling it the rather more intuitive "Reified Triple".

At the risk of howls of "bike-shedding", that says to me that rdf:reifies and reifiedTriple should be revisited, in favor of either a different verb or something that's not a verb at all.

[gkellogg]

@afs, I re-worked the Triple Constructors partly based on your feedback, but it's possible I missed some of your points.

• Removed the "Triple Terms" section, which didn't seem to be needed.
• The Reifier handler now always emits a reifying triple and sets curReifier.
• The Annotation Block handler sets curReifier if not set, in which case it assigns a blank node and emits the reifying triple.
• The Reified Triples handler sets curTripleTerm and produces the node based on curReifier.
• The Annotations handler sets curTripleTerm and stacks curReifier similar to curSubject and curPredicate.

[pchampin]

This was discussed during the rdf-star meeting on 2024-08-29: https://www.w3.org/2024/08/29-rdf-star-minutes.html#t04