WebID vs. JSON (Was: Re: Think before you write Semantic Web crawlers)

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