John Sowa wrote: (01)
> -----Original Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-
> bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F Sowa
> Sent: Friday, February 15, 2013 1:44 PM
> To: '[ontolog-forum] '
> Subject: [ontolog-forum] Architectural considerations in Ontology
> Development (02)
<snip> (03)
> 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. (04)
This is simply not true of replacement of a major system. The good management
practice is to operate both systems side by side, feeding the transactions to
both (by some means) and, as experience and confidence with the new system
becomes established, appointing a changeover date for retirement of the legacy
system. (05)
> 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. (06)
Yes. The problem is inevitably with all the environmental concerns, including
many other systems, that the new system must work with. Over time, dozens of
hacks have been made to accommodate those environmental elements in the
operating legacy system, and it is only when the new system is trying to run in
parallel with the legacy system that one realizes which of these were entirely
overlooked and which assumptions about the interfaces to these other systems
were false. I am reminded of the documentation in a section of the code for
some DEC front-end around 1980, which read "When we first connect to the
DECsystem-10, it says a great many things it doesn't mean, so we ignore
everything until we see the XXX Message, which is the indication that the XYZ
app is finally in control." (07)
> The duration of that transition is usually *decades*, not years. (08)
Not in my experience. If the new system was properly designed, the legacy
system itself can be retired within the year. The environment and cooperative
interfaces of any large system are always in a state of flux, and all John is
seeing is that the stream of little changes and fixes to the legacy system has
now become a stream of little changes and fixes to the new system, only some of
which are hacks to support the environmental features that were hacked earlier
in the legacy system. The reason these things get overlooked is the quick and
dirty fixes that avoided having to make a small clearly documented change with
high impact ripples -- this record is not always available; the datum in this
slot is not always an X; sometimes you get a type B message when you should get
a type A message, etc. In other trades, senior engineers call this "lore" (09)
> 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. (010)
It seems to me that there is a powerful empirical test for the validity of this
assertion. Remove the upper level axioms from the KB and run the same queries. (011)
<snip> (012)
> 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.
> (013)
I fully agree. An ontology is a model. " All models are wrong; some are
useful." An ontology is made for a purpose. It includes what is useful to the
purpose.
That said, an ontology may borrow from, or wholly incorporate, an ontology made
for another purpose, as long as it is not inconsistent with the needs for the
current purpose. (014)
As some wag said of software modules, there is no such thing as design for
unknown reuse. Reuse arises by serendipity and when it is mandated. (015)
<snip>
>
> 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. (016)
Well, I can say from bitter experience that most modelers do not understand the
need for mereological theories. Those "subtle philosophical distinctions" may
be hard to explain to a high school graduate, but without that understanding
you get intuitive, rather than well-founded, uses of "part of" and "member of"
and "set" and bizarre query results as a consequence. And we have had a number
of 'go-rounds' in various ontological efforts about the proper distinction
between mass nouns and count nouns in stating quantitative requirements,
because there are gray areas. I agree with John that there is a lot of upper
ontology stuff that is pure philosophy and largely irrelevant to any practical
use of the ontology, but let's not throw out the babies with the bathwater. If
you push all of these concerns down to microtheories, you will have serious
problems integrating jointly relevant ontologies. The fact that two theories
can be proven to be equivalent does not make that equivalence obvious to the
reasoner. And a purpose of most ontologies is to enable a reasoner to get
certain kinds of results. (017)
-Ed (018)
>
> 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
> (019)
_________________________________________________________________
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 (020)
|