Re: Summary of the options on the table

On 26/01/2024 11:29, Thomas Lörtsch wrote:
> Hi Pierre-Antoine,
>
>
> thank you for this table! Of course, I have questions…
>
> First about the table row "Supports one name for several triples?".
Sorry, I admit that this is a rather cryptic title for a notion that has 
been discussed more or less formally in various channels. Fortunately, 
once I post this email, I will have a link with a clear explanation :)
>   What does that mean and how does the sugar proposal differ from all others in that respect? As far as I understood, every proposal allows to name multiple occurrences/instances of the same triple - just as RDF standard reification does. Furthermore each proposal provides some mechanism to prevent that the same occurrence name can refer to more than one triple, but that is covered in the next row, "Atomicity". So what is the meaning if the row "Supports one name for several triples?"?

You are correct, these two rows ("Supports one name..." and "Atomicity") 
are somehow related.

You can think of "Support one name for several triples" as meaning:
   is it possible to annotate a /set/ of triples with the "edge" construct ?

Consider the following Turtle:

     << :e | :s1 :p1 :o1 >>.
     << :e | :s2 :p2 :o2 >> :a :b.

(I'm slightly abusing the Turtle notation here by using the << .. >> 
notation as a standalone statement)

With the "sugar" proposal, it expands to

     <e> <rdf:subject> <s1> .
     <e> <rdf:subject> <s2> .
     <e> <rdf:predicate> <p1> .
     <e> <rdf:predicate> <p2> .
     <e> <rdf:object> <o1> .
     <e> <rdf:object> <o2> .
     <e> <a> <b>.

and this graph would not be well formed, so this practice would be 
discouraged.

Even if you accept ill-formed-graphs (as you are allowed to do -- 
well-formed-ness is a weak constraint),
note that it could then be serialized back as follows (among other things):

     << :e | :s1 :p2 :o1 >>.
     << :e | :s1 :p2 :o1 >>.
     << :e | :s1 :p1 :o2 >>.
     << :e | :s2 :p2 :o1 >> :a :b.

(after all, they generate exactly the same triples)
which is probably not what you expected when writing the original Turtle.

None of the other proposals suffers from this. Even in the sugar+ 
proposal, the triples generated would be

     <e> <rdf:nameOf> _:t1.
     _:t1 <rdf:subject> <s1> .
     _:t1 <rdf:predicate> <p1> .
_:t1<rdf:object> <o1> .
     <e> <rdf:nameOf> _:t2.
     _:t2 <rdf:subject> <s2> .
_:t2<rdf:predicate> <p2> .
_:t2<rdf:object> <o2> .
     <e> <a> <b>.

which is well-formed, and does not shuffle the subjects, predicates and 
objects of the two triples.

>
> The next question I should actually address to Enrico, but since he’s in South Africa and you made the table, I'll bother you ;-) Why is it significant that a blank node and not an IRI represents the reification?

(assuming you are talking about "sugar+" here, more precisely its 
variant proposed by Enrico here: 
https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jan/0138.html)

I think the main reason for introducing a blank node here is simply 
because the concrete syntax does not provide a way to name this 
intermediate node. So the easiest thing to do is to introduce a fresh 
blank node. Note that Peter proposes as an alternative: "Instead of a 
fresh blank node the node might be determined by :s, :p, and :o" 
(https://github.com/w3c/rdf-star-wg/blob/main/docs/sugar-proposal.md#syntax).

What I believe is important in Enrico's variant is that well-formed-ness 
only concerns the reification nodes that are in the object position of 
rdf:nameOf (or rdf-star:is-reification-of) . Outside of this context, 
the predicates rdf:subject, rdf:predicate and rdf:object can be used any 
way you want: on bnodes or IRIs, with missing or multiple values... 
Enrico does not want any existing (or possible) RDF 1.1 graph to be 
deemed ill-formed in RDF 1.2.

> And why is that indirection via rdf:nameOf needed in the first place, what’s its special power?

I believe that the explanation above illustrate the special power of 
that indirection.

   pa

>
>
> Best,
> Thomas
>
>
>> On 25. Jan 2024, at 18:14, Pierre-Antoine Champin<pierre-antoine@w3.org>  wrote:
>>
>> (resending to the correct mailing-list, sorry about the confusion)
>>
>> Hi everyone,
>>
>>
>> following last week's discussions (on Thursday and Friday), I tried to collate the different options that are on the table. Their description is scattered in many places (minutes, emails, documents and wiki pages on github), so I tried to summarize them all in one document, with links to what I consider are the more recent sources.
>>
>> https://htmlpreview.github.io/?https://github.com/w3c/rdf-star-wg/blob/main/docs/seeking-consensus-2024-01.html

>>    (source:https://github.com/w3c/rdf-star-wg/blob/main/docs/seeking-consensus-2024-01.md)
>>
>> As can be seen, for each proposal, we have a relatively clear and stable description of the corresponding abstract syntax and semantics. They are aggressively summarized in this document, but the link to the source can be used to access the more detailed description.
>>
>> Hopefully, this synthetic document will help us discuss the commonalities and differences between the different approaches, and help each of us decide what they can and can not live with.
>>
>>    pa
>>
>>
>>
>> <OpenPGP_0x9D1EDAEEEF98D438.asc>
>