Re: [foaf-protocols] owl:Restrictions in ACL - was Re: ACL Ontology and Discussion

Story Henry wrote:
> 
> On 21 Apr 2010, at 11:36, Nathan wrote:
>> [ ✂ ] they are, but as you know "Harry says that his father is Joe" and "Joe
>> says that his son is Harry" are different things, in different
>> situations you may choose to believe one party, the other party or only
>> believe the statement(s) if both parties make them.
> 
> great. So perhaps what would be useful to do, would be to express
> your problem that way in english first.
> 
> 1. You have someone U who wants access to /photo.jpg on your server
> 2. Cerebros, the access control robot has been told  that /photo.jpg 
>    can be accessed by anyone of Nathan's friends
> 
> That is all that is done declaratively. How Cerebros goes around checking
> what a friend of Nathan is, is another issue. You hope that he does not do it 
> 
>   - by torturing you to admit it
>   - by killing all your friends so that the list is empty
>   - by asking U if he is your friend
> 
> but rather goes and checks your foaf file where you have stated it.
> 
>> [ ✂ ] I see no other way of providing this knowledge of where to look to the
>> system.
> 
> There are many ways to provide this knowledge. You don't necessarily need to 
> formalise it, do you? What is for sure is that your attempt at formalizing it
> is certainly not the right way as I will show below
> 
> 
>> Story Henry wrote:
>>> So you now are at the authorisation stage. We imagine you have the resource 
>>> the user wants access to is protected by the following or equivalent acl
>>>
>>> @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> 
>>> ] .
>>>
>>>
>>> Your acl uses the <http://webr3.org/nathan#me> WebId to identify you. Presumably
>>> it trusts the document <http://webr3.org/nathan> to correctly declare the foaf:knows relationships. So it
>>> can probably just create a list (set) of WebIds from there and check if the users' WebId is part of that
>>> list. Notice that you merge the information from the acl G1 and what <http://webr3.org/nathan#me> declares,
>>> but not the information about what the authentifying user declares at his webid document. (g2)
>> indeed, in this scenario, if I were to write:
>>
>> :myfriends owl:equivalentClass [
>>      a owl:Restriction;
>>      owl:onProperty [ owl:inverseOf foaf:knows];
>>      owl:hasValue <http://webr3.org/nathan#me>
>> ] .
>>
>> then I would be checking if the authentifying user declares that he
>> foaf:knows me in his webid document (g2).
> 
> No, not really that is just saying that the class :myfriends is the class of people
> who have who <http://webr3.org/nathan#me> foaf:knows. Where the information comes from is not
> stated there.

what a place for a typo :( i meant

 :myfriends owl:equivalentClass [
      a owl:Restriction;
      owl:onProperty foaf:knows;
      owl:hasValue <http://webr3.org/nathan#me>
] .

copy paste confusion

>> [ ✂ ]
>>
>> Honestly Henry, I get what you are saying and fully comprehend it -
>> afaict neither owl nor the acl has a way of expressing "where to check"
>> or "which named graph(s) to trust" thus to tackle this in the short term
>> I've opted to use the above ways of doing it, clarified here:
>>
>> # CHECK IF THE USERS WEBID DOCUMENT SPECIFIES THEY ARE
>> # a sioc:member_of <http://dynamic.org/wg/social#us>
>> #
>> [] a owl:Restriction;
>>  owl:onProperty sioc:member_of;
>>  owl:hasValue <http://dynamic.org/wg/social#us> .
>>
>> # CHECK IF <http://dynamic.org/wg/social> SPECIFIES THAT
>> # <http://dynamic.org/wg/social#us> sioc:has_member <webid>
>> #
>> [] a owl:Restriction;
>>  owl:onProperty [ owl:inverseOf sioc:has_member ];
>>  owl:hasValue <http://dynamic.org/wg/social#us> .
>>
>> make sense?
> 
> What you want to do makes sense. But the above will not do what you want, however
> much you hope to. To do what you want precisely you would have to use N3 rules.

ty, will check out N3 rules (on the side)

> I would say, keep the group definitions declarative, keep where you get the 
> information from simple, and you have done stage 1. 
> 
> To get generalised trust rules is going to take a lot more work. But it is not clear from
> the examples that you need that. Stick to solutions where it all that is needed is dereferencing one
> or two files, a tiny bit of rasoning and a for loop.

will do for now, long term I (and we) definitely do need the generalised
trust rules and aware that what I've mentioned isn't a solution (even
though i can make my implementation understand it in this set way) - but
again this is why I wanted to avoid all reasoning and inference for ACL
in the first place by introducing a couple of terms to the vocab as
mentioned initially :p

Sadly, I'm going to have to implement the above in the short term though
as can't for the life of me see any other way of expressing:

if graph <Gx> holds the triple <group> <has_member> <webid> .
  where <Gx> is found by dereferencing <group>
  where <group> and <has_member> are defined in the ACL
  where <webid> is only known at runtime after checking foaf+ssl.

Best,

Nathan

Received on Wednesday, 21 April 2010 11:44:00 UTC