Re: Latest changes introducing the RDF API

On Apr 18, 2011, at 12:18 , Nathan wrote:

> Ivan Herman wrote:
>> This is not a detailed review of the API document, just reaction based on a cursory look.
>> - I am opposed to include a Graph Literal interface. Unless the RDF WG decides to allow graph literals, we should not introduce something in the RDF API that clearly goes beyond RDF. Extensions may do it, the core RDF API should not...
> 
> Does this also apply to the other features that go beyond RDF, such as support for blank node predicates and literal subjects?
> 

I know you will hate me for this, but my answer is yes...


>> - This refers back to the issue I raised the other day. We have here a comprehensive API for RDF heads. This is needed, and is good to have.
> 
> Fully agree, and personally that's always been my core aim with the API, create a stable foundation on which libraries and tools can be built (to complement each other and integrate easily), and from those either a cool jquery-for-rdf type library, or a another level of API which caters for common end user functionality, will be sure to arise. Remembering of course that different people have different tastes, and require different levels of abstraction and information hiding to be the most productive.
> 
>> But a Javascript developer will run away screaming if he/she would like to use RDF data on the Web for a simple application.
> 
> I fully agree here too, however I'm unsure if we should even attempt to create such a thing, and if we do, I feel it would be wise to get the stable foundation going with the RDF API, implement in libraries, start using on a daily basis, then see what emerges from daily usage - if we took this write code and standardize the common functionality path I wouldn't mind at all, but I'm very wary about just trying to come up with an end user API and calling it a standard. Additionally, I worry that it would either stifle innovation if done correctly, or simply get ignored if done wrong, both of which don't appear to be beneficial for the developer community.
> 
>> What the RDFa API found as a beautiful balance and provide a high level interface for those who do not really care about RDF, is missing here.
> 
> I agree it's missing, as above, but unsure whether it should even be an API, or is beneficial doing, to me it seems better results would come from getting core functionality out there and available for RDF heads and advanced developers, then they'll create some awesome libraries for end users on top of it.

But... We already have, in RDFa API:

getSubjects, getProperties, getValues,
getProjection, getProjections,
the Projection interface
setMapping

None of these are RDFa specific, in fact, except for the fact that in the RDFa document they are part of the document.data. This collection of interfaces and methods form, in fact, a high level API to RDF data parsed from some source.

What I am proposing is to have a layer on top of the RDF API, possibly in a separate document, that contains only those interfaces. What I would hope for is that many of the Javascript programmers will be happy with that layer. Of course, just as in the RDFa API, there would be a 'hook' to get to the low level RDF API, but that is only for geeks...

Ivan



> 
>> More specifically, we should have somewhere (in another document, perhaps) the projection interface and the necessary functions around it as a separate layer that could be on top of the RDF API but is not bound to RDFa. It should be possible to use such an interface while the data is parsed from a turtle file on the Web.
> 
> I certainly wouldn't mind spending some time working on resource/subject/object oriented APIs here, like the Projections - I'm sure a few of us have already had a stab at this in our own libraries (my own last attempt was js3) - again though, I strongly feel that we'd need to back it up with code and standardize between at least 3 working libraries with slightly different approaches (existing or to be created soon), and do it as a different document, focussed at end non-rdf developers rather than RDF heads.
> 
>> I do believe we have all this, it is a matter of editing and make it more explicit...
> 
> Hmm, I believe we can see it there somewhere, but don't have it yet, could probably get there though with some good coding, experimenting, and real world daily use of that code.
> 
> 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