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

> On Sep 4, 2020, at 5:27 AM, thomas lörtsch <tl@rat.io> wrote:
> 
> This is not so much RDF* related but since the issue came up here...
> 
>> On 2. Sep 2020, at 07:41, Patrick J Hayes <phayes@ihmc.us> 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. 
>> 
>> 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. 
> 
> 
> What if some administrative metadata asserts the source of a statement and another statement asserts that that source can’t be trusted and all statements it emits have to be considered false? 

What indeed, but I don't see what this has to do with the point I was making, which is that if <<some kind of annotation of a triple T>> expands out into, or has the same meaning as, <<Something>> & T, then it cannot modify the truth of T, because no RDF triple can alter the asserted content of some other RDF triple. This is really just an observation about the semantics of RDF being monotonic.

Returning to your what-if, two responses. First, there is no way in current RDF to assert that anything is false. That would require having some form of negation, which RDF notably does not have. Second, even if we say that a source is unreliable, it does not usually follow that /everything/ it asserts must be /false/. That would be like a lying demon in a logic puzzle, where you can actually rely on it by asking it the ‘backward’ question. 

> The way I see it RDF can’t resolve this issue, but likewise it can’t forbid it to occur either.

RDF doesn’t forbid anything, but the question is whether or not it can express the result. Right now it can't express denial or contradiction or assertions of falsity at all, whether or not they have to do with reliability of sources. 
(https://www.w3.org/TR/rdf11-mt/#properties-of-simple-entailment-informative <https://www.w3.org/TR/rdf11-mt/#properties-of-simple-entailment-informative>)

> I would go even futher and say that the issue at hand is not better or worse than two statements contradicting each other like { :car :is :small, :big. }.

Why do you say these contradict one another? A small elephant might be same size as a large horse, and much bigger than a large flea. But even if they do, that contradiction is invisible to RDF or RDFS reasoning, 

> Do we really HAVE TO treat statements that talk about other statements any different from statements that talk about anything else in the world? 

Of course not, but we should not get them muddled up with one another. For example, if I say (P, but this is true in 2001) then I have not simply asserted P and also something about it: I have modified the actual assertion, said something different about the world. So the bare assertion of P is NOT true, in this scenario. Contrast with the case where if I assert (P, and this was told to me by Fred in 2001) which is a genuine annotation which does not change the truthvalue of the statement being annotated. 

Put another way, the complicated thing here, that needs care, is not that meta-statements about other statements are fundamentally different in kind (as you say, they are not) but that the relationship between them and the statements they they are about can be subtle, and needs to be treated with care. 

> 
> The question of what is ground knowledge and what is meta knowledge is highly dependent on perspective

I deeply disagree. It is a very basic distinction that needs to be treated seriously and carefully. It can change the underlying logic in strange ways and even introduce hidden paradoxes. It is, in a word, dangerous. 

> . It shouldn’t depend on a modelling decision, e.g. if complex flatland n-ary relations with lots of indirections and nested blank nodes are used or if snippets of RDF are referenced in other statements. 
> 
> To properly deal with contradictions RDF needs a semantic extension to
> - partition the knowledge space
> - soundly reference those partitions
> - assign truth values to them
> - define coherent combinations of partitions.

At least that, yes. See https://www.slideshare.net/PatHayes/blogic-iswc-2009-invited-talk <https://www.slideshare.net/PatHayes/blogic-iswc-2009-invited-talk>, especially around slide 20 et seq.

> Lacking that so far it still has to rely on application logic and other out-of-band means to handle contradictions. 
> 
> It seems to me like this is all quite doable with what we have right now plus some vocabulary and of course a mode of operation that gives special attention to the expressions made in such vocabulary, e.g. taking care not to include triples from a source that under the operating assumptions is not trustworthy. Currently application logic does this. It should be moved into RDF.

I agree. But we might not agree on how best to do it :-)

Pat

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