Re: summary un/asserted

Hi Dave,

first: welcome, and thanks for your question! 
And sorry that I missed to properly greet you in my slightly hurried first reply from yesterday!

Also see some additions to my answer below...

> On 11. Jul 2024, at 18:12, Thomas Lörtsch <tl@rat.io> wrote:
> 
> 
> 
>> 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.

This has been discussed repeatedly, first quite in the beginning of the RDF* Community Group a few years ago, and a few times after that. Each time it was stated by different participants, mostly implementors/vendors, that the ability to annotate statements without asserting them is an essential requirement to their customers. IIRC no concrete use cases were given, except one from Richard Cyganiak who mentioned that they use RDF standard reification to keep outdated versions around (my wording, not his, but you can look up his mail in the CG mailing list archives), but the sentiment seemed strong enough to not require use cases. Of course, now it would be helpfull to have some, to be better be able to assess if our approach is sufficient or not. 
TBH I was a long time sceptic wrt this requirement and actually it was me who brought up the question repeatedly if we really need to support it, but the result was always the same, even just recently, a few weeks ago. That was when I started to investigate if we do indeed support it properly, and found that what we offer is lacking in precision.

My assessment is so far not widely shared, and the reason for that is partly that the problem can also be described the other way round: unasserted assertions are handled just fine, but annotating asserted assertions is actually not possible. But discussing that issue properly will require to define our take on reification, and that I fear will be an even more difficult discussion. But let’s see.


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

You’re not alone with that sentiment, but the result is that the meaning of what you said changes, and you may not be okay with that. In general I prefer formalisations that are more robust to change in the data. This is not really comparable to the fact that the meaning of a graph - and implicitly of the statements it’s composed of - may change when one adds more statements to it. It is a rather hard difference if an annotated statement is actually part of the graph or not. Therefore I think this needs more care.

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

The statement that some reification is of (a to be defined) type rdf12:Fact would also need to entail the reified statement. That is a further complication. However, the shorthand annotation syntax does it already, so it can also be understood as a macro, invoked when mapping the shorthand syntax to standard Turtle-star. 
Some argue that Turtle is all that people should use and therefore the expressivity of the shorthand annotation syntax in Turtle-star (e.g. ' :s :p :o {| :a :b |}') is good enough. However, and opinions vary on this as well, one may also regard N-Triples as the normative serialization, because that is what is transmitted over the wire, what a triple store works on, what a streaming environment is based on, etc. From that perspective it is critical that both serializations have the same expressivity. IMO it is a requirement of good system design anyway and I see no reason to give up so early in this case .

Again, thanks for asking!

Best,
Thomas

> 
> Best,
> Thomas
> 
>> Thanks. 
>> -dave
> 
>

Received on Friday, 12 July 2024 07:46:17 UTC