Re: RDF-star use cases from Amazon Neptune

It would be nice to discuss these if we have time.

The point of our use cases is not that we could not come up with a representation (in RDF or RDF-star), but that we are looking to bring RDF(-star) and LPGs closer together. RDF (with reification) and RDF-star have plenty of expressive power for these cases, but the solutions do not match how folks do this stuff with LPGs. The popularity of LPGs has something to do with the fact that the (programming) patterns and abstractions match what many software developers are used to, while RDF does not. This is not criticism of RDF, just an observation. And as you can imagine I am sure, I am (and always have been) a big proponent of RDF.

My use of the word “restriction” may be a bit unfair, but it is there to reflect that with RDF-star we are somewhat constrained as to what we can do. The bigger (and more important) picture is that the real difference between RDF and LPGs is really that while RDF can be used as a logical model for data, LPGs are “just” a data structure. I will touch on this in my talk later today at CDW 2021.


Dr. Ora Lassila
Principal Graph Technologist
Amazon Web Services

From: Pierre-Antoine Champin <>
Date: Friday, December 3, 2021 at 6:32 AM
To: "Lassila, Ora" <>, "" <>
Subject: RE: [EXTERNAL] RDF-star use cases from Amazon Neptune


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 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]).


[1] Bruyat et al.  "PREC: Semantic Translation of Property Graphs". 1st Workshop on Squaring the Circle
on Graphs (SCG2021), SEMANTiCS 2021.

On 02/12/2021 19:43, Lassila, Ora wrote:


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.



Dr. Ora Lassila
Principal Graph Technologist, Amazon Neptune
Amazon Web Services<>

Received on Friday, 3 December 2021 12:52:12 UTC