Re: [Graphs] Proposal: RDF Datasets

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
syntax.

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.

  pa



[1] http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC

Received on Tuesday, 23 August 2011 09:49:39 UTC