W3C home > Mailing lists > Public > public-rdf-wg@w3.org > August 2011

Re: [Graphs] Proposal: RDF Datasets

From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
Date: Tue, 23 Aug 2011 10:51:53 +0200
Message-ID: <4E536A29.30703@liris.cnrs.fr>
To: Richard Cyganiak <richard@cyganiak.de>
CC: RDF Working Group WG <public-rdf-wg@w3.org>
Hi Richard,

our discussion yesterday helped me pinpoint another thing that bothers
me in the Dataset model, and that was an implicit rationale of my own
proposal -- thanks for helping me making it explicit :)

An important motivation for standardizing multi-graphs is to be able to
cope with RDF data from multiple sources without blindly merging them.
This is covered by the Storage, Query and Provenance use cases [1].

RDF data is currently defined as a set of triples, so with SPARQL
Datasets or any other kind of quad-store, we have a nice way to keep
different graphs separate.

But if tomorrow RDF data is defined as a set of triples *or quads*, then
people will come up 5-uples to keep track of different quad-sets, and
will ask the next WG to standardize them...

The only way out of the vicious circle is, IMHO, to specify a way to
"project" (N+1)-uples into N-uples, so that arbitrary level of embedding
can still be represented in the abstract syntax of RDF.

My proposal was to work with N=3, as this is what we already have, and
attempted to define a way to perform that projection.

You would prefer, it seems, to extend the abstract syntax to N=4, but
didn't make any proposal yet to project data with N>4 into that abstract

Note that this notion of "projecting" (N+1)-uples to N-uples does not
mean that we will never work with (N+1)-uples anymore... In my proposal,
the fact that Trig and SPARQL datasets *can* be expressed as a plain
triples does not mean that people *must* do it that way: they would
probably continue to serialize in Trig or store their datasets in
quad-store... But the "projection" ensures a level of interoperability
by allowing anyone working with the plain concrete syntax to retrieve,
store and handle more complex data, even if non-optimally.


[1] http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC
Received on Tuesday, 23 August 2011 09:49:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:08 UTC