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

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

yup i understand that, honestly, just looking for how to infer in some
way to the processor which graph to check out... cont below..

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

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.

That's what this is about (now); and the above gives me a way to infer
where to check (assuming no prior system knowledge of where). To infer
the system should check both I could use a union of both restrictions -
I see no other way of providing this knowledge of where to look to the
system.

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

indeed, in this scenario, if I were to write:

:myfriends owl:equivalentClass [
      a owl:Restriction;
      owl:onProperty 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).


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

perhaps I should have throw one in, as above the foaf:knows example.

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

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?

under no circumstances do I ever want to check if the users webid
document states that:
<http://dynamic.org/wg/social#us> sioc:has_member :me .
other than in the specific scenario where both the group and the webid
dereference to the same doc / named graph, which thankfully is catered
for by the above anyway.

Nathan

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