W3C home > Mailing lists > Public > public-lod@w3.org > April 2010

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

From: Story Henry <henry.story@bblfish.net>
Date: Wed, 21 Apr 2010 12:01:25 +0100
Cc: Linked Data community <public-lod@w3.org>, foaf-protocols <foaf-protocols@lists.foaf-project.org>
Message-Id: <D29B08D7-CDD0-4309-9A8F-9EE847C54AFD@bblfish.net>
To: nathan@webr3.org


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.

> [ ✂ ]
> 
> 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.

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.

Henry
Received on Wednesday, 21 April 2010 11:01:57 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:26 UTC