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

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.

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