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

Hi Thomas,

I don't think that ways to deal with contradictions and trustworthiness 
"should be moved into RDF." Decisions whether something contradicts something 
else and what is to be trusted are application specific and subjective. So, it 
is hardly something that can be backed into a data model for data exchange and 
data publishing. Moreover, decisions about contradictions or trustworthiness 
are not always a binary choice (e.g., some data comes with confidence values 
that may have to be propagated to the results of data processing tasks).

Best,
Olaf


On fredag 4 september 2020 kl. 12:27:42 CEST thomas lörtsch 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?
> 
> The way I see it RDF can’t resolve this issue, but likewise it can’t forbid
> it to occur either. 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. }. Do we really HAVE TO treat statements that talk
> about other statements any different from statements that talk about
> anything else in the world?
> 
> The question of what is ground knowledge and what is meta knowledge is
> highly dependent on perspective. 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.
> 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.
> 
> 
> 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

Received on Friday, 4 September 2020 11:58:26 UTC