Re: RDFa API - graph?

Hi Nathan,

On Sat, Oct 30, 2010 at 4:03 PM, Nathan <nathan@webr3.org> wrote:
> Hi All,
>
> Just a small thought.. it dawned on me this morning that Graph or RDFGraph
> may be a better / alternative name for DataStore - personally when I
> mentally swap out all mentions of store for graph in examples, design and
> text things feel that bit clearer
>
>  graph.add(triple);
>  graph.merge(otherGraph);
>  document.data.graph;
>  serialize(graph);
>  graph.filter(myFilter);
>
> and so forth, it clearly separates the concepts of "Store" (somewhere to
> store graphs and triples) and "Graph" (a set of triples, an RDF Graph),
> further, graph is a common concept in the RDFa Core documentation, and all
> RDF documentation which goes unrepresented in the RDFa API.
>
> Anyway, just a thought, I'm sure you get the idea - any opinions?

You seem to be saying two different things here:

* that 'graph' is a better name for 'store';

* that a store should contain one or more graphs.

You and I have already had some discussion on this:

  <http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0162.html>

where I've indicated that a store is not a graph, but rather a
collection of graphs. This is important because the whole API only
makes sense with multiple graphs, and the only conceptual level at
which they can exist is in a store -- so we really must sort this out.

First, the 'theoretical' aspects:

The reason that the API only makes sense with multiple graphs is
because RDFa itself supports multiple graphs; although we only say
that triples are placed in the default graph, by implication that
still means that there are other graphs, even if we don't refer to
them. And therefore any API we define needs to indicate how to manage
graphs, otherwise we run the risk of people implementing this in
different ways.

And the reason that the only conceptual level at which these graphs
can exist is that of a store -- i.e., that it doesn't make sense to
simply rename stores as graphs -- is that we need to be able to group
graphs together into a single conceptual unit, so that we can query
multiple graphs at the same time in the same way that SPARQL allows us
to do.

>From an implementation perspective grouping graphs by store also means
that you can have many graphs sharing the same underlying
implementation mechanism; you can have a store that keeps all of its
graphs in memory, a store that uses HTML5 local storage, a store that
is simply a 'gateway' to a SPARQL end-point, and so on, and still
query across 'all graphs' in the same store.

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:

> Just a small thought.. it dawned on me this morning that Graph or RDFGraph
> may be a better / alternative name for DataStore...

then I can only say that I strongly disagree, and we need to discuss
this some more! (And I'm grateful for you raising it again.)

But allow me to assume for the moment that you favour the former, and
therefore that there's now a common understanding on the architecture
-- because that allows me to make some suggestions as to how we make
this whole 'graph thing' happen.

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

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

Regards,

Mark


>
> Best,
>
> Nathan
>
>
>
>

Received on Sunday, 31 October 2010 11:15:04 UTC