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

ok - i was just trying to save traffic but it is fine to cast your inclination to the
group.
Ian is right  I should not have used the word vote  and kept the word poll that enrico
used.

deborah

Ian Horrocks wrote:

> Hang on a minute! What is this about a vote? I think we have to be
> very careful with the use of that word!
>
> If this is really intended to be a vote, then I would have to protest
> very strongly on the grounds that the "ballot paper" is rigged, that
> members of the WG have not been given adequate time to consider and/or
> respond to the ongoing discussion, and that I would be very surprised
> if collecting votes off-line were to be considered a legitimate
> procedure.
>
> Regards, Ian
>
> On May 1, Deborah McGuinness writes:
> > 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
> >
> >

--
 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 21:38:32 UTC