W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > April 2011

Re: Latest changes introducing the RDF API

From: Nathan <nathan@webr3.org>
Date: Mon, 18 Apr 2011 11:18:56 +0100
Message-ID: <4DAC1010.3080609@webr3.org>
To: Ivan Herman <ivan@w3.org>
CC: benjamin.adrian@dfki.de, Manu Sporny <msporny@digitalbazaar.com>, RDFa WG <public-rdfa-wg@w3.org>
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?

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

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

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


Received on Monday, 18 April 2011 10:19:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:51 UTC