Re: Comment on non-global keys

Thanks, Ian.

I basically agree with your proposed response.
Two small points  in-line.

Guus


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. 

This argument woukld also rule out "InverseFunctionalProperty", which is 
also dedicated syntax, as you correctly explained. We should present it 
as a trade-off between useful synyactic sugar and too much "bloat". I 
propose:

   In an effort to avoid too much syntax "bloat" in OWL, the working
   group haas strived to limit the amount of 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 

insert here: therefore

> 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

-- 
NOTE: new affiliation per April 1, 2003

Free University Amsterdam, Computer Science
De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands
Tel: +31 20 444 7739/7718
E-mail: schreiber@cs.vu.nl
Home page: http://www.cs.vu.nl/~guus/ [under construction]

Received on Wednesday, 7 May 2003 08:32:03 UTC