Re: LANG: compliance levels

I agree with most/all of what Deb says. I would just like to emphasise
that I believe that existential restriction (hasClass) is really what
users need to express in many applications, not just in medicine. For
example, when describing physical objects in general, it seems natural
to state that they have certain characteristics or are made up of
certain components: a Computer's components might be said include
keyboard, screen, cpu etc. These are obviously existential
restrictions: there exists some part/component that hasClass Keyboard,
Screen, Cpu etc.

Universal (toClass) restrictions are often more difficult to
use/understand as they have the "strange" characteristic that they are
satisfied in the case where the property in question provably does not
exist. Moreover, hasClass + singleValued property leads to an implicit
toClass constraint (e.g., if I have an age that is an integer and I
have at most 1 age, then all my ages are integers), which is a very
common idiom; this cannot be expressed using only toClass constraints
as the singleValuedness of a property is equivalent to a maximum
cardinality restriction, and does not imply existence (e.g., if all my
ages are integers and I have at most 1 age, then there is nothing to
say that I have any age at all).

I am, however, prepared to believe that toClass restrictions are all
that is required in many applications. The two types of restriction
thus exemplify the problem I pointed out in my earlier email: that it
is difficult/impossible to find a total ordering on OWL constructs
that makes sense in all applications. The solution being suggested by
the current proposal is to make OWL level 1 compliance easy to achieve
and leave it to "the market" to determine which extra features tool
developers will need to provide in order to meet the requirements of
various application domains. The alternative seems to be to define a
partially ordered hierarchy of OWL compliance levels, and this does
not look like a very attractive solution!

Regards, Ian


On April 27, Deborah McGuinness writes:
> I also strongly supported local ranges in our discussion at KR.  (this was
> also my first comment on the earlier proposal for rdf on steroids that
> without local ranges I could not support the constituencies I talk to most
> often).  Frank also strongly supported it - he and I seem to speak to people
> with similar needs.
> 
> My claim is that this is imperative to usefulness for most e-commerce
> applications and most verification applications.  To be precise, I was
> arguing for universal restrictions on local ranges.
> Thus, in to meet Guus' point below, i claim it is imperative for ease of use
> for those communities.
> 
> However, I stopped arguing my point when Ian made a point that his
> communities require existentially qualified range restrictions.  He claims
> that it is imperative to his large medical users.
> All of us agreed that it was not a good thing to have both in the level one
> and thus in order to get some agreement, both sides compromised by not
> putting either in level 1.
> This is what I thought was the largest concession from what I was looking
> for in my optimal level 1.
> 
> 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.
> 
> 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.
> 
> 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
>

Received on Sunday, 28 April 2002 16:03:02 UTC