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

Story Henry wrote:
> Hi Nathan,
> 
> it seems to me you need to invest in an introductory book on the semantic web.
> I suggest "Semantic Web for the Working Ontologist" by Dean Allemang
> which I reviewed here
> 
>    http://blogs.sun.com/bblfish/entry/semantic_web_for_the_working
> 
> It is very nice, it goes over RDF, RDFS, OWL without mentioning rdf/xml, in an intutive
> but precise way.

Ty, and agreed, I'll move it from my wishlist to my desk :)

> On 21 Apr 2010, at 03:44, Nathan wrote:
> 
>> Nathan wrote:
>>> Nathan wrote:
>>>> Request for a bit of help / clarification - started implementing.. see
>>>> in-line from here..
>>>>
>>>> Story Henry wrote:
>>>>> On 20 Apr 2010, at 21:13, Nathan wrote:
>>>>>
>>>>>> Story Henry wrote:
>>>>>>> On 20 Apr 2010, at 15:52, Nathan wrote:
>>>>>>>> I'd like to propose a few new additions to the ACL Ontology, I won't be
>>>>>>>> specific on names but will describe each one and the associated need.
>>>>>>>>
>>>>>>>> The addition of "groups" - personally I see no need to define a set
>>>>>>>> ontology for what constitutes a group when dealing with ACL, however it
>>>>>>>> would be fantastic to be able to point to the URI of a "Group of WebIDs"
>>>>>>>> and the relation, or predicate, that should be used. For example:
>>>>>>>>
>>>>>>>> [] a acl:Authorization ;
>>>>>>>> acl:accessTo </pictures-of-me> ;
>>>>>>>> acl:mode acl:Read ;
>>>>>>>> acl:agentGroupSource <http://webr3.org/nathan#me> ;
>>>>>>>> acl:agentGroupLink foaf:knows .
>>>>>>> I think you can get what you want by using owl reasoning
>>>>>>>
>>>>>>> @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> 
>>>>>>> ] .
>>>> managed to get the above implemented and working, basically this equates
>>>> to find the triple:
> 
> What the above is saying is that :myfriends is a class that has exactly the same members
> as the class that can be found by asking the following query
> 
> SELECT ?mem
> WHERE { 
>   <http://webr3.org/nathan#me> foaf:knows ?mem .
> }
> 
> and adding all ?mem to the set.
> 
> 
>>>> <http://webr3.org/nathan#me> foaf:knows <users-webid> .
>>>>
>>>> if it's there then grant access, else not.
>>>>
>>>> is that correct?? or should it equate to looking for:
>>>>
>>>> <users-webid> foaf:knows <http://webr3.org/nathan#me> .
>>>>
>>>>>>>> in this scenario the agentGroupSource is a foaf:Person (me) and the
>>>>>>>> relation to be used as members who have acl:Read access is everybody i
>>>>>>>> foaf:knows.
>>>>>>>>
>>>>>>>> [] a acl:Authorization ;
>>>>>>>> acl:accessTo </working-group> ;
>>>>>>>> acl:mode acl:Read , acl:Write ;
>>>>>>>> acl:agentGroupSource </groups#working-group-members> ;
>>>>>>> you probably want a 
>>>>>>>
>>>>>>>  acl:agentGroupSource </groups/#userGroup1> ;
>>>>>>>
>>>>>>>> acl:agentGroupLink sioc:has_member .
>>>>>>> [] a acl:Authorization ;
>>>>>>> acl:accessTo </working-group> ;
>>>>>>> acl:mode acl:Read , acl:Write ;
>>>>>>> acl:agentClass :wkgrp.
>>>>>>>
>>>>>>> :wkgrp owl:equivalentClass [
>>>>>>>   a owl:restriction;
>>>>>>>   owl:onProperty sioc:member_of;
>>>>>>>   owl:hasValue </groups/#userGroup1> .
>>>> managed to get this one in too.. equates to needing:
>>>>
>>>> <users-webid> sioc:member_of </groups/#userGroup1> .
> 
> SELECT ?mem 
> WHERE { 
>    ?mem sioc:member_of </groups/#userGroup1> .
> }
> 
> 
>>>> (hopefully)!
>>>>
>>>> but what I needed in the first place was the opposite, to find the
>>>> following triple:
>>>>
>>>> <http://example.org/usergroups#group1> sioc:has_member <users-webid> .
> 
> 
> sioc:has_member is the owl:inverseOf sioc:member_of . So that is indeed what you got.
> 
> 
>>>> my first thought was..
>>>>
>>>> [] a acl:Authorization ;
>>>> 	acl:accessTo <https://ssl.data.fm/index.php> ;
>>>> 	acl:agentClass _:group ;
>>>> 	acl:mode acl:Read .
>>>> 	
>>>> _:group owl:equivalentClass [
>>>> 	a owl:Restriction ;
>>>> 	owl:hasValue <http://example.org/usergroups#group1> ;
>>>> 	owl:onProperty [ owl:inverseOf sioc:member_of ]
>>>> 	] .
>>>>
>>>> is that correct?
> 
> That is semantically the same as the above.
> 
>>>> if so then the foaf:knows implementation above is a bit of a special
>>>> case isn't it.. because the inverse of { <a> foaf:knows <b> } is { <b>
>>>> foaf:knows <a> } but the inverse of { <c> sioc:member_of <d> } is { <d>
>>>> sioc:has_member <c> } - different predicates.
> 
> Not a problem. Sometimes the inverses, don't have the same names. :-)
> 
>>>> I could be (and probably am) wildly wrong here, any clarification?
>>> figured a bit out i think..
>>>
>>> above..
>>> :myfriends owl:equivalentClass [
>>>      a owl:Restriction;
>>>      owl:onProperty [ owl:inverseOf foaf:knows ];
>>>      owl:hasValue <http://webr3.org/nathan#me>
>>> ] .
>>>
>>> would equal:
>>>
>>> <users-webid> foaf:isKnownBy <http://webr3.org/nathan#me> .
>>>
>>> if such a thing existed, but it doesn't so to check if <users-webid> is
>>> known by :me then we have to
>>>
>>> <http://webr3.org/nathan#me> foaf:knows <users-webid> .
>>>
>>> but I think I've just inferred that last bit of knowledge myself, and
>>> that it'd be impossible for a machine to figure that bit out.. because
>>> surely in the case of:
>>>
>>> _:group owl:equivalentClass [
>>> 	a owl:Restriction ;
>>> 	owl:hasValue <http://example.org/usergroups#group1> ;
>>> 	owl:onProperty [ owl:inverseOf sioc:member_of ]
>>> 	] .
>>>
>>> I'd have to dereference sioc, see if there was an inverse property of it
>>> and then look for:
>>>
>>> <users-webid> sioc:has_member <http://example.org/usergroups#group1> .
>>>
>>> which isn't what i want and means the two cases above seem impossible to
>>> me at the minute.. looks like I don't need onProperty hasValue but
>>> rather some other something..?
>>>
>>> back to owl spec!
>>>
>> 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> .
}

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.

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

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.

Does it make more sense now why I'm saying that it doesn't entail..? I
guess it's the difference between

g1 {
  <a> sioc:member_of <b> .
  <b> _:x <a> .
  _:x owl:inverseOf sioc:member_of .
  _:x owl:sameAs sioc:has_member .
}

g2 {
  <b> sioc:has_member <a> .
  <a> _:y <b> .
  _:y owl:inverseOf sioc:has_member .
  _:y owl:sameAs sioc:member_of .
}

aside: not using sparql for this.

>> thus in our context to check the acl we would need to see if
>> <http://example.org/usergroups> states that:
>>
>>  <http://example.org/usergroups#group1> sioc:has_member <users-webid> .
> 
> yes, if you add the inverse relation to your reasoning engine, then that
> falls out.
> 
> Now as I mentioned earlier it all depends if you control what is being said
> in the RDF documents. If it is, then just write things out in the simplest
> way your reasoning engine can understand.
> 
> As you make things more general, and perhaps allow other people to specify access
> control rules, then you will need to use more general and powerful reasoning engines.
> 
> Of course there will always be limitiations on how much energy you will be willing
> to spend finding the consequences of rules people write out. So if someone
> makes rules too complex, they may just not get your access control agent to give
> everyone they intended to give access to, access.
> 
>> this is also true for the foaf:knows acl above.
>>
>> I do sincerely hope the above is correct, if not I leave it in your
>> capable hands.
>>
>> Best & good night all - late here in the UK!,
>>
>> Nathan
>>
> 
> Hope that helps,
> 
> Social Web Architect
> http://bblfish.net/
> 

Certainly does, cheers Henry,

Nathan

Received on Wednesday, 21 April 2010 08:18:35 UTC