- From: Kurt Cagle <kurt.cagle@gmail.com>
- Date: Fri, 19 Apr 2024 07:49:33 -0700
- To: Pierre-Antoine Champin <pierre-antoine@w3.org>
- Cc: "Lassila, Ora" <ora@amazon.com>, RDF-star WG <public-rdf-star-wg@w3.org>
- Message-ID: <CALm0LSEGPHWsA1X0xUxd-0DpmPOCFcFomwVeCCFDRHOWHV3G5Q@mail.gmail.com>
Pierre-Antoine,
It's worth noting that some of the difficulties here arise because we are
modelling temporal phenomena:
<<#marriage1 | :liz :marries :richard>> a :Event;
:bride :liz ;
:groom :richard ;
:startYear 1964 ;
:endYear 1975 ;
.
This works in the case where Liz later marries Bob:
<<#marriage2 | :liz :marries :robert>> a :Event;
:bride :liz ;
:groom :robert ;
:startYear 1977 ;
:endYear 1981 ;
.
But gets into trouble when Liz and Richard decide to remarry:
<<#marriage3 | :liz :marries :richard>> a :Event;
:bride :liz ;
:groom :richard ;
:startYear 1985 ;
.
This is actually an error that arises in LPGs, because they have no way of
differentiating #marriage1 from #marriage3.
What this suggests is that there is an error in modelling, and that it
should properly be:
<<#marriage1| :liz :marries :richard>> a :Marriage ;
:groom :richard
:bride :liz ;
:intervals [ :from 1964; :to :1975], [:from :1985] ;
.
<<#marriage2| :liz :marries :robert>> a :Marriage ;
:bride :liz ;
:groom :robert
:intervals [ :from 1977; :to :1981] ;
.
This isn't necessarily intuitive - we think of #marriage3 as being the
third marriage, but, given the reification statement, it is in fact a
continuation of the same marriage across two separate intervals in time.
Note as well that :groom and :bride here are clarifications. We can infer
that
#marriage1 rdf:subject :liz .
#marriage1 rdf:object :richard .
but we cannot tell who is :bride or :groom from the reification itself,
unless there is some explicit ruleset:
CONSTRUCT {?marriage :bride ?bride}
WHERE {?marriage rdf:subject ?bride}
CONSTRUCT {?marriage :groom ?groom}
WHERE {?marriage rdf:object ?groom}
These things aren't contained in LPGs, because in general LPGs don't have
the expressivity of RDF. They are assumed (usually without explicit
declaration) by the modeller.
This also points to a limitation of reification -
*if we have a temporal sequence (or any sequence for that matter) that
incorporates the same <<:s :p :o>> relationship, where you have multiple
reifiers describing the same relationship, those reifiers MUST perforce
describe the same thing.*
You see this in expressions of time series data. Here's the scenario:
At time :t1, sensor :s1 has a reading of :A
At time :t2, sensor :s1 has a reading of :B
At time :t3, sensor :s1 has a reading of :A
I cannot say:
:s1 :hasReading :A .
without having context :t1 or :t3.
I can say:
:s1 :hasReading [:value :A; :time :t1],[:value :B; :time :t2],[:value :A;
:time :t3].
but that's all I can say. Put another way, I can only reify the statements:
:s1 :hasReading <<:r1 | [:value :A; :time :t1]>>, <<:r2 | [:value :B; :time
:t12>>,<<:r3 | [:value :A; :time :t1]>>.
Once I do, then I can say:
:r1 :reportedBy :joe .
:r2 :reportedBy :jane .
:r3 :reportedBy :joe.
The same can be applied to the first scenario:
<<::m1 | liz :marries :richard>> a :Marriage; :hasIntervals <<:mi1-1 | [
:from 1964; :to :1975; a :MarriageInterval]>>, <<:mi1-2 | [:from :1985; a
:MarriageInterval]>>.
<<::m2 | liz :marries :robert>> a :Marriage, :hasIntervals <<:mi2-1 | [
:from 1977; :to :1981; a :MarriageInterval]>>.
(I'm including the type declarations to make the relationships explicit,
but most likely they wouldn't be included.
Given this case, we can say:
:mi1-1 :hasChildren :wendy .
:mi1-2 :hasChildren :john, :michael .
:mi2-1 :hasChildren :peter .
and can infer:
:m1 :hasChildren :wendy, :john, :michael .
:m2 :hasChildren :peter .
through the ruleset:
CONSTRUCT {?marriage :hasChildren ?child}
WHERE {
?marriage :hasIntervals ?interval .
?interval :hasChildren ?child .
}
Let me put this another way: LPGs can induce bad modelling because they
hide a lot of the complexity of the model at the expense of excluding these
kind of edge cases.
This makes RDF MORE expressive than LPGs (I'm not a hundred percent sure
you could even model the above statements in Neo4J as an example without
having to create two distinct predicates) but the case that I think we
should be most concerned about, can RDF represent LPG content, is readily
satisfied. This should be stated explicitly:
My position: We, as a working group, are under no obligation to create RDF
that can be modelled via an LPG, but we MUST ensure that any LPG
representation can be represented in RDF. If you need RDF/LPG
interoperability, then you need to conform to a more limited RDF profile.
Let the LPG vendors play catch up for once.
*Kurt Cagle*
Editor in Chief
The Cagle Report
kurt.cagle@gmail.com
443-837-8725 <http://voice.google.com/calls?a=nc,%2B14438378725>
On Fri, Apr 19, 2024 at 5:56 AM Pierre-Antoine Champin <
pierre-antoine@w3.org> wrote:
> 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>
> <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>
> <pierre-antoine@w3.org>
> *Date: *Thursday, April 18, 2024 at 5:05 PM
> *To: *Gregory Williams <greg@evilfunhouse.com> <greg@evilfunhouse.com>,
> Franconi Enrico <franconi@inf.unibz.it> <franconi@inf.unibz.it>
> *Cc: *RDF-star WG <public-rdf-star-wg@w3.org> <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> <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>
> <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 14:50:08 UTC