W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > April 2011

Re: primary use case of the RDF API

From: Benjamin Adrian <benjamin.adrian@dfki.de>
Date: Thu, 21 Apr 2011 23:42:20 +0200 (CEST)
Message-ID: <48293.>
To: nathan@webr3.org
Cc: benjamin.adrian@dfki.de, public-rdfa-wg@w3.org
Hi Nathan,

In general I agree with you and of course your arguments. I just want the
RDF API be kind of applicable even without the use of third-party
libraries. We also had this application focus in mind when designing the

You refer to the DOM API. It is a good comparison and I like our API be as
clear, focussed and concise. But I have also in mind that I never use the
DOM API as such, because it is not developing-friendly. For rapid
developments I prefer using the simplified wrappers JDOM in Java, TagSoup
in Python, and JQuery in Javascript. I would like the RDF API be
developing-friendly without creating a one-API fits all needs monster.

And this compromise can be achieved by adding just a handful of convenient


> Benjamin Adrian wrote:
>> Nathan said in the telcon about the RDF API use cases:
>>> primary use cases were the same interfaces being able to be used by
>>> reasoners and sparql implementations and for n3 compat (because you
>>> know,
>>> one lib will handle all this)
> Just to clarify, my comment was referring to the primary use cases for
> generalized triples in the API - to allow implementations of the
> interfaces to be used generally for RDF and semantic web purposes.
> You may also be interested in this exchange around generalized triples
> with Andy Seaborne:
>    http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0093.html
> And an interesting one from Ivan where we both conceded we were unsure
> what to do for the best with regards generalized triples:
>    http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0081.html
>> I disagree. In my opinion the primary use case of the RDF API is:
>> Allow web developers to consume and produce RDF in application by
>> writing
>> a minimal amount of code.
> However, on this topic which is a bit different, the goals of the RDF
> API; from some earlier mails regarding the scope of the RDF API:
> [[
> The RDF API defines a set of standardized interfaces for working with
> RDF data in a programming environment.
> These interfaces are, and have to be, designed to enable:
>    - interoperability between library and extension developers
>    - modularity (separate interchangeable components)
>    - standardized interfaces giving access to core functionality
> If we are to be successful in the definition of this API, then we need
> to ensure the nice jQuery-for-rdf-like library works with foo-reasoner,
> bar-store and baz-query, that users can mix and match components to get
> their ideal setup; that innovation in libraries and specialization in
> components is encouraged, rather than stifled.
> ]] http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0091.html
> One way of looking at this is to consider whether people commonly use
> jQuery or the DOM API? Library writers use the DOM API, general
> developers use jQuery.
> Now the interesting bit, do all developers only use jQuery? No, many use
> other libraries like Dojo, MooTools, Prototype, YUI, ExtJS etc, as a
> matter of preference, or simply picking the right tool for the job. Do
> all those libraries use the DOM API though? Yes they do.
> We need the equivalent of the DOM API first. And we cannot possibly
> define a secondary level API which everybody will be happy with, that's
> the job of the library implementers IMHO.
> Disagree?
> Best,
> Nathan

This email was sent using SquirrelMail.
   "Webmail for nuts!"
Received on Thursday, 21 April 2011 21:42:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:51 UTC