W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > April 2011

Re: API changes - was Re: feedback from an RDF API implementation

From: Ivan Herman <ivan@w3.org>
Date: Fri, 22 Apr 2011 10:18:01 +0200
Cc: RDFA Working Group <public-rdfa-wg@w3.org>, Gavin Carothers <gavin@topquadrant.com>, Manu Sporny <msporny@digitalbazaar.com>
Message-Id: <380CC026-9689-40EF-BC70-2B65535A0EAB@w3.org>
To: nathan@webr3.org
Works for me.

Ivan

On Apr 22, 2011, at 24:06 , Nathan wrote:

> Following on from the email below, I'd like to drop in the changes to RDF API reflected by this feedback tonight as I'm updating the document.
> 
> My general train of thought is, get as much done before we review it as a proposed FPWD, then raise any issues on things people aren't happy with then, rather than going through the ISSUE process for a doc that doesn't even have a FPWD yet.
> 
> Is that okay with everyone?
> 
> Best,
> 
> Nathan
> 
> Nathan wrote:
>> Hi All,
>> Some good news, Gavin Carothers (cc'd) has successfully implemented the RDF API in python:
>>  https://github.com/norcalrdf/pymantic/blob/master/pymantic/primitives.py
>> Good news, since they managed to do it straight from the doc without needing support, and with only minor (imo) feedback.
>> To quickly outline the feedback:
>> 1- Expand on the difference between Graph.import and Graph.merge
>> 2- Note about encoding of the values in the API, convert to UTF-8 or what? particularly around handling N-Triples and the like.
>> 3- They ended up needing to implement a Graph.match function, in addition to Graph.filter, the primary reason for this being that the filter function accepts a closure, meaning that the details of the filter are not visible to the Graph implementation, therefore the execution of the filter cannot be optimized, which can be an issue with large graphs. Thus the Graph.match method they implemented accepted a simple "partial triple" to match against, for instance one with only the subject and predicate set, in their library this meant a difference of 50ms for match rather than 50s for filter.
>> 4- DataParser.parse method requires a callback. Whilst this is needed for async operation, it isn't for sync scripts, thus should be optional / nullable.
>> 5- Some general notes that reminded me we were going to drop the DataSerializer interface, and need to asap.
>> 6- They intentionally avoided the GraphLiteral interface, "as using them would mean making the data un SPARQLable?" - which I must concead, has almost twisted my arm to say that the GraphLiteral interface (well renamed version of it) should be made optional or defined as an extension to the core interfaces.
>> 7- a reminder that Language tags can be more than just 2-chars, and we need to handle that (will send a note to the group as it affects RDFa Core 1.1 IIRC).
>> and here's an extract of the tail end of the conversation:
>> [[
>> Gavin Carothers: Also, the RDF API isn't the API we expose to users
>> Nathan: awesome!
>> Gavin Carothers: the final API looks like: https://github.com/norcalrdf/pymantic/blob/master/pymantic/vocab/skos.py
>> Nathan: that's the whole goal of it, well maybe expose to advanced users and extensions - idea was to make something that libs could implement in order to swap/mix/match reusable modules or interface implementations
>> Gavin Carothers: ::nods::
>> Gavin Carothers: that's how we treated it
>> ]]
>> Best,
>> Nathan
> 
> 


----
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
Received on Friday, 22 April 2011 08:17:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:51 UTC