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

Re: primary use case of the RDF API

From: Nathan <nathan@webr3.org>
Date: Thu, 21 Apr 2011 23:02:34 +0100
Message-ID: <4DB0A97A.5090001@webr3.org>
To: benjamin.adrian@dfki.de
CC: public-rdfa-wg@w3.org
Benjamin Adrian wrote:
> 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

I guess my question to you then would be, if it's not implemented by 
third parties, just where is it implemented / provided, as defacto with 
an OS or?

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

I'm tempted to agree there, to be brutally honest, I'd love to get the 
core interfaces that are there already nailed properly with a couple of 
implementations done ASAP /then/ spend the rest of the time focussed on 
creating a nice set of convenience methods, or perhaps even a 
subject/resource/object oriented view of the API.

Quite sure that's spilling out in to my every day mails as well, when 
often what I mean is can we please get the bare minimum set of 
interfaces done that enable interoperability first, then look at adding 
niceties once we're actually working with implementations of the API, my 
thinking being that these convenience methods should just drop right out 
of the libraries as we use them, and when they do we can balance and 
address whether it would be best to add them to the existing interfaces, 
or whether to create a second layer of abstraction / information hiding.



>> 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 22:03:39 UTC

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