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

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

From: Story Henry <henry.story@bblfish.net>
Date: Wed, 21 Apr 2010 22:47:54 +0100
Cc: Joe Presbrey <presbrey@gmail.com>, Linked Data community <public-lod@w3.org>, foaf-protocols <foaf-protocols@lists.foaf-project.org>
Message-Id: <C1C6B2F4-5AF8-490A-B7E4-CD065D8694C1@bblfish.net>
To: nathan@webr3.org
I think it would be nice if you went off to study "Semantic Web for 
the Working Ontologist" before asking any more questions on this group.
Currently it would be like a php person coming to a php group, who
never really even looked at a php grammar, syntax, or got a simple php
program to run. And then kept asking questions which were due mostly to
the person's trying to guess how php was meant to work from his experience
in Visual Basic.

That book should help you get going. I learnt a lot from it.

Nevertheless I will answer you question one last time below.

On 21 Apr 2010, at 20:35, Nathan wrote:

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

why sparql-less? 

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

With SPARQL it clearly would be easier to ask

  GRAPH <http://ex.org/groups> { 
    <http://ex.org/groups#users> sioc:has_member <webid> .

But if you don't have SPARQL then well, you can do graph traversal, which also
will work. It's just more work programmatically.

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

OWL reasoning helps you to find inferences. So you can ask queries on graphs that
would contain equivalent information written in other ways, and map it.

OWL gives you more power. Of course you need tools to get the extra power.
If you don't have the tools, then simplify the problem so that the tools 
are not necessary. There are many different ways to do that. It requires 
asking users to be more consistent in how they express the data. This is 
probably ok, to start off with as you will be the first to try this out. 
Start simple with a few things, then move to more complciated versions.

But start with something. For the moment we don't see any of your code, or 
any service you have put online.

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

If the representation returned by the <http://ex.org/groups> contains the triples

<http://ex.org/groups#group1> sioc:has_member :joe, :henry, jack, jim, george ...

Then you are done.  IE the ASK query mentioned above will return TRUE if the webid is a member
of the group which has the restiction you have used.

  GRAPH <http://ex.org/groups> { 
    <http://ex.org/groups#users> sioc:has_member <webid> .

in fact if you ask your query directly to the graph <http://ex.org/groups>
then you can just ask 

    <http://ex.org/groups#users> sioc:has_member <webid> .

You can use the above query to determine membership of the 
<http://ex.org/groups#group1> class defined in your the rule
specified in your follow up e-mail.

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

Well! Careful!
The above is not correct, because if you look at the definition of
acl:agentClass the object has to be a owl:Class, not a sioc:Usergroup.

So what is required is one more step to map the members of a sioc:Usergroup into a 
owl:Class (which you can think of as a set)

This is why we were writing the authorization out not as you have above, but

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

But you if you want to do things procedurally, you can just define that set
by getting the results from the query 

> SELECT ?mem
> FROM <http://example.org/usergroups>
>   <http://example.org/usergroups#group1> sioc:has_member ?mem .
> }

or by writing out the procedural equivalent of it, as mentioned in a previous email. 

You don't have SPARQL, or you don't like it? No problem, just iterate through
the graph. It's a good exercise to start that way, as it will show you that there is nothing
magical about SPARQL. It's just easier that graph traversal.

The art of this is to have a web service that is useful, and to solve the main use cases first.
As you and your users get used to this, you can add the more useful use cases later.

Received on Wednesday, 21 April 2010 21:48:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:16:05 UTC