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

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 
> <mailto:phayes@ihmc.us>> wrote:
>
>
>
>>     On Sep 2, 2020, at 2:44 AM, Holger Knublauch
>>     <holger@topquadrant.com <mailto: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 <mailto: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 <mailto:jb@metaphacts.com>
>>>>
>>>>
>>>>     www.metaphacts.com <https://www.metaphacts.com/>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>     htps://www.metaphacts.com/ <https://www.metaphacts.com/>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
> -- 
> - Blake
>
> Dr. Blake Regalia