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

On 22 Apr 2010, at 09:55, Nathan wrote:

> Story Henry wrote:
>> Sorry for being a bit harsh yesterday evening. 
> 
> Likewise :)
> 
>> It is a bit difficult to work out what tools you have access to
>> and what you don't, and as you can imagine that is going to vary from
>> one person to the other. This might be the problem we are facing here.
>> 
>> It is also true come to think of it, that though "Working Ontologist" will
>> give you a very good background in RDF, RDFS and OWL but last
>> I looked, I don't think it really covers graphs, and belief states.
> 
> that's exactly the right term! belief states. The issue is how to
> express in which graph/resource to trust, or at least how to delegate
> that trust in some way (possibly via isDefinedby) with owl is what I
> need to be able to do. (remembering that the acl is by nature trusted).

It may be ok, not to express that directly in any way. You could easily
leave that up to your reasoner. That is the way I would go to start
off with. The reason being that since your service is the one making the
decision, and since very few people will be able to read the more advanced
rule set (not just you), publishing it won't be that much use to start off 
with anyway. 

If people start using and understanding the acls that will be
a huge improvement already, and will help us test the ontology.

Longer term using N3 rules as Tim Berners Lee has done for a long time
in the cwm directory, and for which I published pointers in my answer to

   http://www.semanticoverflow.com/questions/757/

would be ideal in my opinion. Why so few RDF libraries have integrated N3 rules
I don't know. They are very powerful, concise, form a nice superset with turtle, 
and could allow one to build in very few lines of code some awesome reasoners.

1. Simple example
-----------------

Take the simple rule on http://esw.w3.org/WebAccessControl

[] acl:accessTo <card.rdf>; 
   acl:mode acl:Read, acl:Write;  
   acl:agent <http://bblfish.net/peopl/henry/card#me> .

This is easy because when you know the WebId of the user, and having placed all the ACLs in
a graph you trust (by just crawling your web server and merging all the files into a graph you 
could name <myTrustedACLs>)  you can simply query that graph

ASK 
GRAPH <myTrustedACLs> 
{
    [] accessTo <card.rdf>;
       acl:mode acl:Read;
       acl:agent <http://bblfish.net/peopl/henry/card#me> .
}

If the answer is yes, the person gets READ access.

2. with a remote reference
---------------------------


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


Let us say for simplicity that 

<http://ex.org/groups> log:semantics {
  <#group1> is rdf:type of <http://bblfish.net/peopl/henry/card#me>, <george>, ...
}

( the log:semantics is a way of saying that if you dereference the URL you get 
the  graph. The simplicity comes from our not needing to do any inferencing on the
class to find its members )

Then you could just merge the information into <myTrustedACLs> and ask the following
query

ASK 
GRAPH <myTrustedACLs> 
{
    [] accessTo <card.rdf>;
       acl:mode acl:Read;
       acl:agentClass ?c .
       <http://bblfish.net/peopl/henry/card#me> a ?c . ] .
}
 
==BUT==

that would not be a good idea. Because it would be too easy for your whole system
to be subverted with 

<http://ex.org/groups> log:semantics {
  <#group1> is rdf:type of <http://bblfish.net/peopl/henry/card#me>, <george>, ...
 
  #DANGER!!!

  [] a acl:Authorization ;
     accessTo <https://ssl.data.fm/index.php>;
     acl:agentClass <#group1> ;
     acl:mode acl:Read, acl:Write, acl:Control .
}


  Here as you can see, I am adding a twist in that the remotely referenced
file is adding its own acl. We can imagine that it  does this by mistake, and
not necessarily out of evil intentions (perhaps it is the consequence of
something else in there, which the author of the file did not forsee)

  If you just merge that information into your <myTrustedACLs> in order 
to query it with the ASK query shown previously, then the remote resource 
could override your ACL, and could change the meaning of all your other ACLs 
too. So that is clearly not a good idea.

  So what is needed is for you to extract the minimum needed from the remote
resource. 

Perhaps the easiest way here would be to proceed in two query steps.

1. You  ASK 
GRAPH <http://ex.org/groups> {
  <http://bblfish.net/peopl/henry/card#me> rdf:type <#group1> .
}

2. If that is positive you 

ASK GRAPH <myTrustedACLs> 
{
    [] accessTo <card.rdf>;
       acl:mode acl:Read;
       acl:agentClass <http://ex.org/groups#group1> .
}

That is good, you get just what you want out of the remote graph, and nothing 
more, and then proceed with your reasoning. 

Ok so the above seems to require a step 0, where you find out that you need to 
ask something of <myTrustedACLs> to find out that you know the agent class
but not the agents that belong to it. 

It would be nice to find a more generic way of boiling those 3 steps down to less.

3. With a bit of inferencing
----------------------------

This is the other problem we were having earlier, in that some agent classes will be
defined in terms of foaf:knows. So if we had inferencing we would have something defined
like


[] 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://bblfish.net/people/card#me> ;
	owl:onProperty [ owl:inverseOf foaf:knows];
	] .

The simple-to-explain solution proceeds a bit like previously. If you use OWL reasoning,
you could do the following

1. 

create a graph (or a Networked Graph view) that contains all the triples from

 - <http://bblfish.net/people/card#me> 
 - <http://xmlns.com/foaf/0.1/>
 - the owl statements from :myfriends

add inferencing and then 

ASK {
  <http://bblfish.net/peopl/henry/card#me> rdf:type :myfriends .
}

of that graph.

2. If that is positive you 

ASK GRAPH <myTrustedACLs> 
{
    [] accessTo <https://ssl.data.fm/index.php>;
       acl:mode acl:Read;
       acl:agentClass :myfriends .
}

That is easy to explain, solid, but a bit heavy in requirements. 

3.1 A Simplification
--------------------

A lesser reasoner would just 

ASK GRAPH <http://bblfish.net/peopl/henry/card> {
     <http://bblfish.net/peopl/henry/card#me> foaf:knows ?webid .
}

after replacing ?webid with the webid presented to you.


In the case of foaf:knows that would probably cover most of the cases.
In the case of sioc:member_of you would have to ask the question twice, as it
is possible people would use 2 relations.

4. CONCLUSION
-------------

You need to work out what are the core cases that will satisfy most needs, be
a huge improvement over what exists currently, and can grow as the reasoning
tools improve.

Clearly as we all implement this, and as the reasoning tools improve we will be 
able to find some general algorithms that cover a wider and wider range of
cases. We may indeed find that the ACL ontology is a bit clunky, and that
other ontologies would help. We will then build specialised engines to help
us deal with more complex cases.

For the moment we need to get the simplest use cases in place. As you have to do 
a lot of coding without even the help of SPARQL I think you will in any case be
forced into simplicity, which as long as it is generally correct, will be a good
thing :-)

Henry

Received on Thursday, 22 April 2010 10:22:25 UTC