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

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
> 
>

Received on Wednesday, 1 May 2002 19:06:16 UTC