Re: RDFa API comments from TimBL

Hi Mark,

I also agree with you, and personally am keen to see all audiences 
catered for suitably with the choice of several different ways of doing 
things, thus far I can see 4 specific types of user and sets of 
functionality needed:

Basic DOM centric API
  -> general API for non-rdf, HTML/DOM/JS developers
  -> document interface exposing getElement* and getItem* methods
  -> easy to work with (X)HTML+RDFa documents, such as highlighting all 
People mentioned on a page.

Universal Low-level RDF(a) API
  -> defining the very core must haves for any RDF(a) implementation
  -> RDF concepts IDL interfaces (BlankNode, PlainLiteral etc)
  -> Simple DataStore which is a sequence of RDFTriples adding familiar 
forEach, every, some, get, add and iteration methods
  -> DataParser and DataSerializer interfaces, suited for both normal 
and streaming parsers.
  -> easy to implement in any language
  -> very simple to do operations such as parsing an RDFa document, 
filtering to get a set of all triples about x-subject, then serializing 
as turtle

Query API
  -> catering for the broad spectrum RDF(a) community
  -> defining the core interface(s) needed to implement say a SPARQL 
query engine

Indexed RDF(a) API
  -> catering for linked data / sem web application developers
  -> provides easy programmatic access to working with RDF in a familiar 
indexed manner (like Tabulator, ARC etc s[p][o] access)
  -> defines all core functionality needed to work with RDF in a 
sensible, non-verbose manner.

Basically, a set of methods on document which my non-rdf developer 
friends can use easily, a core rdf which anybody making rdf tooling can 
implement, a way to run SPARQL queries for, well everybody linked data / 
sem web related, and finally, a way to work with RDF when your doing 
heavy code+rdf application development.

So far implementing the API, I'm very happy with the "Universal 
Low-level RDF(a) API" bar a couple of small tweaks, it's really good - 
the Basic API I'm sure we'll have sorted without a problem, the Query 
side of things will be an easy hit (specification wise) and the only 
thing frustratingly lacking was a decent way to work with RDF in 
javascript, as I've found myself and I'm sure Tom (Thomas Steiner) will 
agree.

The approach I'd hoped to take is to define and implement an additional 
IndexedDataStore (extending DataStore) that exposes all the 
_functionality_ of tabulators IndexedFormula. Keeping in mind the naming 
conventions which are common in WebIDL, ECMAScript and the rest of the 
RDFa API, together with the principal of "always as simple as you can".

To prove the implementation, I plan to use it heavily myself, then drop 
it in to tabulator (wrapped in a backwards compatible proxy api) and 
ensure it works, then implement a SPARQL query engine behind the 
DataQuery interface which uses the functionality exposed. I'll also 
release the full js implementation with all parsers/serializers etc 
under cc-zero for anybody who wants to use it, client or server side.

Finally, to give some background, in part my reasons for all of this are 
a bit selfish, I *need* a full RDF library in javascript which can be 
seen as a mix between ARC2, Redland/Raptor/Rasqal and Tabulators 
rdflib.js, all wrapped up and standardized, a library which I can use in 
all my capacities and which I can comfortably pass on to both my fellow 
HTML5y web developers and to the heaviest of sem web users such as Tim 
or yourself.

And likewise, everything is up for discussion and every drop of input 
from all quarters is greatly appreciated.

Best,

Nathan

Mark Birbeck wrote:
> Hi Nathan,
> 
> This is just the kind of feedback we'd been hoping for...thanks!
> 
> However, I don't agree that the Tabulator API is better then the RDFa
> API, or (most importantly) that it has been ignored.
> 
> When I first started working on a JavaScript API some years ago --
> much of that work has fed into the RDFa API spec -- I looked at
> Tabulator and every other RDF-related API I could find, and tried to
> take the best from all of them. The RDFa API contains many
> Tabulator-inspired features, from big architectural things like the
> distinction between parsers, stores and query objects, through to
> small details such as the 'add' method. (select() even used to be
> called query().)
> 
> However, as with anything, designs move on, particularly if the goals
> of a project are different. And one of the key design goals in the
> later versions of the RDFa API was that it should be 'more JavaScript'
> and 'less RDF'.
> 
> That means that wherever possible we would avoid sprinkling the API
> with the need to create objects such as literals or URIs just so that
> they can be passed in to functions, and we also avoid as much as
> possible expressing everything in terms of s/p/o.
> 
> I'm afraid that in my view the Tabulator API goes in the opposite
> direction; for example, the programming namespace is littered with
> objects that do nothing other than manipulate strings (foaf(x), dc(x),
> etc.), which is not good from a JavaScript programming perspective,
> and in my mind leads to confusion.
> 
> The 'more JavaScript' and 'less RDF' approach is based on the belief
> that the audience for this API goes way beyond the RDF community,
> which also means that we should leverage people's familiarity with
> existing DOM practices. This is why methods are named things like
> 'getElementsByType' and 'getItemBySubject', leveraging familiarity
> with method names such as 'getElementsById'.
> 
> Again, I feel that Tabulator goes in the opposite direction with its
> use of method names like 'sym' and 'statementsMatching'.
> 
> Having said all of that, the RDFa API is essentially in two parts, one
> of which covers lower-level RDF-related features and the other
> providing a higher-level interface for those less familiar with RDF.
> Since the lower-level functions are aimed primarily at the RDF
> community then it's certainly possible that we could take those in a
> more Tabulator-like direction, if that's what people want.
> 
> However, I personally wouldn't like to see the higher-level API taken
> in that direction, if nothing else because JavaScript programming has
> moved on enormously since Tabulator was first formulated.
> 
> Hopefully it goes without saying that everything is up for discussion
> on the list, and that the views I've expressed here are just one
> potential take on this topic.
> 
> Best regards,
> 
> Mark
> 
> --
> Mark Birbeck, webBackplane
> 
> mark.birbeck@webBackplane.com
> 
> http://webBackplane.com/mark-birbeck
> 
> webBackplane is a trading name of Backplane Ltd. (company number
> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
> London, EC2A 4RR)
> 
> 
> On Mon, Oct 4, 2010 at 10:29 PM, Nathan <nathan@webr3.org> wrote:
>> Hi All,
>>
>> I was speaking to Tim Berners-Lee earlier who asked me to pass on some
>> feedback, he is very keen to see the RDFa API (particularly the DataStore
>> interface) aligned with the IndexedFormula from Tabulator, to be specific "I
>> think there is a big mistake happening to not make the RDFa API look like
>> (tabulators) RDF API where it can" - he has also quickly hacked out some
>> examples in section 3.2 here to cover some of the use-cases:
>>
>>  http://www.w3.org/2010/rdf-api/RDF-API.html#using-the-basic-api
>>
>> Personally, I am also keen to see this happen, preferably implementing a
>> simple DataStore which can be wrapped in an IndexedDataStore - tabulators
>> library is time proven and many years of feedback and improvements have been
>> made, it would be a shame to loose that.
>>
>> Unless there are any objections, I'll start defining and implementing an
>> IndexedDataStore to match the functionality of the IndexedFormula from
>> tabulator, which is also in line with my post-implementation-feedback [1]
>> earlier this week.
>>
>> Best,
>>
>> Nathan
>>
>> [1] http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Sep/0149.html
>>
>>
> 
>

Received on Tuesday, 5 October 2010 12:34:07 UTC