Re: API musings....

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?

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

Received on Thursday, 14 April 2011 10:53:03 UTC