Re: ACL Ontology and Discussion

Story Henry wrote:
> On 20 Apr 2010, at 15:52, Nathan wrote:
>>
>> 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 .
> 
> I think you can get what you want by using owl reasoning
> 
> @prefix owl: <http://www.w3.org/2002/07/owl#> .
> @prefix acl: <http://www.w3.org/ns/auth/acl#> .
> 
> [] a acl:Authorization ;
>  acl:accessTo </pictures-of-me> ;
>  acl:mode acl:Read ;
>  acl:agentClass :myfriends .
> 
> :myfriends owl:equivalentClass [ 
>       a owl:Restriction;
>       owl:onProperty [ owl:inverseOf foaf:knows ];
>       owl:hasValue <http://webr3.org/nathan#me> 
> ] .
> 
>> 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> ;
> 
> you probably want a 
> 
>    acl:agentGroupSource </groups/#userGroup1> ;
> 
>>  acl:agentGroupLink sioc:has_member .
> 
> 
> [] a acl:Authorization ;
>  acl:accessTo </working-group> ;
>  acl:mode acl:Read , acl:Write ;
>  acl:agentClass :wkgrp.
> 
> :wkgrp owl:equivalentClass [
>     a owl:restriction;
>     owl:onProperty sioc:member_of;
>     owl:hasValue </groups/#userGroup1> .   

I'd really like to invest some time in to making better use of owl
restrictions, ranges etc however a couple of things are stopping me (at
the minute).

1: how do I implement this? I've not seen any tools yet that can handle
this level of owl, inferencing and reasoning at runtime easily (to be
realistic any implementation would need to have done it's work in a few
milliseconds at most to be usable). If there are tools that can do this
(even slowly) at runtime at the minute then I'm all ears! :)

2: how does this play with agentClass "# Must be subclass of foaf:Agent"?

Also, even though this is a possibility surely some way of handling
groups with simple to calculate methods would be a useful addition to
the ontology? - I know that what I've suggested could be implemented
with a simple forloop and if-match and that it would cover a huge range
of functionality (most use cases I can think of / need at the least).

>> 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 :)
> 
> That is not a question of the direction of the realtion, but a question 
> of which information you take as reliable. If you don't trust the information
> from the user's profile, don't merge it into the graph you use to decide 
> who get access to some resource.
> 
>> 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,
> 
> Not sure why you think so. The point of agentClass is to link to the set
> of agents that have access. Seems pretty reasonable to me.

point taken, i like the owl route (for research, future implementations
etc), but for realistic quick implementations of ACL "now" surely a keep
it simple additional option would help?

>> 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.
> 
> The agent class is not a way of defining the type of the agent, it is a way to
> define the type of people who will be given access. 
> 
> agentClass   a rdf:Property;
>         rdfs:label "agent";
>         rdfs:comment "A class of persons or social entities to being given the right";
>         rdfs:domain     Authorization;
>         rdfs:range      rdfs:Class.  # Must be subclass of foaf:Agent. 
> 
> 
> 
>> 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.
> 
> That is why one would not use information from your foaf file to decide
> what class you are in. Presumably the class could be one defined either directly
> by a URL, which could list all its members, and presumably would be access 
> controlled by someone reliable, or as above indirectly as your friends.
> 
>> 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?
> 
> If you want that you would do as the note in the acl ontology points out, you
> would use the class of foaf:Agent 
> 
>>
>> 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.
> 
> You can use set operators defined here 
> 
> http://www.w3.org/TR/2004/REC-owl-guide-20040210/#SetOperators
> 
> to define sets of people who are not allowed access.

which is great but I really need a non reasoning approach too - one of
the huge strengths of the ACL ontology is it's focus on keeping things
simple, like using basic Read,Write,Control permission set - a simple
way to handle cases where a certain set of people had no access would be
a really good thing to have.

>> 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,

Nathan

Received on Tuesday, 20 April 2010 20:14:38 UTC