- From: Nathan <nathan@webr3.org>
- Date: Wed, 21 Apr 2010 01:18:24 +0100
- 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