Re: Annotation syntax [was: SPARQL* test suite]

>
> :bob
>     a :Person ;
>     :age 23 ;         {| :author :alice; :certainty 0.9 |} ;
>     :gender :male ;   {| :author :alice |} ;
> .


^^ Hmm, this example of mixing different annotations strikes me as a bit
odd. Annotating the certainty for each statement seems reasonable, and so I
see the appeal of the granularity, but I would not say this is more natural
from a "how people currently work with Turtle" perspective. Also, why does
the statement that Bob is a person appear in the same predicate-object list
as assertions *about* Bob made by Alice?

I would expect the annotations to exhibit locality as they 'scope' the
assertions; consider the typical use case for a linked data:

# no annotations
:bob :name "Bob" .

# assertions made by alice
<| :bob a :Person ;
    :age 23 ;
    :gender :male |>
        :author :alice ;
        :submitted "2020-06-01" ;
        .

Is much clearer and concise to me.

I have not yet come across cases where a reified triple is used in the
> object position.


We are currently experimenting with an approach where changes are recorded
as such:

r:47e1cf2 a :Commit ;
    :delete <<:bob :age 23>> ;
    :add <<:bob :age 24>>, <<:bob :gender :male>> .

 - Blake Regalia


On Wed, Sep 2, 2020 at 7:05 PM Holger Knublauch <holger@topquadrant.com>
wrote:

>
> On 3/09/2020 08:49, Blake Regalia wrote:
>
> Reading thru quickly here, but I think the suggested `{| ... |}` syntax
> for the proposed annotation sugar is simply on the wrong part of the
> triple. Instead, the new production should identify the triple which is
> being both asserted and annotated. This gets around the subject/object
> issue Olaf pointed out and is complementary to `<< ... >>` satisfy for PG
> mode while having another for SA:
>
> Using `<|` here simply to distinguish from previous:
>
> <| :bob :age 23 |> :certainty 0.9 .
> ## equivalent to: ##
> :bob :age 23.
> <<:bob :age 23>> :certainty 0.9 .
>
> :alice :disbelieves <| :bob :age 23 |> .
> ## equivalent to: ##
> :bob :age 23 .
> :alice :disbelieves <<:bob :age 23>> .
>
> This design would unfortunately break how people currently work with
> Turtle. People would need to use a different syntax for the asserted
> triples that carry reifications than for asserted triples that don't carry
> reifications.
>
> In particular, consider the ; case at the subject:
>
> :bob
>     a :Person ;
>     :age 23 ;         {| :author :alice; :certainty 0.9 |} ;
>     :gender :male ;   {| :author :alice |} ;
> .
>
> The syntax above looks reasonably natural and much less disruptive than
> surrounding the asserted triples, esp how in cases like ; and , lists?
> Furthermore this syntax works well if a triple has multiple annotations.
>
> But you are right that from a symmetry POV your syntax would be better. I
> have not yet come across cases where a reified triple is used in the object
> position. Your example above could semantically be rewritten as
>
> :bob :age 23 {| :disbelievedBy :alice |}
>
> Sometimes allowing less flexibility is actually better, as long as the
> majority of cases is covered. My current gut feeling tells me that having
> good support for subjects will be enough, and all other cases can fall back
> to the generic, original << >> syntax.
>
> Holger
>
>
>
>  - Blake Regalia
>
> On Wed, Sep 2, 2020 at 7:48 AM Patrick J Hayes <phayes@ihmc.us> wrote:
>
>>
>>
>> On Sep 2, 2020, at 2:44 AM, Holger Knublauch <holger@topquadrant.com>
>> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 2/09/2020 15:41, Patrick J Hayes
>>
>> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>> Jeen and Holger, greetings.
>>
>>
>>
>>
>>
>>
>> It seems to me that there is a more basic issue
>>
>> here. However it is written, if this maps to an RDF graph
>>
>> containing the triple
>>
>>
>>
>>
>>
>> :bob :age 23 .
>>
>>
>>
>>
>>
>>
>>
>> then that triple is /asserted to be true/, and
>>
>> that assertion of truth is independent of any other triples,
>>
>> be they called ‘annotations’ or not. Adding a triple to an RDF
>>
>> graph cannot change or modify the asserted truth of any other
>>
>> triple in the graph, even if it refers to it. This follows
>>
>> from the monotonicisty of the underlying semantics.
>>
>>
>>
>>
>>
>>
>> Yes, understood. Adding RDF* triples does not alter the
>>
>> truthvalue of any other triple. The example :certainty could have
>>
>> been any other property, such as dct:created.
>>
>>
>> It seems that the topic you raise applies to RDF* in general, not
>>
>> just this particular syntax extension here in this thread.
>>
>> Yes, it does. This was the first time I had seen the suggestion to use
>> annotations to change the underlying logic, though, so I reacted in place,
>> as it were. Sorry.
>>
>> Best wishes
>>
>> Pat
>>
>>
>>
>> Holger
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> One could of course provide an alternative
>>
>> semantics which would allow this, but the underlying language
>>
>> would then no longer be RDF.
>>
>>
>>
>>
>>
>>
>>
>> This of course does not apply to annotations which
>>
>>  record provenance of triples or describe their status in some
>>
>> way. But an annotation which changes the truthvalue of a
>>
>> triple is not merely meta-knowledge or documentation, but
>>
>> rather moves it into a different logic.
>>
>>
>>
>>
>>
>>
>>
>> Pat Hayes
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sep 1, 2020, at 8:07 PM, Jeen Broekstra
>>
>> <jb@metaphacts.com>
>>
>> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>> Yes, I think so and apologies if I
>>>
>>> didn't communicate this clearly.
>>>
>>> The point here is to *add* an
>>>
>>> alternative short cut so that instead of
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>     :bob :age 23 .
>>>
>>>
>>>     <<:bob :age 23>> :certainty
>>>
>>> 0.9 .
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> we can simply (alternatively)
>>>
>>> write
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>    :bob :age 23 {| :certainty 0.9
>>>
>>> |} .
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> This would serve as syntactic
>>>
>>> sugar for the (common) use case of both
>>>
>>> asserting and annotating a triple, while still
>>>
>>> allowing free-standing annotations. The short
>>>
>>> cut will not only make files significantly
>>>
>>> shorter, but also make editing more
>>>
>>> user-friendly. The cost is for implementers
>>>
>>> though, who would have to cover an additional
>>>
>>> case (both in parser and serializer).
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>> Thanks for clarifying  - in that case
>>
>> I think it's actually a very good idea. The main
>>
>> issue I see with supporting it is in the
>>
>> serialization side, which will be tricky to do for
>>
>> any streaming writer. However, we could support
>>
>> that kind of thing under the moniker of "pretty
>>
>> printing", which is already something that
>>
>> requires buffering anyway.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Jeen
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>>
>>
>>
>>
>> Dr Jeen
>>
>> Broekstra (he, him)
>>
>>
>>
>>
>> *principal software engineer*
>>
>>
>>
>>
>>
>>
>>
>> jb@metaphacts.com
>>
>>
>> www.metaphacts.com
>>
>>
>>
>>
>>
>>
>>
>> [image: htps://www.metaphacts.com/] <https://www.metaphacts.com/>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> - Blake
>
> Dr. Blake Regalia
>
>