Sean and Pat, (01)
At the end of this note is a copy of the previous note in this thread.
During the discussion, I'll mention the use of different kinds of
ontologies for development, interpretation, and interoperability.
You can check the definitions of kinds #1, #2, #3, and #4 below. (02)
SB> I would like to reject the idea that the formalization of a lower
> level ontology implies the existence of an upper level ontology. (03)
That is true for an ontology for interpretation (case #2) or an
ontology for task-oriented interoperability (case #4). (04)
PC> I agree that no *explicit* upper ontology is needed *if* we can
> rely on the users all interpreting the information in the same way. (05)
No. A given lower-level ontology can be *consistent* with each of
multiple upper levels that are *inconsistent* with one another.
There is no shortage of examples to illustrate that point. (06)
One typical example are the ontologies for units of measures. Most
of those units were defined during the 19th century when Newton's
theory was the foundation for physics. Since then, measurements
are much more precise, but the same units are compatible with
multiple inconsistent upper levels: Newtonian mechanics, relativity,
quantum mechanics, quantum electrodynamics, string theory, etc.
An ontology for units of measure is a microtheory that can be plugged
into different ontologies for different purposes (#1, #2, #3, #4). (07)
The Amazon.com database schema is a typical example of the way that
most businesses interact for ordinary transactions. They have unique
identifiers for product types (such as ISBN and UPC codes), and they
never worry about philosophical "identity conditions" that might
distinguish a vase from the underlying lump of clay. As long as
the suppliers and buyers agree to various conventions for the
identifiers (name, address, city, state, country, postal code,
credit cards, ISBN, UPC, etc.), they can interoperate through the
Amazon.com schema without any knowledge about the details of how
the other parties define or use those products. This is an
example of an ontology for task-oriented interoperability (#4). (08)
A third example is the different ways of thinking, talking, and
reasoning in four different divisions of the same company:
engineering, manufacturing, sales, and finance. The first one
designs products, the second makes them, the third sells them,
and the fourth counts the profits made on items bought and sold.
The only things common to all of them are the identifiers for
products and part numbers. Nothing else matters. This is
another example of task-oriented interoperability (#4). (09)
PC> But can we rely on machines having similar understandings? (010)
Of course not. That is the beauty of the Amazon.com schema and
the ontologies for units of measure. Two parties that agree on
a UPC code don't need to agree on anything else about the product
other than that code, the price, and the method of shipping.
Any further detail is irrelevant. (011)
PC> But when information is being communicated among multiple
> communities with multiple local understandings, a more detailed
> description of the meanings is required because the local
> understandings of particular communities do not apply. (012)
Now you seem to be thinking about a kind of ontology used for
development (#1) or for interoperability by fiat (#3). But
you definitely do not need the additional detail in an ontology
for interpretation (#2) or task-oriented interoperability (#4). (013)
PC> Until we actually have such an ontology [I think you mean a
> development ontology #1] with its broad user base and effective
> utilities, I don't see how we can predict whether it would be
> better than development of local ontologies without such a tool.
> But for the task of general automatic and accurate interoperability,
> I have not yet a suggestions that comes close to the effectiveness
> of a common foundation ontology. (014)
Today, we do have examples of development ontologies for narrow
domains, and I agree that they have the kinds of advantages you
are talking about. It is certainly worthwhile to explore the
possibility of generalizing them to wider ranges of applications.
I would endorse R & D to generalize such things. (015)
But I also believe that we should recognize the highly successful
task-oriented ontologies and database schemas. They have been
supporting interoperability among computer systems for over
40 years, and they resemble the ways that people interact
with strangers on specific tasks (such as buying, selling, or
traveling). You never have to align your global ontology with
the bus driver or the sales clerk at a supermarket. (016)
Summary: Whenever we get into endless rounds of disagreements,
I suggest that we consider which kind of ontology we're talking
about -- either one of the four kinds below or some variation. (017)
John
_________________________________________________________________ (018)
Dear Matthew and Godfrey, (019)
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: (020)
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. (021)
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. (022)
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. (023)
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. (024)
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. (025)
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. (026)
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. (027)
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. (028)
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). (029)
MW> During the '90s one part of Shell estimated that 70% of the cost
> of new systems was in constructing such interfaces... (030)
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. (031)
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. (032)
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. (033)
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. (034)
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. (035)
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. (036)
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. (037)
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. (038)
JFS> The ontologies for units of measure, for example, are
> completely neutral to 3d or 4d issues. (039)
MW> That would be very interesting if true. Can you prove it? (040)
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. (041)
MW> Your choice is to comply [with the Amazon.com DB] or not
> to use it. (042)
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: (043)
1. Convert the development ontology (#1) to case #2 or #4. (044)
2. To do the conversion, remove all identity conditions and
axioms that make assumptions about 3D vs 4D from the
upper levels. (045)
3. Copy those axioms into each of the lower level modules
(microtheories) that depend on them. (046)
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. (047)
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. (048)
GR> I wonder if you could expand a little on why you say this,
> because it conflicts with my experience: (049)
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. (050)
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. (051)
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. (052)
GR> I think the centrality of identity management is even more obvious
> with ontological or linguistic terms, because they lack well-
> administered standard identifiers... (053)
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. (054)
John (055)
_________________________________________________________________
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 (056)
|