Dear Matthew and Godfrey, (01)
After reflecting on the issues we discussed, I realize that our
conflicts arise from different assumptions about how an ontology
will be used. There is no such thing as a one-size-fits-all
ontology, and we have been focusing on different applications.
I'll distinguish four cases: (02)
1. Ontology for development: A precise, formally defined ontology
at all levels (top to bottom) that is suitable for designing
and implementing applications that are guaranteed to fit
together. This seems to be the focus of your interests, and
I agree that it is probably the main interest for those people
who want a single upper level that governs everything. (03)
2. Ontology for interpretation: An ontology with a loosely
axiomatized upper level that is suitable for interpreting
natural languages and determining which domain-level ontology
is relevant to a particular sentence or phrase. This kind of
ontology is important for interpreting unrestricted natural
language and for question answering about an open-ended range
of topics. (04)
3. Ontology for interoperability by fiat: A development ontology
that enables all applications designed to its specifications to
interoperate. This kind of ontology has been the focus of many
discussions in this forum, but it does not address interoperability
among systems developed with different ontologies or with no
explicit ontology. (05)
4. Ontology for task-oriented interoperability: An ontology used
to *discover* commonalities among independently developed
ontologies for a specific low-level task. This kind of ontology
could be a ontology designed for interpretation. It could also
be an ontology derived from a development ontology, but with the
detailed axioms moved out of the upper levels and into the lower
levels. (06)
MW> One of the characteristics of data models is just that they are
> not permissive. You can only hold the data that they allow, nothing
> else is You are only a person to them if you can provide an acceptable
> data set about yourself. Quite possibly the same person can provide
> more than one acceptable data set. (07)
That is true of a development ontology (case #1) or an ontology
designed for interoperability by fiat (case #3). But consider
the problem of making one of those ontologies interoperate with
the Amazon.com database. It is almost certain that much of the
information you want is not available. But for the task of
selling books or cameras through Amazon.com, it is irrelevant. (08)
Therefore, you can adapt your development ontology (#1) to a
task-oriented ontology (#4) by not demanding any information
that is not needed for the application. (09)
MW> And what you are talking about in this situation is a mapping
> between an enterprise's own database and the Amazon schema. That
> will need to take account of any ontological differences, something
> that will often be done without even realizing what is happening --
> which is why this can be an expensive and error prone affair. (010)
I agree that if you don't "realize what is happening", you can create
errors and inconsistencies. You need a systematic and automatic way
of way of mapping your development ontology (#1) to a task-oriented
ontology (#4). (011)
MW> During the '90s one part of Shell estimated that 70% of the cost
> of new systems was in constructing such interfaces... (012)
I agree that a good development ontology would reduce those costs
for systems that Shell designs and implements. But right now, over
99.99% of all databases in the world do not use your ontology. (013)
Furthermore, you can't even assume that all the ontologies within
a single enterprise use the same upper level. If you legislate
a particular ontology for Shell's engineering division, you can be
certain that Shell's finance and sales division will not use it. (014)
The finance and sales divisions will not care about the details
of your beautiful design for a product or service. They just
want to know how to sell it and how to count up profits from the
sales. Even the operating divisions will have to interoperate
with suppliers that use a wide range of different ontologies
that are unlikely to be the same as yours. (015)
MW> Interaction requires a mapping, not a common upper ontology.
> Knowledge of the upper ontologies of the two systems will make
> this much easier and less error prone. (016)
We can agree on that. But note that at least 99.9% of today's
systems do not have upper levels. I keep coming back to the
Amazon.com example, because that is typical of the overwhelming
number of systems in use today and for at least the next 20 years. (017)
JFS>> When you're linking your DB or KB to the Amazon.com schema,
>> you *never* want to worry about whether a human being is a 3D
>> or 4D entity or whether a vase is identical to the lump of clay
>> from which it is made. (018)
MW> Yes you do, or your mapping won't work. Any differences have
> to be catered for in the mapping for the interoperation to work
> consistently. (019)
If those mappings require that level of detail, then you can
be sure that they will *fail* on 99.9% of the systems in use
today, and probably 99% of those designed in the next 10 years. (020)
JFS> The ontologies for units of measure, for example, are
> completely neutral to 3d or 4d issues. (021)
MW> That would be very interesting if true. Can you prove it? (022)
Just look at them. I'll defer to people at NIST for details,
but the standards for a meter or a volt were established in
the 19th century for 3D systems. Today's measurements are
more precise, but they don't depend on a 3D or 4D ontology. (023)
MW> Your choice is to comply [with the Amazon.com DB] or not
> to use it. (024)
If you're selling books, cameras, or electronics, you must
use it if you want to stay in business. Furthermore, you
can comply with such things with a systematic method: (025)
1. Convert the development ontology (#1) to case #2 or #4. (026)
2. To do the conversion, remove all identity conditions and
axioms that make assumptions about 3D vs 4D from the
upper levels. (027)
3. Copy those axioms into each of the lower level modules
(microtheories) that depend on them. (028)
4. If some required fields in the development ontology are
not present in input data from an external system, just
assert that there exist values for those fields, but
don't say what those values are. (029)
Please note that OntologyWorks has been making a profitable
income by making systems with different ontologies or no
explicit ontologies interoperate. They use a task-oriented
approach (case #4) with a collection of low-level ontologies
for special domains. Bill Andersen said that they started
with an upper level based on Dolce, but they discarded it
because it was not helpful. (030)
GR> I wonder if you could expand a little on why you say this,
> because it conflicts with my experience: (031)
JFS>> If you listen to the philosophers, they will tell you that
>> identity conditions are essential to ontology. But for
>> interoperability, you have to *ignore* the identity conditions.
>> When you're linking your DB or KB to the Amazon.com schema,
>> you *never* want to worry about whether a human being is a 3D
>> or 4D entity or whether a vase is identical to the lump of clay
>> from which it is made. (032)
GR> but you do worry which edition, format or version of the item
> you are referring to. That is critically reliant on the uniqueness
> of identifiers like ISBN or UPC. (033)
I certainly agree that unique identifiers such as ISBN or UPC are
absolutely essential. But that is very different from the philosophers'
discussions about identity *conditions* . The ISBN or UPC identifiers
are neutral with respect to a 3D or a 4D ontology. Anybody who uses
the UPC identifier to buy or sell a vase would never imagine anyone
selling the vase without also selling the underlying clay. (034)
GR> I think the centrality of identity management is even more obvious
> with ontological or linguistic terms, because they lack well-
> administered standard identifiers... (035)
I am completely in favor of "well-administered standard identifiers".
Those things are critical to the Amazon.com DB (and other commercial
DBs). But the philosophical issues that might affect the upper level
of Matthew's developmental ontology, are irrelevant to databases for
buying and selling things identified by ISBN or UPC. (036)
John (037)
_________________________________________________________________
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 (038)
|