Re: primary use case of the RDF API

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
RDFa API.

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

Ben

> 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!"
http://squirrelmail.org/

Received on Thursday, 21 April 2011 21:42:45 UTC