- From: Deborah McGuinness <dlm@KSL.Stanford.EDU>
- Date: Wed, 01 May 2002 18:55:04 -0700
- To: Ian Horrocks <horrocks@cs.man.ac.uk>
- CC: Enrico Motta <e.motta@open.ac.uk>, www-webont-wg@w3.org
I need to disagree with Ian when he says that when describing a class in terms of their properites, existential quantification is what is meant. I do not disagree that people many times need min cardinality 1 as well as universally quantified local ranges but I disagree that they usually want to say the equivalent of some instead of the equivalent of all. I have done a number of applications where I heavily used universally qualified local ranges for consistency checking, configuration, and commerce. I depended on the use of the universal so that I could catch contradictions. My roles had multiple values so I could not use the functional property to imply an universal. Deborah Ian Horrocks wrote: > On May 1, Enrico Motta writes: > > At 5:34 pm -0700 28/4/02, Deborah McGuinness wrote: > > > > > > > Can't one define existentially qualified range restrictions by having > > >> local ranges + min-cardinality? Or are they something else? > > > > > >with universally qualified range restrictions one can say things > > >such as "all my > > >children are doctors" > > >and with min cardinality one can say things such as "i have at > > >least one child" > > >but in combination that only allows one to say I have at least one child and > > >ALL my children are doctors. > > >This DOES imply that I have at least one child who is a doctor. > > >BUT it does not allow you to state the full generality of > > >existentially qualified > > >range restrictions - for example there is no conceptually good way > > >way to state > > >(or imply) with just min cardinality and local ranges for example that I also > > >have at least one child who is a lawyer after I have stated the previous > > >information about my children being doctors. > > > > > > An alternative could be to simply define two slots: > > children-who-are-lawyers and children-who-are-doctors and make them > > sub-properties of children. Local range restrictions in conjunction > > with min-cardinality would then make it possible to express your > > example, I think. It is not incredibly elegant but that's life in > > limited expressivity KR! And moreover, if distinguishing the types > > of children is important for an application, maybe splitting the > > slots would not be such a bizarre modelling decision. At the same > > time I suspect that the opposite is not true. If I don't have > > universally quantified local range restrictions, I would not know how > > 'to fake' them using existentially quantified local restrictions. > > > > Correct? > > Not entirely. As I pointed out before, if you have existentials > (hasClass) and functional properties, then by stating the existence of > a property using a hasClass restriction, e.g., stating that all > HeavyObjects have a weight that is of type Heavy, then if weight is a > functional property there is an implicit "universal" - all the weights > of a HeavyObject must be heavy. This is a very common idiom, and one > that can't be expressed without existential quantification (hasClass). > > I strongly maintain that when describing objects in terms of their > properties, existential quantification is what is usually > intended. E.g., when describing a pentium-PC I want to say that it is > a PC that has a processor which is a pentium (if I use toClass I don't > say anything about whether it has a processor or not, with the result > that a computer with no processor turns out to be a member of the > class). Similarly, when describing a web page about football I want to > say that it is a web page that has a subject and that that subject is > football. If I make processor/subject functional, then I get the > additional inference that all processors/subjects are > pentiums/football (if I want to get fancy I can introduce > uniqueProcessor and uniqueSubject as subProperties of processor and > subject). > > The prevalence of existential properties is even more striking when > using datatypes and nominals (singleton enumerated classes). Take a > look at daml+oil-ex.daml and you will see that all the classes > described using datatypes and enumerated classes employ hasClass > restrictions. E.g., Senior is described as a person whose age is over > 60, and a TallThing is described as a person whose height is > tall. > > I would suggest that where universal quantification is being widely > used in practice, it is either as a result of its being the only > available option and/or the fact that many users assume an implicit > existential - it never occurs to them that people all of whose > children are doctors may not have any children at all (I would hardly > bother telling you what type their children must be if they don't have > any children, would I?). > > Regards, Ian > > > > > Enrico > > > > > > > >If one has disjunction in the language, I could make a disjunctive class of > > >Doctor OR Lawyer and then state that all my children are instances > > >of this class > > >and then state that I have at least 2 children, but I would not be > > >stating that > > >one child is a doctor and one is a lawyer. > > >Even without disjunction, I could state that Doctor and Lawyer are both > > >subclasses of the class DoctorOrLawyer thereby effectively getting > > >the notion of > > >disjunction. > > >If we have disjointness or negation, I can also state that the > > >classes Doctor and > > >Lawyer are disjoint. > > >With negation, I can also state that a particular child is an instance of the > > >class Not Doctor... > > >All this is showing ways of getting some of the information but > > >not getting the > > >full notion of existentially qualified range restrictions. > > > > > >> > > > >> >to address mikes suggestion of dropping local ranges from level 2 if they > > >> >are not in level 1, i would vote strongly against this. > > >> >Local ranges are one of the most heavily used features in the work that I > > >> >have done on ecommerce and I would not be as vocal a supporter of > > >> >daml+oil/owl/fowl for web applications if we were not to include this in at > > >> >the worst level 2. > > >> > > >> I also think that they are so used that they shoudl be in level 1 > > >> > > >> > > > >> >on cardinalities, while i am a strong supporter of their use in > > >>applications > > >> >and while I also wanted to get this in level 1, in the effort to gain some > > >> >agreement, and since we do allow functional roles (thereby allowing [0,1] > > >> >roles), I am willing to have functionality in level 1 while expecting that > > >> >many tool developers will market: > > >> > > > >> >level1 support > > >> >level1 support + things of use to their clients. My expection is that > > >> >cardinalities will be something added by most tool developers. > > >> > > >> The main purpose of level 1 is to provide a simplified language for > > >> tool developers. So, if we expect them to put cardinality in, why not > > >> adding it ourselves? > > >> > > > > > >We will not be expecting all tool developers to support cardinality > > >- just those > > >that are interested in marketing to segments that find them critical. In my > > >opinion, this will be many but not all tool developers. The reason I do not > > >expect all tool developers to support this (in all of their > > >deployments) is that > > >one can gain some efficiencies by making limitations to the language and some > > >communities will be more interested in the efficiencies than in a > > >more expressive > > >language. > > > > > >Our small group strategy was to > > >1 - come up with an agreement on a small language that hopefully many tool > > >developers will support > > >2 - attempt to get the most useful features in this small language > > >3 - keep the small language small - thus we explicitly were not taking the > > >strategy of including everyone's favorite constructor for which they > > >could make a > > >compelling argument. > > >4 - not penalize too heaviliy tool developers who want to add > > >construct XX to the > > >core language. > > > > > >3 & 4 were the hardest to maintain however we all believed them to > > >be important. > > >for example if we put in existentially qualified range restrictions > > >in the core > > >language, we penalize tool developers who need universally qualified range > > >restrictions but could live without existentially qualified range > > >restrictions. > > >And conversely, if we put in universally qualified range > > >restrictions in the core > > >language, then we penalize tool developers who need existentially > > >qualified range > > >restrictions but could live without universally qualified range restrictions. > > > > > >I agree with Ian's statements that some communities can not live without > > >existentially qualified range restrictions. Just as one data point, I was the > > >main liaison for CLASSIC - a limited expressive power DL - for over > > >a decade. I > > >always asked users what they needed from CLASSIC and existentially qualified > > >range restriction was the only language constructor that was not in > > >CLASSIC that > > >we got consistent requests for. (CLASSIC did have universally qualified local > > >range restrictions so I do not have data about the reverse situation.) > > > > > >> > > >> Enrico > > >> > > >> > > > >> >deborah > > >> > > > >> >Guus Schreiber wrote: > > >> > > > >> >> I strongly support Mike Dean's remarks on local domain/range constraints > > >> >> and cardinality. Both are so commonly used in ER and O-O data models > > >> >> that it would be very weird if OWL would not support that at Level 1. > > >> >> > > >> >> I should add that "ease/frequency of use" is for me the prime criterion > > >> >> for putting a language feature in Level 1, and not whether the feature > > >> >> is difficult to implement in a DL reasoner (not saying this is the > > >> >> case). > > >> >> > > >> >> Guus > > >> >> > > >> >> -- > > >> >> A. Th. Schreiber, SWI, University of Amsterdam, Roetersstraat 15 > > >> >> NL-1018 WB Amsterdam, The Netherlands, Tel: +31 20 525 6793 > > >> >> Fax: +31 20 525 6896; E-mail: schreiber@swi.psy.uva.nl > > >> >> WWW: http://www.swi.psy.uva.nl/usr/Schreiber/home.html > > >> > > > >> >-- > > >> > Deborah L. McGuinness > > >> > Knowledge Systems Laboratory > > >> > Gates Computer Science Building, 2A Room 241 > > >> > Stanford University, Stanford, CA 94305-9020 > > >> > email: dlm@ksl.stanford.edu > > >> > URL: http://ksl.stanford.edu/people/dlm > > >> > (voice) 650 723 9770 (stanford fax) 650 725 5850 (computer fax) 801 > > >> >705 0941 > > > > > >-- > > > Deborah L. McGuinness > > > Knowledge Systems Laboratory > > > Gates Computer Science Building, 2A Room 241 > > > Stanford University, Stanford, CA 94305-9020 > > > email: dlm@ksl.stanford.edu > > > URL: http://ksl.stanford.edu/people/dlm > > > (voice) 650 723 9770 (stanford fax) 650 725 5850 (computer fax) 801 705 > > >0941 > > > > > > -- > > Enrico Motta, PhD > > Director, Knowledge Media Institute > > The Open University > > Walton Hall > > Milton Keynes, MK7 6AA > > United Kingdom > > > > URL: http://kmi.open.ac.uk/people/motta > > Tel: +44 1908 653506 > > Fax: +44 1908 653169 -- Deborah L. McGuinness Knowledge Systems Laboratory Gates Computer Science Building, 2A Room 241 Stanford University, Stanford, CA 94305-9020 email: dlm@ksl.stanford.edu URL: http://ksl.stanford.edu/people/dlm (voice) 650 723 9770 (stanford fax) 650 725 5850 (computer fax) 801 705 0941
Received on Wednesday, 1 May 2002 21:55:53 UTC