Re: New RDF API and RDFa API Editor's Drafts

On 12/09/2010 09:56 AM, Toby Inkster wrote:
> On Thu, 2010-12-09 at 00:59 -0500, Manu Sporny wrote:
>> The RDF API
>> http://www.w3.org/2010/02/rdfa/sources/rdf-api/
>>
>> The RDFa API
>> http://www.w3.org/2010/02/rdfa/sources/rdfa-api/ 
> 
> A few comments:
> 
> Firstly, what's the point of the callback parameter to
> DataParser.parse(). It seems pretty useless, but it's not optional. 

I believe that Nathan put that in there to ensure that people could do
something once the graph was constructed (like merge it in w/ the
default graph, clean it up, etc.). I think it's only called on
success... Nathan will have to clarify.

> If I
> want "foo" to happen to the graph after parsing is complete, it's
> encouraging me to use:
> 
>  turtle.parse(doc, function(g) {
>   foo(g);
>  });
> 
> whereas it seems far more simple and natural to do this:
> 
>  turtle.parse(doc, null, null, null, g);
>  foo(g);

Yes, one could do that as well... but you don't know if g was
constructed successfully in that case. I guess you could check the
return value, though. Again, Nathan will have to respond.

> Anticipating an answer of "parallel processing", I'll counter with "look
> at the return value of parse()"! If parse() has to wait to return a
> success indicator, it can't be processed in parallel with the following
> code.

I don't think "parallel processing" came into the equation at any
point... but again, Nathan.

> Given that (at least in the way it's currently defined) it's pretty
> esoteric it should be made optional, and placed *after* the other more
> useful parameters like base, filter and graph in the method's argument
> list.

I agree, I wouldn't expect the callback to be used that often. I would
expect the graph to be provided more often than any of the other
arguments, maybe this should be the signature instead:

boolean parse (in any toparse,
               in optional Graph graph,
               in optional DOMString base,
               in optional TripleFilter filter,
               in optional ParserCallback callback);

> Secondly, PropertyGroups (which are still an awful name by the way, or
> are they now Projections?) seem to make a lot more sense as part of the
> RDF API.

We have both PropertyGroups and Projections in the RDFa API now.

The difference is that a PropertyGroup holds a bunch of properties
associated w/ a particular subject and is returned by these calls:

 document.getItemBySubject()
 document.getItemsByType()
 document.getItemsByProperty()

Maybe we should rename PropertyGroup to Item :P - I don't like the name
either, but Mark is really pushing for it (for a number of sensible
reasons).

A Projection is a very specific, language-native view on a subject's
data that is specified by the developer and is returned by this call:

 document.data.query()

I had argued to put one or both of these into the RDF API. The issue
with this approach is that we simultaneously want to decouple the RDFa
API from the RDF API... so we can't have any links from the RDFa API
document to the RDF API document. Perhaps the RDF API could reference
the RDFa API - it would be strange, but that would ensure that the RDFa
API could proceed at a faster pace than the RDF API.

Or, perhaps we should just give up on decoupling both specs, put
PropertyGroups and Projections into the RDF API spec and call it a day.
Implementers are probably not going to care - Projections and Property
Groups are such simple objects, they're not going to change much during
the development of the spec.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Linked Data in JSON
http://digitalbazaar.com/2010/10/30/json-ld/

Received on Friday, 10 December 2010 12:03:30 UTC