Re: RDFa API - graph?

Hi Mark,

Full mail below:

Mark Birbeck wrote:
> On Sun, Oct 31, 2010 at 3:32 PM, Nathan <nathan@webr3.org> wrote:
>> 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.
> 
> Ah...ok. In which case I don't agree. We need both Graphs /and/ Stores.

see below I agree we need a distinction between Graphs and Stores, and 
that often we need a Store to handle our RDF Graphs, but more on that below.

>> 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.
> 
> Yes, that's pretty much all we need.
> In the main, the Graph interface needs to have methods that act
> directly on the graph (such as adding triples), whilst the Store
> interface needs to have an additional parameter so that the graph to
> operate on can be specified (such as which graph to add the triple
> to).

agreed

>>> 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);
> 
> No...it's not like that at all. The parallel to what I'm talking about
> would be writing a SPARQL query without expressing any 'FROM' clauses;
> in that case the query is run against 'all graphs' (what SPARQL calls
> the 'RDF dataset').
> 
> It's very common now to place data from multiple sources into a
> triple-store and use named graphs to track the provenance, but then
> query the store as if it were one graph. (See the example that I gave
> in response to Ivan's email for more on this.)

Perhaps just a slight confusion, I'm saying there are two kinds of query 
interface, one "query a graph" and two "query a store" - looks like you 
are too - hopefully clarified below

>> Best and thanks for replying, hopefully we can get the details of this
>> agreed :)
> 
> Not at all...in fact I'm jumping on this. ;) I raised the distinction
> between graphs and stores a while back but got some pushback; this is
> a great way to revisit some of the issues.

Great, I too see the distinction between a Store and a Graph, and tbh 
I'd be surprised to hear an argument to the contrary!

So, right back to basics, here's how I'm seeing things:

We're working with RDFa so need to extend the DOM document interface 
with methods to handle the RDF in attributes / work with RDFa documents.

Also, since it's RDF, we need interfaces for the core RDF Concepts:

  RDF Graph, RDF Triple, IRI, BlankNode, PlainLiteral, TypedLiteral

In addition to these interfaces we need:
- Methods to create instances which implement the above interfaces
- Methods handle CURIEs
- Methods to handle converting to and from a typed literal

Then we need an interface to lift Graphs from serializations in a 
synchronous or asynchronous manner, or to process (parts of) the Graph 
contained within the serialization.

As I see things, the above is the bare minimum that we must standardize 
in order to make any form of RDFa API.

Next up I see four areas of common functionality which aren't always 
needed in every scenario, but are extremely common, and would be nice to 
standardize:

1 - Serializing a Graph
2 - Querying a Graph
3 - Storing Graphs
4 - Querying a Store which contains multiple Graphs.

The first, Serializing a Graph is extremely simple and could be classed 
as an easy hit: interface Serializer { String serialize(graph) }

The second, Querying a Graph, is also extremely simple and could be 
classed as an easy hit: interface Query { any select(query, graph) }

The third and fourth are (arguably) somewhat more complex, sure we can 
come up with really simple interfaces for both, but would they actually 
be implementable by every Store and query engine? Regardless I do see 
the need for them both, but also the "RDF TripleStore APIs (optional)" 
listed in our deliverables, and forgive me for asking, but if we're not 
talking about an RDF Triple Store API when we talk about a Store for 
RDF, then what are we talking about?

Best,

Nathan

Received on Sunday, 31 October 2010 21:09:41 UTC