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
