Re: RDFa API - Collections / List

Hi Nathan,

On Tue, Oct 12, 2010 at 10:46 AM, Nathan <nathan@webr3.org> wrote:
> Mark Birbeck wrote:
>>
>> I agree with Ivan's comments, and would also add that the reason we
>> have avoided putting anything to do with lists and collections into
>> RDFa is that there is no consensus in the RDF community on the best
>> way to do them. It would have been very easy to make use of ol, ul and
>> li...but to generate what? alt, seq and bag are rarely
>> used...rdf:first, rdf:rest and rdf:nil don't have unanimous
>> support...it's really not clear what we should do.
>
> shame, this is something that should probably be nailed sooner rather than
> later, hopefully this will be addressed soon :)

I doubt it, I'm afraid. :) I think that issue could take a while for
the RDF community to sort out -- it's not very straightforward, and as
you are no doubt aware, there are many ways that lists can be
modelled.

(Of course that's my personal opinion.)


>> By the way, the main reason that the RDFa spec talks about triples
>> being generated in the 'default graph' is to allow for experimentation
>> to take place by using additional graphs.
>>
>> So if you wanted to generate rdf:first, rdf:rest and rdf:nil --
>> perhaps derived from <ol> and <ul> -- then provided your parser placed
>> these triples into a separate graph it would still be fully
>> conformant. Obviously you'd need to provide a way for developers to
>> get those triples, but that wouldn't be that difficult.
>>
>> (The RDFa API should support this, but there has been some reluctance
>> to get down to the graph level in the API...we might need to revisit
>> that.)
>
> If you think of a DataStore as a graph...

I would prefer that a store is a collection of one or more graphs, for
reasons explained below.


> ...there's no reason why you can't
> simply run a document through different parsers and in to different store -
> the API is really flexible this way.. one of the many ways of writing it
> would be
>
>  var lists = data.createStore();
>  new RDFaListParser(data.context).parse(document, lists);

Yes, that's the idea. Which by the way hopefully also reassures you
that the original design *did* take Tabulator into account. ;)


> I'm unsure whether the best approach is to have one parser using one store,
> or one parser producing multiple stores (graphs) and providing access to
> them - that's the functional programmer in me battling the OO programmer
> though!

Well, from an RDFa specification standpoint you need one parser to
send its triples to one store, with that store can contain many
graphs. This is because the spec allows for all defined triples to be
placed in a default graph, but then for extra triples to be placed in
additional graphs alongside that; it would be up to the parser to
decide which graph to place the triples into, within that store.

You could say that the same can be achieved by having multiple stores
(i.e., each store represents a graph), but that would mean that the
parser is no longer in control; you'd need to create multiple stores
and hand them over to the parser.

Also, I've always viewed a store as a standalone object that manages a
number of graphs via some particular storage medium. So one store
might just use JavaScript arrays, another store might use the HTML 5
local storage API, and yet another store might just be an interface to
a SPARQL/SPARQUL end-point. Within each of those stores you need one
or more graphs, since they will all be using the same storage medium,
and any queries to the store will need to be applied to all of the
available graphs.

(Another way to look at it is that the store provides a 'context'.)

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Tuesday, 12 October 2010 10:06:11 UTC