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

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.

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



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

Received on Wednesday, 21 April 2010 06:15:34 UTC