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