RE: RDF* vs RDF vs named graphs

I have been unable to follow this thread adequately. But I want to encourage the group to fully-bake an excellent value proposition (speaking to Thomas' <rant>rant content</rant>). Since 1994 I've been designing databases, with mastery in relational and star schema (Kimball). My interest in PG and RDF/RDF* is very strong--I see them as complimentary to what I've already learned. Nevertheless, I have found RDF difficult to get into, whereas PG has been easy. To get serious market buy-in, you must capture the heart of the developers. Being accessible to relational and PG folks will be essential.


-----Original Message-----
From: thomas lörtsch <>
Sent: Monday, November 30, 2020 8:55 AM
To: Miel Vander Sande <>
Cc: james anderson <>;
Subject: Re: RDF* vs RDF vs named graphs


> On 30. Nov 2020, at 12:21, Miel Vander Sande <> wrote:
> That's valid and I also see the merit of having it as part of RDF* rather than N3 (then should be well aligned and the nquads/trig syntaxes would be rooted).
> But AFAIK nobody actually officially dismissed including graph annotation,

That’s not true. Over the last one and a half years I brought up the issue of quads and Named Graphs several times in mails long and short and Olaf made it quite that he doesn’t want to discuss this matter. The RDF* space actually feels like a rather hostile territory w.r.t. quads, graphs etc. I understand that the failed attempt of the RDF 1.1 WG to standardize Named Graph semantics burned the ground and that it might seem easier to get things done if one evades the question, but actually: one just can’t.

> so why not gather the stakeholders from enterprise, make a joint request for scope expansion, and have a structured discussion there? Evidently, a broader scope should come with the necessary engagement to manage the debate, follow-up on issues, and draft the specs. Let's approach this positively, this group is an opportunity :)

We had that funny little moment of awkwardness in last week's call when the WikiData use case came up and nobody dared to spell it out: as long as RDF is based on sets there is no way to have the same assertion multiple times in the same graph, with different annotations. PG mode looks like it could do it but it can’t. There is no clear mapping between PG and SA mode.
Pierer-Antoine proposes to introduce an intermediate blank node in SA mode, but that is exatly the opposite of a new approach to reification: one can model everything with blank nodes in RDF already, one always could.
Named graphs can do it, of course, but we then get to some kind of nesting or embedding of graphs. I’m quite convinced that nesting graphs (while not giving up on the triple-ish surface and serialization) is the way to go for a solution that can cater to all use cases! But is it well-investigated, proven, does it have a semantics covering all the corner cases? I’m not aware of such work. I’m working on it but I definitely can’t pull it off alone.
I did write some long-ish and one very long mail regarding this subject and I got very little support or even actual discussion on the nitty-gritty. Pat and Peter are dropping Named Grapgs superiority from time to time on thias list, which is good to keep the topic on the table, but of course not enough to solve it. Of course there are issues, e.g. I disagree with Pat on how graphs should be named.

In that respect I totally agree with you, Miel: where is the activity, warmly welcomed or not? But in the end this needs both: people willing to work on it, and this community to endorse the activity.



I don’t know why nobody reacts when I write to this list that Pierre-Antoine's semantics ground RDF* in abstract triple types while Peter’s semantics grounds them in occurrences - and I couldn't think of a more fundamental difference in terms of semantics, certainly more fundamental than the question if they are referentially opaque or transparent.

I’d rather not have work my way around RDF* later because it has subtly broken semantics. It would be much better if RDF* was formalized in a way that fits into the semantics of RDF, including sensible default assumptions for the semantc pieces missing in RDF, or extending it right away!

If RDF* ends up with the a semantics that doesn’t only have gaps, like RDF Standard Reification and RDF Named Graphs, but is outright misguided, where is the value proposition that may convince PG store users to switch boat? What’s left then of the advantage of RDF over PG: standardized serializations? I think the PG community can pull that off on its own. If I had vested interest in an RDF software and would want to make inroads in the PG market rather sooner than later, I’d be careful nonetheless…

RDF* is a subset of what can be done with Named Graphs. It may very well be a very intuitive and useful subset, even giving the impression it was orthogonal to named graphs. But if RDF* isn't formalized in a way that relates it to Standard Reification and Named Graphs the risk is very high that in the end RDF* will only add to the mess of half-finished approaches to meta modelling in RDF: supporting some practical needs but not supporting others - and no poor soul that doesn’t crawl very deep into the rabbit hole of formal semantics will be able to understand which, and why. There goes intuitivity.

> Op ma 30 nov. 2020 om 11:56 schreef james anderson <>:
> > On 2020-11-30, at 09:48:18, Miel Vander Sande <> wrote:
> >
> > ...
> >
> > I appreciate the work this group is doing in terms of making the interpretation of reification clear and usable. Its main goal is still to provide compatibility with the PG world, where properties over a group of edges simply doesn't exist. I think this limited scope actually helps getting somewhere within reasonable time.
> in order for this effort to yield a useful result it will need to do more than "provide compatibility with the PG world”.
> during the call last friday, one exchange included
>     blake: I want to inquire a bit to see the aspects of embedded graph, embedded quad
>     <thomas> +1 to blake: keeping the possibility open to have embedded quads in the future
>     pchampin: A very good question by blake. There should be an issue for that in the repo. Yet another separate question
>     ... that need to be checked and discussed
>     ... Anyone wants to react?
>     <pchampin> ACTION: blake to submit an issue on embedded quads
> that is, quads are seen as “something to be discussed”.
> the statistics on our sites suggest a stronger imperative.
> while triples dominate quads on a free site by a ratio of five to one, which would suggest that to claim pg-compatibility suffices, on an enterprise site the ratio is fifty to one in the opposite direction.
> in those contexts, if rdf* does not provide for quads, it will be of little use.
> ---
> james anderson | |



The information contained in this message is intended only for the recipient, and may be a confidential attorney-client communication or may otherwise be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please be aware that any dissemination or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the message and deleting it from your computer. S&P Global Inc. reserves the right, subject to applicable local law, to monitor, review and process the content of any electronic message or information sent to or from S&P Global Inc. e-mail addresses without informing the sender or recipient of the message. By sending electronic message or information to S&P Global Inc. e-mail addresses you, as the sender, are consenting to S&P Global Inc. processing any of your personal data therein.

Received on Monday, 30 November 2020 14:08:13 UTC