reifiesDomain-14 (Re: proposal: a reifier should reify only one "thing")

Ora,

thanks for this response, I think eliciting our respective assumptions 
is a way to better understand each other and reach a trade-off 
acceptable to everyone.

If I understand your argument below, the use of rdf:reifies (including 
the use of the syntactic sugar) should be limited to use-cases about 
"statements" (for some definition of statement, which I'll defer to 
another discussion). Any use of rdf:reifies for something that is not a 
"statement" (e.g. a wedding) is a semantic error. If you want to talk 
about weddings, just to it "the RDF 1.1 way", with a class :Wedding and 
corresponding properties. This position can be defended by a strict 
reading of the charter ("statements about statements").

The position I defend below is based on the assumption that reifiers can 
actually model a wide range of entities, such as weddings (Enrico's 
example below), pipes (Niklas' recent example [1]). The main argument 
for this position, IMO, is that it is required to ensure smooth 
("intuitive"?) interoperability with LPGs: in LPGs, edges /are/ used to 
model all kinds of things.

Of course, if reifiers can be anything, we need to be able to 
disambiguate. My understanding is that this can be done via typing, but 
this discussion makes me realize that we should actually be more 
prescriptive about this. We should probably instate a good practice that 
every reifier should be explicitly typed. Consider an extended version 
of Bob's graph below:

     <<#w64 | :liz :married-in 1964 >> a :Wedding ;
         :groom :richard .

     <<#stmt | :liz :married-in 1964 >> a rdf:Statement ;
         :source <https://en.wikipedia.org/wiki/Elizabeth_Taylor>.

Remark 1: writing this, I realize an interesting difference between LPGs 
and RDF 1.2: the role of the edge label in LPGs is split in RDF 1.2 into 
(a) the predicate of the reified triple, and (b) the type of the 
reifier. Another example, IMO, of RDF semantics forcing us to be more 
precise (and that's good).

Remark 2: of course, the typing of the reifier could be inferred from 
the additional properties we put on the reifier (e.g. id the domain of 
:groom is :Wedding). So technically, the type could be ommitted. But at 
least when we write examples, explicit is better than implicit [2].

Remark 3: if we decide to restrict rdf:reifies to "statements", then I 
fully support the many-to-one camp. Even though it would be tempting to 
include complex statements (modeled by graphs) in the picture, I came to 
the conclusion that it does not fly [3].
For the same reason, if we decide to allow reifiers to be anything, we 
can still restrict rdf:reifies /per class of reifier/. In particular, 
for "statement" reifiers:

     rdf:Statement rdfs:subClassOf [
         a owl:Restriction ;
         owl:onProperty rdf:reifies ;
         owl:maxCardinality 1;
     ].

Remark 4: pulling the thread on Remark 3, could we imagine something 
like this?

     :Wedding rdfs:subClassOf [
         a owl:Restriction ;
         owl:onProperty rdf:reifies ;
         owl:allValueFrom [
             a owl:Restriction ;
             owl:onProperty rdf:predicate ;
             owl:allValuesFrom :WeddingDescribingProperty
         ]
     ].
     :married-to a :WeddingDescribingProperty .
     :married-in a :WeddingDescribingProperty .

(I know, this is totally out of scope of this group! But food for 
thought, I think...)

   pa

[1] 
https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Apr/0112.html

[2] https://peps.python.org/pep-0020/#the-zen-of-python

[3] 
https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Apr/0096.html


On 19/04/2024 05:45, Lassila, Ora wrote:
>
> 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 thiattributes.ngs 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.
>
> 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.
>
> *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
>
>
>