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

Sorry for being a bit harsh yesterday evening. 

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.

Our answers are in terms of OWL and SPARQL because this allows us to
express relatively clearly and concisely what is needed. None of this 
should require those tools. They are great shorthands for a lot of background 
coding though, and so are useful in a mailing list discussion.

As I understand it now you don't have access to a either a good owl 
reasoner or a  very advanced SPARQL query, the thing to do is to just 
simulate some of this, and to simplify the problem. But the answers 
given with SPARQL and OWL should help you 

  a. understand how to simplify without going wrong
  b. understand what is dependent on inference 
  c. what is dependent on graph selection
 

On 21 Apr 2010, at 23:05, Nathan wrote:

> Story Henry wrote:
>> This is why we were writing the authorization out not as you have above, but
>> as 
>> 
>> [] 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 
>> or by writing out the procedural equivalent of it, as mentioned in a previous email. 
> 
> but that's what I have, and have implemented already over on
> https://ssl.data.fm/ - and have done since the first time i mentioned this!

good. 

> you can't access because i don't foaf:knows you, whereas melvin,
> kingsley, michael can; similarly I'm the only one who can actually read
> the acl because i have acl:Control over it. the acl is exposed via the
> Link header using a rel of the acl ontology.

This is partly what I was thinking. Your setup is going to be initially
very much under your own control. This is good, because it should help
you simplify things quite a lot.

But it can also lead you  - if you are not careful - to your making 
big reasoning mistakes, that you may not notice initially at all.

So for example your comments about using the sioc:member_of relation to
do one thing, and the sioc:has_member relation to do something else are 
the types of errors that stem from that. Those are inverse relations so 
they imply one another. You should not work as if you could have

  G sioc:has_member p .

without having

  p sioc:member_of G .

Of course if you don't have reasoning set up, then you won't notice it.
But when later you do start switching it on, the parts of your reasoning that
were relying on those non existent distinctions won't work.

> 
> acl:
> 
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix acl: <http://www.w3.org/ns/auth/acl#> .
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> @prefix owl: <http://www.w3.org/2002/07/owl#> .
> 
> [] a acl:Authorization ;
> 	acl:accessTo <https://ssl.data.fm/index.php> ;
> 	acl:agent <http://webr3.org/nathan#me> ;
> 	acl:mode acl:Control, acl:Read, acl:Write .

That looks good.

> 
> [] a acl:Authorization ;
> 	acl:accessTo <https://ssl.data.fm/index.php> ;
> 	acl:agentClass _:myfriends ;
> 	acl:mode acl:Read .

That looks good. (I have not tried this stuff, so I can only
speak theoretically here. I should go and implement this too frankly.
I was looking for a reason to do so.)

> 	
> _:myfriends owl:equivalentClass [
> 	a owl:Restriction ;
> 	owl:hasValue <http://webr3.org/nathan#me> ;
> 	owl:onProperty [ owl:inverseOf foaf:knows ]
> 	] .

Good so this is what I think we were proposing earlier.
Clearly if you don't have a good owl reasoner, which few of us have, 
then you would just use the above to calculate the set of members of the
class by using it to write out a query such as 

CONSTRUCT {
  ?p a _:myfriends .
} WHERE {
  <http://webr3.org/nathan#me> foaf:knows ?p .
}

You would add the results to the graph that the access control
engine then uses to make its decision. If you can you should try to
cache that graph, so that you don't need to calculate these things 
all the time.

> exactly the same code works for the above sioc:Usergroups acl,

The concern I was having in some of your previous remarks is that
you were treating a sioc:Usergroup as a class. I am not really sure
why it is not, and clearly it would make things easier with these
owl reasoning tools. But then the foaf:knows case shows more precisely
why one will need these intermediate mappers.

> if you
> want any proof then simply fire through a usergroup you are a member of
> and I'll throw up a resource w/ acl / give you acl:Control if you want,
> or I can always foaf:knows you.

cool.

My WebId is <http://bblfish.net/people/henry/card#me> 


> you can have the code immediately if you want (even though it's wip) but
> i was going to opensource the whole lot after the sparql-less foaf+ssl
> auth is in to libAithenticate.

great!

> nothing against sparql - just wanted 0 dependencies (other than arc at
> this time).

Great. As you can understand it is easier for the list to explain things 
using SPARQL than to write out the equivalent graph query. 

> 
> Henry I fear this has been one big misunderstanding other, than the odd
> typo and a mad idea of saying an Individual is Class earlier, i follow -
> the problem at heart is what IanD was asking on semantic overflow the
> other day [1] and nicely explained by danbri, dave reynolds and john
> erickson
> 
> [1]
> http://www.semanticoverflow.com/questions/757/which-owl-reasoners-understand-named-graphs

I have added a few more explanatons to that post. Hope it helps.

> 
> will leave this here and possibly just drop in a <group-uri>
> rdfs:isDefinedBy <dereferenced-group-uri> to atleast delegate some kind
> of trust / indicate where to look.

If what you do is private, and only you can see it, you can pretty much
do what you want. Things will get more complex and require proper usage of terms
if you do publish your ACLs and try to integrate with public documents.

Henry


> 
> Nathan
>

Received on Thursday, 22 April 2010 07:26:01 UTC