Re: LANG: compliance levels

comments in line below.

Enrico Motta wrote:

> At 5:09 pm -0700 27/4/02, Deborah McGuinness wrote:
> >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.
>
> 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.

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

Received on Sunday, 28 April 2002 20:34:54 UTC