- From: Christopher Welty <welty@us.ibm.com>
- Date: Thu, 8 Aug 2002 11:46:49 -0400
- To: Dan Connolly <connolly@w3.org>
- Cc: www-webont-wg@w3.org
Dan, et al, You said from this: my:KeyProperty rdfs:subClassOf owl:FunctionalProperty. db:key rdfs:range db:KeyProperty. fred:Order db:key fred:customer. It should follow that: FunctionalProperty(fred:customer) This example is so confusing, you couldn't have picked a better way to show that there are huge misconceptions going on here. We really need a semantics. There are a number of problems with this example: - You are using db:key but you are not getting a database key - Clearly an order shouldn't have customer as a database key - You have exposed *exactly* the kind of incompleteness that making the language too expressive introduces. The real source of the confusion is the symbols you have chosen and what they mean outside of this example. key, order, and customer all have real-world meanings, and here you are giving them a semantics that is not consistent with that real-world meaning. Even if there was a reasoner which could conclude this (which there never will be), if your goal from this example is simply to conclude FunctionalProperty(fred:customer), all you are saying is that an order has only one customer. You are NOT saying that it is a "key" in the database sense. As I have said in the description of the functionalProperty feature, functionalProperty is weaker (less constrained) than the notion of a database key. In the database sense of "key", it is a 1:1 relationship which, *for a specific table* uniquely identifies a row in the table, however the "same" "property" could be used in another table and not be a key. Since owl:functionalProperty is a global restriction, concluding FunctionalProperty(fred:customer) would mean that anywhwere fred:customer is used, it is functional, even if it is used in instances of other classes than fred:Order. What you want is some sort of local restriction on fred:Order for the fred:customer relation, and a restriction on the inverse of fred:customer that it can have only one fred:Order. Dr. Christopher A. Welty, Knowledge Structures Group IBM Watson Research Center, 19 Skyline Dr. Hawthorne, NY 10532 USA Voice: +1 914.784.7055, IBM T/L: 863.7055 Fax: +1 914.784.6078, Email: welty@us.ibm.com Dan Connolly <connolly@w3.org> Sent by: www-webont-wg-request@w3.org 08/02/2002 06:17 PM To: Jonathan Borden <jonathan@openhealth.org> cc: www-webont-wg@w3.org Subject: Re: SEM/GUIDE: subclasses of classes of Properties? (5.3) On Fri, 2002-08-02 at 07:23, Jonathan Borden wrote: > Dan Connolly wrote: > > > > > Sorry, that example didn't make the point... > > To clarify, we want to be able to make the sorts of conclusions: > > email:cust24 owl:sameIndividualAs phone:cust34. > > given, > FunctionalProperty(fred:customer) > and > fred:order24 fred:customer email:cust24. > fred:order24 fred:customer phone:cust34 . We want that, but that's not the point I'm making. The point I making is that I (we?) also want to conclude FunctionalProperty(fred:customer) from my:KeyProperty rdfs:subClassOf owl:FunctionalProperty. db:key rdfs:range db:KeyProperty. fred:Order db:key fred:customer. > wouldn't something like this be the case under _any_ implementation of > FunctionalProperty? > > (I am assuming that owl:sameIndividualAs is our term for '=') -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ see you in Montreal in August at Extreme Markup 2002?
Received on Thursday, 8 August 2002 11:47:43 UTC