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

On 21 Apr 2010, at 09:17, Nathan wrote:

> Story Henry wrote:
> 
>> On 21 Apr 2010, at 03:44, Nathan wrote:
>>> [ ✄ ] figured it - finally.. (?)
>>> 
>>> _:group owl:equivalentClass [
>>>  a owl:Restriction ;
>>>  owl:hasValue <http://example.org/usergroups#group1> ;
>>>  owl:onProperty [ owl:inverseOf sioc:has_member ]
>>> ] .
>>> 
>>> which leaves you looking for the following :
>>> 
>>> <users-webid> _:y <http://example.org/usergroups#group1> .
>>> _:y owl:inverseOf sioc:has_member .
>>> 
>>> which afaict does not entail:
>>> <users-webid> sioc:member_of <http://example.org/usergroups#group1> .
>> 
>> It does because
>> 
>> sioc:member_of owl:equivalentProperty [ owl:inverseOf sioc:has_member ] .
>> 
>> 
>>> because that would be specified by:
>>> 
>>> _:group owl:equivalentClass [
>>>  a owl:Restriction ;
>>>  owl:hasValue <http://example.org/usergroups#group1> ;
>>>  owl:onProperty sioc:member_of
>>> ] .
>> 
> 
> must be different surely - I know what you are saying about
> equivalentProperty; but the above should =
> 
> SELECT ?mem
> WHERE {
>    ?mem sioc:member_of <http://example.org/usergroups#group1> .
> }

_:group is indeed a class equivalent to any class that contains all the
bindings to ?mem in your query above. Note that as you add more information
you may also get more results.


> What I forgot to mention is that at runtime when we are processing the
> ACL we have two (or more) graphs to pull information from; the users
> foaf file and an unknown graph.

yes, that is the whole point of the semantic web. 
But it is not because you can merge information from every graph that you should, just
like it is not because you can believe what everyone tells you that you should.

So once you have tied the WebId to the user at the end of the ssl connection, you 
know what he is telling you about himself. Your access control information is 
something you will not want to merge with what he says, unless you completely trust him.

> 
> I'm suggesting that the above equates to:
> 
> SELECT ?mem
> FROM <users-foaf>
> WHERE {
>    ?mem sioc:member_of <http://example.org/usergroups#group1> .
>    FILTER( ?mem = <users-webid> )
> }
> 
> whilst an acl w/ the following:
> 
> _:group owl:equivalentClass [
>  a owl:Restriction ;
>  owl:hasValue <http://example.org/usergroups#group1> ;
>  owl:onProperty [ owl:inverseOf sioc:has_member ]
> ] .
> 
> would equate to:
> 
> SELECT ?mem
> FROM <http://example.org/usergroups>
> WHERE {
>    <http://example.org/usergroups#group1> sioc:has_member ?mem .
>    FILTER( ?mem = <users-webid> )
> }

You seem to think that the relations are fixed in how they can
be used, in that only one document type can publish one of the relation. 
But that is not the case, both your ACL or the users' document could publish 
either sioc:has_member or sioc:member_of.

In any case, whenever you have one relation the other one is true too.
That is just like when if I say Joe is the father of Harry, it is simultaneously 
true to say that Harry's father is Joe, or that Harry is the child of Joe. 
The same facts make all those true: the are logically equivalent.


> The two queries are obviously v different because they are asking
> different graphs the question, and we need a way to be able to infer
> which graph to ask based on the limited information available in the
> equivalentClass, Restriction pairing.

You may indeed want to ask both graphs a question. We first have to work out
what you are trying to do.


> Does it make more sense now why I'm saying that it doesn't entail..?

I think I am starting to see where your conceptual problem is coming from.
You are looking in the wrong place for a solution to a problem that I think you
have not yet got. (you should come across it later).

To summarize you have are the following graphs

G1. Access control rules you trust
G2. User Information (which you get from the WebId)
G3. Information about what user you are dealing with (you have a WebID handle
    on the user at the end of the connection)

( btw. This is laid out in detail in "FOAF+SSL: RESTful authentication 
for the social web"
http://bblfish.net/tmp/2009/05/spot2009_submission_15.pdf )

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


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


So let us now look at your other example

[] a acl:Authorization ;
   acl:accessTo </social/wiki> ;
   acl:mode acl:Read , acl:Write ;
   acl:agentClass :wkgrp .

:wkgrp owl:equivalentClass [
   a owl:restriction;
   owl:onProperty sioc:member_of;
   owl:hasValue <http://dynamic.org/wg/social#us>;
   ] .


Here the working group is defined at <http://dynamic.org/wg/social>, so
you just look there to find the members. From that you can define a class of all
the members, and you are ready to roll: just check if the authenfied user is member 
of that class.

In none of these examples does it look like you really needed to ask any questions of the
users WebId Document.

You could use information about what the authentifying user says
in his foaf file to help you search for an answer to a question. That is a more
advanced use case. One such would be the case where you are allowing friends of friends access to
a party. Perhaps you don't have time to GET all your friends foaf file dynamically, so if
you find someone who claims to know someone you know, then you do a quick update on their
file, to see if they link back.

But again, start with the simple examples first, where you don't have to do complex searches. There you
can just build a list quite easily which you can iterate through with a for loop.

Henry

Received on Wednesday, 21 April 2010 09:53:30 UTC