If ontology will save hundreds of billions of dollars to countries who
companies and organizations adopt it, why is there no market? (01)
I am not sure that the lack of ontologies is really the answer. (02)
I would like to know what is the "killer" application for the average
company or industry. A typical competing project would have an ROI of
over 20% and I guess that an ontology-based project would be much higher.
What are the top 10 areas for any company that wants to get involved in
ontology-based solutions? (03)
I suspect that there is a lack of tools that are user friendly and help
a SME to be productive quickly. (04)
Ron (05)
Patrick Cassidy wrote:
> 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).
>
> 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.
>
> I might also suggest that the current economic situation might give one
> pause in relying exclusively on the "market" to solve issues.
>
> Pat
>
> Patrick Cassidy
> MICRA, Inc.
> 908-561-3416
> cell: 908-565-4053
> cassidy@xxxxxxxxx
>
>
>
>> -----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
>>
>>
>
>
> _________________________________________________________________
> 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)
|