Re: LANG: compliance levels

Ian Horrocks wrote:

> On May 1, Deborah McGuinness writes:
> > 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.
>
> Of course min cardinality 1 is equivalent to (a restricted form of) an
> exists restriction: (minCardinality 1 P) is equivalent to
> (hasClass P thing).

agreed of course   but when we look at conceptual modeling issues,
I claim that it is more natural for people who want to say that I have at least 1 P is to
say it with a mincardinality statement instead of saying that there exists a filler for the
P role that is of type thing.

If we ended up with only existential restrictions, this "trick" would end up going in our
tricks of the trade section.

> > 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.
>
> Even with the addition of universally qualified local ranges, the
> level 1 language we have been discussing would be of limited use for
> consistency checking and catching contradictions because it cannot
> express negation or disjointness of classes. So, if you state that all
> the children of a person must be persons, and I find a person with a
> child of type plant, then I don't get a contradiction, I just get the
> inference that the child in question is both a person and a plant (I
> can't express that plants and persons are disjoint). The exception to
> this is datatypes, where there may be some "built in" assumptions
> about disjointness. In my experience, however, datatype properties
> (e.g., age, height, weight) are almost always functional, so this can
> often be handled equally well using existential restrictions and
> functional (unique) properties.
>

I agree of course that one gets more usefulness out of universals when there are more ways
to generate disjointness.  Even in the limited level 1 we are discussing however, one can
still get disjointness - there are the concrete domains vs. the rest of the terms - this is
something that I ended up using a lot in many of the configuration applications.  If I find
that something that is a person is filling an age slot where age is a number, then I have a
contradiction.
we can also get disjointness because we allow people to state functional roles and also
multivalued roles thereby generating disjointness.  If we end up adding any kind of closed
world assumption (which it seemed we were going to do), then of course you end up with lots
of disjointness that can be exploited.

>
> I am not saying there are NO cases where universal restrictions are
> useful. I am simply saying that the utility of local ranges is
> relatively limited. In contrast, the use of existential restrictions
> is pervasive. I can point you to a number of large medical ontologies
> using existential restrictions (e.g., Galen, UMLS, Snomed), and many
> other similar examples such as product catalogues. As an example of
> the latter take a look at the tower records DVD catalogue [1]. This
> categorises DVDs by genre, price etc. It seems pretty obvious that an
> action DVD is a DVD where there exists a genre that is action.
>
> [1] http://tower.endeca.com/tower

I also am not saying that you can not point out examples of existential usage.
I am just saying that there are many examples where universal local ranges are used quite
effectively in practice.
The Lucent/AT&T configurator family of PROSE/QUESTAR is one good example as is the simple
stereo configurator we did for a more approachable domain.


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

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