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

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

^ probably a good snip point ^

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

Ty Henry, at runtime I do have a virtuoso 6 to fall back on for sparql
and am quite familiar, however for ACL specifically I'm keen to
implement with 0 dependencies, i.e. via code. Creating the code to do
the reasoning and implement the logic isn't a problem, but the specific
syntax of expressing which graph to trust in owl (or rdf) is where I'm
coming short.

> 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

AFAICT, only c is left to handle now, and specifically I know what is
dependant on graph selection, but can't figure out how to express that
graph selection in the acl (owl/rdf). The equiv of "[] checkGraph
<graph>" or even "[] checkResource <resource> . <resource> isDefinedBy
<x>" .. struggling!

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

exactly, what I had suggested is a short term hack and I want to avoid
it, rather address the true problem listed above
 	
>> _: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.

:) good, have implemented the equiv in code with http caching, sadly not
many people are publishing graphs w/ ETags and cache control - that's an
aside though!

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

exactly, all that remains now is to express "who to trust" in owl


>> the problem at heart is what IanD was asking on semantic overflow the
>> other day  
>> 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.

ty

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

indeed, hence looking for the real solution to this problem of
expressing who to believe as outlined througout :)

Best & thanks once again,

Nathan

Received on Thursday, 22 April 2010 09:22:51 UTC