Semantic Web APIMore food for thought, this is a transcript of a conversation between Giovanni Tummarello and Jeen Boekstra on June 28, 2005. He had anticipated that the project was difficult; this gives a bit more details. It also gives a bit of more details why we think it's still very useful (e.g. Supporting tools that make use of RDF not really the creation of general applications).
jeen0312 : ok, API standardization...
jeen0312 : I haven't actually read your precise proposal so I am more reacting to the general idea of such an effort.
giovannitummarello: there is just the general idea
jeen0312 : I see
jeen0312 : well, I've been involved in a few attempts to come with such an API before.
giovannitummarello: thre isnt any precise proposal.. except.. take all the API, list their functions, factor them together
giovannitummarello: look at what can be done, come out with a "solution"..
giovannitummarello: ok
jeen0312 : the problem there was almost always that if you go for a 'lowest common denominator' approach you end up with virtually nothing.
jeen0312 : ...and if you go with another approach you inevitable have to favor one tool over the other, because some things are easy to implement in Sesame and difficult in Jena or KAON or... and the other way around as well.
jeen0312 : the central thing that we almost always ran into was that at the end of the day a unifying API has no practical value, because it just gives you 'the worst of all worlds'.
giovannitummarello: i believe it has a precise use case: tools supporting rdf operations
giovannitummarello: let me make myself clearer..
giovannitummarello: of course if one wants to do a sw application from scratch.. then why not chose a tool say sasame or jena and stick with it.. use the advanced features etc.
giovannitummarello: but
giovannitummarello: i believe there will be a lot of tools that somehoe "support " or "need" or "act upon" rdf datasets
giovannitummarello: say our digital signature infrastructure
giovannitummarello: that you might want to use in your application..
giovannitummarello: in that case.. a generic api mgiht enable people to write "RDF based" "components".. How to word this better?
jeen0312 : I understand what you mean, and I fully agree that it would be great if we could come up with something like that.
jeen0312 : ...but...
jeen0312 : there are a number of major stumbling blocks. for example, consider inferencing. some tools support rdfs, some don't. some do it partially.
jeen0312 : if I have a generic api call that says 'give back all properties of resource p', does that include inferencing, or not? if it does, how much inferencing? if it does not, is it still useful?
giovannitummarello: carefully setting the project target at "supporting the creationg of generic RDF based utilities" rather than full featurured applicatioms might ease things. might allow some profile to be defined "no inferencing, rdf inferencing only" and that's it.
giovannitummarello: but of course..
giovannitummarello: this inferencing thing is unclear.. in general. we kind of "solved" we believe it by using a stack of databases
giovannitummarello: the bottom one is pure rdf.. no inferencing whatsoever.. then there is an rdfs one .. then further rules are on other DBs which lay on top
jeen0312 : also, it is very difficult to get any kind of performance out of such an API by simply 'layering' it on top of existing tool APIs. it needs buy-in from the tool developers (and ingraining into the actual tool) to succeed I think.
jeen0312 : ...but I sound like a petulant old man, sorry for that
giovannitummarello: no you dont
giovannitummarello: your points are clear and sound
giovannitummarello: they will not discourage our google sponsored man however 
something will be done!
giovannitummarello: at least to allow external utility such as our digital signature toolkit and the other rdf utilities to run SLOW but run on different systems and within applications that use diverse DBs..
jeen0312 : that is very true.
jeen0312 : btw he might want to take a look at work done in the EU SEKT project by OntoText, they defined a minimal ontology API there as well.