Re: RDFa API comments from TimBL

Sorry, forgot to mention one thing, the idea was to essentially make the 
API switchable and easy to use for anybody by (1) making 
IndexedDataStore extend DataStore (thus it can be used anywhere 
DataStore can) and (2) exposing a single toIndexedStore() method on the 
DataStore interface - this way nothing changes, or is polluted so to 
speak, rather it's all hidden just a method away for anybody who 
wants/needs it.

Nathan wrote:
> 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:44:50 UTC