Re: RDF-star use cases from Amazon Neptune

> Am 04.12.2021 um 20:12 schrieb Kingsley Idehen <kidehen@openlinksw.com>:
> 
> On 12/3/21 6:31 AM, Pierre-Antoine Champin wrote:
>> 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.
>> 
>> 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 ;-)
>> 
>> 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]).
>> 
>>   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
>> 
> 
> 
> Yes!
> 
> In my excitement I inadvertently truncated part of the original response :)


Yeah, this is so wrong, it just hurts. You think semantics have to be awkward and if they are that’s a good thing because it is a sign of logical superiority - is that it? You are falling for some pretty false advertizing!

Now, the example that Ora calls awkward is an example of a syntactic problem of RDF-star, not a semantic problem. RDF-star is obviously very verbose and using its nesting provess to solve the Wikidata use case (which in more tecnical terms is a multiset use case) is syntactically awkward. There’s nothing nice about that. Proper statement identifiers like the ID attribute that the RDF/XML syntax provides would be much more practical.

But the core of Pierre-Antoine’s claim is even worse. He says because RDF (and by extension RDF-star) has semantics it naturally is more awkward than property graphs - but that is false. What is true is that in a language without semantics you can stuff different semantics into the same syntax. This may be fine in local applications but can lead to trouble when sharing data - which is why RDF is based on formalized semantics. Disambiguation however doesn’t come for free and so some things are more tedious in RDF than they are in property graphs. That is indeed just unavoidable - expressivity comes with a cost, always.

However, there are many different ways in which a semantics can be defined. It can be tailored to some very specific use case, it can try to provide an 80/20 compromise of sensible defaults with clear extension points, or it can take a formalistic stance and favor simple primitives at the cost of being hard to use in most practical use cases.

The RDF-star CG has made some very peculiar decisions that make it indeed awkward to implement standard use cases. Instead it dramatically favors niche ones. RDF-star was conceived as syntactic sugar for RDF standard reification, to get rid of the reification quadlet. With the Community Groups’s proposal that quadlet is now reduced to a dohblet - two triples instead of four - while it could just as well have been reduced to zero extra triples with a different semantics. It didn’t even bother to think this through and provide a definitive vocabulary for the case where e.g. you want to annotate a statement with some provenance information. How’s that for "Yes!"?

Now, Pierre-Antoine has the nerve to call this progress - two is less then four, right?! -because he doesn’t care, because he doesn’t want to deal with the complexities of RDF semantics in real life, because his Explainable AI use case is covered, because he thinks that basing all meta modelling in RDF on the equivalent of triples printed out on paper would be a good idea. Sure, every use case can be based on such a semantics, it just takes two extra triples here, two extra triples there, and new properties galore, in case you didn’t notice.

In other words: the proposed RDDF-star semantics is as unbalanced as it can possibly get. But it has semantics, yippie yippie yeah. You will have to look a little closer to come to a fair assessment I’m afraid.

Thomas





> Kingsley
> 
>> 
>> 
>> 
>> 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
>>> 
> 
> 
> --
> Regards,
> 
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Home Page:
> http://www.openlinksw.com
> 
> Community Support:
> https://community.openlinksw.com
> 
> Weblogs (Blogs):
> Company Blog:
> https://medium.com/openlink-software-blog
> 
> Virtuoso Blog:
> https://medium.com/virtuoso-blog
> 
> Data Access Drivers Blog:
> https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers
> 
> 
> Personal Weblogs (Blogs):
> Medium Blog:
> https://medium.com/@kidehen
> 
> Legacy Blogs:
> http://www.openlinksw.com/blog/~kidehen/
> 
> 
> http://kidehen.blogspot.com
> 
> 
> Profile Pages:
> Pinterest:
> https://www.pinterest.com/kidehen/
> 
> Quora:
> https://www.quora.com/profile/Kingsley-Uyi-Idehen
> 
> Twitter:
> https://twitter.com/kidehen
> 
> Google+:
> https://plus.google.com/+KingsleyIdehen/about
> 
> LinkedIn:
> http://www.linkedin.com/in/kidehen
> 
> 
> Web Identities (WebID):
> Personal:
> http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
> 
>         :
> http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
> 
> 
> 
>