- From: William Waites <ww@styx.org>
- Date: Wed, 22 Jun 2011 16:41:22 +0200
- To: public-lod@w3.org
What does WebID have to do with JSON? They're somehow representative of two competing trends. The RDF/JSON, JSON-LD, etc. work is supposed to be about making it easier to work with RDF for your average programmer, to remove the need for complex parsers, etc. and generally to lower the barriers. The WebID arrangement is about raising barriers. Not intended to be the same kind of barriers, certainly the intent isn't to make programmer's lives more difficult, rather to provide a good way to do distributed authentication without falling into the traps of PKI and such. While I like WebID, and I think it is very elegant, the fact is that I can use just about any HTTP client to retrieve a document whereas to get rdf processing clients, agents, whatever, to do it will require quite a lot of work [1]. This is one reason why, for example, 4store's arrangement of /sparql/ for read operations and /data/ and /update/ for write operations is *so* much easier to work with than Virtuoso's OAuth and WebID arrangement - I can just restrict access using all of the normal tools like apache, nginx, squid, etc.. So in the end we have some work being done to address the perception that RDF is difficult to work with and on the other hand a suggestion of widespread putting in place of authentication infrastructure which, whilst obviously filling a need, stands to make working with the data behind it more difficult. How do we balance these two tendencies? [1] examples of non-WebID aware clients: rapper / rasqal, python rdflib, curl, the javascript engine in my web browser that doesn't properly support client certificates, etc. -- William Waites <mailto:ww@styx.org> http://river.styx.org/ww/ <sip:ww@styx.org> F4B3 39BF E775 CF42 0BAB 3DF0 BE40 A6DF B06F FD45
Received on Wednesday, 22 June 2011 14:41:56 UTC