Re: RDF-star use cases from Amazon Neptune

Hello. 

I may be not very bright, and not very adept to these issues, but it seems to me dangerous to conflate in the same triples meanings that are very different in nature. In this case, marriage and wedding. 

"Being married" is a state, and can only be true or false, but not multiple. On the other hand, most states are time-dependent and they may change truth value over time (as well as jurisdiction, point of view, etc.). Most states that I know about are time-dependent, even though it affects only one interval: is Barack Obama President of the United States? Is Napoleon the Emperor of France? In both cases (as in the proposed wedding example) the answer is neither "yes" nor "no", but "wrong tense, buddy!": they were in the past, they are not. This is exactly the situation for which I understood there was the most urgent need for RDF*: 

:lizTaylor :married :richardBurton {|
 time:during :interval1;
 time:during :interval2; 
|}

:interval1 a time:interval;
 time:starts "1964"^^xsd:Year;
 time:ends "1974"^^xsd:Year.

:interval2 a time:interval;
 time:starts "1975"^^xsd:Year;
 time:ends "1976"^^xsd:Year.

In this case it does not even make sense to mention the location of the wedding.

--

"Marrying" is an event, it happens in one specific interval in time, and there can be multiple exemplars with the same attributes, but each one has its own identity.

:FirstMarriage a :wedding;
 :bride :lizTaylor;
 :groom :richardBurton;
 :in :montreal;
 :on "1964-05-15"^^xsd:Date.

:SecondMarriage a :wedding;
 :bride :lizTaylor;
 :groom :richardBurton;
 :in :botswana;
 :on "1975-10-10"^^xsd:Date.

If we are describing events, there is very little need for RDF*, as far as I can see. 
 
I personally do not see the Liz Taylor/Richard Burton example as a situation in which we want to count the occurrences of  (plain or RDF*) triples. listing occurrences answers, from my point of view, a different type of question: not "how many times were Taylor and Burton married", but "how many different datasets mention that Taylor and Burton were married?" 

Counting occurrences of triples is used to identify how many different representations of the fact we were able to collect, not how many different facts were collapsed into identical triples. 

Fabio

> On 3 Dec 2021, at 13:23, thomas lörtsch <tl@rat.io> wrote:
> 
> 
> 
> Am 3. Dezember 2021 12:31:44 MEZ schrieb Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>:
>> Ora,
>> 
>> thanks for these use-cases? Do you want to add an agenda item in today's 
>> call for discussing them?
>> 
>> Below are my 2¢ about this.
>> 
>>> RDF semantics (...) stipulate that a triple <s, p, o> is unique 
>> (...). In LPGs, however, no such restriction exists for edges.
>> 
>> I think that presenting this feature of RDF as a "restriction" is 
>> unfair, and misses the point. In my view, the impedance mismatch between 
>> RDF and PGs is not due to some arbitrary restriction on the RDF model. 
>> It is due to the fact that RDF is a logic, that can be represented as a 
>> graph, while PG is a graph data model, without any semantic commitment.
> 
> That's giving the wrong impression that logic wouldn't allow to solve the wikidata use case. RDF semantics is based on sets because that is simpler than basing it on multisets (probably much simpler) and does the job in many cases. However not in all cases. Nobody wants to change the RDF semantics to multisets to accomodate those multiset usecases but it seems we have to find a solution for this problem - the easier the better. The current proposal by RDF-star is not very compelling in this respect. 
> 
>> An RDF triple (s p o) is a /statement/ before being an edge in a graph. 
>> It states that the relation (denoted by) p holds between (the things 
>> denoted by) s and o. That statement is either true or false; therefore 
>> the triple is either in the RDF graph or it is not.
>> 
>> Either Bob is married to Alice or not. Either there is a pipe between M1 
>> and M2 or there is none. If finer grained information is required (which 
>> marriage? which pipe?), then additional nodes must be added (as 
>> suggested by Jos in his answer, or in 
>> https://w3c.github.io/rdf-star/cg-spec/2021-07-01.html#occurrences). 
>> That is a feature of RDF, not a bug.
>> 
>>> [ about the example with  "double-nested" triples ]
>>> This is of course a perfectly valid approach, but it does not match 
>> the typical approach when using LPGs.
>>> Note also that, while the example above captures the correct 
>> semantics, it is awkward (...
>> 
>> It might be awkward, but if it captures the correct semantics, then 
>> maybe that's the way it should be represented in RDF ;-)
> 
> It's not awkward in real life, in natural communication. If it's awkward to express in a formal language than that is a problem. The challenge is to find ways to formalize natural communication in ways that are both easy to use and formally correct. That's of course not easy, but it sure isn't a sign of success if the logic is sound but the formalization is awkward. 
> 
>> More generally, I strongly believe that, because of the different 
>> focuses of RDF vs. PG, we should not strive for a one-size-fit-all 
>> mapping between the two. Different patterns in PGs convey different 
>> semantics, therefore they should be mapped differently to RDF. This is 
>> the line of work explored by Julian Bruyat in his PHD (which he also 
>> presented at the SCG workshop [1]).
> 
> I strongly believe that you don't care enough because your main interest is in extreme use cases like explainable AI. With that mindest you fail to see the significance of the shortcomings of the RFD-star proposal in more main stream use cases. A good formalization has to strike a balance.  That is of course much harder than settling for an extreme and then let everybody else jump through some hoops, or declare their needs irrelevant.
> 
> The hope of the broader community was that RDF-star could bridge the gap between RDF and Property Graphs. That's how Olaf pitched it at the W3C graph workshop in Berlin 2019 and how it got support and thrust (besides the other claim that it was just syntactic sugar for RDF standard reification). You're not willing to work on that but would rather like to turn RDF-star in an N3 surrogate for singleton formulas. Fine, but don't claim that this is the way it has to be as if logic dictated this outcome, because that's a betrayel to the community. Not to mention that with the proposed semantics RDF-star isn't syntactic sugar for RDF standard reification anymore either. 
> 
> 
> Thomas 
> 
> 
>>   best
>> 
>> [1] Bruyat et al.  "PREC: Semantic Translation of Property Graphs". 1st 
>> Workshop on Squaring the Circle
>> on Graphs (SCG2021), SEMANTiCS 2021. 
>> https://mosaicrown.github.io/scg2021/#mu-schedule

>> 
>> 
>> On 02/12/2021 19:43, Lassila, Ora wrote:
>>> 
>>> Folks,
>>> 
>>> Attached is a document that outlines a couple of uses cases (variants 
>>> of one modeling pattern ,really) we would like to submit for 
>>> consideration by the upcoming RDF-star Working Group. I am submitting 
>>> these now just in case this turns out to be relevant to how the 
>>> charter gets written. Comments are welcome, and I am happy to discuss 
>>> these use cases whenever.
>>> 
>>> Regards,
>>> 
>>> Ora
>>> 
>>> -- 
>>> 
>>> Dr. Ora Lassila
>>> 
>>> Principal Graph Technologist, Amazon Neptune
>>> 
>>> Amazon Web Services
>>> 
>>> ora@amazon.com
>>> 
>

Received on Friday, 3 December 2021 14:55:53 UTC