W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > October 2010

Re: RDFa API - adding Namespace

From: Nathan <nathan@webr3.org>
Date: Tue, 12 Oct 2010 11:20:44 +0100
Message-ID: <4CB4367C.7030108@webr3.org>
To: Tim Berners-Lee <timbl@w3.org>
CC: Manu Sporny <msporny@digitalbazaar.com>, RDFA Working Group <public-rdfa-wg@w3.org>
Tim Berners-Lee wrote:
> On 2010-10 -11, at 20:23, Manu Sporny wrote:
>>>> When we did the second pass of the design phase on the RDFa API, we
>>>> attempted to make sure that it was a simple as possible for those not
>>>> familiar with RDF.
> 
> That was what happened in the RDF/XML design and it was to a certain
> extent a disaster.   It is much more important to make it very 
> clean for this who do understand RDF, and then people will actually
> learn RDF that much faster.  RDF is very simple, in fact.

I wanted to pick up on this under separate cover, because personally, I 
wish somebody had said 'RDF is very simple, in fact' to me when I first 
started getting heavily involved in sem web related work.

The fact is that RDF was presented to me (generally, by the community 
and via Linked-Data) as being a complex beast full of nuances and 
complexities that required a thorough understanding of not just RDF, but 
all it's serializations, OWL, web architecture and a host of other 
technologies.

Due to this I approached learning RDF from a perspective of expecting 
something complex, and thus it was - I literally 'lost' several thousand 
hours which had real life repercussions resulting in lost contracts, 
delivery delays and knock-on effects in my personal life which I still 
feel to this day. In some ways it's a sad story, but in other ways I'm 
very glad, because I'm here and surrounded by some great minds in an 
interesting fast moving sector, and glad of all the heavy studying I did 
along the way.

The end result for me though, is that my first sentence to anybody when 
speaking about RDF is "it's really very simple" followed by the simplest 
explanation of a triple that I can manage - usually taking the approach 
of saying that you simply take an object, stick the id on the left, swap 
id's for web scale guid's (URIs), mount the results on the web and then 
do the same for class blueprints (schemas), introducing the benefits of 
each as I go - I find this works quite well with programmers and usually 
they grok it in circa 30 minutes.

Bringing this back to the current context, I do feel the 
RDFa-document-specific part of the API is simple, I also feel the RDF 
API we're working on is simple for implementers and provides a core 
subset of functionality needed by javascript developers. What we're 
doing definitely isn't "a simple, usable RDF API for javascript 
developers" though, and as discussed this would need to be handled 
separately.

Which leads me to think, perhaps we do need to split the RDFa API in to 
two documents, one with the RDF & Data Interfaces (the core RDF API) and 
another with the RDFa document-based API - in order to keep it simple 
and present it as such.

Best,

Nathan
Received on Tuesday, 12 October 2010 10:21:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:21 UTC