Re: OWL Restrictions and RDF Named Graphs

Hi Pat,

Thanks for clarifying - I've been pointed to N3 Rules by Henry Story who
also gave a very good overview of the situation over on semantic
overflow http://www.semanticoverflow.com/questions/757/ (see his reply,
in 2 parts).

In the short term I think I found a way around this given the very
specific context in which I'm working and asking at this particular time
(web access control)..

To process an ACL and provide access (or not) to a resource, based on
that ACL, requires 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://ex.org/groups#group1> ;
     owl:onProperty [ owl:inverseOf sioc:has_member ]
] .

then the ACL processor by extension must trust
<http://ex.org/groups#group1> .

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

<http://ex.org/groups#group1> rdfs:isDefinedBy <http://ex.org/groups> .

In which case the processor now trusts <http://ex.org/groups> 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://ex.org/groups> {
  <http://ex.org/groups#group1> sioc:has_member ?webid
}

And not:

ASK
GRAPH ?webid {
  ?webid sioc:member_of <http://ex.org/groups#group1>
}

(note, I'm not using sparql but the above seems a very simple way of
expressing the difference at run time)

It seems to me the trust is inherently there in the case of ACL any
way, and by extension to all resources it mentions (otherwise it's not
fit to be used for ACL) - so maybe in this scenario it was all a bit of
a wild goose chase?

Many Regards,

Nathan

Pat Hayes wrote:
> Nathan, the issue you raise is clearly important, but it goes beyond the
> semantics currently available for RDF or OWL. So to seek an answer in
> some OWL or RDF 'rule' (using this word informally) or style of usage,
> is looking under the wrong lamppost. All of the current crop of SWeb
> formalisms (including RDF and all the OWLs) deal with simple assertions.
> Their semantics provide for claiming that a graph is true, as opposed to
> not true. There are no notions of provenance, or of trust, or of claims
> made by one authority as opposed to another, etc. etc. While (as you
> point out) such matters are important in practice, they all turn on
> which source of asserted facts you decide to believe, rather than the
> nature of the facts being asserted. So in your example, the claim that
> John is a member of Group might be made by John, or published by Group,
> or maybe derived by a reasoner from some complex tissue of assertions
> made by a variety of sources. But as far as the semantics is concerned,
> it is the same claim in all these cases, and to assert it - to claim it
> is true - is the same assertion no matter who makes it. So you cannot
> expect to find anything in any OWL (or RDF. etc.) standard which can
> help you distinguish the assertion as made by John from the assertion as
> made by the Group.
> 
> The named graph proposal (which has never been ratified by the W3C) 
> included quite an elaborate device of 'warrant graphs' which allowed for
> explicit 'speech acts' where one graph could be securely signed by an
> authority and then in turn act as a warranted assertion of another
> graph, allowing these patterns of assertion to be make explicit in the
> RDF. But this amounted to a kind of RDF ontology of assertion and
> authority, rather than a change to the basic semantics.
> 
> Maybe the new RDF will be able to handle some of this. But it will take
> a while.
> 
> Pat
> 
> On Apr 22, 2010, at 4:44 AM, Nathan wrote:
> 
>> Michael Schneider wrote:
>>> Hi Nathan!
>>>
>>> It is not clear to me what your actual question is and what you want to
>>> achieve. But I can see several issues that I want to make you aware
>>> of. This
>>> may help you to rephrase your question, or to reconsider your ideas.
>>>
>>> 1) Named graphs are not supported by OWL, neither semantically nor
>>> syntactically.
>>
>> That's the problem I fear!
>>
>>> 2) The two restriction classes are equivalent to each other. I don't
>>> know
>>> whether you have intended this. The two class expressions only differ
>>> in the
>>> owl:onProperty part. But, as you state in your mail, the properties
>>> sioc:member_of and sioc:has_member are inverse to each other, so the
>>> property expressions "sioc:member_of" and "[ owl:inverseOf
>>> sioc:has_member
>>> ]" that occur in the owl:onProperty parts are equivalent to each other.
>>> Hence both restriction classes are equivalent.
>>>
>>> 3) I don't know what you mean when you say that a certain class
>>> "equates to
>>> asking" a named graph. I also don't know what you mean by "if [the
>>> class]
>>> asserts [some statement]" (classes don't assert anything). But what I
>>> can
>>> see is that the two given statements
>>>
>>>  <http://ex.org/john#me> sioc:member_of <http://ex.org/groups#g1>
>>>
>>> and
>>>
>>>  <http://ex.org/groups#g1> sioc:has_member <http://ex.org/john#me>
>>>
>>> are equivalent, since the properties sioc:member_of and
>>> sioc:has_member are
>>> equivalent. So you cannot use these statements as selection criteria,
>>> since
>>> if one statement is asserted/inferred (by whatever means), the other
>>> will be
>>> asserted/inferred as well.
>>
>> exactly, yet "john says he is a member of group-g1" is very different to
>> "group-g1 says that one of it's members is john". Belief states, truth,
>> unsure the precise term.
>>
>> context:
>>
>> I've hit this problem a few times, specifically this time it's do with
>> processing the ACL ontology at runtime for access control, where a user
>> (identified by <users-uri>) is allowed access if it is deemed to be a:
>>
>> _:myfriends owl:equivalentClass [
>>     a owl:Restriction ;
>>     owl:hasValue <http://ex.org/groups#group1> ;
>>     owl:onProperty [ owl:inverseOf sioc:has_member ]
>> ] .
>>
>> at runtime we have two graphs available to check, either the graph
>> containing <users-uri> or the graph containing
>> <http://ex.org/groups#group1>
>>
>> this would equate either:
>>
>> ASK {
>>  GRAPH <group> {
>>    <group> <has_member> <webid> .
>>  }
>> }
>>
>> or:
>>
>> ASK {
>>  GRAPH <webid> {
>>    <webid> <member_of> <graph> .
>>  }
>> }
>>
>> (or both)
>>
>> due to the delicate nature of access control, it is critically important
>> to be able to assert which graph(s) to check (or maybe trust?) at
>> runtime.
>>
>> In the above, perhaps if we swapped the term graph for resource it would
>> make more sense.. For some reason I feel that rdfs:isDefinedBy could be
>> leveraged in an owl:Restriction, but I could easily be (and often am)
>> wrong.
>>
>> Best,
>>
>> Nathan
>>
>>
> 
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
> 
> 
> 
> 
> 
> 
>

Received on Friday, 23 April 2010 13:41:01 UTC