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

Sasaki, Felix
1:11 PM (30 minutes ago)
to me, ddooss@wp.pl, Pierre-Antoine, Ora, RDF-star

> “The user usually doesn't see the predicate identifiers directly; they
> only see the label“
>
> For creating data
> CREATE        (liz:Person {name: 'Liz'}), (richard:Person {name:
> 'Richard'})
> CREATE        (liz)-[:MARRIED {from: 1964, to: 1975}]->(richard)
> CREATE        (liz)-[:MARRIED {from: 1985}]->(richard)
>
> That does not bother them, and also not for querying the data
> MATCH (liz:Person {name: 'Liz'})-[m:MARRIED]->(richard:Person {name:
> 'Richard'})
> RETURN m.from AS StartYear, m.to AS EndYear


The issue is not that it bothers LPG viewers, but whether this can be
rendered in RDF-Star. If you take this assumption naively (a direct
translation) this becomes:

<< :m | :liz :marriedTo :richard >> :from 1964; :to 1975 .
<< :m | :liz :marriedTo :richard >> :from 1986 .

This implies that you have the potential for:

:m :from 1988; :to 1975 .

which should be self-evidently wrong.

Even though the MARRIED element looks like it's an identifier, it is STILL
text, though probably text that is constrained. This is what I meant
earlier about LPGs modelling the situation incorrectly. They can get away
with it because the data is kept in the form of records, not assertions. In
RDF, you don't have bundles of assertions (you do, but they are called
named graphs, and I won't get into that discussion here).

The statements above are still modelled as:

<<:m1 | :liz :married-1 :richard>> :from: 1964, to: 1975 .
<<:m2 | :liz :married-2 :richard>> from: 1985.
:m1 rdfs:label "MARRIED".
:m2 rdfs:label "MARRIED".

Now this is not necessarily a deal breaker. You can readily query from this:
SELECT ?bride ?groom ?from ?to WHERE {
?marriage rdfs:label "MARRIED".
?marriage rdf:subject ?bride .
?marriage rdf:object ?groom.
?marriage :from ?start .
OPTIONAL {
      ?marriage :to ?end
       }
}

and this will give us the expected responses, but that's only because we
have used the "MARRIED" label as an ersatz property URL, creating what
appears to be a hypergraph relationship, if you assume that any hypergraph
requires a proxy for a set (here rdfs:label is used as a subproperty of
rdfs:member).

That's why you have to be very careful about how close you create
equivalencies between LPGs and RDF. LPGs hide a lot of the complexity, but
they also don't handle multiplicities efficiently. RDF is more verbose, but
is also more exacting in its specification.

With regards,

*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 1:11 PM Sasaki, Felix <felix.sasaki@sap.com> wrote:

> “The user usually doesn't see the predicate identifiers directly; they
> only see the label“
>
>
>
> For creating data
>
> CREATE        (liz:Person {name: 'Liz'}), (richard:Person {name:
> 'Richard'})
>
> CREATE        (liz)-[:MARRIED {from: 1964, to: 1975}]->(richard)
>
> CREATE        (liz)-[:MARRIED {from: 1985}]->(richard)
>
>
>
> That does not bother them, and also not for querying the data
>
> MATCH (liz:Person {name: 'Liz'})-[m:MARRIED]->(richard:Person {name:
> 'Richard'})
>
> RETURN m.from AS StartYear, m.to AS EndYear
>
>
>
> Best,
>
>
>
> Felix
>
>
>
> *Von: *Kurt Cagle <kurt.cagle@gmail.com>
> *Datum: *Freitag, 19. April 2024 um 21:53
> *An: *ddooss@wp.pl <ddooss@wp.pl>
> *Cc: *Pierre-Antoine Champin <pierre-antoine@w3.org>, Lassila, Ora <
> ora@amazon.com>, RDF-star WG <public-rdf-star-wg@w3.org>
> *Betreff: *Re: reifiesDomain-14 (Re: proposal: a reifier should reify
> only one "thing")
>
> >> This is actually an error that arises in LPGs, because they have no way
> of differentiating #marriage1 from #marriage3.
>
> > It's not true. Most PG definitions or implementations allow you to
> create two edges with the same label and different properties.
>
>
>
> I'm saying that this is a modelling error with LPGs.  The edge contains
> the identifier in the assertion, not the nodes. In an LPG (specifically
> Neo4J):
>
>
>
> (Liz marries Richard) [from 1964; to 1975]
>
> and
>
>
>
> (Liz marries Richard) [from 1985]
>
> are distinct because the predicate "marries" carries the (implicit)
> identifier, and any query is actually an query on the text of the labels.
>
>
>
> This is equivalent to
>
>
>
> <<:liz :marries-1 :richard>> [:from 1964 ; to: 1975] .
>
> <<:liz :marries-2 :robert>> [:from 1977 ; to: 1981] .
>
> <<:liz :marries-3 :richard>> [:from 1985] .
>
>
>
> :marries-1 rdfs:label "marries" .
>
> :marries-2 rdfs:label "marries" .
>
> :marries-3 rdfs:label "marries" .
>
>
>
> The user usually doesn't see the predicate identifiers directly; they only
> see the label, so they don't recognize that the first and third statements
> actually have different predicates with the same name. That is CERTAINLY
> the case for Neo4J; I'm not sure about other LPGs.
>
>
>
>
>
>
>
> *Kurt Cagle*
>
> Editor in Chief
>
> The Cagle Report
>
> kurt.cagle@gmail.com
>
> 443-837-8725
>
>
>
>
>
> On Fri, Apr 19, 2024 at 12:30 PM ddooss@wp.pl <ddooss@wp.pl> wrote:
>
> Kurt Cagle <kurt.cagle@gmail.com>:
>
> <<#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.
>
>
>
> It's not true. Most PG definitions or implementations allow you to create
> two edges with the same label and different properties.
>
>
>
> Best,
>
> Dominik
>
>
>
>