- From: Dave Reynolds <dave@epimorphics.com>
- Date: Wed, 12 Jan 2011 12:02: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 <andy@epimorphics.com>
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 that.] Dave [Added Andy to the CC list.] -- 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:13:53 UTC