SEM: Reaching consensus (was Re: SEM: "natural" entailments)

[snipping all the threads]

WOWG:

Usually when I try to play peace maker I either get beat up or 
ignored, but it is my job as chair to "facilitate reaching consensus" 
(quote from Guide) so let me try this:

RULING:
   I'm going to rule the generic discussion of DLs v. Logic out of 
scope (this is my right as chair - see the process document: 
http://www.w3.org/Guide/chair-roles.html) - www-rdf-logic is a 
wonderful place to have that discussion, but not here.

CLARIFICATION ON RULING:
  However, what is very much in scope is the discussion of the 
properties we need for our language and how to achieve them.  Peter 
and Ian have consistently (and  convincingly )argued that the 
features of soundness, completeness, decidability and/or lowest 
possible computation class are important, and we achieved consensus a 
long time ago that these are desirable properties.  THis is 
succinctly reflected in our requirements document [1] as the 
Objective O6

>O6. Effective decision procedure
>
>     The language should be decidable.
>
>     Motivation: Balance of expressivity and scalability

This document was written with a lot of discussion and reflects group 
consensus.
  If we can reach this objective using DLs, and not lose on our 
requirements, then we have good consensus to go ahead, as well as 
having DAML+OIL precedent for this.

  However, please note that the above is an Objective - we did not get 
consensus from the group that we HAVE to have a decidable langauge. 
There are many known KR frameworks that can be implemented just fine, 
have a rigorous semantics, and work well in practice -- but they 
sacrifice usually decidability and always theoretical complexity. 
One way we could achieve our REQUIREMENTS is to chuck the above 
objective completely, and use one of these other frameworks - I do 
not advocate this - but I point it out because there are other 
frameworks out there we could have chosen - the arguments for the DL 
approach shouldn't be made on "aesthetics" or history, but on the fit 
to our needs.  We are not wedded to this approach, but we should 
probably depart from it only with careful consideration of the 
consequences (while still achieving our requirements).

REMINDER: CONSENSUS ISSUES:

So, I can find no group consensus anywhere in our records to use DLs, 
but also no consensus not to - and our WG history seems to bear out 
the idea of trying to stay close to this known class, but knowing we 
may need to go outside this class at some point if those who defend 
the class cannot find appropriate mechanisms for the things we 
identified as requirements.

  I find it very instructive to read our requirements document from 
time to time and see what we have and have not achieved - we're doing 
relatively well, but still have some gaps - I urge you all to do the 
same.  Remember that this document reflects a group consensus we took 
a long time to establish, and that it has been externally reviewed 
favorably - we should probably depart from it only with careful 
consideration of the consequences

BOTTOM LINE:

We have to either find consensus, or come out with competing 
proposals that could be put to a binding vote with those who "lose" 
being allowed to write dissenting opinions -- I strongly hope we can 
find the consensus, but it means we all must accept some things we 
can LIVE WITH even if we don't actually like them much. A consensus 
document will result in a language likely to be widely used and much 
more able to pass AC muster -- a divided opinion with dissents is 
more likely to block adaptation (as some developers will worry about 
the stability of the language) and it will provide anyone in the AC 
who doesn't like our language with a strong argument against 
acceptance.

  Our job as a committee is to find the right place in the tradeoff 
space between our requirements and objectives, and to consider the 
usability of our final language.  The MT is a means, not an END.  It 
is the way we will write down the semantics of the language we decide 
we want -- one of the desirable features of the approach we've been 
exploring the past few weeks, talking as chair, is that it has let us 
find a framework where the group could decide issues like classes as 
instances (a requirement) or desirable implementation needs for our 
use cases (Dan's inverseFunctionalProperty needs on dataTypeProperty) 
and then to "implement" those decisions within the theoretical 
framework - I hope we can continue to find a means forward that helps 
achieve this.

  I find it very instructive to read our requirements document from 
time to time and see what we have and have not reached.  Remember 
that this document reflects a group consensus we took a long time to 
establish, and that it has been externally reviewed favorably.

  -JH



[1] http://www.w3.org/TR/webont-req/
-- 
Professor James Hendler				  hendler@cs.umd.edu
Director, Semantic Web and Agent Technologies	  301-405-2696
Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
Univ of Maryland, College Park, MD 20742	  240-731-3822 (Cell)
http://www.cs.umd.edu/users/hendler

Received on Tuesday, 24 September 2002 20:28:17 UTC