Re: summary un/asserted

> On 10. Jul 2024, at 17:09, Dave Richardson <drichardson@aifarms.com> wrote:
> 
> Hello everyone. Longtime lurker, first-time poster. :)
> On 7/9/2024 3:43 AM, Thomas Lörtsch wrote:
>> For example, we may want to document and comment on a statement without endorsing it. We write 
>> 
>> << :s :p :o >> :a :b .
>> 
>> If however that same statement is also to be part of the graph, for whatever reason, like so:
>> 
>> << :s :p :o >> :a :b .
>> :s :p :o .
>> 
>> there is no way to express that the annotation is meant to refer to an unasserted statement. 
>> There are many situations in which this problem might occur: we might want to document different viewpoints or versions, graphs might be merged or updated, adding the fact, etc.
>> Thomas
> Apologies if this use case is already clear to most, but why would you need to express that an annotation is meant to refer to an unasserted statement"? I had a good go-round with ChatGPT on this question, and we couldn't come up with any satisfactory examples.

E.g. you have a theory and three arguments supporting it, but you only believe in one of them:

   << :Foo :madeOf :Bar >> 
       :src :Paper_1 ;
       :arg :Argument_1 .

   << :Foo :madeOf :Bar >> 
       :src :Paper_2 ;
       :arg :Argument_2 .

   << :Foo :madeOf :Bar >> 
       :src :Paper_3 ;
       :arg :Argument_3 .

  :Foo :madeOf :Bar .

Which one of those papers is the one that led you to adding the actual triple to the graph?

That also nicely illustrates how the shorthand annotation syntax differs in expressivity from bare Turtle-star, e.g.:

   << :Foo :madeOf :Bar >> 
       :src :Paper_1 ;
       :arg :Argument_1 .

   :Foo :madeOf :Bar {|
       :src :Paper_2 ;
       :arg :Argument_2 .
   |}

   << :Foo :madeOf :Bar >> 
       :src :Paper_3 ;
       :arg :Argument_3 .

One way around this is to add another triple to Turtle-star that explicity states which statement is endorsed by the publisher of the data, e.g.:

   << :Foo :madeOf :Bar >> 
       :src :Paper_1 ;
       :arg :Argument_1 .

   << :Foo :madeOf :Bar >> 
       :src :Paper_2 ;
       :arg :Argument_2 
       a rdf12:Fact .

   << :Foo :madeOf :Bar >> 
       :src :Paper_3 ;
       :arg :Argument_3 .

  :Foo :madeOf :Bar .



> Similarly...
> 
> On 7/10/2024 5:55 AM, Thomas Lörtsch wrote:
>> But I also want to be sure that adding that fact (because of/by some 
>> other reason, or circumstance, or context, or user) doesn’t overwrite 
>> the implication of my initial annotation to not 
>> endorse/state/assert/"fact-ualize" that statement.
> What implication(s)? It seems like, given the open world assumption, people will just have to assume that their unasserted triple might get asserted down the road. But again, I can't think of examples of what we miss without being able express that an annotation is meant to refer to an unasserted statement.
> My understanding is, if there no (or very little) value in being able to express that an annotation is meant to refer to an unasserted statement, we are all set with reification not triggering assertion, and you can just assert a statement if you want it asserted.

In general I trust abstractions more than examples. If a conversion is lossy then I know that something is amiss. That said recent discussions made me realize that there are more reasons than I was aware of that may lead to wanting to describe a statement but not to add it as a triple to the graph: the source of the statement may not endorse it, the publisher of the graph may not endorse the statement, the publisher may want to describe the opinion that endorses the statement but not want to endorse it itself, etc. In summary, there are many reasons why one may not want to state the triple, but only describe it. However, one distinction is special, and that is if the publisher wants to state a triple AND annotate it. In that case something like the rdf12:Fact classification might help.

Best,
Thomas

> Thanks. 
> -dave

Received on Thursday, 11 July 2024 16:12:28 UTC