- From: Story Henry <henry.story@bblfish.net>
- Date: Wed, 21 Apr 2010 12:01:25 +0100
- To: nathan@webr3.org
- Cc: Linked Data community <public-lod@w3.org>, foaf-protocols <foaf-protocols@lists.foaf-project.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