Re: Comment on non-global keys

Jim,

Good point! Turns out that I messed up my formulation of
inverseFunctional/keys, that what is really required in order to
express that property P is a key for class C is a QCR, and so we can't
capture it in OWL. What I *should* have said is that to "localise"
inverse functionality to a class C requires a qualification to C of
the maxCardinality restriction on the inverse property, e.g.,
(inventing syntax as I go) asserting that Thing is a subclass of
restriction(inv-F maxCardinalityQ(1 C)). 

I have appended a modified response proposal.

Thanks again to Jim for spotting the inconsistency in my argument(s).

Ian

-----------------------------------------------------

Bob,

Thanks for your comments. I have tried to address them below.


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.

As you know, 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 (see [1]). To "localise" the inverse functionality to a
class C, and thus to provide a form of localised keys, would require
the use of a qualified cardinality restriction on inv-F, with class C
as the qualifier. This cannot be expressed in OWL as the language does
not include qualified cardinality restrictions (QCRs). The issue of
whether QCRs should be added is currently under discussion - see [2].
Of course all these forms (including the use of
InverseFunctionalProperty) would be 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'.
>
>  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'.
>
>  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 you mention above, global key constraints can already be captured
in OWL Full. If QCRs are added to the language, this would provide the
ability to express (in OWL Full) localised key constraints. Adding
support for compound keys would represent a significant extension to
the language and may be outside the scope of the Working Group
charter (see [3]).

As far as adding syntax for key declarations is concerned, the working
group has striven to avoid too much syntax "bloat" in OWL by limiting
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 (see, e.g., [4]).

Regards, Ian

[1] http://www.w3.org/TR/owl-ref/#InverseFunctionalProperty-def
[2] http://lists.w3.org/Archives/Public/www-webont-wg/2003May/0072.html
[3] http://www.w3.org/TR/webont-req/
[4] http://www.w3.org/2001/sw/WebOnt/webont-issues.html#I5.16-Feature-decision-for-CL1-cardinality

>
>  Cheers, Bob






On May 7, Jim Hendler writes:
> 
> 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 18:38:25 UTC