Proposed Upper Ontology for the Semiotics of Complex Systems

a Polymathix white paper

Draft - Version 0.1
May 5th, 2004 - 0830 CDT

Mark P. Line
<mark@cassandra-institute.org>

This is a brief sketch of the kind of upper ontology I envision to support an ontological treatment of semiotics, which in turn would support sign-based ontologies of complex systems.

0. The Treatment of Time and Space

Because this ontology is intended to support the behavior of complex systems, the temporal dimension as well as the spatial dimensions are taken as given in their entirety. This is the usual way of viewing time in the physical sciences, but people whose background lies mostly in the human sciences may find it odd. It means that prose explanations in a tense-constrained language such as English may be somewhat misleading. In this paper, present tense will be used for all such explanations, as though all of time were laid out before us (even though this may lead us to assertions such as "the Battle of Gettysburg is part of the Civil War").

1. The Map and the Territory

A distinction is made here between a complex system under discussion, called the System, and a set of descriptions, called a Model, designed to manipulate knowledge about the System. There can be any number of Models referring to the same System, and there is no requirement that Models of the same System necessarily be compatible with each other (i.e. there is no requirement that assertions of one Model do not contradict assertions of another Model of the same System).

Elements of the System that we can talk about will be called System Referents. Elements of the Model that we can talk about will be called Model Referents.

2. System Referents: Identity and Change

Every System Referent is either an Object or an Event. The distinction is made on the basis of what, in talking about the System, we see as changing vs. what we see as staying the same: an Event entails a change in at least one Object. Ontologically, nothing in an Object ever changes in the absence of Events, and no Events may occur in the absence of Objects.

3. Model Referents

Every Model Referent is either an Instance Description or a Class Description. An Instance Description organizes specific knowledge pertaining to an Object or Event of the System. A Class Description organizes more general knowledge in terms of an abstract collection of Objects and/or Events of the System. There are many techniques and formalisms for constructing Instance Descriptions and Class Descriptions of the kind described here, most recently in the field of software design. In later work, I will be proposing a variant of the Unified Modelling Language (UML) for this purpose, as well as an Extended Markup Language (XML) vocabulary for capturing Models under this ontology.

3.1. Instance Descriptions

Every Instance Description is either an Object Description or an Event Description.

3.1.1. Object Descriptions

An Object Description may include the following kinds of information:

Identity Assertions: a set of assertions which represents the unchanging aspect of the Object
State Assertions: a set of assertions which represents the changing aspect of the Object for a particular interval of time
Trajectory Assertions: a set of assertions which identify Events in which this Object participates
Category Assertions: a set of assertions which identify any Classes (see below) of which this Object is a direct (as opposed to transitive) instance
Container Assertions: a set of assertions which identify any Objects of which this Object is a direct (as opposed to transitive) part
Part Assertions: a set of assertions which identify any Objects which are direct (as opposed to transitive) parts of this Object

3.1.2. Event Descriptions

An Event Description may include the following kinds of information:

Temporal Assertions: a set of assertions which identify the interval of time over which this Event occurs
Participant Assertions: a set of assertions which identify Objects which participate (are changed by) this Event
Antecedent States: the States of this Event's Participants before its Time Interval begins
Subsequent States: the States of this Event's Participants after its Time Interval ends
Category Assertions: a set of assertions which identify any Classes (see below) of which this Event is a direct (as opposed to transitive) instance
Container Assertions: a set of assertions which identify any Events of which this Event is a direct (as opposed to transitive) part
Part Assertions: a set of assertions which identify any Events which are direct (as opposed to transitive) parts of this Event
Cause Assertions: a set of assertions which identify any Events which influence this Event
Effect Assertions: a set of assertions which identify any Events which this Event influences

3.2. Class Descriptions

Every Class Description is either an Object Class Description, an Event Class Description or a Metaclass Description.

3.2.1. Object Class Descriptions

An Object Class Description may include the following kinds of information:

Superclass Assertions: a set of assertions which identify any Classes all of whose assertions hold for every Object that is an instance of this Class
Identity Constraints: a set of Identity Assertions which hold for every Object that is an instance of this Class
State Constraints: a set of State Assertions which hold for every Object that is an instance of this Class
Trajectory Constraints: a set of Trajectory Assertions which hold for every Object that is an instance of this Class
Category Constraints: a set of Category Assertions which hold for every Object that is an instance of this Class
Container Constraints: a set of Container Assertions which hold for every Object that is an instance of this Class
Part Constraints: a set of Part Assertions which hold for every Object that is an instance of this Class

3.2.2. Event Class Descriptions

An Event Class Description may include the following kinds of information:

Superclass Assertions: a set of assertions which identify any Classes all of whose assertions hold for every Event that is an instance of this Class
Temporal Constraints: a set of Temporal Assertions which hold for every Event that is an instance of this Class
Participant Constraints: a set of Participant Assertions which hold for every Event that is an instance of this Class
Antecedent State Constraints: a set of Antecedent State Assertions which hold for every Event that is an instance of this Class
Subsequent State Constraints: a set of Subsequent State Assertions which hold for every Event that is an instance of this Class
Category Constraints: a set of Category Assertions which hold for every Event that is an instance of this Class
Container Constraints: a set of Container Assertions which hold for every Event that is an instance of this Class
Part Constraints: a set of Part Assertions which hold for every Event that is an instance of this Class
Cause Constraints: a set of Cause Assertions which hold for every Event that is an instance of this Class
Effect Constraints: a set of Effect Assertions which hold for every Event that is an instance of this Class

3.2.3. Metaclass Descriptions

A Metaclass Description identifies a set of Classes which share some property and may include the following kinds of information:

Superclass Assertions: a set of assertions which identify any Metaclasses all of whose assertions hold for every Metaclass that is an instance of this Metaclass
Metaclass Constraints: a set of assertions which hold for every Class that is an instance of this Metaclass

Metaclass Example

Consider the following terms:

Hydrogen: subclass of Atom such that each instance has exactly one proton
Helium: subclass of Atom such that each instance has exactly two protons
Lithium: subclass of Atom such that each instance has exactly three protons
etc.: subclass of Atom such that each member has exactly N protons
Atom: an Object which contains 1 or more protons, 0 or more neutrons and 0 or more electrons
Element: "atoms with a constant number of protons"

How can the term 'Element' be defined in terms of Atom, Hydrogen, Helium and all the rest?

We may be tempted to consider 'Element' as a Superclass of 'Hydrogen', 'Helium', 'Lithium' etc. If that were so, then 'Element' would contain the union of all its subclasses: exactly the set of all Atoms. But that would mean that 'Element' and 'Atom' refer to exactly the same thing. Is 'Element' synomymous with 'Atom'? Clearly not: the term 'Element' is always defined (if perhaps less formally) in terms of Atoms having the same number of protons.

Is 'Element' perhaps a Superclass of 'Atom'? If so, then it is also a Superclass of 'Hydrogen', 'Helium', 'Lithium' etc. and the problem illustrated in the previous paragraph would hold here as well.

The important realization that must be made here is that 'Element' does not in fact refer to a set of Objects at all: it refers to a set of Classes. 'Element' refers to all Subclasses of Atom which are defined in terms of the number of protons they contain. An instance of Element, then, is a subclass of Atom whose instances all have the same number of protons. Lithium is an instance of the Metaclass 'Element' because (a) Lithium is a subclass of Atom (everything we can assert about Atom will be true about Lithium) and (b) all instances of Lithium have the same number of protons (three, to be specific).

4. The Process of Conceptual Analysis

The intellectual process of constructing a Model to help manipulate knowledge about a System will be referred to here as Conceptual Analysis. This process proceeds in five overlapping subprocesses, as identified below and briefly sketched in the following sections.

System Identification: add Identity, State and Temporal Assertions/Constraints to a Model
Taxonomic Analysis: add Superclass Assertions and Category Assertions/Constraints to a Model
Structural Analysis: add Container and Part Assertions/Constraints to a Model
Dynamic Analysis: add Participant, Antecedent State, Subsequent State and Trajectory Assertions/Constraints to a Model
Semiotic Analysis: add Cause and Effect Assertions/Constraints to a Model

4.1. System Identification

Starting from an empty Model, the tasks of the System Identification process are to construct

a set of Object Descriptions to be included in the Model
a set of Identity and State Assertions for the Object Descriptions
a set of Event Descriptions to be included in the Model
a set of Temporal Assertions for the Event Descriptions

After other processes have added information to the Model, this process may be revisited as needed to introduce new descriptions or Identiy, State or Temporal Assertions.

4.2. Generalization and Taxonomic Analysis

After at least one iteration of the System Identification process, the tasks of the Taxonomic Analysis process are to construct

a set of Category Assertions for the Object and Event Descriptions of the Model
a set of Object Class, Event Class and Metaclass Descriptions for the Model
a set of Category Constraints for the Object Class and Event Class Descriptions
a set of Superclass Assertions for the Descriptions
a set of Metaclass Constraints for the Metaclass Descriptions

Assertions relating Instances to their Classes, and Classes to their Superclasses and Metaclasses, can be expressed as a Taxonomic Hierarchy. In many cases, more than one Taxonomic Hierarchy may be possible in the same Model, each adding richness to our understanding of the System. Taxonomic Analysis will often proceed in lock-step with Structural Analysis (see below).

4.3. Aggregation and Structural Analysis

After or during at least one iteration of the Taxonomic Analysis process, the tasks of the Structural Analysis process are to construct

a set of Container and Part Assertions for the Object and Event Descriptions of the Model
a set of Container and Part Constraints for the Object Class and Event Class Descriptions of the Model

A simple Object would have no parts, but most Objects are complex -- they have other, less inclusive Objects as parts. A simple Event would involve only the changes that define it, but most Events are complex -- they have other, less inclusive Events as parts.

Structural Analysis of an Instance involves the discovery of less inclusive Instances which are part of the Instance in question. Assertions relating Containers with their Parts can be expressed as a Structural Hierarchy. In many cases, more than one Structural Hierarchy may be possible in the same Model, each adding richness to our understanding of the System.

Note that Structural Analysis will generally be carried out on whole Classes of Objects or Events, or else structural and taxonomic analysis will proceed in lock-step with each other (since the identification of Structural Hierarchies often leads to generalizations suggesting the creation of additional Class Descriptions).

Example

Human
  SkeletalSystem
  MuscularSystem
  EndocrineSystem
  RespiratorySystem
  CardiovascularSystem
  IntegumentarySystem
  DigestiveSystem
  NervousSystem
  UrinarySystem
  ReproductiveSystem
  LymphaticSystem

4.4. Behavior and Dynamic Analysis

After or during at least one iteration of the Taxonomic and Structural Analysis processes, the tasks of the Dynamic Analysis process are to construct

Trajectory and Participant Assertions for the Object and Event Descriptions of the Model
Trajectory and Participant Constraints for the Object Class and Event Class Descriptions of the Model
Antecedent and Subsequent State Assertions for the Event Descriptions of the Model
Antecedent and Subsequent State Constraints for the Event Class Descriptions of the Model

Given a set of taxonomic and structural hierarchies for a population of Objects and Events, one interesting avenue for further study is the way in which the Objects and Events relate to each other. What is the behavior of our Objects, in terms of the Events which change them?

Dynamic analysis involves the discovery and capture of generalizations about the Events which change the Objects of a certain Class. This may proceed using the Classes of Objects and Events already discovered, but it may also lead to the discovery of additional Classes based on the behavior discovered.

4.5. Influence and Semiotic Analysis

In previous stages of analysis, the repertoire of Events was established in which a particular kind of Object participates. It will generally be clear at this point that the Events of a given Object are not entirely random: the occurrence of one Event allows us to predict the occurrence of another Event. We say that the former Event influences the latter Event.

We may be tempted to use the word cause instead of influence, but this would open a Pandora's box of ontological problems that would be self-defeating in the end. We assume that there is no Event in the real world which has just one other Event as its "cause". That being the case, no Event which is identified as "a cause" is given any particular priority over other such "causal" Events. Such "partial causes" are better termed influences. Only if we had complete knowledge of every influence on an Event would it be reasonable to speak of "the cause" of that Event. Because I assume that such complete knowledge is unattainable, I prefer to emphasize the weakness of "causal" claims by referring to the relationship as influence instead of causation.

Semiotic Analysis, as practiced here, involves the discovery and capture of generalizations about the way Events influence each other. It is called "semiotic" because I believe that

signs are Events, not Objects, although they may be associated with "substance" Objects which participate in their occurrence;
signs can stand for something because one part of their occurrence (the sign's "form") influences another part (the sign's "meaning");
any pattern of influence can be formulated in terms of signs; and
the long-established conceptual apparatus of semiotics, once re-analyzed under this proposed ontology, is useful for the understanding of any complex system (and its Descriptions)

Semiotic Analysis may proceed using the Event Classes already discovered, but it may also lead to the discovery of additional Classes based on the patterns of influence discovered.