Re: Proposed Solution: Non-global Keys

On Mon, 2003-06-16 at 21:12, Jim Hendler wrote:
> Here is my proposed response on this issue.  I suspect that Dan had
> something else in mind,

Yes... what was that... ah, good; the 8 May minutes capture it:

"Dan - three issues:
    1 has exactly one - asked and answered,
    2 Qualified cardinality,
    3 compound keys not yet covered by an issue"

My first point was that I thought his hasSSN example
was something we can currently express, and the only
difference was syntactic sugar like "hasExactlyOne";
but I see from Ian's message[2] that this isn't so.

You've addressed the 2nd point, but I don't
see anything in your response about compound keys.

His comment about compound keys...

> >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.

is essentially a request to add compound keys to
our requirements. The closest thing is "complex datatypes";
quite a stretch... hmm... we called them "records (complex datatypes)"
in the Jan 2002 ftf.

The 8 May minutes say "Hard to add compound without adding syntax.  
Should not come up in next agenda"; I guess I can look at that
as the chair saying that MacGregor's comment doesn't have
sufficient new information that we should re-open our decision
not to have such a requirement. Now... when did we make
that decision?

The decision to take requiremnts to last call is sort of
an implicit decision not to have such a requirement
http://www.w3.org/2001/sw/WebOnt/ftf5.html#Closure

In sum, I suppose the rationale for not having compound
keys is "we can do a bunch of interesting stuff without
them."

I think it would be much more responsive if we elaborated
the stuff in/near "complex datatypes" in the requirements
document to explicitly discuss modelling records and keys and
the tradeoffs. Jeff, do you feel inspired to take
MacGregor's comment and Ian's discussion[2] and add a paragraph
or two to the requirements document?


>  but the below seems to address the comment -- If anyone has anything
> more contentive to add, I'd welcome it

I'd suggest rather the rationale for postponing QCRs were
given by copy as well as by reference, but that's not critical.



>  -JH
> 
> --------------
> 
> Dear Bob-
>  Thank you for your comment, the working group has considered it
> carefully.  We considered how this could be added to OWL - see the
> discussion thread starting at [1] and particularly [2].  The group
> considered the addition of Qualified Cardinality Restrictions, which
> we believe are needed to implement the sort of global keys you need. 
> However, the WG decided to postpone the issue of QCRs as discussed in
> my response to Alan Rector at [3].
> 
> Please let us know if this decision to (a) acknowledge that our
> design is lacking, but (b) postpone further design work to a future
> version is acceptable.
>    -Jim Hendler
> 
> 
> [1]
> http://lists.w3.org/Archives/Public/www-webont-wg/2003May/0064.html
> [2]
> http://lists.w3.org/Archives/Public/www-webont-wg/2003May/0085.html
> [3]
> http://lists.w3.org/Archives/Public/public-webont-comments/2003Jun/0024.html
> 
> 
> 
> 
> 
> >Date: Tue, 06 May 2003 14:22:16 -0700
> >To: public-webont-comments@w3.org
> >From: Bob MacGregor <macgregor@ISI.EDU>
> >Subject: Non-global Keys
> >X-Archived-At:
> http://www.w3.org/mid/5.1.1.6.0.20030506142115.00bb75c0@tnt.isi.edu
> 
> >
> >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.
> >
> >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.
> >
> >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-277-3388 (Cell)
> http://www.cs.umd.edu/users/hendler      *** NOTE CHANGED CELL NUMBER
> ***
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Thursday, 19 June 2003 10:02:03 UTC