Re: LANG: compliance levels (VOTE on local range restrictions)

I think Enrico makes a good suggestion of polling concerning local range
restrictions.

I am willing to collect votes in advance of tomorrow's meeting for any who will not
be on the telecon (as well as those who want to reply while they are thinking about
it).

The choices are (for Level 1 compliance)
1 - no kind of local range restriction.
    the rationale for voting for this is because choosing 2 or 3 below makes adding
the other one hard and it is not clear which is most useful.  Putting both in is
harder to implement for tool developers.  I had more to say on this in [1] and the
embedded message and so did Frank in [2].

2 - Universally qualified local range restrictions.  (this allows me to say that
all my children are doctors).  This alone is not hard to explain or implement but
makes adding 3 harder to implement.
Ian has more to say on this in [3] and I have more to say on this in [1] (to which
ian responded with [3]).

3 - Existentially qualified local range restrictions.  (this allows me to say that
some of my children are doctors).   This alone is not hard to explain or implement
but makes adding 2 harder to implement.  More details in [1, 2, 3]

4 - both universally qualified and existentially qualified local range
restrictions.  (this allows me to say that all my children are persons and I have
some child who is a doctor and some child who is a lawyer).    This is harder to
implement and thus could mean some tool developers will not do it.

[1] http://lists.w3.org/Archives/Public/www-webont-wg/2002Apr/0351.html
[2] http://lists.w3.org/Archives/Public/www-webont-wg/2002Apr/0380.html
[3] http://lists.w3.org/Archives/Public/www-webont-wg/2002Apr/0357.html

deborah

Enrico Motta wrote:

> 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.
> >
> >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.
>
> OK, got it!
>
> >
> >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 see your point but I am still not 100% convinced. It is a tricky
> one because we are heavily relying on our subjective impressions of
> what users want.  And I am worried that if OWL level 1 is only a
> small improvement over rdfs, then it loses its raison d'etre.  The
> counter-argument is that tool developers will then add the
> functionalities they consider important.  But even this is not
> totally convincing, because they won't necessarily be in a better
> position than us to make a decision and I guess many (most?) tool
> developers  expect us to make such  a decision. So, on balance I
> would still say that  not to have any kind of local range restriction
> is probably the worst decision and if we have to choose my feeling
> remains that universal local restrictions are probably what people
> are used to.  But this is only a 'feeling' and it may be useful to
> poll the members of this wg to get additional data.
>
> In any case, we are definitely moving in the right search
> neighbourood, which is a major improvement!
>
> Enrico
>
> --
> 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 15:36:00 UTC