Re: Layers of RDF API

Nathan,

What you say does make sense.

Putting on my absolutely-boring-administrative-non-technical hat on: as you say, _this_ WG is chartered to do, essentially, Layer 1 + RDFa extensions. And I believe most of what is in the current RDFa API document is like that. If the WG feels it has time to work on Layer 2 and publish Layers 1&2 as a separate Note, that would be a huge service to the community. At the moment I do not think we should spend our time on Layers 3 & 4: not that those are not important (and interesting:-) but because I do not believe it is achievable. 

Let us not forget that we should have, ideally, a last call on the API out by the end of the year and I begin to be seriously afraid of running out of that. Of course, a charter extension is always possible, but there is, currently, a real uptake of RDFa out there and it would be a real problem if the WG could not properly ride that wave with an updated version of the documents.

Just a thought: a charter extension might includ decoupling the RDFa Core+XHTML and the API development in time. I think that we could get the RDFa Core earlier and call it done. It is a bit complicated, at this moment, to do both at the same time, and the group is running a bit thin...

Ivan 


On Oct 12, 2010, at 23:40 , Nathan wrote:

> Hi Mark, Tim, Ivan, All,
> 
> It appears to me that there are different layers of RDF API, each ever more simplified and "Javascripty", and that we are having many conversations which mix up functionality from the different layers, leading to much discussion, and dare I say disagreement.
> 
> Perhaps it would help discussion if we define a few clear layers of API - here's a quick stab at it:
> 
> Layer 1
> =========================
> A fully typed API providing the bare minimum which implementers require to implement any RDF library, this includes:
> - RDF Interfaces (BlankNode, PlainLiteral etc)
> - An Interface which represents a set of triples with methods to add / filter / iterate / combine
> - A core-functionality interface, providing create methods for RDF Interfaces, CURIE resolution, Type Conversion
> - Parser and Serializer interfaces
> 
> This can be summed up with the following method signatures and usage:
> 
>  RDFTriple createTriple(RDFResource subject, IRI property, RDFNode object);
>  boolean add( RDFTriple triple );
> 
>  var triple = y.createTriple( new IRI('http://..'), resolveCurie('foaf:me'), new PlainLiteral('nathan') );
>  x.add( triple );
> 
> In some ways this can be thought of as the N-Triples of RDF APIs.
> 
> 
> Layer 2
> =========================
> A simpler API for RDF-familiar end users which is more Javascript friendly, this includes
> - dynamically typed methods which are aware of native types (Date, Boolean, String etc)
> - special interfaces for working with Lists and BlankNodes
> - tabulator IndexedFormula style functionality
> 
> This can be summed up with the following method signature and usage:
> 
>  boolean add(any subject, any property, any object);
> 
>  var t = y.create( c(':me') , dc('created') , new Date('2010-09-02') );
>  x.add( t );
>  x.add( you , foaf.name , "Bob" );
> 
> In some ways this can be thought of as the Turtle of RDF APIs.
> 
> 
> Layer 3
> =========================
> An API which can be seen as as-close-to pure Javascript and RDF integration as possible, this includes:
> - working with RDF like JSON objects
> - transparent linked data and HTTP integration
> - built in reasoning and inference
> 
> This can be summed up with code similar to the following:
> 
>  var me = get('http://webr3.org/nathan#me);
>  me.name = "Nathan";
>  me.vehicle.wheels = 4;
>  assert(me.vehicle.type === "Car");
> 
> In some ways this can be thought of as our mid-term goal.
> 
> 
> Layer 4
> =======================
> Well, layer 4 is probably an entirely different language which features first class support for RDF, linked-data, reasoning, rules, inference and so forth - quite possibly a language which compiles to Javascript. Something like N3+CWM+Javascript+Stuff-we-don't-know-yet combined.
> 
> 
> In addition to the above, we have extensions such as RDFa specific functionality for working with documents and RDF together (considering the presentation tier) and query extensions like SPARQL support.
> 
> 
> It appears to me that often I am talking in the context of Layer 1 with an eye on Layer 2, that Tim is often speaking of Layer 2 functionality with an eye for Layer 3, and that Mark is coming from the other side thinking primarily of Layer 3 and working backwards to layers 2 and 1. Regardless this perhaps doesn't matter how we are approaching things.
> 
> Can we agree that we do have several distinct layers, roughly as described, and that we need to define and implement each as and when we can - and then hopefully tag our notes, discussions, proposals with which layer we're talking about so clarity is assured from the off.
> 
> It is my current understanding that we (this WG) are to define Layer 1 and the RDFa-document extensions.
> 
> Also, I've got a vague inclination that because of the simplicity of RDFa and because it's where JS+RDF+DOM+HTML all collide, that we all feel an urge to be defining the Level 3 API, but we don't have the level 2 and 1 APIs required so are having to start by defining Level 1 instead - and thus functionality we are all itching for from levels 2&3 is creeping in to the discussions when perhaps it's outside of scope all together for now.
> 
> Does that all make sense?
> 
> 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