Re: RDFa DOM API - New Editor's Draft

On May 29, 2010, at 19:56 , Manu Sporny wrote:
[snip]
> 
>> - I need some education on the role of DataIterator in a DataParser.
>> My mental model seems to be too simple: I would expect a parse
>> operation to be defined on a DataStore, so that I say
>> 
>> store = new DataStore() // or whatever the syntax is
>> store.parse("http:....")
>> 
>> and that is it.
>> I obviously miss something...
> 
> The reasoning goes something like this:

First of all, I think my question had two parts. One is why having the DataParser interface separately (and that is what you are arguing for below) and the second is what is the role of the 'DataIterator' method within that interface. You did not answer on the second...

> 
> "Parsing" is the job of the "Parser", not the store. To put this in
> another context. We don't expect a MySQL's InnoDB store to be able to
> extract information from a non-SQL source and place it into storage.

I am not sure that comparison is relevant, frankly. What we are talking about here is a data store that parses in RDF data (ie, using one single data model) that has different (ie, conceptually equivalent) serializations. Microdata might be a bit of a stretch at first glance, but not that much. 

> That is the job of the application - to "parse" and direct the
> information into a "store".
> 

I was never particularly bothered by RDFLib's approach to have a parse method on a graph or, equivalently, Jena's approach doing the same:

Model model=new ModelMem()
model.read(new InputStreamReader(in)

Ie, I am not convinced by this argument. My concern, as always in this thread, is simplicity and an attempt to reduce the number of different interfaces...

Ivan


> We /could/ provide .parse() as a convenience function on DataStore and
> when a parser is created, do:
> 
> store.parser = theNewParser;
> 
> but then that limits us to only having one parser associated with a
> particular store when we may want to have multiple parsers associated
> with a particular store.
> 
> Mark wants to put .parse() on the document.data object, so you could do
> this:
> 
> document.data.parse()
> 
> This would use the default parser (document.data.parser) to perform the
> parse of the data.
> 
> At the moment, no decision has been made as to whether or not we need a
> .parse() convenience method. At the moment, .parse() resides here:
> 
> document.data.parser.parse()
> 
> At the moment, we instruct implementers to call
> document.data.parser.parse() once the document is loaded. There is an
> argument for not calling it (we shouldn't assume that pages have RDFa
> data in them and we don't want to increase the burden of having to do
> this for mobile devices).
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: Bitmunk 3.2.2 - Good Relations and Ditching Apache+PHP
> http://blog.digitalbazaar.com/2010/05/06/bitmunk-3-2-2/2/
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf