Re: Question about RDF Spaces

On Sun, 2012-05-27 at 23:42 +0100, Nathan wrote:
> Hi Sandro / All,
> 
> Regarding http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-spaces/index.html
> 
> It appears to me (still) that every use case could be handled with more 
> specificity and in a more extensible way, by allowing RDF Graphs to be 
> in the subject or object position of an RDF Triple.
> 
> Thus I have to ask, what advantage does the approach of using RDF Spaces 
> / Quads / Datasets have?

It's deployed in SPARQL.   From where I'm sitting, that's at least 90%
of the reason the WG has gone in that direction.

It's taken me a long time to get comfortable with that, after many years
of thinking about about handling graphs as one would in n3 or might in
Prolog, but I'm pretty sure this works fine, too.
 
> As a secondary question, what happens when I want to apply any of the 
> usecases to a quadset / dataset? do I then need a 5-tuple?

No, that's what the somewhat confusing 'Untrusting Merge" section is
trying to explain, although I understand it does it poorly.

If you want to load a graph into a dataset while keeping it distinct (so
you can delete it later, keep track of where it came from, whatever,
without it touching anything in there now), you put it into a fresh
named graph.   If you want to load a dataset into a dataset while while
keeping it distinct in the same way, you load each of its graphs into
fresh named graphs, and do a little renaming and recordkeeping.   It's
not quite as elegant as arbitrary nesting, but it's not bad, and might
be easier to code efficiently.

> Finally, what is the relation between a space and the triples in that 
> space? I read it's formalised as CT(S, T) - but to me that just looks 
> like a triple { S CT T. }, with the constraint imposed that you can't 
> specify what the CT relation is.

Right -- because SPARQL doesn't let you specify what that relation is,
we have to pick one.   In the rdf-spaces proposal, I'm saying that
relation is either what you'd know from n3 as log:semantics or perhaps
log:semantics!log:include.  (It's an open issue which of the two the
relation is, or if we'll settle on it at all or leave it somehow open.)

  -- Sandro

> 
> Best,
> 
> Nathan
>

Received on Monday, 28 May 2012 00:59:34 UTC