Re: entailing that a quoted triple is false

Hi Peter,


I find the attitude with which you’ve been treating me for months now very annoying and sometimes bordering on ad hominem attacks - not understanding me "at all" right from the start when I began to discuss rdf:reifies et al, and treating me like someone who just doesn’t get it and keeps the WG from making progress (and in pretty unacceptable ways at times). However, I think that it’s you who just doesn’t get it, and please let me explain.

> On 31. Aug 2024, at 19:08, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> On 8/30/24 08:43, Thomas Lörtsch wrote:
>> Am 30. August 2024 14:11:31 MESZ schrieb "Peter F. Patel-Schneider" <pfpschneider@gmail.com>:
>>> Is anyone in the working group actually wanting the graph
>>> :a rdf:reifies < :b :c :d > .
>>> to entail that :b :c :d is false?
>> not "false", but also not true in the graph. you should know the difference
> 
> There are only four possibilities - entails false, entails true, entails neither, and entailing both.   Entailing not true is either nonsensical or entailing false.

First of all, I never proposed that rdf:reifies entails anything. That should be obvious and consequently I’m at a loss of what the intent and direction of your argument is. You should be aware that non-logicians like me may can not always catch what you try to clarify in formal ways. I agree that formalizations can be very helpful, but only if everybody is aware of the interpretative context. You don’t provide that.

>>> (I don't remember anyone wanting that.  I don't even remember any input to the working group advocating that.)

And neither do I.

>>> If not, then arguments that include statements to that effect are not persuasive.

And that dismissive judgement before anybody had a chance to answer the question (or wasn’t it a question at all?) is just as helpful as beginning a discussion with "I don’t understand AT ALL..." (emphasize is mine). 

But now the actual discussion, i.e. an attempt to clarify what I mean (and I admit that the paragraph you cite below is a bit sloppy, but I made the point before in more detail, so it could have been clear from context).


There’s two ways to discuss reification:
- the statements that describe the reification (that’s basic RDF), and 
- what the reification describes (that’s the meta level).
What you say above it seems to me does only apply to the statements that describe (or construct, or state) the reification, but that’s not the interesting part. The question at hand is what the reification describes. What should it describe? What do we consider a useful meaning of the description? What’s the purpose of the construct in the context of our task as a WG: to standardize a mechanism to enable "statements about statements" in RDF? I hope you agree that there are many ways in which that meaning could be specified. 

Reification, as it stands, has very little meaning on its own. You’ve reinforced that fact yourself many times, e.g. in a mail exchange on this list with Bryan Thompson in which you notably described reification by all the things that it is _not_. And a natural response to that is: "Then why should I care?" (my words, not his!). The problem is - and I think you are aware of that problem because you recognize all the misuse and wrong and overdeterministic interpretations - that reification has so little meaning on its own that people tend to interpret it in the way they want it to behave (fitting their needs and expectations), and often fall into the all to common trap of thinking that that is _the_ intuitive meaning of reification. That is a problem, and it’s not solved by telling users that they’ve all got it all wrong. Enrico in a recent Semantics TF meeting instead suggested that reification shouldn’t be used at all. He instead advocated, and you and some others agreed, for E/R style modelling as the way forward to enhance expressivity of RDF. 
I think this is the point where we really disagree, and the reason why this discussion has been dragging on for months now, and gets so heated again and again: we have very different visions for the future of expressivity of RDF, of how it should evolve. Some want to turn it into a glorified RDBMS: decentralized and shareable, with meaningful column descriptors and therefore "with semantics", but a relational system of tables at heart. Some want to develop further the graph formalism by enabling qualification of statements, not unlike LPG. And some don’t care much about such visions, but just need a simple way to add orthogonal, maybe administrative, metadata to simple statements. 
That third position doesn’t seem to need more than the first position is willing to provide (albeit reluctantly), and so it may seem like a good common ground. But IMO it’s too little too late and - after two decades of attempts to extend RDF’s expressivity with a sound meta modelling mechanism - really rather a nail in RDF’s coffin than a way forward. IMO if we don’t succeed in standardizing sound statement qualification now, we’ve failed, and I’m honestly not sure if we get another chance in ten years from now.


The meaning of a reification certainly isn’t that the statement it describes is true, or that it entails that statement. Neither does it say that the statement so described is false. Nor does it say that the statement it describes even exists in some graph somewhere, let alone in the graph that contains the reification. It is in a way a very extreme form of Schrödinger’s cat: we do not know if the cat is alive or dead, we do not even know if the cat is in the box, or if the box even exists?! I think we should all be able to agree that this is a pretty underspecified construct: it allows us to speak about statements, but without further clarification it is very unclear what exactly we are refering to by a reification. Reification is a loose cannon: it can be used in a lot of ways because it is so underspecified, but it can also do lot of damage because it is prone to be used based on unfounded assumptions. It needs to be made more specific to be useful in practice. It needs a more specific meaning, or multiple versions of such specifity.

And this is where it gets concrete: a proposal has been made that in certain cases - when an annotation is intended to annotate a true statement, a statement in the graph - a further statement is added to that effect, saying e.g. ":reificationID rdf:type :Stated". And also the argument was made that we do not have enough practical experience to define and standardize all the possible meanings that a reification can have (stated, endorsed, just documented, not yet approved, hypothetical, etc), and therefore should refrain from any further activity beyond defining an rdf:reifies property.
The problem with this approach is twofold:
- such a clarifying statement would be needed not just for some but for every reification, making the mechanism verbose in practice, prone to omission, implementation troubles and  technical failure
- the vocabulary would still need to be defined in the RDF specification as otherwise we’re right back in the "but it has no normative semantics" hell that we are in with RDF standard reification already, not to mention named graphs. I really, really, very honestly, wholeheartedly do _not_ want to be part of an endeavour that leads into that exact same mess once again. The thought alone makes me sick. Yes, it’s that bad.


I’ve been for months now trying to establish that this is a problem that we need to solve, and the solutions that I proposed have evolved a bit. I’ve been arguing that there are two basic configurations:

1) a statement that is true in the graph is annotated (not true in some abstract sense, not true somewhere else, but that really is part of the same specific set of statements that also contain teh annotation)

2) a statement is annotated, but that statement is not assumed/expected to be part of the graph (and if the statement nonetheless happens to be part of the same set of statements that contains the annotation, then that is to be considered a mere coincidence and certainly not as some kind of reference)

Most of this can pretty evidently be gleaned from the use cases, some of it is a bit more speculative. But in essence I really think these are the two fundamental options, and we need to cover them in RDF proper. Anything more specific can and should be handled by domain ontologies.
Maybe we need a third option, i.e. rdf:reifies in its original and very unspecific meaning, to cater for other needs that don’t fall into the two main categories (or their eventual subcatgories). That would then lead to three properties, e.g. rdf:reifies, rdf:mentions and rdfs:states. The latter two would be defined as subproperties of rdf:reifies, ready to use and mapped to/supported by respective syntaxes << … >> and annotation syntax, whereas rdf:reifies could then only be used with abstract triple terms <<(…)>> and users were encouraged to provide more detail with additional statements.


The problems becomes even more complicated because the set semantics of RDF makes it pretty impossible to refer to one specific RDF statement, as any such statement itself just stands in for all statements of that type. I’ve therefore proposed to attack the problem from the opposite direction and make the annotated reification entail the statement (expressed e.g. with an 'rdfs:states' property). I think that is a pretty neat trick, but it requires a bit of support in syntax and in SPARQL. Certainly doable, but of course a break from established customs, and therefore met with resistance. I understand that, but I also hope that at some point we will all come to the agreement that meta modelling, aka "statements about statements", is such a special beast that it _requires_ such a break with established practices in one way or the other. RDF* did it (the embedded triple was both asserted and annotated) but missed an important detail, RDF-star per CG report took the opposite direction (quoting the triple type) but proved too detached from practical requirements. Now IMO we have to find a way to complete and formalize what RDF* tried to do (and what people liked). And that is also how I understand the task of this WG. 


The WG is not tasked to advance entailments in general, it is not tasked to advance E/R modelling, it is not tasked to just provide some syntactic sugar for RDF standard reification and it is b.t.w. also not tasked to care much about the annotation of unstated statements. It is tasked to bring the expressivity of RDF on par with (and thereby quite necessarily beyond) LPG to enable RDF-LPG interoperability. That requires semantically sound and syntactically concise means to qualify statements that are in the graph. Adding some more low hanging fruit like annotating unasserted statements is fair game, opposing that goal alltogether (like you and some others have done repeatedly) is not.


I hope you do at least agree with me now about the problem, so that we can start to meaningfully discuss possible solutions.


Best,
Thomas


>>> peter
>>> 
>>> 
>>> On 8/30/24 06:04, Thomas Lörtsch wrote:
>>> [...]
>>>> However, I also think that all those nuances still fall into two main categories, namely if the annotated triple term is meant to be true in the graph or not:
>>>> - most of them are meant to be true (see use cases, see real world data)
>>>> - those that aren't can’t be introduced first and then taken back (that would jeopardize monotonicity)
>>> [...]
>>> 
> 
> 
> peter
>

Received on Monday, 2 September 2024 09:24:17 UTC