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

Joe Presbrey wrote:
> On Wed, Apr 21, 2010 at 2:26 PM, Nathan <nathan@webr3.org> wrote:
>>>> I'm not sure about the Gx dereference at this point.  I guess this is
>>>> analogous to multiple groups being defined in the same graph and
>>>> distinguished by fragment.  Are you planning to do this like:
>> more GET uri, parse rdf and then check resulting triples.
> 
> Say my group is <groups#users>.
> When I go HTTP GET <groups#users>, don't I actually get <groups>?
> 
> If my rule had been simply:
> 
> """group says who is in group"""
>   GRAPH <groups#users> {
>     <groups#users> <has_member> <webid> .
>   }
> 
> it would fail. It should have been:
> 
> """groups file says who is in users"""
>   GRAPH <groups> {
>     <groups#users> <has_member> <webid> .
>   }
> 
> Of course had my source been TriG or SPARQL endpoint, the former may
> have been just fine depending on my schema.
> 
> Is your plan to determine authorized named graphs automagically from
> the ACL or require them declared explicitly?

determine automagically, and sparql-less implementation - should be as
simple as:

GET <http://ex.org/groups#users>
parse in to triples
foreach( triples as triple ) {
  if( triple->s == <http://ex.org/groups#users> ) {
    if( triple->p == <has_member> ) {
      if( triple->o == <webid> ) {
         return TRUE;
      }
    }
  }
}

but how to express that in acl+owl.. here's the full abridged run down
of the problem, rewritten to be as unambiguous as possible..

>>

The problem is (should be) a very simple one.. I'm implementing ACL
using the acl ontology, all I want to do is handle a very simple group
based system where the uri of the group and the predicate are specified
in the acl file / graph.

for example given that an authenticated user is <http://ex.org/john#me>
then we simply want to check if the following triple exists

<http://ex.org/groups#group1> sioc:has_member <http://ex.org/john#me> .

or another simple example

<http://webr3.org/nathan#me> foaf:knows <http://ex.org/john#me> .

We can take it for granted that the implementing system knows how to
dereference the uri's in the subject position to get the graphs.

So I suggest originally adding to properties to the acl ontology (badly
named but you can see what I'm getting at I'm sure.

acl:agentGroupSource
acl:agentGroupLink

so in the above two examples that would equate to acl's of:

[] a acl:Authorization ;
	acl:accessTo <https://ssl.data.fm/index.php> ;
	acl:agentGroupSource <http://ex.org/groups#group1> ;
	acl:agentGroupLink sioc:has_member ;
	acl:mode acl:Read .

and

[] a acl:Authorization ;
	acl:accessTo <https://ssl.data.fm/index.php> ;
	acl:agentGroupSource <http://webr3.org/nathan#me> ;
	acl:agentGroupLink foaf:knows ;
	acl:mode acl:Read .

Seemed pretty simple to me and means it can be implemented with no owl
reasoning or suchlike.

Then I was pointed to acl:agentClass in unison with owl:equivalentClass
and owl:Restriction - and thus set about trying to "say" the above using
the aforementioned owl.

first point of call

[] a acl:Authorization ;
	acl:accessTo <https://ssl.data.fm/index.php> ;
	acl:agentClass _:myfriends ;
	acl:mode acl:Read .
	
_:myfriends owl:equivalentClass [
	a owl:Restriction ;
	owl:hasValue <http://ex.org/groups#group1> ;
	owl:onProperty sioc:has_member
	] .

but that says

<http://ex.org/john#me> sioc:has_member <http://ex.org/groups#group1> .

then we try:

_:myfriends owl:equivalentClass [
	a owl:Restriction ;
	owl:hasValue <http://ex.org/groups#group1> ;
	owl:onProperty sioc:member_of
] .

now that says:

<http://ex.org/john#me> sioc:member_of <http://ex.org/groups#group1> .

which is the complete inverse of what we want and defeats the purpose
(as it would indicate dereferencing your webid and checking if your foaf
said you were a member!)

then we try:

_:myfriends owl:equivalentClass [
	a owl:Restriction ;
	owl:hasValue <http://ex.org/groups#group1> ;
	owl:onProperty [ owl:inverseOf sioc:has_member ]
] .

and that says:

<http://ex.org/john#me> _:x <http://ex.org/groups#group1> .
_:x owl:inverseOf sioc:has_member .

and here's where it get's grey; as I'm saying that in my implementation
to find out the truth I want to refactor the above in to:

<http://ex.org/groups#group1> sioc:has_member <http://ex.org/john#me> .

to check it for truth. to check the other way around we have the
aforementioned example of:

_:myfriends owl:equivalentClass [
	a owl:Restriction ;
	owl:hasValue <http://ex.org/groups#group1> ;
	owl:onProperty sioc:member_of
] .
equals:
<http://ex.org/john#me> sioc:member_of <http://ex.org/groups#group1> .

So I think I figured my way around it - but it isn't "correct" as far as
I'm being told, because obviously given:

<http://ex.org/john#me> _:x <http://ex.org/groups#group1> .
_:x owl:inverseOf sioc:has_member .

then:

_:x owl:sameAs sioc:member_of .

thus entails:

<http://ex.org/john#me> sioc:member_of  <http://ex.org/groups#group1> .

which means that both options are identical some would say, but I want
to interpret them differently because I am dealing with named graphs,
and am asserting that:

"john says that he is a member of group1"
is completely different to
"group1 says that it has a member, john"

and the only way for me to express this distinction and infer where to
check is by using the two rules:

"john says that he is a member of group1":
_:myfriends owl:equivalentClass [
	a owl:Restriction ;
	owl:hasValue <http://ex.org/groups#group1> ;
	owl:onProperty sioc:member_of
] .

"group1 says that it has a member, john":
_:myfriends owl:equivalentClass [
	a owl:Restriction ;
	owl:hasValue <http://ex.org/groups#group1> ;
	owl:onProperty [ owl:inverseOf sioc:has_member ]
] .

and to check both ways we'd union the two, but that's a different matter
for a different time,

So back to the source, this should be bloody simple to express and
implement, the fact i even have to bring in restrictions and then use
them "incorrectly" must say something.

through all the debating though, I just want to make it work - half way
through an implementation of ACL and now blocked - again  :(

Best,

nathan

Received on Wednesday, 21 April 2010 19:42:47 UTC