Re: Comment on non-global keys

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

Received on Wednesday, 7 May 2003 04:41:44 UTC