The problem with letting the "market" determine standards is that there has
to be an effective "market", with multiple candidates, and multiple users,
for it to work. In the case of a foundation ontology, there have been
publicly available candidates for over 6 years, but as yet there are few
users (applications, anyone?) and nothing remotely resembling a "market" has
developed. This should give us a clue that we are dealing with a technology
that is not simplistically analogous to the ones we are accustomed to. On
reflection this should not be terribly surprising- a proper foundation
ontology will have the content and expressive power of a human language, and
nothing like it has been actually developed **and widely used** up to now
(WordNet is not an ontology in that sense). (01)
I suggest that, in dealing with a truly powerful and potentially
revolutionary technology that is aimed at supporting the replication of the
thinking function of humans, we keep an open mind about what approaches are
likely to work. Sure, past experience must be consulted, but when new
technologies are being developed, over-rigid analogies with previous
experience may well be more misleading than helpful. I respectfully suggest
that prior work on information standards is just not relevant to this issue. (02)
I might also suggest that the current economic situation might give one
pause in relying exclusively on the "market" to solve issues. (03)
Pat (04)
Patrick Cassidy
MICRA, Inc.
908-561-3416
cell: 908-565-4053
cassidy@xxxxxxxxx (05)
> -----Original Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-
> bounces@xxxxxxxxxxxxxxxx] On Behalf Of Ed Barkmeyer
> Sent: Tuesday, January 06, 2009 11:44 AM
> To: [ontolog-forum]
> Subject: Re: [ontolog-forum] Next steps in using ontologies as
> standards
>
> John F. Sowa wrote:
>
> > The standards that have proved to be the most valuable in practice
> > have been based on successful technologies that many independent
> > groups have adopted, used, developed, and extended on major
> > applications. In most cases, those standards started with a
> > successful implementation (e.g., SQL or HTML), polished up the
> > rough edges, made it more systematic, and added new features.
> >
> > About 20 years ago, some people working on standards got the idea
> > that it would be good for the standards organizations to take a
> > "proactive" stance in developing and promoting cleaner, more
> > elegant systems that take advantage of the latest theories and
> > practices. But the results have been decidedly "mixed".
> >
> > I once thought that "proactive standards" seemed promising,
> > but after observing many attempts, I have very serious doubts.
>
> I fully agree with this.
>
> I would also point out that there are situations in which several
> software tools have been on the market, all performing essentially the
> same function and all having incompatible representations of the
> information they capture and produce. A variant situation is the
> existence of a common established practice, with emerging software
> tools
> to support it. In such situations, getting the implementors to agree on
> a common exchange form can produce a valuable standard (some CAD
> standards, some HL7 standards and some HR-XML standards leap to mind).
> To avoid giving anyone an advantage, the standard will match none of
> the
> existing forms. Some such standards have been very successful -- those
> that get "critical mass" among the major players. But they are not
> "proactive" in the sense that John means. The functions and concepts
> they need to support are mostly well understood and well tested; the
> primary concern is only to agree on a representation.
>
> The truly "proactive standards" are based on only preliminary analysis
> of the problem space. Their first concern is to identify the functions
> and concepts that will need to be supported, based on little experience.
> And many of these efforts begin by assuming that the needed functions
> and concepts are well-understood and the only issue is to agree on
> representation, and founder on the discovery that the primary players
> well understand very different requirements or very different
> approaches
> to solution.
>
> > Among the problems with proactive standards is that they are
> > inevitably designed by committees. The basic strength *and*
> > weakness of a committee is the diversity of people with
> > different backgrounds, views, and requirements. That gives
> > them great strength in *evaluating* proposals from many
> > different points of view. But it also means that committees
> > inevitably have "too many cooks" who "spoil the broth" when
> > they try to do the design.
>
> I agree that this is common and the results are almost always shelfware.
>
> At the same time, there are examples in which a cohesive leadership
> team
> of a few largely like-minded individuals, coupled with some external
> pressure, can result in an effective standard. But the leadership team
> consciously suppresses the noisy committee members and effectively
> shuts
> them up or drives them out. OWL and BPMN are the obvious examples.
>
> Unfortunately, there are also many such examples in which the effective
> leadership team doesn't have a significant share of the market (or the
> practicing hearts and minds). They get their standard, but it is
> shelfware that is snubbed by the leading vendors and practitioners.
>
> > I don't believe that any proposed system should be adopted as
> > a standard until *after* there has been a considerable amount
> > of experience in using and testing it on a wide range of
> > practical applications. Instead of "deliberate planning",
> > we need extensive testing, comparison, and evaluation of
> > proposed alternatives on major applications.
>
> Well, there is a tradeoff here too. Once there is a set of software or
> hardware products in the field, even if it is open source, there is a
> sunk investment cost. And choosing a standard direction that will lose
> most of that investment for some body of investors will create discord.
> If one or more of them has a significant market share, there will be
> a
> viable competing standard, whether formal or proprietary. The examples
> of SGML and ODA leap to mind -- structured document markup is simply
> better, but it is not what Word, Wordstar and WordPerfect did.
>
> So the secret to success is market timing. (What a surprise.) You
> have
> to strike when there is enough communal knowledge, agreement,
> motivation
> and market strength to make a viable standard. And then you have to
> make it happen in 2 years, before the window closes. And since it
> always takes a year to bring a community together, you have to have the
> prescience to start the standards effort, or some forerunner community,
> at least a year before the window really opens. And after you publish,
> it will take 2-5 more years to observe success or failure. Not many
> communities have people with the perspicacity, political skills and
> management commitment to make such a thing happen, and even those that
> do have a low success rate. It is like starting a business, without
> the
> potential for getting rich.
>
> -Ed
>
> --
> Edward J. Barkmeyer Email: edbark@xxxxxxxx
> National Institute of Standards & Technology
> Manufacturing Systems Integration Division
> 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
> Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694
>
> "The opinions expressed above do not reflect consensus of NIST,
> and have not been reviewed by any Government authority."
>
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> Shared Files: http://ontolog.cim3.net/file/
> Community Wiki: http://ontolog.cim3.net/wiki/
> To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
> To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
> (06)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (07)
|