Table of Contents

Introduction
Upper Ontology
  ModelReferents
  SystemReferents
An Ontology of Signs
Ergosemiotics
Biosemiotics
Noosemiotics

Introduction

"There was a passionate craving among all ... [intellectuals] ... for a means to express their new concepts. They longed for philosophy, for synthesis. The erstwhile happiness of pure withdrawal each into his own discipline was now felt to be inadequate. Here and there a scholar broke through the barriers of his specialty and tried to advance into the terrain of universality. Some dreamed of a new alphabet, a new language of symbols through which they could formulate and exchange their new intellectual experiences."

It is just such a "new language of symbols" that is the goal of the ontology set out in this document. It is a pan-semiotic ontology of complex systems, a glass bead game of energy, life and consciousness.

The current version of this document is the first draft of a collection of ontologies currently under intense development. It was deemed more fruitful to provide this material online as soon as possible, so that interested members of the ontology, semiotics and complex systems communities can see it and provide input, than to proceed with further elaboration behind closed doors, as it were. A glass bead game should have more than one player.

It is hoped that this early draft will suffice for a certain degree of exploratory construction of lower ontologies. Such exploration will then serve to refine subsequent versions of the ontologies described here. One glass bead game should lead to another.

Upper Ontology

U0100. A Term is a (vaguely natural-language) constant which is used in the representation of knowledge.

U0200. A Referent is anything about which knowledge can exist.

U0200.10 Every Term names a Referent.

U0200.20 Not every Referent is necessarily named by a Term.

U0200.30 Every Referent is either a SystemReferent or a ModelReferent.

ModelReferents

U0300. A ModelReferent is a Referent that is not a SystemReferent.

U0300.10 Terms, Frames and Slots are ModelReferents.

U0400. A Frame is a ModelReferent which introduces a Term and uses it to identify a Referent.

U0500. The Term naming a Frame may be referred to simply as the Name of that Frame.

U0600. With respect to a given Frame, a Slot identifies one or more Referents in terms of the Referent identified by that Frame, and introduces a Term to name the Slot.

U0600.10 Different kinds of Frame may be defined by specifying one or more required Slots; constraints on the Referents possibly identified by a Slot may also be specified.

U0700. The Term naming a Slot may be referred to simply as the Name of that Slot.

U0800. The Referent(s) identified by a Slot may be referred to simply as the Value of that Slot.

U0900. An Assertion is a Frame containing three Slots, called LeftReferent, Relation and RightReferent.

U0900.10 An Assertion represents a certain kind of potentially asymmetric binary association, which is named by a Term in the Relation Slot, between two Referents, which are identified by the LeftReferent and RightReferent Slots.

U0900.20 The Relation Slot of an Assertion contains exactly one of the following Terms: instance-of, kind-of, part-of, occurs-on, identical-to, influences.

U0900.30 Correspondingly, every Assertion is either an InstanceAssertion, a SubclassAssertion, a PartAssertion, an OccurrenceAssertion, an IdentityAssertion or an InfluenceAssertion.

U0900.40 Every Assertion has certain entailments, i.e. other Assertions that are implied when the first Assertion is stated.

U0900.50 Each of the six types of Assertion has a different pattern of entailments, as specified in this ontology.

U1000.An Assertion is associated with a Frame if the Term naming the Frame occurs as the LeftReferent or the RightReferent of that Assertion.

U1100. A Class is a Frame containing a Slot called Constraints, each value of which is an Assertion that is associated with the Frame.

U1200. A Class can be thought of extensionally as a set of Referents, called its Extension.

U1200.10 Including an Assertion in the Constraints of a Class has certain entailments for each element of the Extension of that Class, as specified in this ontology.

U1200.20 Every Class is either a SystemClass or a MetaClass.

U1300. A SystemClass is a Class whose Extension is a set of SystemReferents.

U1400. A MetaClass is a Class whose Extension is a set of Classes.

U1500. The Relation Slot of an Assertion can contain the Term instance-of; such an Assertion is called an InstanceAssertion.

U1500.10 The LeftReferent of an InstanceAssertion must be a SystemReferent or a Class (SystemClass or MetaClass).

U1500.20 The RightReferent of an InstanceAssertion must be a Class (SystemClass or MetaClass).

U1500.30 If the LeftReferent of an InstanceAssertion is a SystemReferent, then the RightReferent of that Assertion must be a SystemClass.

U1500.40 If the LeftReferent of an InstanceAssertion is a Class (SystemClass or MetaClass, then the RightReferent of that Assertion must be a MetaClass.

U1500.50 An InstanceAssertion describes knowledge that everything entailed by its RightReferent's Constraints is also entailed about its LeftReferent.

U1500.60 Given an InstanceAssertion, its LeftReferent may be referred to simply as an instance of its RightReferent.

U1600. The Relation Slot of an Assertion can contain the Term kind-of; such an Assertion is called a SubclassAssertion.

U1600.10 Both the LeftReferent and the RightReferent of a SubclassAssertion must be SystemClasses, or both must be MetaClasses.

U1600.20 A SubclassAssertion describes knowledge that every Referent that is an instance of the LeftReferent is also an instance of the RightReferent.

U1700. The Relation Slot of an Assertion can contain the Term part-of; such an Assertion is called a PartAssertion.

U1700.10 Both the LeftReferent and the RightReferent of a PartAssertion must either be SystemReferents or Classes.

U1700.20 If both Referents of a PartAssertion are SystemReferents, then the Assertion describes knowledge that the LeftReferent is a part of the RightReferent.

U1700.30 If both Referents of a PartAssertion are Classes, then the Assertion describes knowledge that every instance of the LeftReferent is a part of an instance of the RightReferent; such an Assertion will typically occur as one of the Constraints of a Class.

U1800. The Relation Slot of an Assertion can contain the Term occurs-on; such an Assertion is called an OccurrenceAssertion.

U1800.10 Both the LeftReferent and the RightReferent of an OccurrenceAssertion must either be SystemReferents or SystemClasses.

U1800.20 If both Referents of an OccurrenceAssertion are SystemReferents, then its LeftReferent must be an Event, its RightReferent must be an Object, and the Assertion describes knowledge that the LeftReferent occurs on the RightReferent.

U1800.30 If both Referents of an OccurrenceAssertion are SystemClasses, then its LeftReferent must be a Class of Events, its RightReferent must be a Class of Objects, and the Assertion describes knowledge that every instance of the LeftReferent occurs on an instance of the RightReferent; such an Assertion will typically occur as one of the Constraints of a Class.

U1900. The Relation Slot of an Assertion can contain the Term identical-to; such an Assertion is called an IdentityAssertion.

U1900.10 Both the LeftReferent and the RightReferent of an IdentityAssertion must either be SystemReferents, SystemClasses or MetaClasses. p

U1900.20 An IdentityAssertion describes knowledge that the LeftReferent and the RightReferent are the same Referent.

U2000. The Relation Slot of an Assertion can contain the Term influences; such an Assertion is called an InfluenceAssertion.

U2000.10 Both the LeftReferent and the RightReferent of an InfluenceAssertion must either be SystemReferents or SystemClasses.

U2000.20 If both Referents of an InfluenceAssertion are SystemReferents, then both Referents must be Events and the Assertion describes knowledge that the RightReferent would have occurred differently or not at all if the LeftReferent had occurred differently or not at all.

U2000.30 Given an InfluenceAssertion between two SystemReferents, the LeftReferent may be simply said to influence the RightReferent.

U2000.40 If both Referents of an InfluenceAssertion are SystemClasses, then both Referents must be Classes of Events and the Assertion describes knowledge that every instance of the LeftReferent influences an instance of the RightReferent.

U2000.50 An InfluenceAssertion describes knowledge that the RightReferent, an Event, would have occurred differently or not at all if the LeftReferent, also an Event, had not occurred.

SystemReferents

U2100. A SystemReferent is a Referent that is described as though it existed independently of the description.

U2100.10 Every SystemReferent is either an Event or an Object.

U2200. An Object is a SystemReferent to which parts may be added or from which parts may be removed without that Object necessarily losing identity.

U2200.10 Circumstances may be described under which an Object loses identity upon change of its parts.

U2200.20 Circumstances may be described under which an Object gains identity by convergence of its inaugural parts.

U2300. An Event is a SystemReferent to which parts may not be added and from which parts may not be removed.

U2300.10 Every gain or loss of an Object's parts is an Event.

U2300.20 Every Event is a gain or loss of one or more parts in one or more Objects.

U2400. An Event is said to occur on an Object if that Event is a gain or loss of one or more parts of that Object.

U2400.10 A single Event can occur on more than one Object.

U2500. An Object is said to participate in an Event if that Event occurs on the Object.

U2500.10 More than one Object can participate in a single Event.

U2600. A Collection is a SystemReferent that is identified in terms of its parts.

U2600.10 Every Collection is either an EventCollection or an ObjectCollection.

U2700. An EventCollection is a Collection in which each part is an Event.

U2700.10 An EventCollection is itself an Event.

U2800. An ObjectCollection is a Collection in which each part is an Object.

U2800.10 An ObjectCollection is itself an Object.

U2900. The Trajectory of an Object is an EventCollection of every Event that occurs on the Object.

U2900.10 An Object's Trajectory is itself an Event which has all the Events occurring on the Object as its parts.

U2900.20 The distinction between an Object and its Trajectory is ontological (i.e. for the pragmatic purpose of representing knowledge), not metaphysical (i.e. this ontology does not address any notion of real existence of an Object as distinct from its Trajectory).

U3000. Two Objects are said to interact if there is an Event in which they both participate.

U3000.10 In other words, any Interaction of two Objects entails an Event in which each Object gains or loses one or more parts.

U3100. Two Objects A and B transitively interact if they interact or if there is another Object C with which A and B transitively interact.

U3200. An ObjectCollection is transitively closed under interaction if every Object in the Collection transitively interacts with every other Object in the Collection.

U3300. A System is an ObjectCollection that is transitively closed under interaction.

U3300.10 A System is itself an Object, and therefore also a SystemReferent.

U3400. The SystemTrajectory of a System is an EventCollection containing the Trajectory of each part of the System as a part.

U3500. The Environment of a System is an ObjectCollection containing each Object which interacts with the System and is not itself part of the System.

U3500.10 The Environment of a System S1 will often usefully be modelled as one or more Systems S2-Sn, such that S1-Sn are exactly the parts of a larger System S0.

An Ontology of Signs

S0100. A Sign is an Event that meets three criteria: (a) the Event is described by a Frame containing two Slots, Antecedent and Consequent; (b) the values of both a Sign's Antecedent and its Consequent are Events, such that every part of the Sign is part of either its Antecedent or its Consequent but not both; and (c) the Antecedent of a Sign influences its Consequent.

S0200. A SimpleSign is a Sign which does not contain as a part any other Sign.

S0300. A CompositeSign is a Sign which contains as a part at least one other Sign.

S0400. An Interactor is any System which participates in a Sign.

S0500. A particular Sign is an InternalSign of an Interactor if both its Antecedent and its Consequent occur on the Interactor but not on the Interactor's Environment.

S0600. A particular Sign is an IncomingSign of an Interactor if its Antecedent occurs on the Interactor's Environment but not on the Interactor itself, while its Consequent occurs on the Interactor itself but not on the Interactor's Environment.

S0700. A particular Sign is an OutgoingSign of an Interactor if its Antecedent occurs on the Interactor itself but not on the Interactor's Environment, while its Consequent occurs on the Interactor's Environment but not on the Interactor itself.

S0800. Some collection of Signs of an Interactor may be exhaustively describable as a collection of Sign Classes. In such a case, the collection of Sign Classes is called a Code. Note that more than one Code may describe the same Interactor.

S0900. The Substance of a Sign is the collection of all Interactors on which it occurs.

S1000. Relative to a given Interactor I, the SyntacticSubstance of a Sign is the collection of all parts of I which participate in the Sign's Antecedent.

S1100. Relative to a given Interactor I, the SemanticSubstance of a Sign is the collection of all parts of I which participate in the Sign's Consequent.

S1200. Relative to a given Interactor I, the PragmaticSubstance of a Sign is the collection of all parts of I's Environment that participate in that Sign.

S1300. A SyntacticPattern describes a property of an Interactor with reference to its Signs' SyntacticSubstances, but not to their SemanticSubstances or PragmaticSubstances.

S1400. A SemanticPattern describes a property of an Interactor with reference to its Signs' SemanticSubstance, but not to their SyntacticSubstances or PragmaticSubstances.

S1500. A RealizationPattern describes a property of an Interactor with reference to both the SyntacticSubstances and SemanticSubstances of its Signs, but not to their PragmaticSubstances.

S1600. A PragmaticPattern describes a property of an Interactor with reference to its Signs' PragmaticSubstance.

S1700. A StationaryPattern describes a property which holds for an Interactor over a certain period of time.

S1800. An EvolutionaryPattern describes the way in which a property of an Interactor changes over a certain period of time.

S1900. A MicroPattern describes a property of an Interactor with reference to its parts.

S2000. A MacroPattern describes a property of an Interactor without reference to its parts.

S2100. An EmergentPattern describes a property of an Interactor with reference to both one or more MicroPatterns and one or more MacroPatterns of the Interactor.

S2200. A SyntagmaticPattern describes a property of an Interactor in terms of the positive correlation of Sign subclasses along the Interactor's Trajectory (i.e. the subclass of Sign occurring at one point in the Trajectory correlates positively with the subclasses of Sign occurring nearby in the Trajectory).

S2200.10 SyntagmaticPatterns presuppose distance metrics, not elaborated in this ontology, for determining relative distance between two parts of an Interactor's Trajectory; it will be the task of lower ontologies to elaborate whatever metrics are chosen to support the description of SyntagmaticPatterns.

S2300. A ParadigmaticPattern describes a property of an Interactor in terms of Sign subclasses which correlate syntagmatically (expressed as a subclass of Sign which figures in one or more SyntagmaticPattern).

Ergosemiotics

E0100. EnergyEvents are not further elaborated in this ontology.

E0100.10 It will be the task of lower ontologies to elaborate the Class of EnergyEvents.

E0200. An Ergosystem is an Interactor on which EnergyEvents occur and which is neither a Biosystem nor a Noosystem.

E0200.10 EnergyEvents in Ergosystems are analogous to the similarly unelaborated ConsciousnessEvents (in Noosystems) and LifeEvents (in Biosystems).

E0300. A Particle is a minimal Ergosystem in the sense that it does not contain any other Ergosystem as a part.

E0400. An Aggregate is a (typically intermediate) Ergosystem which may contain both Particles and other Aggregates as parts.

E0500. A Universe is a maximal Ergosystem in the sense that it is not contained in any other Ergosystem as a part.

E0500.10 It follows that a Universe is also an Aggregate.

E0600. A Code which describes an Ergosystem is called an Ergocode.

E0700. A Sign in which an Ergosystem participates is called an Ergosign.

E0700.10 Every Ergosign of an Ergosystem is either a QuantumSign or a MacroSign.

E0800. A QuantumSign is an Ergosign whose Antecedent and Consequent are both Particles.

E0900. A MacroSign is an Ergosign whose Antecedent and Consequent are both Aggregates.

E1000. The Quantome of an Ergosystem is the collection of all the QuantumSigns of that Ergosystem.

E1100. The Macrome of an Ergosystem is the collection of all the ClassicalSigns of that Ergosystem.

Biosemiotics

B0100. LifeEvents are not further elaborated in this ontology.

B0100.10 It will be the task of lower ontologies to elaborate the Class of LifeEvents.

B0200. A Biosystem is an Interactor on which LifeEvents occur, or which contains another Biosystem as a part, and which is not a Noosysem.

B0200.10 LifeEvents in Biosystems are analogous to the similarly unelaborated ConsciousnessEvents (in Noosystems) and EnergyEvents (in Ergosystems).

B0300. A Biostructure is an Ergosystem that is part of a Biosystem.

B0300.10 A Biostructure may have one or more other Biostructures as parts.

B0400. A Cell is a Biosystem which contains only Biostructures as parts.

B0500. An Organism is a Biosystem which has one or more Cells as parts.

B0500.10 An Organism may also contain one or more Biostructures, but not any other Organisms.

B0600. An Ecosystem is a Biosystem which has one or more Organisms as or other Ecosystems as parts.

B0700. A Biosphere is a maximal Ecosystem in the sense that it is ont contained by any other Ecosystem as a part.

B0800. A Code which describes a Biosystem is called a Biocode.

B0900. A Sign in which a Biosystem participates is called a Biosign.

B0900.10 Every Biosign of a Biosystem is either a GeneticSign, MetabolicSign or BehavioralSign of that Biosystem.

B0900.20 Every Biosystem of any type -- Cell, Organism or Ecosystem -- may participate in GeneticSigns, MetabolicSigns and BehavioralSigns (and presumably does).

B0900.30 A Biosign may be a SimpleSign or a CompositeSign.

B1000. A Codon is a Biostructure which is part of a nucleic acid molecule and contains three adjacent nucleotides as its parts.

B1100. A GeneticSign is an InternalSign of a Biosystem whose SyntacticSubstance is one or more Codons.

B1100.10 A GeneticSign of a Biosystem may influence one or more MetabolicSigns of that Biosystem.

B1200. A MetabolicSign is an InternalSign of a Biosystem which is not a GeneticSign.

B1200.10 A MetabolicSign of a Biosystem may influence one or more other Biosigns (Genetic, Metabolic or Behavioral) of that Biosystem.

B1300. A BehavioralSign is a Biosign which is a CompositeSign of a Biosystem and contains at least one IncomingSign and one OutgoingSign of that Biosystem.

B1300.10 A BehavioralSign of a Biosystem may influence one or more MetabolicSigns of that Biosystem.

B1400. The Genome of a Biosystem is the collection of all the GeneticSigns of that Biosystem.

B1500. The GeneticSubstance of a Biosystem is the collection of all the SyntacticSubstances of the GeneticSigns of that Biosystem.

B1500.10 Note that the GeneticSubstance, so defined, corresponds more closely to the conventional concept of "genome" than the Genome defined here: the GeneticSubstance of a Biosystem is an Object, while its Genome is an Event. This departure from convention is inspired by recent conceptions of a "fluid genome".

B1600. The Physiome of a Biosystem is the collection of all MetabolicSigns of that Biosystem.

B1700. The MetabolicSubstance of a Biosystem is the collection of all the SyntacticSubstances of the MetabolicSigns of that Biosystem.

B1700.10 Note that the MetabolicSubstance, so defined, corresponds more closely to the conventional concept of "physiome" than the Physiome defined here: the MetabolicSubstance of a Biosystem is an Object, while its Physiome is an Event. This departure from convention is inspired by analogy with recent conceptions of a "fluid genome".

B1800. The Behaviorome of a Biosystem is the collection of all BehavioralSigns of that Biosystem.

Noosemiotics

N0100. ConsciousnessEvents are not further elaborated in this ontology.

N0100.10 It will be the task of lower ontologies to elaborate the Class of ConsciousnessEvents.

N0200. A Noosystem is an Interactor on which ConsciousnessEvents occur or which contains another Noosystem as a part.

N0200.10 ConsciousnessEvents in Noosystems are analogous to the similarly unelaborated LifeEvents (in Biosystems) and EnergyEvents (in Ergosystems).

N0300. An Individual is a minimal Noosystem in the sense that it does not contain any other Noosystem as a part.

N0400. A Group is a (typically intermediate) Noosystem which may contain both Individuals and other Groups as parts.

N0500. A Noosphere is a maximal Noosystem in the sense that it is not contained in any other Noosystem as a part.

N0500.10 It follows that a Noosphere is also a Group.

N0600. If a Noosystem contains a Biosystem as a part, this Biosystem is called the Body of the Noosystem.

N0600.10 The Body of a Noosystem can be indicated by a Slot on the Frame describing the Noosystem, the value of which identifies a Biosystem.

N0700. A Code which describes a Noosystem is called a Noocode.

N0800. A Sign in which a Noosystem participates is called a Noosign.

N0800.10 Every Noosign of a Noosystem is either a Meme, an Act or a Sensation of the Noosystem.

N0900. An InternalSign of Noosystem is called a Meme.

N1000. An OutgoingSign of a Noosystem is called an Act.

N1100. An IncomingSign of a Noosystem is called a Sensation.

N1200. The Memome of a Noosystem is the collection of all the Memes of that Noosystem.

N1300. The Actome of a Noosystem is the collection of all Acts of that Noosystem.

N1400. The Sensome of a Noosystem is the collection of all Sensations of that Noosystem.