W3C home > Mailing lists > Public > public-lod@w3.org > April 2010

owl:Restrictions in ACL - was Re: ACL Ontology and Discussion

From: Nathan <nathan@webr3.org>
Date: Wed, 21 Apr 2010 01:18:24 +0100
Message-ID: <4BCE4450.30505@webr3.org>
To: Story Henry <henry.story@bblfish.net>
CC: Linked Data community <public-lod@w3.org>, foaf-protocols <foaf-protocols@lists.foaf-project.org>, Melvin Carvalho <melvincarvalho@gmail.com>
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:

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

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

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?

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.

I could be (and probably am) wildly wrong here, any clarification?

Best,

Nathan
Received on Wednesday, 21 April 2010 00:19:02 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:26 UTC