Re: Comment on non-global keys

Ian/WOWG -
   I have a question.  For QCRs we have said that creating 
intermediate classes is not a good enough solution because in the 
long run it is cumbersome and not exactly equal.  I'm not convinced 
that what Ian proposes in this case is not essentially the same -- 
that is, you show we can qualify a key by creating a new class of 
essentially "employess who are designated by their SSN"  -- in fact, 
if we had a syntax that would let us qualify cardinalities, I believe 
the same syntax could be used to more easily qualify 
inverseFunctionalProperty (and maybe other things) - essentially all 
these are things where the best solution is to have a way to say  a 
local restriction, on a property, has some special local features.
  I believe the best answer to Bob would be to do what some of us 
proposed for QCRs - send him essentially what you have, but instead 
of saying "we won't do X" I'd propose we raise (and then POSTPONE) 
this issue, thus recommending to any successors we may have someday 
that this is something to look at (and it also could include his 
multiple keys without us having to be quite as dogmatic).  If nothing 
else, I would point out that multiple keys is EASY in OWL Full if we 
simply invented a little syntax -- it's only research in that we 
don't know how to do it in the DL framework (I'm not advocating this 
- I'm just saying that saying "X is research" is not always the best 
response)

  anyway, my proposal is to reword the below, say that we will not add 
it at this point, and create a POSTPONED issue to point at this email 
as the raising of this issue

   -JH
p.s. please note some weasel words in the above - I know this is not 
identical to the QCR case, but it is syntactically similar, and their 
are known implementations in the DB world for handling these in many 
cases.




At 9:41 +0100 5/7/03, Ian Horrocks wrote:
>On May 6, Jim Hendler writes:
>>
>>  Bob Macgregor has a comment at [1] about our decision that
>>  inverseFunctionalProperty is used globally.  This comment is not
>>  addressed to any specific document - which means we can chose pretty
>>  much anyone who would like to to address this comment.  Anyone want
>>  to take a shot at thinking about it/addressing it?
>>    thanks
>>    JH
>
>I have appended a proposed response.
>
>Ian
>
>-----------------------------------------------------
>On May 6, Bob MacGregor writes:
>>
>>  OWL ought to include a syntax for defining non-global
>>  keys.  For example, suppose the classes Employee and
>>  EmployeeHistory both share the attribute hasSSN.
>>  One would like to be able to assert that 'hasSSN' is
>>  a key for instances of Employee, but not for instances
>>  of EmpoyeeHistory.  InverseFunctionalProperty does not
>>  permit this.
>>
>>  Currently, single valued restrictions on properties
>>  can be stated globally or with respect to instances
>>  of a Class.  Similarly, range restrictions on properties
>>  can be stated globally, or with respect to instances
>>  of a Class.  By analogy, keys should have similar
>>  flexibility.
>
>Asserting that F is an InverseFunctionalProperty is just syntactic
>sugar for an assertion that Thing is a subclass of restriction(inv-F
>maxCardinality(1)), where the property inv-F is the inverse of
>F. Using such an assertion with classes other than Thing gives the
>ability to "localise" the inverse functionality to particular classes,
>and thus to provide a form of localised keys. E.g.,
>subClassOf(Employee restriction(inv-hasSSN maxCardinality(1))) would
>make hasSSN a key for instances of Employee.
>
>Of course all these forms (including the use of
>InverseFunctionalProperty) are in OWL Full if
>InverseFunctionalProperty is a DatatypeProperty.
>
>
>>  The property we have in mind for specifying a key
>>  would have domain Class and range Property.  One
>>  might call it something like 'hasKey' or 'classHasKey'.
>>  However, if we are broad-minded, we will recognize
>>  that sooner or later we will also want to support
>>  compound keys.  So perhaps it could be called
>>  'hasSimpleKey' or 'hasAtomicKey'.
>
>In an effort to avoid syntax "bloat" in OWL, the working group have
>deliberately avoided trying to provide dedicated syntax for idioms
>that can already be expressed using the language primitives. The
>thinking is that tools will provide idioms appropriate to the
>applications for which they are designed and generate the relevant OWL
>syntax.
>
>
>>  When n-ary relational tables are converted into RDF
>>  format, each table maps to a class and each of a table's
>>  columns maps to a property.  If a table has
>>  a compound key (a rather common-place occurrence),
>>  then one would like to be able to map its key
>>  restriction to RDF as well.  That would require
>>  that we support the notion of a compound key.  For
>>  example, the class EmployeeHistory might have the
>>  key <hasSSN, historyDate>.
>>
>>  A property representing a compound key declaration
>>  might map a Class to a List.  Perhaps this property
>>  could be called 'hasCompoundKey'.
>
>Compound keys cannot be represented in OWL, and the ability to do so
>would require a significant extension to the existing language.
>
>
>>
>>  Provisions for supporting key declarations appear
>>  in the OWL "wish list".  Given how fundamental they
>>  are in real-world modelling, they ought to become
>>  more than that.
>
>As discussed above, keys can be defined in OWL full. Support for
>compound keys is the subject of ongoing research (see [1]) and it is
>not planned to include them in the current version of OWL.
>
>Regards, Ian
>
>[1] http://www.cs.man.ac.uk/~horrocks/Publications/download/2003/LAHS03a.pdf
>
>>
>>  Cheers, Bob

-- 
Professor James Hendler				  hendler@cs.umd.edu
Director, Semantic Web and Agent Technologies	  301-405-2696
Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
Univ of Maryland, College Park, MD 20742	  240-731-3822 (Cell)
http://www.cs.umd.edu/users/hendler

Received on Wednesday, 7 May 2003 11:09:37 UTC