John or Barry or anyone (01)
In order for any two or more systems to interoperate successfully they
must implicitly or explicitly agree on the ground rules of such an
interaction (among them: methods of command-response or collaboration,
interoperation or cooperation of processes, composition and division of
processes, interactive control, certain types, etc.). (02)
Irrespective of the objects interacting-- How can anyone ever be certain
of an outcome that depends on the unfolding interaction while taking the
ground rules (grundegesetz) of the interaction for granted, or worse,
leaving them for others to fix or modify at will? (03)
Ken Ewell (04)
ontac-forum-request@xxxxxxxxxxxxxx wrote: (05)
>Send ontac-forum mailing list submissions to
>To subscribe or unsubscribe via the World Wide Web, visit
>or, via email, send a message with subject or body 'help' to
>You can reach the person managing the list at
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of ontac-forum digest..."
> 1. RE: RE: framework approaches designed to support
> forinteroperable systems (Hans Teijgeler)
>Date: Sun, 15 Jan 2006 18:29:44 +0100
>From: "Hans Teijgeler" <hans.teijgeler@xxxxxxxxxxx>
>Subject: RE: [ontac-forum] RE: framework approaches designed to
> support forinteroperable systems
>To: "'ONTAC-WG General Discussion'" <ontac-forum@xxxxxxxxxxxxxx>
>Content-Type: text/plain; charset="us-ascii"
>Even after having read this entire exhaustive (and exhausting) thread I am
>not sure about what we REALLY want to achieve. This uncertainty is mainly in
>the question whether you want to focus on natural language (in particular
>English) or also on lifecycle information representation, as we do. And will
>the focus be mainly on activity models, like John seems to address?
>When starting a new undertaking like this it is a good practice in US
>businesses (at least the ones I worked in) to formulate a Vision Statement.
>This is a clear description of future scenario that will be positively
>influenced by our efforts (try Google: define: vision statement )
>I suggest that we come up with such a Vision Statement because I miss that
>in the charter of ONTAC-WG (to me that is more of what we call a Mission
>ISO 15926 specialist
> -----Original Message-----
>[mailto:ontac-forum-bounces@xxxxxxxxxxxxxx] On Behalf Of Gary Berg-Cross
>Sent: Sunday, January 15, 2006 17:50
>Subject: [ontac-forum] RE: framework approaches designed to support
>The extended discussion launched by "The world may fundamentally be
> inexplicable" addresses some of the really underlying issues of
>compatibility in support of "interoperability" of applications that use
>We have some of the grandfathers of the ontological field participating in
>and I am reminded of a saying that one grandparent alone will spoil a
>but two (or more) of them will raise a healthy child because they will each
>that the others asy tendencies that might spoil the child. So I think a
>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
>and in from John Sowa's framework discusion, perhaps as a way to move
>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
>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.
>: Sat, 14 Jan 2006 11:50:49 -0500
>From: "John F. Sowa" <sowa@xxxxxxxxxxx>
>Subject: Re: [ontac-forum] Re: The world may fundamentally be
>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.
>-------------- next part --------------
>An HTML attachment was scrubbed...
>Message Archives: http://colab.cim3.net/forum/ontac-forum/
>To Post: mailto:ontac-forum@xxxxxxxxxxxxxx
>Shared Files: http://colab.cim3.net/file/work/SICoP/ontac/
>End of ontac-forum Digest, Vol 9, Issue 23
Message Archives: http://colab.cim3.net/forum/ontac-forum/
To Post: mailto:ontac-forum@xxxxxxxxxxxxxx
Shared Files: http://colab.cim3.net/file/work/SICoP/ontac/