Re: ACL Ontology and Discussion

On 20 Apr 2010, at 21:13, Nathan wrote:

> 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! :)

You probably don't need to do the reasoning every time. You just need to do it every so 
often, when you one of the resources you are relying on has changed. Then you fill out the
class with all the members and you are done.

It all depends how you use it. 


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

foaf:Agent is the set of all agents, if you want.
then any class you place as the object of the acl:agentClass relation must be a set of
agents, ie a subset of foaf:Agent. That fits in well.

In any case what was proposed there is not that different from your proposal.
It's just already documented and ready to roll.

> 
> 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).

You could implement something basic with a for loop perhaps. It's a good exercise.
Are you trying to read any restriction that could be found anywhere on the internet? 
Or are you going to be in charge of the acls? If you are somewhat in charge of the acls,
then you can make sure not to create too complex restrictions.


You can probably get some of the Java reasoning tools to help you. They do some reasoning, and
you can probably get quite far by using owl class descriptions to get you a listing of all the
members of your class. That is at its most basic what these owl reasoners do really.

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

Yes, as said, you can use own and keep it simple. It's up to you how you
implement it.

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

for loops are also types of reasoning. They are just procedural (and therefore non declarative), somewhat
language dependent and not that easy to reason about.

I think it would help if you worked out the use cases for your reasoning.
Start with a simple implementation that we can use and test, and then we can help
from there.

Henry


> 
>>> 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 21:15:07 UTC