To: Jim Hendler <firstname.lastname@example.org>
Subject: [LC response] To Jim Hendler
Thank you for your comment
on the OWL 2 Web Ontology Language last call drafts.
In subsequent discussion, our understanding is that you have agreed that the way keys interact with classes (i.e., the class is additional check, not something to be inferred) has merit but that the documentation should more clearly indicate that merit. See your message:
To this end, we have followed your suggestion and added a couple of sentences to the first paragraph of
which we hope makes things clear.
This response supercedes any prior response.
Please acknowledge receipt of this email to <mailto:email@example.com> (replying to this email should suffice). In your acknowledgment please let us know whether or not you are satisfied with the working group's response to your comment.
on behalf of the W3C OWL Working Group
CUT AND PASTE THE BODY OF THE MESSAGE (I.E. FROM "Dear" TO "Group") INTO THE BODY OF AN EMAIL MESSAGE. SET THE To:, CC:, AND Subject: LINES ACCORDINGLY.
PLEASE TRY TO REPLY IN A WAY THAT WILL ALLOW THREADING TO WORK APPROPRIATELY, I.E., SO THAT YOUR REPLY CONTINUES THE THREAD STARTED BY THE ORIGINAL COMMENT EMAIL
|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  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).
However, given two of us who had PhDs in AI and long experience with DBs took a while to work through the semantics, and didn't get the idea of these examples without the emails from you folks, I do think documenting it will be important...