- From: Kurt Cagle <kurt.cagle@gmail.com>
- Date: Fri, 19 Apr 2024 07:53:18 -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: <CALm0LSHwTWxN4qkyXssv=D-pm7pMygNHytiCNz+2ZOZy4L5atA@mail.gmail.com>
Sorry, a correction that I missed in the previous email:
START----------------------------------------------------------------------
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]>>.
END-----------------------------------------------------------------------
should be:
START------------------------------------------------------------------------
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 *:t3*]>>.
END
--------------------------------------------------------------------------
*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 7:49 AM Kurt Cagle <kurt.cagle@gmail.com> wrote:
> 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:53:53 UTC