Re: API musings....

Hi Ivan,

On Thu, Apr 14, 2011 at 09:33, Ivan Herman <ivan@w3.org> 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.

Opening remark: I could not be present at the F2F, hence I have no
background with regards to the discussions that were going on, so bare
with me if I write about things that got already discussed.

> 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).

Agreed and makes sense.

> 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)

At a first glance my immediate reaction was to wonder why 1 and 2 and
3, and not (1&&2) and 3, but the more I think about it, the more it
makes sense. 1 could be something like the private APIs of iOS (hope
the metaphor makes sense), 2 the layer more advanced JavaScript
developers (or whatever programming language) will reach down to, and
3 the level normal Web (JavaScript) developers will need. This still
leaves room for uniting 1 and 2 specification-wise, but the separation
might help us API-architectural-wise.

> 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.

What I tried to reproduce before, but in better (your) words :-)

> 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...

This is most probably where I would have needed the background of the
discussions yesterday. I can /very well/ see a need for mash-up
developers pulling in data from, say, the DBpedia API in JSON,
(optionally) parsing it with the API (or using the JSON data directly)
and working with it. My intern and me have just created a mash-up
based on Freebase data that then gets data from MusicBrainz and
finally from Last.fm using MusicBrainz IDs. Am I getting your points
wrong? Did I miss an elementar tidbit from the discussions? Thanks for
clarifying.

Best,
Tom

-- 
Thomas Steiner, Research Scientist, Google Inc.
http://blog.tomayac.com, http://twitter.com/tomayac

Received on Thursday, 14 April 2011 09:10:17 UTC