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

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.

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