Re: Question about RDF Spaces

On Mon, 2012-05-28 at 03:02 +0100, Nathan wrote:
> Sandro Hawke wrote:
> > 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.)
> 
> Thanks for the clear answers Sandro :)
> 
> Final question, are blank node identifiers now scoped to surfaces (or 
> named graphs) such that they are reliable over time - thus enabling 
> common set operations on graphs? (Roughly where each surface sets the 
> scope for bnode identifier resolution / defines the universe in which a 
> bnode exists)

No, although I don't understand how this would work without breaking
things.

Blank node *identifiers* have always been scoped by particular RDF
syntaxes.  So far, they've been scoped such that there is no way to
serialize two graphs containing the same blank node.   You can construct
such things in an API or in SPARQL, but then not serialize it.  I
strongly advocate allow a multiple-graph syntax to convey graphs with
shared blank nodes, since they occur in several use cases -- typically
ones where one named graph is derived from another.

   -- Sandro

Received on Tuesday, 29 May 2012 23:32:25 UTC