Re: Question re: HasKey entailments

On Dec 30, 2008, at 4:20 PM, Thomas Schneider wrote:

> Hi Jim and Michael,
>
> how about these examples:
>
> * A book (edition) is uniquely determined by its ISBN, but a book  
> copy in a library isn't---because there can be several copies of the  
> same book in the library. However, we might want to have books and  
> book copies in the same ontology, together with information on their  
> ISBN. Hence, hasISBN can be a key for books, but not for book copies.

yes, but this assumes you'd have books and book copies as the same CE,  
and Ian H. has argued on many occasions that that sort of thing is bad  
modeling

>
>
> * If several employees, but only one manager, work for a department,  
> then we might want to declare worksFor to be a key for Manager, but  
> it can't be a key for employees. Still, we might want to capture  
> which employee works for which department(s).

that was what I referred to as a contrived example

>
>
> * In the UK, each car normally has a unique number plate during its  
> lifetime, even if it changes owners. In Germany, cars have their  
> number plates changed when registered in a different region. Taking  
> this into account, we might want to declare hasNumberPlate to be a  
> key for UKCar, but it can't be a key for GermanCar or Car. Still,  
> German cars will have hasNumberPlate values.
>

that one sounds closer to a real example - and I'd like to see  
something of that sort in the document.

Again, to be clear, I understand he design decision,  and I can see  
where this could be a useful property to have, but the traditional use  
of keys in databases (or inverseFunctional datatype properties)  
doesn't assume this sort of localness, so my editorial suggestion is  
that this be made explicit in the structure document -- minimally this  
could be done by just adding a sentence to the existing example  
explaining why the HasKey doesn't entail the 5th statement (that Peter- 
Griffin is a person) and why that is useful

> Cheers
>
> Thomas
>
> On 30 Dec 2008, at 15:20, Jim Hendler wrote:
>
>>
>> Michael-
>> I understand that that is the way it works now, and I hadn't really  
>> thought about the idea of "local" keys -- I wonder about that  
>> design decision, but won't argue.  However, given the somwwhat non- 
>> intuitive nature of this (at least to some people, including me)  
>> perhaps the document should include either a better explanation of  
>> why the class assertion about Peter is needed and/or an explicit  
>> mention of the fact that the HasKey doesn't make  
>> the :PropertyDomain assertion and/or an example that makes some  
>> sense of this (the best I've come up with is a contrived example  
>> where some sort of permission is unique to managers but non-key to  
>> regular employees, or something like that)
>> So I hereby raise this as a LC Document issue (I believe the right  
>> terminology) -- i.e. the design is okay, but the documentation  
>> should better reflect it
>> -JH
>> p.s. I would suggest this change in the syntax/structure document  
>> itself, again, since this will be nonintuitive to at least some  
>> users and is likely to cause to the creation of buggy ontologies in  
>> OWL 2.0 if not explained
>>
>> On Dec 30, 2008, at 8:12 AM, Michael Schneider wrote:
>>
>>> Hi Jim!
>>>
>>> The idea behind the class a:Person (the first argument) in the  
>>> HasKey axiom
>>> is /not/ to entail that subjects of the key property a:hasSSN are  
>>> instances
>>> of the class a:Person. This could easily be achieved by putting an
>>> additional domain axiom on that property a:hasSSN :  
>>> PropertyDomain(a:hasSSN
>>> a:Person).
>>>
>>> Instead, the idea is that the given property a:hasSSN is only "key- 
>>> ish" for
>>> instances of a:Person. For instances outside of a:Person (or for  
>>> instances
>>> that are at least not known to be from a:Person), the property  
>>> a:hasSSN does
>>> not need to be a key. This allows to define a sort of "local key",  
>>> i.e.
>>> local to some given class, which you cannot define with inverse  
>>> functional
>>> properties.
>>>
>>> In the given example, both a:Peter and a:Peter_Griffin are known  
>>> to be in
>>> class a:Person, and hence the property a:hasSSN really acts as a  
>>> key for
>>> them: They are entailed to be the same individual, based on the  
>>> fact that
>>> the objects of the two property assertions are equal  
>>> ("123-45-6789"). But if
>>> you drop the last axiom, then nothing specific is known about the  
>>> individual
>>> a:Peter_Griffin, and so the key axiom will not "fire".
>>>
>>> To summarize: In order to make a HasKey(C p) axiom fire for two  
>>> individuals
>>> a and b, two premises must be met:
>>>
>>> (1) The objects x and y in two property assertions "a p x" and "b  
>>> p y"
>>> must be identical: x = y.
>>>
>>> (2) The individuals a and b must both be instances of the class C.
>>>
>>> You can see these two conditions (somewhat buried by other  
>>> conditions) in
>>> the definitions of the semantics of Keys, both in the Direct  
>>> Semantics [1]
>>> and the RDF-Based Semantics [2].
>>>
>>> Cheers,
>>> Michael
>>>
>>> [1] <http://www.w3.org/2007/OWL/wiki/Semantics#Keys>
>>> [2]
>>> <http://www.w3.org/2007/OWL/wiki/RDF-Based_Semantics#Semantic_Conditions_for
>>> _Keys>
>>>
>>>> -----Original Message-----
>>>> From: public-owl-wg-request@w3.org [mailto:public-owl-wg-request@w3.org 
>>>> ]
>>>> On Behalf Of Jim Hendler
>>>> Sent: Monday, December 29, 2008 9:58 PM
>>>> To: OWL Working Group WG
>>>> Subject: Question re: HasKey entailments
>>>>
>>>>
>>>> (Since I'm not a member of the WG this can be considered a LC  
>>>> comment
>>>> or since my group is in the group, you can consider it an  
>>>> internally
>>>> discussible comment)
>>>>
>>>> I was talking to someone about keys and we were looking at the
>>>> document section on this (http://www.w3.org/2007/OWL/wiki/Syntax#Keys 
>>>> )
>>>> where the example is given of
>>>>
>>>> HasKey( a:Person a:hasSSN )
>>>> PropertyAssertion( a:hasSSN a:Peter "123-45-6789" )
>>>> ClassAssertion( a:Person a:Peter )
>>>> PropertyAssertion( a:hasSSN a:Peter_Griffin "123-45-6789" )
>>>> ClassAssertion( a:Person a:Peter_Griffin )
>>>>
>>>> and my colleague asked why the last axiom wasn't entailed by the
>>>> HasKey.  We went and looked in the model theory, and it says  
>>>> under the
>>>> circumstances of the first four expressions HasKey won't apply
>>>> (because there's no evidence of a CE for Peter_Griffin) -- so it
>>>> appears this is not entailed in the current model theory.
>>>> Guess my question is why does one need the additional condition  
>>>> (and
>>>> thus the additional axiom) -- wouldn't it follow that if HasKey
>>>> relates person's via hasSSN (i.e. the HasKey assertion) that  
>>>> anything
>>>> that has that key (the SSN) would have to be a person?
>>>> If HasKey would entail that the domain of the property asserted
>>>> would be the first argument to the HasKey (which is what seems to  
>>>> be
>>>> intended) then wouldn't the fact that X is an element of
>>>> (CE)^^C [1] and in fact that it is a Person follow?
>>>> Is there a reason we don't do this ?-- would seem to simplify the
>>>> use of HasKey without causing an obvious semantic harm that I can  
>>>> see
>>>> (and would make its use more intuitive in many cases).
>>>> thanks
>>>> JH
>>>>
>>>>
>>>>
>>>>
>>>> [1] sorry, my mailer doesn't seem to like the fonts from the  
>>>> document
>>>> - see http://www.w3.org/2007/OWL/wiki/Syntax#Keys fpr the
>>>
>>>
>>> --
>>> Dipl.-Inform. Michael Schneider
>>> FZI Forschungszentrum Informatik Karlsruhe
>>> Abtl. Information Process Engineering (IPE)
>>> Tel  : +49-721-9654-726
>>> Fax  : +49-721-9654-727
>>> Email: Michael.Schneider@fzi.de
>>> Web  : http://www.fzi.de/ipe/eng/mitarbeiter.php?id=555
>>>
>>> FZI Forschungszentrum Informatik an der Universität Karlsruhe
>>> Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
>>> Tel.: +49-721-9654-0, Fax: +49-721-9654-959
>>> Stiftung des bürgerlichen Rechts
>>> Az: 14-0563.1 Regierungspräsidium Karlsruhe
>>> Vorstand: Rüdiger Dillmann, Michael Flor, Jivka Ovtcharova, Rudi  
>>> Studer
>>> Vorsitzender des Kuratoriums: Ministerialdirigent Günther  
>>> Leßnerkraus
>>>
>>
>> "If we knew what we were doing, it wouldn't be called research,  
>> would it?." - Albert Einstein
>>
>> Prof James Hendler				http://www.cs.rpi.edu/~hendler
>> Tetherless World Constellation Chair
>> Computer Science Dept
>> Rensselaer Polytechnic Institute, Troy NY 12180
>>
>>
>>
>>
>>
>
> + 
> ----------------------------------------------------------------------+
> |  Dr Thomas Schneider                          
> schneider@cs.man.ac.uk  |
> |  School of Computer Science       http://www.cs.man.ac.uk/ 
> ~schneidt  |
> |  Kilburn Building, Room 2.114                 phone +44 161  
> 2756136  |
> |  University of  
> Manchester                                            |
> |  Oxford Road                                             _/// 
> _       |
> |  Manchester M13 9PL                                       
> (o~o)       |
> +-----------------------------------------------------oOOO--(_)-- 
> OOOo--+
>
> Zigong (n.)
> Screeching skid made by cartoon character prior to turning round and
> running back in the opposite direction.
>
>                 Douglas Adams, John Lloyd: The Deeper Meaning of Liff
>
>
>
>
>
>

"If we knew what we were doing, it wouldn't be called research, would  
it?." - Albert Einstein

Prof James Hendler				http://www.cs.rpi.edu/~hendler
Tetherless World Constellation Chair
Computer Science Dept
Rensselaer Polytechnic Institute, Troy NY 12180

Received on Tuesday, 30 December 2008 21:45:04 UTC