W3C home > Mailing lists > Public > www-archive@w3.org > January 2011

Re: Non-Javascript RDF API-s?

From: Dave Reynolds <dave@epimorphics.com>
Date: Wed, 12 Jan 2011 13:19:21 +0000
To: Ivan Herman <ivan@w3.org>
Cc: Jeremy Carroll <jeremy@topquadrant.com>, Dave Beckett <dave@dajobe.org>, Jeroen Wester <jeroen.wester@aduna-software.com>, Jans Aasman <ja@franz.com>, Lee Feigenbaum <lee@thefigtrees.net>, renau.delbru@deri.org, Chris Bizer <chris@bizer.de>, Gregg Kellogg <gregg@kellogg-assoc.com>, Daniel Krech <eikeon@eikeon.com>, Jan Wielemaker <J.Wielemaker@uva.nl>, Mark Nottingham <mnot@yahoo-inc.com>, Ora Lassila <ora.lassila@nokia.com>, Damian Steer <pldms@mac.com>, Manu Sporny <msporny@digitalbazaar.com>, W3C Public Archives <www-archive@w3.org>, "andy.seaborne" <andy.seaborne@epimorphics.com>
Message-ID: <1294838361.1622.105.camel@dave-desktop>
[Resend, adding the right email address for Andy this time!]

Hi Ivan,

My personal opinion, not necessarily representative of either Jena
committers or Epimorphics, is that this effort is better kept focused
purely on Java[/ECMA]Script rather than generalized to cross languages.

The current WD shows how language style issues affect an API (e.g. the
introduction of PropertyGroups and the use of structures as filter
specifications). The Javascript API is more likely to be accepted if it
continues to be specifically targeted at what Javascript developers
would expect and not compromised by being suitable for all other
programming languages.

I agree that the migration cost of shifting developers to a new API
would be huge, just announcing an intent to develop a W3C cross-language
RDF API would risk send out a destabilizing message to the existing
developer community. 

However, there is also the question of whether the goal is a Javascript
RDF API or a Javascript-in-a-browser RDF API. The current RDFa draft is
clearly intended only for in-browser use whereas Javascript is also used
server side. A general purpose Javascript RDF would require making the
DOM Node links optional, decoupling the literal encoding from the
document encoding, support for multiple graphs and SPARQL Datasets etc.

It may also be helpful to review existing APIs to see if there are
capabilities in them that should be in a general purpose Javascript RDF
API. For example, unless I'm missing something (which is always
possible) the WD just supports forward link traversal whereas finding
all incoming links to a node is a commonly used feature of other APIs.
[Though I see, via Andy, that the Editor's draft has changed rather a
lot from the publish WD and may already have addressed issues like

Epimorphics Ltd                        www.epimorphics.com
Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT
Tel: 01275 399069                     Mobile: 07906 628814

Epimorphics Ltd. is a limited company registered in England (number 7016688)
Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT, UK

On Tue, 2011-01-11 at 13:05 +0100, Ivan Herman wrote: 
> Dear all,
> first of all, a very happy new year to you all!
> The reason of this mail is some sort of an informal poll. I am not sure how closely you followed this, but there has been quite some discussion in the past few months on the necessity (or not...) of a standard RDF API for Web Application developers. In practice this means a standard API for {Java|ECMA}Script, with a particular attention to the needs and programming style of that community. In parallel to this discussion the RDFa Working Group[1] had been working on an RDFa API for a while and, in the course of this work, it became clear that it would be properly done only if a proper RDF API for Javascript is also defined. So the current thinking at W3C is that we would slightly recharter the current RDFa Working Group to publish that RDF API part as a Recommendation, too.
> However... that obviously raises the question of non-Javascript API-s to RDF. The reason I contact you all is because you have all been involved in some way or other with API definition and/or development for other languages, let that be C, Java, Python, PHP, or Lisp. It is not clear at this moment whether such an RDF API work, as envisaged in the RDFa Working Group, should take into account other programming languages actively from the start (ie, define something much more generic) or whether it should really concentrate on Javascript only. There are a number of issues here, including non-technical ones (the effort it would take both for the developer and the application community to migrate to a new API is the obvious and huge issue). I for myself believe that the non-technical issues are the really tough ones; my strictly _personal_ feeling at this point is that the effort in the Working group should concentrate on the needs of Javascript/Web Application only, and let other programming language communities decide whether they want to take that work into account or not. But maybe my judgement on the community's need is wrong. That is why it would be very helpful for us to get some feedback from you...
> Sincerely
> Ivan
> P.S. I may have missed somebody in this list. Feel free to add, in your reply, anybody else whom you think should be consulted...
> [1] http://www.w3.org/2010/02/rdfa/
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Wednesday, 12 January 2011 13:20:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:33:54 UTC