[Top] [All Lists]

Re: [ontolog-forum] standard ontology

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "John F. Sowa" <sowa@xxxxxxxxxxx>
Date: Fri, 20 Feb 2009 11:52:08 -0500
Message-id: <499EDFB8.3070005@xxxxxxxxxxx>
Dear Matthew,    (01)

I don't believe that our positions are far apart.  We are
mainly using different ways of talking about similar
methodologies.    (02)

JFS>> I wouldn't claim that upper levels are totally irrelevant,
 >> but that there is no unique upper level that would be ideal
 >> for all purposes.    (03)

MW> That is a bold statement. Can you prove it?    (04)

For starters, consider the interminable debates about 3D vs 4D
ontologies.  I agree with you that a 4D view simplifies many
of the issues in DB and KB design.  But the terminology of
natural languages is thoroughly grounded in a 3D view, and
any mapping of the DB or KB to and from ordinary language
must do some kind of transformation.    (05)

The issue of an objective vs a subjective view creates much
more diversity than the 3D vs 4D view.  Engineering and
personnel databases tend to ignore subjective issues.  But
such issues are becoming increasingly important for social
networks, entertainment, politics, crime, terrorism...    (06)

The current ontology proposals barely scratch the surface
of subjective issues.   They define social organizations as
sets without considering the purpose that causes those sets
to form.  Trying to define even a halfway decent upper level
for subjective issues is still an open research issue.    (07)

MW> ... if we don't have an explicit upper ontology before we
 > integrate the two sub-ontologies, the fastest way to integrate
 > them will be to discover the implicit upper ontology each has,
 > and then integrate or map those.    (08)

No.  Ever since the punch card days of the late 19th century,
systems designers have developed an extremely effective and
efficient methodology for dealing with systems with different
ontologies or no ontology at all:  *ignore* the upper levels.    (09)

For example, they look at the terminology that is actually used
in the interfaces and define the constraints that relate a person
to name, address, serial number, date of birth, etc., without
ever defining what is the "essence" of being a human being.
With that approach, an enormous number of systems with different
upper levels or no upper level at all can interoperate effectively.    (010)

As I said in the quotation above, I don't believe that an upper
level is totally irrelevant.  As you noted, it can be useful for
resolving thorny issues in designing a database schema.  But
systems with different schemata have been interoperating for
over a century -- without any kind of upper level ontology.    (011)

MW> ... in the process industries we have found an upper ontology
 > (ISO 15926) very useful. To be specific, when two people are
 > fighting over what a term like "pump" means, by asking each to
 > place it in the context of an upper ontology, you can find out
 > that one of them is talking about a physical object with a serial
 > number, and the other is talking about a class of physical object
 > you find in a catalogue.    (012)

That is indeed a very important distinction, but it does not
require an upper level -- or even any explicit ontology whatever.
Database designers have been very clear about the distinction
between physical objects and data written on a disk.  It's
lesson #1 in every tutorial on DB design.  You need guidelines
and tutorials for such issues, *not* a universal upper level.    (013)

MW> However, what is also true is that you need nothing like as
 > sophisticated as Cyc to do this, or as sophisticated as most
 > people here would like to be doing. You don't need complex axioms
 > (you hardly need simple ones).    (014)

We are in violent agreement on this point.  Following is an
interchange with Sean B. from an earlier note:    (015)

SB>> Noting some of the comments earlier in the thread, in all
 >> these interactions, one thing I never need to consider is
 >> whether clay or the number seven is an individual.    (016)

JFS> Indeed.  Those questions never arise when we interoperate
 > with other drivers on a highway.  And they are also irrelevant
 > to suppliers who map a subset of their database to the Amazon DB.    (017)

In the continuation of your note, I suggest one tiny modification:
replace the word 'ontology' in the next sentence with 'terminology':    (018)

MW> You just need a basic upper ontology [terminology], so that as
 > you bring the ontologies [terminologies] of the systems you are
 > integrating together within it, you see how the different concepts
 > they contain relate to each other in a wider context.    (019)

As soon as you drop the axioms (except perhaps for simple ones
that relate terms by generalization/specialization or part/whole),
the difference between a terminology and an ontology vanishes.    (020)

In fact, the overwhelming majority of people who have adopted
the word 'ontology' are simply rewriting their old familiar
terminology in a notation such as OWL.  With suitable tools,
they could use semiautomated methods based on controlled English
to write their terminology in notation that would be equally
readable by both humans and computers.    (021)

To summarize the issues, I'll make the following observations:    (022)

  1. All interoperations between different agents (human or computer)
     are *always* on a task or domain-dependent basis.    (023)

  2. When one of those agents is a computer, the possible interactions
     are limited to messages in some language, natural or artificial.    (024)

  3. The total domain of interoperability is determined by the set
     of terms (words or other symbols) used in those messages.    (025)

  4. For the purpose of interoperation, the *meaning* of those terms
     is determined by the practical effects that occur as a result
     of those messages.    (026)

  5. No linguistic or philosophical issues about a term other than
     the effects triggered by messages that use it are relevant to
     interoperations among the agents that send/receive the messages.    (027)

  6. Therefore, any methodology for supporting interoperability
     among a group of agents must begin with the terms used in
     the messages that pass among those agents and the effects
     triggered by those messages.    (028)

  7. Anything outside those messages, the terms in them, and the
     effects of the messages is *irrelevant* to interoperability
     among the agents that send/receive those messages.    (029)

Note that only the terminology actually used needs to be aligned.
Any defining terminology, axioms, or schemata outside the terms
that occur in the messages do not need to be aligned.  For many,
if not most domains, such terminologies already exist.    (030)

Requiring all interacting systems to switch to a single universal
schema determined by some upper level ontology would be unrealistic,
unnecessary, and a waste of time, money, and effort.    (031)

John    (032)

PS:  Anybody who has read anything by C. S. Peirce might note that
my observations above are corollaries of his "pragmatic principle":    (033)

    "The elements of every concept enter into logical thought at the
    gate of perception and make their exit at the gate of purposive
    action; and whatever cannot show its passports at both those
    two gates is to be arrested as unauthorized by reason." (CP 5.212)    (034)

For computer agents, those two gates are the send/receive ports for
messages.  Many, but not all of the proposed upper levels should
"be arrested as unauthorized by reason."   The claim that there
must be only a single upper level should definitely be arrested.    (035)

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    (036)

<Prev in Thread] Current Thread [Next in Thread>