- From: Nathan <nathan@webr3.org>
- Date: Tue, 20 Apr 2010 15:52:26 +0100
- To: Linked Data community <public-lod@w3.org>, foaf-protocols <foaf-protocols@lists.foaf-project.org>
- CC: Michael Hausenblas <michael.hausenblas@deri.org>, Tim Berners-Lee <timbl@w3.org>, Joe Presbrey <presbrey@csail.mit.edu>, Story Henry <henry.story@bblfish.net>, Melvin Carvalho <melvincarvalho@gmail.com>
Hi All, I'd like to propose a few new additions to the ACL Ontology, I won't be specific on names but will describe each one and the associated need. The addition of "groups" - personally I see no need to define a set ontology for what constitutes a group when dealing with ACL, however it would be fantastic to be able to point to the URI of a "Group of WebIDs" and the relation, or predicate, that should be used. For example: [] a acl:Authorization ; acl:accessTo </pictures-of-me> ; acl:mode acl:Read ; acl:agentGroupSource <http://webr3.org/nathan#me> ; acl:agentGroupLink foaf:knows . in this scenario the agentGroupSource is a foaf:Person (me) and the relation to be used as members who have acl:Read access is everybody i foaf:knows. [] a acl:Authorization ; acl:accessTo </working-group> ; acl:mode acl:Read , acl:Write ; acl:agentGroupSource </groups#working-group-members> ; acl:agentGroupLink sioc:has_member . in this scenario the agentGroupSource is a sioc:Usergroup and the relation to be used as members who can Read,Write is sioc:has_member. I'm very aware that there are inverse relations here (sioc:member_of), but strongly feel that we can't be trusting anything in somebodies foaf profile document for ACL, so thus have negated entirely :) I've also given the above pretty poor names of agentGroup* in the examples, purposefully to get some input on better names! Next up is acl:agentClass, I'm actually going to suggest deprecation or reserving it for future use, because afaict everything which is requesting access to a resource must be an agent of some kind, and if we were to distinguish between Classes of Agent then the only place we can find out what Class an Agent has, is in their foaf profile - which they control. So for example you can say that access can only be granted to ex:Admin and I can say I am a foaf:Person, ex:Admin and gain access. In addition access control is a pretty critical issue, and adding in things which bring up many design issues about inference etc when they aren't strictly needed (as in groups and lists of WebIds suit the purpose and always have - imo) may not be the best course of action. (You've no idea how humbly I say that, but figure it best to bring it up). This does however bring up the issue of how to say "read access for anybody with a webid" - is there any wild card syntax that could be used for acl:agent or suchlike? And finally, some form of "doesn't have access" - in many cases and on many systems I've implemented there has been very strong, non-optional, requirements to effectively "ban" or restrict access to certain people. Often access is granted to everybody who is logged in but not to person-x and person-y. It seems that some for of acl:Unauthorisation is needed - but I'll leave it there for those more intelligent than me to pick up :) /end-of-list Out of all the above, the first issue group access is the one I'd most like to get out of the way asap, or even ideas on a temporary work around as keen to be progressing with the acl implementation. Best Regards, Nathan
Received on Tuesday, 20 April 2010 14:53:08 UTC