Re: Proposal: described vs stated triple terms

> On 25. Jul 2024, at 16:32, Franconi Enrico <franconi@inf.unibz.it> wrote:
> 
> 
> 
>> On 25 Jul 2024, at 16:29, Franconi Enrico <franconi@inf.unibz.it> wrote:
>> 
>> On 25 Jul 2024, at 16:21, Thomas Lörtsch <tl@rat.io> wrote:
>>> 
>>>> I said that a reifier denotes an existing resource in the graph.
>>>> A reifier reifies a triple term, and it represents the induced resource by the triple term.
>>> 
>>> can you please define "induce"? is that term in any way related to "entail"?
>> 
>> Uh? No, obviously in our context: “the resource reified by the triple term”.
> 
> Ops, autocorrect error: reified by —> reifying”


Okay, let’s try to re-word your original mail:


> On 25. Jul 2024, at 15:41, Franconi Enrico <franconi@inf.unibz.it> wrote:
> 
>> On 25 Jul 2024, at 15:18, Thomas Lörtsch <tl@rat.io> wrote:
>> 
>>> On 25. Jul 2024, at 15:00, Franconi Enrico <franconi@inf.unibz.it> wrote:
>>> 
>>> Hi Thomas,
>>> 
>>>> that is exactly how I see it, but Enrico’s responses to Gregory Williams [0] and the RDF/LPG wikipage [1] they refer to seem to suggest a different reading.
>>> 
>>> I happen to agree 100% with Andy’s email.
>>> I don’t see any contradiction with [0] and [1].
>> 
>> Well, the contradiction is that you talk about a reified statement as if it was asserted in a graph, but you call it optional if it is actually asserted.
> 
> I never said that. 
> I said that a reifier denotes an existing resource in the graph. 
> A reifier reifies a triple term, and it represents the induced resource by the triple term.

IIUC this could also be worded as:

A reifier reifies a triple term, and it represents the resource reifying the triple term.

1) Is that correct?

2) I’m afraid to say that it doesn’t make much sense to me. The first half sentence, "A reifier reifies a triple term", seems to describe the syntactic level, whereas the second half "A reifier … represents the resource reifying the triple term". seems to describe the meaning, the semantics. The syntactic half seems okay, obvious even. The meaning however…

"A reifier … represents the resource reifying the triple term"

What does that mean? IIUC it defines reification as being reification. That definition is void of any appreciable meaning.

But let’s go on to the example.

> In our example, 
> :e1 rdf:reifies <<(:a1 :transaction :a2)>>.
> :e2 rdf:reifies <<(:a1 :transaction :a2)>>.
> :e1, :e2 a :transaction.
> there are two transactions, denoted by the two reifiers of the same triple term.
> The triple structure of the triple term it reifies does not necessarily appear as a triple in the graph.

This is on its own a vague statement: "not necessarily" because of what?

> But It could, if you want to have it in the graph:
> :a1 :transaction :a2.

And adding a "could" doesn’t make it better. "Could" why, for what reason or purpose. This is so wishi-washi that it is practically useless. Gregory W. said something very specific: those transactions EXIST. It is not optional to specify their existance. So that extra triple has to be in the graph. We need to ensure that when authoring, and we need to check it in retrieval.

> But this triple in the graph is by no means “identifying” a transaction (in fact, we know that it “relates” to at least two transactions).

Yes, that is the crux of set semantics.

[ Not the main topic of this mail, but nonetheless:

And that is why I say we need two different primitives, one to annotate statements that exist as triples in the graph, and one that doesn’t assume their existance in the graph. Given the limitations of reification, that is the best we can hope for, but at least that we can do.

In practice we will still have to make sure that the triple is in the graph when we annotate it, and we will have to check for its existance when we retrieve an annotation on a statement that is assuemd to exist in the graph, as a proper triple. That extra work is a result of using reification.

]

> So, the graph says that there are two transactions (:e1 and :e2, both between :a1 and :a2), and that the (one) triple :a1 :transaction :a2. is a true fact the graph.

Yes, that is exactly how I have understood reification for a long time now, and IMO it is too vague to be useful. Reification is so delicate because it doesn’t want to touch the fact in the graph. It does not only not want to, it CAN NOT according to the semantics. Fine, and I understand that. If only you understood how this is not good enough in practice.

The example you give is thankfully not one of provenance etc, where one can argue that such a brittle connection between triple and annotation is just the right amount - not too far, not to near. The example you give is really a qualified relation, a transaction between a1 and a2, or rather multiple transactions, some of them between a1 and a2. All those annotations refer to specific and very real transactions, and the triple ':a1 :transaction :a2.' is just a common denomiator to them. 

Singleton properties are just so much better suited to express such qualified relations because they approach the problem from the opposite direction: they don’t construct some shaky scaffolding to get near the triple, so that you can almost - but only almost! - touch it, and annotate it. Instead they
start out from the specific relation, with all the attributes that define it, and then add a "and hey, this is of type ':a1 :transaction :a2', just so you know where to find it". That is so much more practical!

Compare your descrioption above - 

"A reifier reifies a triple term, and it represents the resource reifying the triple term." and all the extra baggage you could merely explain by means of an example, including terms like "not necessarily" and "could" 

- with that of a type instance relation:

A singleton property relation instantiates a relation of type <property> and may annotate it with additional attributes.

The latter everyone vaguely educated in computerism will understand: type/instance is by far one of the easiest to grasp concepts. And the connection between the SP relation and its type is crystal clear: the SP relation ENTAILS its super type: if 

    :A :married_inMay :B 

is true, then also

   :A :married :B

is true. This is dead simple, and correct. 

And it is always correct, no matter if the annotation is qualifying or if it is purely administrative. Reification would be a better fit for purely administrative, but it qualification doesn’t hurt much either. The opposite is not true, as seen above. And that is why reification is not the solution to our problem. It is of too limited expressivity, and not easy to understand (which makes it even harder to successfully navigate its limited expressivity).

There is a lot of FUD around singeton properties. Some of it is semi-real, like troubles when implementing it too naively (but that is not our problem, because we would implement it totally different to the naive approach, by means of triple terms).
However, the concerns wrt to its semantics are really ill conceived. All the hysteria that it might lead unsound reasoning results or that it might endanger monotonicity are completely unfounded. 

Again: there is nothing simpler than a type-instance-relationship. Whoever gets that wrong has no business in KR whatsoever. Reification OTOH is a hellishly unintuitive concept, and it lacks what we need most by design: the direct grasp on a statement for the purpose of qualification. 

So: repent!


Best,
Thomas






> For my terminology, see https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jul/0096.html
> 
> —e.

Received on Friday, 26 July 2024 10:28:34 UTC