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

Story Henry wrote:
> 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.

I may have been asking a non question.. again.. consider:

To process an ACL and provide access (or not) to a resource, based on
that ACL, requires implicit trust of that ACL by the processor. Thus it
can be said that the processor implicitly trusts the ACL in the context
of providing access control.

So if the processor trusts the ACL, then the processor trusts the ACLs
contents, i.e. the triples contained.

Thus it stands to reason (no pun intended) that this trust must be
extended to all resources which the ACL expressly links to or mentions
(if not then we don't trust the ACL and shouldn't be using it for access
control!).

So when we have an ACL of:

[] 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];
 	] .

then the ACL processor by extension must trust
<http://bblfish.net/people/card#me> .

One could make this trust crystal clear by simply adding the following
triple to the acl.

<http://bblfish.net/people/card#me> rdfs:isDefinedBy
<http://bblfish.net/people/card> .

In which case the processor now trusts <http://bblfish.net/people/card>
and in order to process the acl correctly must only consider data it
trusts, so the owl:Restriction above must resolve to:

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

I would also suggest then that a resource could actually manage its own
ACL.. consider:

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

where at the remote resource:
 <http://ex.org/my#friends> owl:equivalentClass [ ...

It seems to me the trust is inherently there in the case of ACL any
ways, and by extension to all resources it mentions (otherwise it's not
fit to be used for ACL) - so whilst this has brought up a huge amount of
great feedback from you and pointed the way to N3 rules for some of the
big problems - maybe in this scenario it was all a bit of a wild goose
chase (hope not and hope so at the same time!)

Many Regards,

Nathan

ps: from here on is gold and imho is the missing info about named graph
reasoning all compiled in to one place, especially Henry's response on
semantic overflow, see below ->

> 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 12:35:36 UTC