W3C home > Mailing lists > Public > public-lod@w3.org > June 2011

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

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 22 Jun 2011 16:00:49 +0100
Message-ID: <4E0203A1.1080107@openlinksw.com>
To: public-lod@w3.org
On 6/22/11 3:41 PM, William Waites wrote:
> 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..
Huh?

WebID and SPARQL is about making an Endpoint with ACLs. ACL membership 
is driven by WebID for people, organizations, or groups (of either).

Don't really want to get into a Virtuoso vs 4-Store argument, but do 
explain to me how the convention you espouse enables me confine access 
to a SPARQL endpoint for:

A person identified by URI based Name (WebID) that a member of a 
foaf:Group (which also has its own WebID).

How does this approach leave ACL membership management to designated 
members of the foaf:Group?

Again, don't wanna do a 4-Store vs Virtuoso, but I really don't get your 
point re. WebID and the fidelity it brings to data access in general. 
Also note, SPARQL endpoints are but one type of data access address. 
WebID protects access to data accessible via Addresses by implicitly 
understanding the difference between a generic Name and a Name 
specifically used a Data Source Address or Location.



-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
Received on Wednesday, 22 June 2011 15:01:15 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:29:54 UTC