Re: ACL Ontology and Discussion

Story Henry wrote:
> 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.

Okay, I'll give it a bash :) had considered implementing for data
validation on RDF anyway so maybe now's time to make a start, will
report back in a couple days!

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

Yup, I agree - good idea. Starting point will be the aforementioned
share resources with anybody I foaf:knows and will go from there.

Nathan

> 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:19:44 UTC