Re: Annotation distributivity (Re: Summary: Annotation Syntax Proposals)

> On 25. Jan 2021, at 12:40, Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu> wrote:
> 
> 
> 
> On 23/01/2021 17:06, thomas lörtsch wrote:
>> 
>>> On 22. Jan 2021, at 14:13, Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>
>>>  wrote:
>>> 
>>> 
>>> On 22/01/2021 12:55, thomas lörtsch wrote:
>>> 
>>>>> I can see why you would feel like this, but then how would you
>>>>> suggest we write something producing just my answer?
>>>>> 
>>>> Easy:
>>>> 
>>>> :s :p1 :o1 . :s :p1 :o2 {| :source :URL1 |} ; :p2 :o3 {| :source
>>>> :URL3 |} .
>>>> 
>>> Actually, since you propose to also distribute annotation on semicolon, in order to get the result I suggested, we need write:
>>> 
>>>   :s :p1 :o1 .
>>>   :s :p1 :o2 {| :source :URL1 |}.
>>>   :s :p2 :o3 {| :source :URL3 |} .
>>> 
>>> 
>>> 
>>>>> Finally, I believe that implementing such distribution of
>>>>> annotation would be harder to implement for developers writing
>>>>> Turtle* parsers.
>>>>> 
>>>> Maybe, probably. But it would make life easier for users, and isn’t
>>>> that what developers aim for?
>>>> 
>>> 
>>> I agree that we should in general favor ease of use over ease of development.
>>> 
>>> However, I disagree that this makes the users' life easier. It makes some use-cases easier, and others harder, as illustrated above.
>>> 
>>> More precisely, the current proposal makes it easier when to annotate each triple differently (you can still factorize the     subjects with ";" and subject-predicates with ","), and forces you to repeat the annotation if you want the same annotation on several triples.
>>> 
>>> Your proposal, on the other hand, makes it shorter to put the same annotation on several triples, but more verbose to annotate each triples differently -- as illustrated above.
>>> 
>>> These are two different trade-offs. Both have their pros and cons, but I do prefer the first one, for the reasons I mentioned before, and repeated below:
>>> 
>>> 
>>>>> RDF* is about annotating triples individually (as opposed to named
>>>>> graphs), so I don't think the syntax should default to annotate
>>>>> several of them at once.
>>>>> 
>>>> This is syntax to avoid repeating subjects and predicates.
>>>> 
>>> Yes! :-)
>>> 
>>> 
>>>> It has
>>>> nothing to do with named graphs. Taking the aversion against named
>>>> graphs to this level doesn’t seem productive.
>>>> 
>>> I have no aversion against named graphs, and I don't see what in this sentence made you think so.
>>> 
>>> On the contrary, I was suggesting that if you want the same annotations on a bunch of triples, maybe a better solution is to put them all in a named graph, and annotate that named graph. This has been one argument raised against RDF* by some people, because "a bunch" can also be "one", and so they claim you don't need RDF* at all.
>>> 
>>> If we consider (and I do) that both RDF* and named graphs have their role to play, then the "sweet spot" for RDF* is in annotating each triple differently, leaving the "same annotation for all" use-case to named graphs (without of course forbidding to do with RDF* either).
>>> 
>>> Hence my personal preference for a non-distributive annotation syntax.
>>> 
>> If you use named graphs to group annotations what do you need RDF* for? Where is the line between annotations via RDF* versus those via named graphs?
> I don't have a definite answer to that question, only a hunch.
>>  And as named graphs can be used for a lot of purposes they can’t be used for all those purposes at once, especially as they don’t support nesting natively. So I find the reference to named graphs not helpful.
> It was my intent to make it helpful. Sorry it didn't work.
>> What I was pointing at is that the proposed syntax runs contrary to the way Turtle groups RDF triples.
> I got that, but I still respectfully disagree.
> 
> Turtle groups triples that have a common subject and multiple predicate-objects (with ";") or common subject-predicate and multiple objects (with ",").
> 
> Distributive annotations amount to group triples with a common predicate-object (e.g. {| :p :o |} ) with multiple subjects (all embedded triples "generated" before the annotation). So in my perspective, this is actually opposite to the way Turtle groups triples.

The basic mechanism by which nodes are grouped in Turtle is reading from left to right: all predicates right from the subject have that subject, all objects right from predicate and subjects have that prediacte and subject. So it seems natural that annotations annotate all subjects, predicates and objects left of them.
IIUC the intuition behind your approach requires to first conceptualize the embedded triples that the PG-syntax hides: that is one step more and therefor less intuitive.

OTOH I generally prefer to write one triple per line, like

    :s :p :o1 ,
          :o2 .

over

    :s :p :o1, o2 .

and in that case your approach is better as I wouldn’t want the annotation in

    :s :p :o1 ,
          :o2  {| :y :z |} .

to refer to the first triple

    :s :p :o1

as well. That would seem wrong too.
Another possibility to goup annoatations would be to allott meaning to line breaks :

    :s :p :o1 ,
          :o2
               {| :y :z |} .

Here the annoatation would annotate all triples left and above of it. But I guess that’s diverging too much from Turtle as we know it. So to annotate both triples requires a verbosity that is otherwise uncommon to Turtle:

    :s :p :o1  {| :y :z |} ,
          :o2  {| :y :z |} .


All things considered ("ATC"?) I tend to your approach, although (I suppose) for different reasons. But IMO this behaviour should be pointed out in the spec.

Thomas


>   pa
> 
> 
> 
>>  It rather follows the RDF* approach of treating each triple individually. As the difference is rather subtle in examples like the one above this will be hard to communicate and teach and in practice also hard to spot. That will probably cause some problems, unease, frustration, unexpected consequences. The resulting mess will not necessarily work in favor of RDF*.
>> 
>> Thomas
>> 
>> 
>>