Ron and Pat, (01)
RW> But don't [Pat C's] points lead to the conclusion that the
> problem is in the application area not the ontology area. (02)
I strongly agree. In yesterday's note, I cited the example of
the banking industry, which has a large number of very similar
services provided by each bank and a long history of terminology
and practices that are shared by all the banks. Yet in none of
the many bank mergers have any two banks actually merged their
databases. (03)
A common upper ontology would not be of the slightest help in
aligning the categories of different DBs -- because the shared
terminology is more than adequate for alignment. Instead, the
reasons for the failure to merge lie in the *lowest level details*
such as the terms and conditions for particular account types. (04)
RW>> I am not an expert but I am not very moved by the argument
>> that ontologies exist to please ontologists. (05)
PC> Where the hell did you ever get the notion that I or anyone
> else holds that view? Please try to keep the discussion on
> a professional level. These meaningless sarcastic comments are
> one of the principle problems retarding effective discussion
> in groups like this (06)
I thought that Ron's comment was very cogent. It is easy to see
where he got that idea: reading all the email among ontologists
who talk to or past one another and who are trying to peddle
their own wares without showing any inclination to adopt anybody
else's system. (As for professionalism, note that Ron did not
use any emotion-laden expletives.) (07)
RW>> I understand that the transformation from one format to another
>> may not solve all of the problems in using an existing ontology
>> in a new application but if it is not easy to do then ontology is
>> a rather useless endeavour to begin with. (08)
PC> No, no, no. Translation from one language to another requires
> more than syntactic transformation, it requires that the translator
> understand the meanings of the individual elements.... (09)
That is true of natural languages, but not of most logics. For most
formal ontology and specification languages, such as OWL, RDFS, and Z,
a translation to Common Logic is straight forward. For CycL, Lenat
said that more was needed -- in particular, the IKRIS extensions to
Common Logic, which were defined by a group in which Cyc developers
participated. Lenat said that translating CycL to IKRIS would be
easy, but nobody was paying him to do so. (010)
As for automated translations from Cyc to other versions of logic,
see the following article, which I have cited many times: (011)
Peterson, Brian J., William A. Andersen, & Joshua Engel (1998)
"Knowledge bus: generating application-focused databases from
large ontologies," Proc. 5th KRDB Workshop, Seattle, WA.
http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-10/ (012)
To commercialize that (and other) technology, those three authors
founded the company Ontology Works, which is doing quite well by
developing applications, not asking for grants. (013)
PC> I have previously mentioned that Cycorp is in fact making most
> of their money now from a large project to integrate the DB's of
> a health care company. So at least one large organization is
> convinced that Cyc can successfully solve their interoperability
> problem better than a traditional federated database or data
> warehouse. (014)
That's great. But I seriously doubt that the upper levels of Cyc
(or any other ontology) are a prerequisite (or even useful) for
doing that integration. As with the banking and oil industries,
the most important basis for aligning health DBs is the shared
terminology, not a formal ontology. (015)
As with the case of banks, the biggest deterrent is undoubtedly
going to be low-level details for which the formal axioms are
irrelevant. As another example, one oil company had different
definitions of 'oil well' in different databases: (016)
* The geological database defined an oil well as any hole
dug in the ground with the intention of getting oil,
independent of whether the hole was dry. (017)
* The financial database defined an oil well as any pipe
connected to one or more holes that produced oil. (018)
As a result of this discrepancy, they could not merge the two
databases in order to relate geology to the production results.
A standard upper ontology wouldn't help in the slightest. (019)
PC> But such projects are very expensive, which makes them rare,
> and even when they succeed it may not be feasible for outsiders
> to evaluate the "success" of such proprietary projects. That
> is why we need an open consortium, using a common, open ontology,
> so that at least some successful ontology-based projects are
> visible to everyone. (020)
RW> I suspect that success will be well known. Failure might be
> harder to discover. (021)
That is true. Companies never publish their failures, but they
rarely publish their success stories (except in vague, but glossy
advertising brochures). They don't want to tell their competitors
how they make their money, and there is no way that a consortium
could ever get enough money to pay companies to disclose their
"secret sauce". (022)
John (023)
_________________________________________________________________
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 (024)
|