Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: updated MITRE paper: Towards the Use of an Upper Ontology for U.S. Government and Military Domains



On Fri, 09 Dec 2005 20:40:31 -0500 "John F. Sowa" <sowa@bestweb.net>
writes:
> Leo,
> 
> 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:
> 
> http://www.mitre.org/work/tech_papers/tech_papers_04/04_0603/index.html
> 
> But I'd like to comment on some of the conclusions.  I very
> strongly agree with the following passage in Section 7:
> 
>  > 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.
> 
> This would imply that it is premature to recommend *any* upper
> ontology as a standard.  Another conclusion from Section 7:
> 
>  > 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.
> 
> 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.
> 
>  > 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.
> 
> 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.
> 
>  > 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.
> 
> 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.
> 
> 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?
> 
> 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?
> 
> 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?
> 
> 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.
> 
> John Sowa
> 
>