Re: RDFa API - graph?

Mark Birbeck wrote:
> So, if you are saying that a store is something that holds many graphs:
> 
>> ...it clearly separates the concepts of "Store" (somewhere to
>> store graphs and triples) and "Graph" (a set of triples, an RDF Graph)...
> 
> then that's great, and we can get on with making this happen (more
> below). If on the other hand you are simply suggesting we rename
> stores to graphs:

That's correct, specifically I'm suggesting that the DataStore Interface 
outlined in ISSUE-52:

   http://www.w3.org/2010/02/rdfa/track/issues/52

Be renamed to Graph or RDFGraph, and is a lightweight set of triples, an 
RDFGraph, distinct from the notion of Store.

This would also allow us, or libraries, to extend Graph with a 
NamedGraph interface, by simply adding in the name/uri of the graph.

It would also open the door for the definition of a Store in the way you 
describe, one which handles multiple named graphs and which can be 
SPARQL'd over.

Certainly we need to support multiple graphs (like the default and 
processor graphs), and ensure the API is compatible with the notion of 
NamedGraphs (as in easily extended to provide named graph functionality, 
as outlined above).

However, I'm entirely unsure whether we're the ones who should be 
defining what are essentially NamedGraphs, a QuadStore and SPARQL Query 
interfaces ...

Personally my gut feeling is that this is out of scope, but that the API 
needs defined in such a way that it's compatible with the future 
definition of such interfaces.

Perhaps it's enough for use to define an RDF Graph interface, allowing 
iteration and quantification, one which can be augmented with more 
triples, or filtered to produce a new (sub) graph.

Whilst we're on this subject I'm also unsure about the merge method, 
perhaps it should be more of a concat which treats the Graph as 
immutable (like filter does), returning a new Graph which is the 
combination of the two - that is perhaps a different conversation though.

> In the backplanejs RDFa API a lot of work went into making things work
> at the graph level. Triples can be stored in specific graphs within a
> store, and then queried either by explicitly stating a graph or by
> querying across 'all graphs' in that store.
> 
> This requires therefore that there's a graph interface that supports a
> simple add() method (like we have at the moment for store), but that
> the add() method on a store is changed to support an extra parameter
> to indicate which graph to add to. (In the backplanejs API this is set
> to either the string "default" or a full URI depending on where you
> want the triples stored.)

Kudos for getting named graph support and a multi graph store in there!

> Queries are much the same except that we need an additional concept of
> 'all graphs'.

Unsure on that one, certainly when you have multiple (named) graphs you 
need support for querying either single or multiple graphs, but surely 
there's a notion of just querying the single graph / set of triples you 
have which we can work with? something like a SPARQL select without the 
'FROM', like the where() introduced in Jeni T's library, or like my own 
prototype of RDF Selectors, essentially something along the lines of:

  querylang.query("some query", graph);

Best and thanks for replying, hopefully we can get the details of this 
agreed :)

Nathan

Received on Sunday, 31 October 2010 15:33:22 UTC