Re: API musings....

On Apr 14, 2011, at 12:52 , Nathan wrote:

> Ivan Herman wrote:
>> Something that began to crystallize to me yesterday during and after the RDF F2F... These are just vague ideas that I decided to jot down for further discussion.
>> Our current setup and division is that we have two layers: the RDFa API and the RDF API. Logically, the former sits on the top of the latter (forget about the fact that we may want to hide this to some user community, that is an editorial detail).
>> However... I wonder whether it may not be better, again mostly editorially, to have a three tier division instead of two. Yes, I know, but bear with me... Here is what I thought:
>> 1. Lowest level triple store API. Things like interfaces to triples, get them directly, store them, etc.
>> 2. Higher level RDF API: getSubjects(optional property, optional value) et al, getProperties(optional subject) et al, Projections, set mapping, query
>> 3. RDFa API: document.getElementsByType(type) etc, ie, all DOM related stuffs
>> (obviously, Level #3 has access to Level #2 and that one to Level #1, just as today)
>> Level #1 is for RDF heads. They know what they want, they want to get access to the bare bones. Level #2 is interesting. What it does is to separate from the current RDFa API what is not RDFa specific, but keeps the simplicity level that is attractive for Javascript, non-RDF Web Application Developers. Level #3 is, obviously, the RDFa specific additions.
>> Why? The discussion yesterday at the F2F made one thing clear(er) to me: Javascript developers will not want to get access to, say, DBPedia data as it stands today. Regardless on whether that data is in Turtle or even in JSON. However, if what they see is level #2, so to say, then that might work out well...
>> As I said, just musings...
> 
> Hi Ivan,
> 
> I thought we'd already made this distinction and were focussed on making a level 1 api for advanced users and library developers to ensure interoperability and a base foundation on which to work, thus enabling reuse of library components and increasing the ease at which cool "jQuery for RDF" style libraries could be built, conceding that creating the perfect end user library may be somewhat of a tall order, and that even if we managed it wouldn't be to everybodies tastes (as in, there would still be other libraries).
> 
> Do you think we should now try and do an end user library query-for-RDF like API as well?

We may have to think about this. But... I would think that, conceptually (I do not talk editorially for now) we actually have that. Much of what is now in the RDFa API is, conceptually, independent of RDFa but nevertheless gives a level of abstraction that could/would be fine for a lambda Javascript programmer who would deal with, say, RDF data encoded in a low-level JSON encoded RDF (you probably see where I am coming from...)

Ivan

> 
> ps: getSubjects/getProperties etc was planned to be added to the Graph interface in the RDF API after discussions a couple of weeks ago.
> 
> 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