W3C home > Mailing lists > Public > public-rdf-star@w3.org > September 2020

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

From: Patrick J Hayes <phayes@ihmc.us>
Date: Wed, 2 Sep 2020 00:41:28 -0500
Message-ID: <20D43ED8-B57B-4705-8358-822BDC5180B0@ihmc.us>
CC: Holger Knublauch <holger@topquadrant.com>, <public-rdf-star@w3.org>
To: Jeen Broekstra <jb@metaphacts.com>
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. 

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 <mailto:jb@metaphacts.com>
> www.metaphacts.com <https://www.metaphacts.com/>
>  <https://www.metaphacts.com/>

Received on Wednesday, 2 September 2020 05:41:48 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 2 September 2020 05:41:48 UTC