Re: RDFa API comments from TimBL

Nathan describes a world that I very much hope comes to be.

As I've mentioned before, I work with xhtml+rdfa textbases that rely
on persistent non-information resource URIs and datatypes in the
representation of scholarly works and archival data. The model that I
can almost begin to implement but am definitely planning for relies on
integration between RDF processing approaches and DOM/XPath based
processing model.

 "Find all the foaf:Persons" lets me identify snippets of xml that are
then amenable to DOM- or XPath-based processing. It's key for me to be
able to identify the source element that produced any subject,
predicate or object.

 So this is a fairly abstract comment. Perhaps the only way it
complements Nathan's input is here:

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

I wouldn't want "easy to work with" to be seen as a concession to
non-RDF folk. Rather, the RDFa API is the point at which the
DOM-centric world and the RDF world are combined as equal players in a
very versatile and powerful processing model for xml-serialized data
and prose.

 -Sebastian.

On Tue, Oct 5, 2010 at 8:25 AM, Nathan <nathan@webr3.org> 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 13:52:43 UTC