- From: Tim Berners-Lee <timbl@w3.org>
- Date: Mon, 2 Dec 2013 11:23:54 +0000
- To: Richard Light <richard@light.demon.co.uk>
- Cc: public-lod community <public-lod@w3.org>
- Message-Id: <6CCFADA2-8644-405E-8E5C-C4230A90C239@w3.org>
I think my conclusion from the DOM experience was that actually people wanted jQuery -- something optimized for the language. My own RDF APIs have been optimized for js and python respectively, though they share style and many calls. See undocumented rdflib.js https://github.com/linkeddata/rdflib.js/ I can still think of further optimizations to make writing code even smoother. Timbl On 2013-12 -02, at 11:00, Richard Light wrote: > Hi, > > I'm sure this has been discussed many times and/or ages ago, but I am struck by the absence of a DOM-like W3C framework for RDF. By this, I mean "an application programming interface (API) for [RDF graphs]", which will be "a standard programming interface that can be used in a wide variety of environments and applications. The [RDF] DOM is designed to be used with any programming language". (Quotes taken from [1]) > > A quick search turns up a number of PHP-based libraries, and the odd one for javascript, Delphi, Python and Ruby, but as far as I can see there is little, or no, commonality of approach or functionality amongst these offerings. This means that a programmer (a) has to decide which of these widely varying approaches to adopt, (b) only gets whatever documentation each chooses to provide and (c) is faced with a complete rewrite, should they decide to switch RDF platform. > > Might this situation be a significant factor in the slow take-up of RDF by mainstream developers? > > Richard > > [1] http://www.w3.org/TR/REC-DOM-Level-1/introduction.html > > -- > Richard Light
Received on Monday, 2 December 2013 11:24:06 UTC