Re: proposal: a reifier should reify only one "thing"

Am 19. April 2024 05:45:11 MESZ schrieb "Lassila, Ora" <ora@amazon.com>:
>I was confused before, but now I see where this stuff went “off the rails”. This does not mean that others would not be confused.
>
>Let’s leave owl:sameAs out of this for a moment. Let’s even leave LPGs out for a moment, too. And I now realize that my confusion started way earlier, from someone claiming that
>
>:Liz :married :Richard    [1]
>
>somehow  *represents a wedding*. Well, maybe it does, maybe it doesn’t, but nobody has stated so, so where does that claim come from? What if I said
>
>:Liz :avioitui :Richard    [2]
>
>does that also represent a wedding? No, you will say. And I say “why not?”, because for sure if [1] represents that, [2] must too. “I don’t see it” you say, and that actually is the point I want to make. If we just look at just these statements, the claims are nonsensical, because nobody has stated that “:married” has anything to do with weddings. So if I make a statement about [1], I am doing it because I want to make a statement about that statement, not about a wedding. If I wanted to represent a wedding, I would want to do that in a much more explicit manner.
>
>Ascribing meaning to something that does not have it just because your brain tells you there is meaning is an elementary mistake people make all the time.
>
>What about one reifier for multiple statements? I think that reinforces the “this is implicitly a wedding” -notion, and just adds to my troubles of explaining RDF representation to people and warning them against conflating explicit representation and what’s in their brain. Also, I cannot accept Pierre-Antoine’s claim that Charlie wasn’t wrong about his assertion. He was wrong because he assumed those things represented a wedding.
>
>I want to keep this simple. If someone makes a statement, that is what they do. If they want that statement to be part of something bigger, let them state that explicitly.

You are talking about syntax, but RDF talks about meaning. We may need to get better at explaining this, but it is the core of RDF. And once you grok it, it's great. Otherwise, an application-centric profile of RDF, that takes the syntax as the real thing, could certainly be useful, but that's out of scope. 

>Ora
>
>P.S. After I posted my earlier message about the “Neptune position”, many people have contacted me asking how the “one reifier multiple triples” -scenario is different from named graphs. I knew that would happen. :-( Let’s not mess this up.

So many people are interested in the grouping aspect. 

Did you tell them that named graphs are out if scope because they are used for other, application-specific purposes, and impossible to standardize?

Given that this proposal is largely motivated by a desire to overcome the triple bloat of standard reification it seems slightly ironic that explicit modelling of grouping is now suggested to be a user-friendly approach. 

Thomas 


>
>From: Pierre-Antoine Champin <pierre-antoine@w3.org>
>Date: Thursday, April 18, 2024 at 5:05 PM
>To: Gregory Williams <greg@evilfunhouse.com>, Franconi Enrico <franconi@inf.unibz.it>
>Cc: RDF-star WG <public-rdf-star-wg@w3.org>
>Subject: RE: [EXTERNAL] proposal: a reifier should reify only one "thing"
>Resent-From: <public-rdf-star-wg@w3.org>
>Resent-Date: Thu, 18 Apr 2024 21:05:01 +0000
>
>
>Gregory, Enrico, all,
>
>TL/DR; Enrico convinced me to retract my proposal, and accept that a reifier can reify several thing.
>On 18/04/2024 17:41, Gregory Williams wrote:
>On Apr 18, 2024, at 6:37 AM, Franconi Enrico <franconi@inf.unibz.it><mailto:franconi@inf.unibz.it> wrote:
>While I am against this choice on the ground that it would rule out several typical reification use cases, let’s assume I accept it.
>
>We have two ways to look at it:
>
>  1.  the objects denote the same resource, but not their components s,p,o;
>  2.  the objects denote the same resource, and also their components s,p,o denote the same resource, respectively.
>
>(1) We can still write triples that Amazon-et-al apparently find confusing (most of us do not):
>
>We all come from diverse backgrounds. I’m not sure if “us” was meant to mean WG members, or the RDF community/users, or something else, but I’d suggest we not make claims about what “most” people are or are not confused by here.
>
>I’m not sure I’d describe myself as being confused by (most of) your proposal, but I do think it addresses use-cases which I myself have never encountered, it adds complexity for implementations, and (for myself) it adds mental complexity as I find the modeling counter to how I would naturally try to approach “statements about statements."
>
>:w1 rdf:reifies <<( :liz : married :richard )>> .
>:w1 :location :miami .
>:w1 rdf:reifies <<( :liz :married-in :miami )>> .
>:w1 :groom :richard .
>:w1 rdf:reifies <<( :richard : married :liz )>> .
>
>which by the way entails:
><<( :liz : married :richard )>> owl:same-as <<( :liz :married-in :las-vegas )>> .
>
>I do think this entailment might fall a bit closer towards “confused,” though. I thought I could get myself to an understanding of your reification use-case where the reified :w1 is in some way representing the marriage event. But this new entailment is saying that the triple terms themselves are the same, and I am really struggling to get an intuitive understanding of that. The triples do not represent the same relationship (one between two people, the other between a person and a location), and to me only start to have some connection once the reification or some other modeling of the wedding brings them together as being different aspects of the same event.
>Gregory, I think what's confusing you is that you are misinterpreting Enrico's intention with this owl:sameAs entailment.
>IIUC, Enrico is not advocating for this entailment. On the contrary, he is pointing out that my proposal would have this kind of undesirable consequences.
>
>Enrico, to be clear:
>in my suggestion, this "intended meaning" of rdf:reifies being functional, would not be captured by RDF semantics –just like rdf:subject is meant to be functional, but this is not captured either. So this entailment would not happen under simple entailment nor RDFS entailment. So this would have no negative consequence on the complexity of RDFS reasonners or SPARQL BGP matching.
>
>
>
>However the inferences that you describe would still be valid from an abstract point of view, or if someone using OWL decided to enforce this "intended meaning" formally. And I agree, this would be a problem.
>
>Actually, I would like to rephrase your example; 1st to check that I got it correctly, and 2nd, to emphasize why I think it is a valid counter-example of rdf:reifies being functional.
>
>1. Alice publishes the following graph as <a.ttl>
>    <#w1> rdf:reifies <<( :liz : married :richard )>> .
>    <#w1> :year 1964 .
>    <#w2> rdf:reifies <<( :liz : married :richard )>> .
>    <#w2> :year 1975 .
>I don't expect this one to be controversial, as it complies with the easy-to-explain many-to-one "mode" of rdf:reifies.
>
>
>2. Bob publishes the following graph as <b.ttl>
>
>    <#w64> rdf:reifies <<( :liz :married-in 1964 )>> .
>    <#w64> :groom :richard .
>
>Same comment as above.
>
>
>3. Charlie then notices that Alice and Bob are actually talking about the same wedding, and states
>
>    <alice.ttl#w1> owl:sameAs <bob.ttl#w64>.
>
>Boom! From there, Charlie infers that
>
>    <<( :liz : married :richard )>> owl:sameAs <<( :liz :married-in 1964 )>>.
>
>Is this really a problem after all? Considering that it leads to the following
>
>    <alice.ttl#w1> rdf:reifies <<(:liz :married-in 1964 )>> ;
>        :year 1975.
>
>I believe it is!!
>So we have a problem. If we agree that Alice and Bob are entitled to publish those graphs,
>we must conclude that either
>a) Charlie was wrong in asserting the owl:sameAs between the two wedding, or that
>b) we must accept that a given reifier may reify different things.
>
>I strongly believe that Charlie's graph is legit, so I lean towards option b), and I retract my proposal that "a reifier should reify only one thing".
>
>  pa
>
>

Received on Friday, 19 April 2024 08:48:00 UTC