[ontac-forum] RE: framework approaches designed to support for interoper

["Gary Berg-Cross" <gary.berg-cross@xxxxxxxx>]

The extended discussion launched by "The world may fundamentally be
  inexplicable" addresses some of the really underlying issues of ontologically

compatibility in support of "interoperability" of applications that use "knowledge".

 

We have some of the grandfathers of the ontological field participating in the discussion

and I am reminded of a saying that one grandparent alone will spoil a grandchild

but two (or more) of them will raise a healthy child because they will each check

that the others  asy tendencies that might spoil the child.  So I think a progressively

deepening exposure of issues in good. Still I'm eager to move forward. 

 

Here is one question and one idea I had while reading the exchange leading to

and in from John Sowa's framework discusion, perhaps as a way to move forward.

 

The question is, in the 4 part approach to a framework item, 4 jumps out at me as something that needs more discussion. What are the methodologies for organizing the hubs and modules, relating them to one another? 

 

The idea I had comes from John's suggestion that we consider the lesson from Fred Brooks' Mythical Man Month documentation of mistakes in the original design

for OS/360 -- many of which could have been avoided with a few extra

months of research and analysge is.  I think that ontological methods as human enterprises share problems with its sister efforts of knowledge

engineering and system/SW engineering.  As fallible knowers and groups of knowlers we don't have/document/articulate/model the full "requirements" up front to begin our task.  Brooks pointed out some additional things

that could have been discovered to head off problems down the road.

 

 

What can we do in this regard?  Perhaps it is to use the idea of

prototyping some of these critical issues to mitigate risk.

In a prototype we aren't going down a long road but have some

specific issues we want to investigate with a testable product resulting.

Prototypes can be useful in refining "requirements" and may

significantly enhance our understanding of these issues. 

An ontological prototype could be used, for example, to validate portions

of the  ontological "architecture" ftom top core through hubs and super-hub to modules, which I loosely think of as yet another

extension of John's Conceptual Structures. 

 

Gary Berg-Cross

EM&I

Herndon VA

 

 

---

: Sat, 14 Jan 2006 11:50:49 -0500
From: "John F. Sowa" <sowa@xxxxxxxxxxx>
Subject: Re: [ontac-forum] Re: The world may fundamentally be
        inexplicable

Barry,

There is no way to design an ontology for one field, say
bioinformatics, that does not involve interoperability
with *every* other field of endeavor known to mankind.

BS> Is this work designed to support *all* possible applications?
 > (Pat?) Is it designed to support the work of, say, rocket
 > scientists?

Let's start with medicine.  That involves everything that
physicians of every specialty do, ranging from general
practitioners, to surgery, to research, and all the
specialists for every organ, body part, and disease.

That leads us to biology, with emphasis on humans, but
also with research on primates, which are cheaper than
humans, but still expensive to maintain.  Rats and mice
are much cheaper mammals, but some of the research can be
performed on even cheaper animals, such as fruit flies,
the ever-popular C. Elegans, and even lowly yeast cells.

The pathogens lead us to bacteria, viruses, protozoa, fungi,
insects, and a wide range of worms and worm-like organisms.
Then the methods for treating them include almost every
branch of chemistry for the development of pharmaceuticals.
But there are also many kinds of mechanical, electrical,
and computerized medical appliances that involve many
more branches of physics and engineering.

A major use for the ontology is to systematize patient
records from physicians and hospitals around the world.
That introduces IT issues of databases, networks, and
security concerns about sensitive information.  The same
computers and databases that hold patient records also
process the patients' billing and scheduling, together
with links to all the insurance plans, HMOs, Medicare,
and their payment allowances for each procedure.

As for rocket science, don't forget that NASA has to deal
with extreme conditions for the astronauts' life support.
The requirements for supporting the astronauts and their
equipment impose critical constraints on the size, shape,
structure, and maneuverability of the space vehicles.

 > The issue is, given your principles, whether anything
 > could possibly be left in the central hub. It seems not.

I admit that we're getting close to the starting point of
zero axioms, but the principle of distinguishing "black box"
and "white box" components can support some separability.
If we organize the ontology in hubs, we should consider
clusters of hubs  -- say superhubs -- for related subfields.

 > ONTAC-WG has, I think, no specialists in quantum mechanics,
 > rocket science, magnetic resonance imaging (etc.) in its
 > target audience. Let us therefore simply forget quantum
 > mechanics, etc., and concentrate on those domains which
 > (all of us, I take it) are specialists in...

Nobody can be a specialist in every possible area, but we must
not only consider today's specialties, but also specialties
that may arise in the next 20 to 40 years.  Just look at the
new developments in the past 10 years as a result of research
on DNA and the human genome project.  We can be certain that
the developments in the next 10 to 20 years will be just as
revolutionary, if not more so.

I strongly urge anyone who hasn't read Fred Brooks' _Mythical
Man Month_ to read Brooks' accounts of how mistakes in the
original design for OS/360 -- many of which could have been
avoided with a few extra months of research and analysis --
caused the software to be delayed by years and resulted in
problems that plagued IBM, their customers, and even their
competitors for many decades.

 > Let's leave the relativity theorists, etc., to build those
 > things, and then forget about them.

We don't have to think about it, since we can use a GPS device
as a "black box" -- but we have to support interoperability
with the suppliers who make those boxes, which they consider
"white boxes".  So our ontologies will have some overlap, not
only on the boxes themselves, but on the methods for using them
as well as ordering, shipping, billing, accounts receivable, etc.

 > There are always other things one can do in life. But normally
 > one does not take this fact as an argument that one should do
 > nothing at all.

Of course not.  Other people will do all these things that we
don't want to be bothered with.  All we have to do is to ensure
that our ontologies will interoperate smoothly with their
ontologies.  That implies we must have a framework that can
accommodate *every* ontology and be able to relate them.

 > No one is allowed to talk about bones, or cities, until someone
 > else has worked out the ontology of quantum mechanics! All the
 > hubs must be built before any single one of them can be built!

No.  Our job is to design the framework.  The task of filling
the framework with content will be done by the specialists
in every discipline.

JS>> Preserving the mid-world phenomena and speech patterns while
 >> satisfying those constraints should not be difficult:

BS> Good. So let's concentrate on those and forget the rest,
 > initially, can't we?

A starting point is good.  But we should also survey the territory
so that we know where we're going.

JS>> Similarly, the Cyc ontology and Whitehead's ontology accommodate
 >> the view of dogs as processes without requiring anyone to modify
 >> speech patterns or feeding habits when playing with their pets.

BS> I fail to see the relevance of this. The argument seems to be
 > that, because four-dimensionalists can talk to the rest of us in
 > understandable ways, it follows that we should all of us change
 > our view of reality to be consistent with four-dimensionalism.

No.  It merely means that we must accommodate *all* reasonable
views of reality within the framework.

BS> By the <<QM is not consistent with General Relativity>> argument,
 > this means, a priori, that the core is empty.

Not necessarily.  They both agree that a 3-dimensional space and a
one-dimensional time exist.  Locally, they are flat, but globally
they may be curved.  They also agree that there are processes and
fairly stable things that may be long-lived.

That is sufficient to begin a fairly detailed taxonomy that is
consistent with Newtonian, Einsteinian, and quantum mechanical
views, and it would probably be consistent with any unified merger.
The core can include types for Time, Space, Object, Process, etc.,
but it should be highly *underspecified* -- i.e., very few axioms.

For most ordinary discourse and data processing, detailed axioms
just get in the way.  If you want to get a prescription filled
at the pharmacy, you don't need Newton's F=ma or Einstein's E=mc2,
and you don't need to worry about 3D or 4D space-time.  You might
call your pills "objects", but nobody except philosophers would
call them continuants or occurrents.

Summary:  The primary task for ONTAC WG is to design a framework
for interoperable systems that may be specialized for different
application domains.  I would recommend the following approach:

  1. A core ontology that is mostly a neutral taxonomy with very
     few detailed axioms, and those axioms should not make any
     commitments that would conflict with any reasonable scientific
     or engineering principles or techniques.

  2. Multiple hub ontologies, which include more detailed taxonomies
     for special domains together with prepackaged axioms for the
     common methods of talking and reasoning in each domain.

  3. An open-ended number of problem-oriented modules, some of which
     may be bundled in the packages that are used in one or more hubs,
     but any of which could be used independently in connection with
     the ontologies of any hub.

  4. Methodologies for organizing the hubs and modules, relating
     them to one another, registering them in a metadata registry,
     and providing tools for assembling, verifying, and testing
     modules and hubs.

With this approach, a hub could include as many predefined and
prepackaged definitions and axioms as anyone working in any
specific application domain might desire.  However, it would also
support methods for relating hubs and modules and for sprouting
new hubs for new application domains as they are needed.

John Sowa



******************************************

_________________________________________________________________
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    (01)