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

Re: [Graphs] Proposal: RDF Datasets

From: Richard Cyganiak <richard@cyganiak.de>
Date: Tue, 23 Aug 2011 16:28:35 +0100
Cc: RDF Working Group WG <public-rdf-wg@w3.org>
Message-Id: <09A22A6A-2AE3-48E7-ADFA-7ABFB3883AEA@cyganiak.de>
To: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
On 23 Aug 2011, at 16:06, Pierre-Antoine Champin wrote:
> we seem to agree that, in order to address the multi-graph use cases, we
> need an abstract syntax allowing several datasets to be "embedded" (or
> "projected") into a single dataset.

Well, I don't know -- we have to look at the use cases and check.

But I'm prepared to believe that there are use cases that would benefit from this.

> I proposed a triple-based abstract syntax (from RDF 2004), and achieved
> the "embedding" by using an ugly mix of abstract and concrete syntax.
> You proposed a quad-based abstract syntax (from SPARQL), and aim to
> achieve the "embedding" by ensuring unique graph URIs.

It seems like a promising direction to explore.

>> I think this projection is trivial *if* all “quad publishers” synchronize their graph names to avoid overlaps.
>> That's a big “if” of course, 
> indeed!
>> and there is nothing in the RDF Datasets proposal that demands or even encourages such synchronization.
> and if there was, that would *not* be a simple copy-paste of the SPARQL
> proposal... This amounts to asking to people to use their SPARQL stores
> *in a certain way*.
> So your argument of ensuring interoperability by reusing an existing and
> working solution seems to backfire a little bit...

Well, the synchronization of graph IRIs could perhaps be achieved using some combination of data model features and good practice.

Essentially, I think if N=4 works very well but N>4 is a bit cumbersome or relies on conventions rather than hard standards, then we might still have a good-enough solution.

>> I'd be interested to learn about use cases that require N>4.
> well, none of course, by the virtue of the flattening allowed by your
> strong hypothesis above :)


Let's say, which use cases *motivate* N>4.

> But the kind of thing that I had in mind was like:
>  <pa-says> = {
>    <nostradamus-profecy> = {
>      <end-of-world> <in-year> 2012 .
>    }
>  }
>  <richard-says> = {
>    <nostradamus-profecy> = {
>      <end-of-world> <in-year> 2468 .
>    }
>  }


>> “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.
> Thanks for that reference, I didn't know it, and think it is useful to
> keep it in mind.
> But I also think that someone's tarpit is someone else's swimming pool.

That's why we need to talk about concrete use cases. Is solving the use cases with the proposals under consideration easy or hard?

> Many people around me keep complaining about RDF being a triple-tarpit
> already (without extending it to support multi-graphs, that is).

Yeah, same here. So let's not standardize a tar-pit inside a tar-pit ;-)

Received on Tuesday, 23 August 2011 15:29:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:00 UTC