ontac-forum
[Top] [All Lists]

[ontac-forum] Re: updated MITRE paper: Towards the Use of an Upper Ontol

To: ONTAC-WG General Discussion <ontac-forum@xxxxxxxxxxxxxx>
From: "John F. Sowa" <sowa@xxxxxxxxxxx>
Date: Sun, 11 Dec 2005 08:55:37 -0500
Message-id: <439C2FD9.5000707@xxxxxxxxxxx>
Leo,    (01)

Thanks for sending us the pointer to the latest version of
the report.  It's a careful and thoughtful review of several
important projects that have been under development for a
long time:    (02)

http://www.mitre.org/work/tech_papers/tech_papers_04/04_0603/index.html    (03)

But I'd like to comment on some of the conclusions.  I very
strongly agree with the following passage in Section 7:    (04)

> There is no agreed upon standard upper ontology and few proven
> implementations. Further, the differing theoretical approaches
> taken by the candidate standard upper ontologies we examined
> are evidence that there is no consensus on which approach is
> better. In fact, there may never be a single correct answer.
> Rather, which theoretical approach is best may be situational.    (05)

This would imply that it is premature to recommend *any* upper
ontology as a standard.  Another conclusion from Section 7:    (06)

> Because upper ontologies are evolving, the “best” one today may
> not remain the “best” in the future. However, upper ontologies
> do provide a theoretical foundation and give clues on concepts
> people may wish to consider in their ontology development, even
> if they don’t actually map their domain concepts to an upper
> ontology.    (07)

That sounds reasonable, but one might also say that the midlevel
and domain-level ontologies should be designed to avoid making
any commitments that would restrict their interoperability with
any of the upper levels.  For example, Dolce seems to imply that
a person's brain is essential to his or her identity, but a heart
is not.  For most programs written today, this question has not
been relevant.  Fingerprints and DNA have been used in legal
decisions, but brains have not been considered.  Therefore,
there is no reason to adopt an SUO that makes that commitment.    (08)

> While there is an analysis cost in selecting an upper ontology
> as theoretical framework, there is a greater cost in not doing so,
> especially when one is dealing with relatively abstract concepts.    (09)

What cost?  How has that been determined?  Which abstract concepts?
Abstract concepts are the most difficult to define and the most
likely to vary from one ontology to the next.  Wouldn't it be better
to avoid making any commitment to the details of any version?  If
some application requires some mention of abstract concepts, would
it require anything more than what is contained in a collection of
terms with few or no axioms, such as WordNet?  If so, why make more
assumptions than necessary?  Mathematicians always try to avoid
making any assumptions that are not needed to solve a given problem.
That approach maximizes generality and minimizes obsolescence.    (010)

> Which upper ontology is best to use as even a conceptual model is
> situational and may change over time as upper ontologies mature
> and experience is gained with their use.  However, the risk of
> a suboptimal selection is mitigated by the fact that future upper
> ontologies are likely to be founded on current candidate standard
> upper ontologies.    (011)

But the current candidate upper ontologies have made different
assumptions.  Any commitment to one assumption is going to be
incompatible with the others.  When in doubt, leave it out.    (012)

Computer programs have been communicating and interoperating for
over 40 years without an SUO.  All those programs have had to make
assumptions about the low-level formats of the data, about the
symbols that are communicated, and about operational constraints
on the data.  But those are low-level constraints, not upper-level.
Is there any evidence than an SUO would help those programs?  Or
might it introduce irrelevant constraints that could block other
important operations?    (013)

The stated reason for not recommending OpenCyc is that it lacks rules.
But why should upper-level rules be important for interoperability?
What if those rules contradict constraints that are necessary for
the lower levels?  What if they contradict the implicit assumptions
built into existing programs that are not based on any explicit
ontology?  Must those programs be rewritten or even scrapped just
because somebody edicted a new ontology?    (014)

Every program or database that has ever been implemented makes
ontological commitments, and the likelihood that those commitments
are identical to *any* proposed upper ontology is nearly zero.
Therefore, an SUO might be incompatible with many, if not most
existing programs in government and industry.  That implies that
either (a) the SUO would create major incompatibilities or (b) its
axioms would be independent of the assumptions built into all that
software.  Case (a) would imply that the SUO would be a disaster,
and case (b) would imply that it would be irrelevant.  Are there
any intermediate cases where it might be helpful?  Has anyone done
a study of existing implementations in order to find out?    (015)

In summary, this report discusses many unresolved questions about
all the proposals for an upper ontology or even whether an upper
ontology is desirable.  I would interpret it as a strong case for
adopting a neutral position of emphasizing the midlevel and domain
levels.  Unless anyone can make a much stronger case for adopting
a standard upper level, we should avoid a commitment to any SUO.    (016)

John Sowa    (017)


_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/ontac-forum/
To Post: mailto:ontac-forum@xxxxxxxxxxxxxx
Subscribe/Unsubscribe/Config: 
http://colab.cim3.net/mailman/listinfo/ontac-forum/
Shared Files: http://colab.cim3.net/file/work/SICoP/ontac/
Community Wiki: 
http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/OntologyTaxonomyCoordinatingWG    (018)
<Prev in Thread] Current Thread [Next in Thread>