Re: LANG: compliance levels

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