Re: [Graphs] Proposal: RDF Datasets

Hi Pierre-Antoine,

Thought experiment. Let's assume there was some way to ensure that

1. no two SPARQL stores share any graph names,
2. every SPARQL store has an IRI that allows talking about its contents.

(Don't ask me how -- it's a thought experiment.)

I believe this would mean that collections of “quad-sets” can be “flattened” into just one “quad-set”, so quintuples are unnecessary to keep track of provenance of quad-sets.

Would you agree?

More inline.

On 23 Aug 2011, at 09:51, Pierre-Antoine Champin wrote:
> 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.

I'm sympathetic to that.

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

I think this projection is trivial *if* all “quad publishers” synchronize their graph names to avoid overlaps.

That's a big “if” of course, and there is nothing in the RDF Datasets proposal that demands or even encourages such synchronization.

I'd be interested to learn about use cases that require N>4.

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

“Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.” [1]

Your proposal is a triple tar-pit. We know that *everything* can be represented in triples, but that doesn't mean that doing so is useful. The representation that you propose isn't. Let's not standardize triple tar-pits.

Best,
Richard

[1] http://en.wikipedia.org/wiki/Turing_tarpit

Received on Tuesday, 23 August 2011 11:43:53 UTC