On Fri, 2013-02-15 at 13:44 -0500, John F Sowa wrote:
> In a conference call for the forthcoming Ontology Summit, Barry Smith,
> Chris Partridge, Anatoly Levenchuk, and Mike Bennett presented four
> thoughtful and well organized talks. Following is the summary with
> pointers to the slides and the audio recordings:
>
> http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2013_02_07
>
> On the whole, the presentations were good. But none of them mentioned
> four *extremely* important points:
>
> 1. Trillions of dollars have been invested in legacy software that
> runs the world economy.
>
> 2. That software will not be replaced for a long, long time. In past
> experience, the lifetime of a large, mission-critical system can be
> 40 years or more. Its replacements must interoperate with it in
> as smooth a transition as possible.
>
> 3. Every attempt to replace a critical, working system with a new
> one that could not interoperate during the transition has failed.
> The greater the discontinuity, the greater the ensuing disaster.
>
> 4. Every successful introduction of new technology interoperates with
> the interfaces, infrastructure, and conventions of the old system
> during an extended, incremental, and evolutionary transition.
> The duration of that transition is usually *decades*, not years.
> (01)
That's part of the story. I would add 2 points: (02)
5. The mother of all system disasters happened nearly 50 years ago when
the IBM suits and their ilk commandeered the vision of early personal
computing pioneers who wanted to augment communication and cognitive
activities, and gave us instead a poor imitation of paper and pencil on
a cathode ray tube. I heard Doug Engelbart speak at the Computer History
Museum about an early demo he gave of advanced hypertext creation and
navigation, but the IBM execs were only interested in improving the
productivity of their customers' typing pools. Their idea of
interoperability was "make it the best electric typewriter ever". I
don't know the history of computer graphics applications, but something
similar must have happened--the early developers looked at draftsmen
putting lines and curves on mylar and decided to write a program to put
lines and curves on a CRT. It's taken several generations of graphics
software (each having to "interoperate" with the previous generation) to
really begin to augment the engineer's primary goal of communicating
design intent--and some people still don't believe that's possible
without honoring the conventions of antique draftsmanship. So, be
careful how you interpret the mandate to "interoperate": sure, horseless
carriages had to use the same roads and fit through the same passages as
horsed ones did; but at the same time they shed many of the constraints
of horsepower transportation, and brought on new problems requiring new
solutions. (03)
6. The software vendor-consultant complex plays a large role in inducing
suboptimal system design and deployment. More people (outside the
enterprise) profit from a botched implementation than from an efficient
one. And regardless of system benefits or performance, software vendors
are eager to extend vendor lock-in through proprietary formats and
closed systems. (04)
In general I am sympathetic with John's principles regarding ontology
development, and agree with his recommendations. I might have a slightly
different view of how we got in this mess and specific directions to
take out of it. (05)
Regards,
--Paul (06)
> There was some discussion of these issues in the email list for the
> ontology summit. I'll relate some of it to the slides of the talks.
>
> I'll start with Slide 19 in Barry Smith's talk:
> > Candidate Upper Level Ontologies
> > – Domain Ontology for Linguistic and Cognitive
> > Engineering (DOLCE)
> > – Suggested Upper Merged Ontology (SUMO)
> > – Upper Cyc Ontology
> > – Basic Formal Ontology
> > – all reflections of recognized need for semantic
> > standardization via upper level ontology
>
> That may be true of what the DOLCE, SUMO, and BFO developers say.
> But it is definitely *not* true of Cyc. Doug Lenat has explicitly
> said that the upper level is the *least* important. He said that
> *all* the detailed reasoning is based on axioms and definitions
> at the mid level and lower levels.
>
> The most important role of the upper level is to establish a common
> set shared terms for types and relations. The top level must be
> very underspecified -- usually with little more than type-subtype
> and disjoint-from links. The lower level "microtheories" contain
> the axioms and definitions needed for detailed reasoning.
>
> Cyc has been developing their ontology for over 28 years (since 1984).
> They discovered very early (by 1989) that a single, consistent,
> monolithic ontology was unworkable. Instead, they reorganized the
> ontology by removing most of the detail from the upper level, and
> pushing it down to the possibly *inconsistent* microtheories.
>
> Furthermore, I claim that the same principles are true of BFO, as it is
> actually used. Following is an example.
>
> From http://jowl.ontologyonline.org/bfo.html
> > Definition: An entity [bfo:Entity] that exists in full at any time in which
> > it exists at all, persists through time while maintaining its identity and
> > has no temporal parts.
> >
> > Examples: a heart, a person, the color of a tomato, the mass of a cloud,
> > a symphony orchestra, the disposition of blood to coagulate, the lawn and
> > atmosphere in front of our building
> >
> > Synonyms: endurant
> > Disjoint With:
> > occurrent
>
> For the formal ontology (in OWL), that English definition is a comment
> that has no effect on any computation. The relation "Disjoint With"
> is the only information that distinguishes the very underspecified
> term 'continuant' from the equally underspecified term 'occcurrent'.
>
> But that assumption is inconsistent with the BFO practice. The only
> formal constraint is that the subtree under 'continuant is disjoint
> from the one under 'occurrent'. The metaphysics stated in English has
> no influence on any of the reasoning with or about the BFO ontology.
>
> There are also many questionable points in the examples above. The word
> 'disposition' raises a huge number of thorny, subtle, and controversial
> issues on which professional philosophers have not reached a consensus.
>
> In the slides by Chris Partridge, I very strongly agree with the first
> half dozen slides about the need for an architecture based on a "shared
> understanding" among the key developers. I disagree with later points:
>
> From Slide 9 by Chris P:
> > "Find a scientific man who proposes to get along without any metaphysics...
> > and you have found one whose doctrines are thoroughly vitiated by the crude
> > and uncriticizedmetaphysics with which they are packed"
> > (Charles Peirce, Collected Papers 1.129).
>
> I also quote that point, but I disagree with Chris's assumptions about
> the implications:
> > In other words, there is going to be a top ontology anyway, Do you want
> > to manage it directly (or manage the results of a heterogeneous framework
> > on a piecemeal basis)?
>
> I agree that every ontology will inevitably have some kind of top level.
> I also agree that it should be managed on a systematic basis. But I
> strongly disagree with the following points:
>
> 1. The top level should be based on subtle distinctions that even
> professional philosophers find controversial.
>
> 2. The existing diversity of heterogeneous legacy systems can be
> (let alone, *must* be) replaced by rigid philosophical distinctions
> that will be imposed upon every conforming application.
>
> Comment by JFS from the thread on the Ontology Summit list,
> > The distinctions an ontology requires are determined by its purpose.
> > Making distinctions that are irrelevant to the purpose can decrease
> > its generality and interoperability. Therefore, the quality of
> > an ontology should be measured by its *relevant* distinctions.
>
> Response by Alan Rector,
> > Amen...
>
> Following is a revised version of the recommendations that I proposed
> in earlier notes to the Ontology Summit list:
>
> 1. Avoid subtle and controversial philosophical distinctions in the
> top levels of an ontology.
>
> 2. Avoid making detailed commitments in the top levels. Push any
> complex details or distinctions into the middle and lower levels.
>
> 3. Design the ontology in a way that is easy to modify or adapt
> as needed -- preferably by automated or semi-automated methods.
>
> Refrigerator principle: When in doubt, throw it out. Any distinction
> that is hard to explain to a high-school graduate should be deleted
> or pushed down to a specialized microtheory that is designed for
> and used by the people who understand that distinction.
>
> John
>
> _________________________________________________________________
> 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
> (07)
_________________________________________________________________
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 (08)
|