ACL Ontology and Discussion

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