Re: SUO: Re: Ballot Comment
John,
I agree with the points you are making but am surprised at the
conclusions you seem to draw from them. The point of creating SUMO and
putting it to a vote is exactly to have our SUO "committee" critique an
existing design rather than start with a blank sheet of paper. Some folks
(including you I think, at a different time) have suggested that we start
with a blank sheet of paper and look at "fundamental ontological
distinctions". Your sentence about harsh criticism is particular apt in
our current case.
As for implementation and testing I think as I've mentioned in a
previous reply to you that we're fairly far along. Not only do we have
SUMO "implemented" in a browser, but it's also being used in an Open Group
effort to develop an open source ontology for representing "Quality of
Service". People are already downloading that ontology.
Adam
At 08:55 AM 8/16/2001 -0400, John F. Sowa wrote:
>Matthew makes a very important point:
>
>MW> There are different opinions about how to do standardisation. Some
> > are happy to declare a standardisation effort starting with a blank
> > piece of paper and a title. Others think that work should reach
> > a relatively mature level before being submitted to a more formal
> > standardisation process. I have participated in both approaches.
> > You may guess which I prefer.
>
>I have also participated in ANSI and ISO standards activities for
>the past 10 years. Before that I participated in various IBM
>development projects, many of which had a similar loose organization
>of committees representing multiple divisions that were supposed to
>reach a consensus on a common internal IBM standard.
>
>The two greatest fiascos, one ISO and one IBM, were projects that
>started with a blank sheet of paper. (The IBM one was a greater
>fiasco, primarily because it was better funded.) The most successful
>projects were ones that started with a well-defined specification
>that had already been implemented and tested in an earlier, much
>smaller project.
>
>Committees are horrible at doing fundamental design, but they are
>very good at criticizing an already existing design. (Sometimes
>the criticism can be so harsh that they kill the project.) But
>when the project is already fairly robust and the participants
>in the committee really want to make it better, their criticisms
>can be extremely valuable in filling gaps that the original
>developers had overlooked.
>
>Bottom line: We need some well developed proposals that have been
>implemented and tested, at least at a prototype level, before we
>can get into committee-design mode.
>
>John Sowa
Adam Pease
Teknowledge
(650) 424-0500 x571