CKML Examples

~ Under Construction ~

See also the OML Examples
Controlled Vocabulary
Color Theory
Movie Genre Theory
RSACi Language Rating Theory
Direct Scaling
Automobile Color Logic
Movie Genre Logic
Simple Scaling
Person Age Logic
Relational Scaling
File Copying Logic
Transaction Logic
Theory of an Ontology
Base Ontology Logic
Theory Sum
CG Top Ontology Sum Theory
Theory Cascade
Tree of Porphyry
Industry Terminology
DFKI KnowMore Project
KnowMore Language
KnowMore Ontologies
Dublin Core Metadata Initiative
Dublin Core
Dublin Core Qualifiers

Overview

To illustrate the ideas and terminology incorporated in CKML, several examples from the Conceptual Graphs and Resource Description Framework communities are developed here in Standard CKML. Just as in the previous versions of CKML, the current version extends OML by the addition of theories (which in earlier version were called abstract conceptual scales), theory morphisms (which model concrete conceptual scales), and infomorphisms (which model realized conceptual scales). We offer three points of view on the relationship between OML and CKML.

  1. From the standpoint of natural language processing, OML defines the types for nouns and verbs, whereas the theories in CKML offer a specification form for the modifiers, adjectives and adverbs.
  2. From the standpoint of library and information science, the theories in CKML offer a means for the specification of "controlled vocabularies."
  3. Finally, from the standpoint of knowledge representation and artificial intelligence, the distinction between a theory (abstract conceptual scale) and a theory interpretation (concrete conceptual scale) corresponds to the distinction between a terminological ontology and an axiomatic ontology. Theories (abstract scales) are pieces cut out of terminological ontologies, whereas theory interpretations (concrete scales) are pieces cut out of axiomatic ontologies. The goal of both types of scales is aimed toward the definition of facets, a third type of scale called a realized conceptual scales. Facets are conceptual spaces representing a single dimension of information.

Many examples show that the type lattice of an ontology can be generated by two processes:

If we paraphrase the definition of ontology and the various useful kinds of ontologies given by John Sowa and others on the onto-std list as expressed below, then OML allows the definition of axiomatic and terminological ontologies but CKML makes these definitions much more distinct and detailed. In particular, parts of terminological ontologies are specified and bounded as theories and parts of axiomatic ontologies are specified and bounded as theory interpretations. The terminological aspect of ontologies corresponds to the notion of an theory, whereas the axiomatic aspect of ontologies corresponds to the notion of a theory interpretation.

The subject of ontology is the study of the categories of things that exist or may exist in some domain. The product of such a study, called an ontology, is a catalog of the types of things that are assumed to exist in a domain of interest D from the perspective of a person who uses a language L for the purpose of talking about D. The types in the ontology represent the predicates, word senses, or concept and relation types of the language L when used to discuss topics in the domain D. An uninterpreted logic, such as predicate calculus, CKML, CGIF, or KIF, is ontologically neutral. It imposes no constraints on the subject matter or the way the subject may be characterized. By itself, logic says nothing about anything, but the combination of logic with an ontology provides a language that can express relationships about the entities in the domain of interest.
An informal ontology may be specified by a catalog of types that are either undefined or defined only by statements in a natural language. A formal ontology is specified by a collection of names for concept and relation types organized in a partial ordering by the type-subtype relation. Formal ontologies are further distinguished by the way the subtypes are distinguished from their supertypes: a terminological ontology is an ontology whose concepts and relations need not be fully specified by axioms and definitions that determine the necessary and sufficient conditions for their use; an axiomatized ontology distinguishes subtypes by axioms and definitions stated in a formal language, such as logic or some computer-oriented notation that can be translated to logic; a prototype-based ontology distinguishes subtypes by a comparison with a typical member or prototype for each subtype. Large ontologies often use a mixture of definitional methods: formal axioms and definitions are used for the terms in mathematics, physics, and engineering; and prototypes are used for plants, animals, and common household items.


Examples

Controlled Vocabulary

Previously, OML needed to specify "controlled vocabularies" as a separate kind of object type or category. In fact, there was a time when we modeled these as special user-defined data types, which is what they actually are. But an even better point of view is to view controlled vocabularies as theories; a fact that supports our view that theories specify data types. This was not possible previously, since conceptual scaling was regarded as a second CKML step of specification, whereas the specification of controlled vocabularies was naturally regarded as occurring in the first OML step. However, with our current view that CKML completes the specification of OML ontologies with a first terminological step and a second axiomatic step, it is entirely natural to specify controlled vocabularies as theories.

The theory definitions below can be compared with the earlier specification in OML as object type definitions. In doing this comparison, one uncovers what at first seems to be a confusion between object types and values. And since values correspond to objects (instances), between object types and objects. Yes, linguistically we are blurring the distinction between type and instance here (in many, but not all, of these theories we are at the bottom of the type hierarchy), but there actually is no problem here, since the normal usage is to reference a generic object or instance using an implicit existential quantifier. For example, if we want to assert that the background color of this web page is white, using the Color theory below, we could use language with an embedded virtual generic instance such as the following.

<WWW:Page about="CKML-Examples.html" text="CKML Examples">
  <background><Color.white/></background> 
</WWW:Page>

Or, we could use language with a referenced virtual generic instance such as the following.

<WWW:Page about="CKML-Examples.html" text="CKML Examples">
  <background obj="Color.white"/> 
</WWW:Page>

Or, we could use language with a referenced actual generic instance such as the following.

<Color.white id="x"/>
<WWW:Page about="CKML-Examples.html" text="CKML Examples">
  <background obj="Color.white#x"/> 
</WWW:Page>

These are all abbreviations for, and entirely equivalent to, the following expression.

<Exists var="color" type="Color.white">
  <WWW:Page about="CKML-Examples.html" text="CKML Examples">
    <background obj="color"/> 
  </WWW:Page>
</Exists>

Theories that are controlled, which specify either sets or enumerations, are called "controlled vocabularies." Sets are listed (as values, see below), but unordered. Enumerations are listed, and totally ordered by the listing: There are first and last elements, and for any arbitrary element, if it is not the first there is a previous element and if it is not the last there is a next element. The specific object types (species) defined within a theory represent elements of a controlled vocabulary. These object type names should be unique within the theory. When prefixed by the theory genus type name ( genus.species ) they will be unique within the ontology.

The genus type of a theory corresponds to a noun, whereas the species types defined within the theory correspond to adjectives that modify that noun along a certain dimension, the dimension of information represented by the theory (conceptual scale).


Color Theory

The following example specifies a "controlled vocabulary" in CKML. This nominal theory represents a (rather limited) collection of color terms. By a nominal theory we mean one where the subtypes partition the genus type. The types within the theory are most properly denoted in the form "genus.species". All such types are automatically subtypes of the genus type of the theory: "genus.species subtype genus". For example, "the color red" would be denoted Color.red, and "the color red" is a special case (subtype) of "a color": Color.red subtype Color.

"Rainbow Colors = {red, orange, yellow, green, blue, indigo and violet}."
CKML (Conceptual Knowledge Markup Language)
(ontology)
(located at the address http://www.color.org/ontology/Color/)
<CKML>
  <Ontology id="Color" version="1.0">
    <extends href="http://www.ckml.org/ontology/" prefix="CKML"/>
    <Theory type="Rainbow" genus="Color">
      <Object type="red"/>
      <Object type="orange"/>
      <Object type="yellow"/>
      <Object type="green"/>
      <Object type="blue"/>
      <Object type="indigo"/>
      <Object type="violet"/>
      <partition>
        <red/><orange/><yellow/><green/><blue/><indigo/><violet/>
      </partition>
    </Theory>
  </Ontology>
</CKML>

Of course, at some point we may decide that these are not enough colors. Say we also need a black color and a white color. Then we merely extend the above theory to include these new colors. This extension theory might be located in the above Color ontology or it might be located in a separate ontology (as below) that extends the Color ontology.

"Day-Nite Colors = Rainbow Colors + {black, white}."
CKML (Conceptual Knowledge Markup Language)
(ontology)
<CKML>
  <Ontology id="MoreColor" version="1.0">
    <extends ontology="http://www.color.org/ontology/Color/"/>
    <Theory type="Day-Nite">
      <extends theory="Rainbow"/>
      <Object type="white"/>
      <Object type="black"/>
      <partition>
        <red/><orange/><yellow/><green/><blue/><indigo/><violet/>
        <white/><black/>
      </partition>
    </Theory>
  </Ontology>
</CKML>

Movie Genre Theory

Movie Genre
 
Action
Adventure
Animation
Children's
Comedy
Crime
Documentary
Drama
Film-Noir
Horror
Musical
Mystery
Romance
Sci-Fi
Thriller
War
Western

The following example specifies a "controlled vocabulary" in CKML. This theory represents the controlled vocabulary used by the Internet Movie Database to describe movie genre. Movie genre are listed in the table at the right and in the textual description below. No constraints between genre are specified. As a result, this generates the smallest theory on the set of genre.

"Genre = {Action, Adventure, Animation, Children's, Comedy, Crime, Documentary, Drama, Film-Noir, Horror, Musical, Mystery, Romance, Sci-Fi, Thriller, War, Western}."
CKML (Conceptual Knowledge Markup Language)
(ontology)
<CKML>
  <Ontology id="Movie" version="1.0">
    <extends href="http://www.ckml.org/ontology/" prefix="CKML"/>
    <Theory type="IMDb.Genre" genus="Genre">
      <Object type="Action"/>
      <Object type="Adventure"/>
      <Object type="Animation"/>
      <Object type="Children's"/>
      <Object type="Comedy"/>
      <Object type="Crime"/>
      <Object type="Documentary"/>
      <Object type="Drama"/>
      <Object type="Film-Noir"/>
      <Object type="Horror"/>
      <Object type="Musical"/>
      <Object type="Mystery"/>
      <Object type="Romance"/>
      <Object type="Sci-Fi"/>
      <Object type="Thriller"/>
      <Object type="War"/>
      <Object type="Western"/>
    </Theory>
  </Ontology>
</CKML>

RSACi Language Rating Theory

The following example specifies a "controlled vocabulary" in CKML. This object type, which represents the RSACi.Language ratings, is specified as an ordinal theory (a total order, in this case).

"The RSACi.Language ratings must be one of five levels {0, 1, 2, 3, 4}."
CKML (Conceptual Knowledge Markup Language)
(ontology)
<CKML>
  <Ontology id="RSACi" version="1.0">
    <extends href="http://www.ckml.org/ontology/" prefix="CKML"/>
    <Theory type="RSACi.Rating.Violence" genus="Rating.Violence">
      ...
    </Theory>
    <Theory type="RSACi.Rating.Nudity" genus="Rating.Nudity">
      ...
    </Theory>
    <Theory type="RSACi.Rating.Sex" genus="Rating.Sex">
      ...
    </Theory>
    <Theory type="RSACi.Rating.Language" genus="Rating.Language">
      <Object type="Level4"/> <comment>Crude, vulgar language or extreme hate speech</comment>
      <Object type="Level3"/> <comment>Strong language or hate speech</comment>
      <Object type="Level2"/> <comment>Moderate expletives or profanity</comment>
      <Object type="Level1"/> <comment>Mild expletives</comment>
      <Object type="Level0"/> <comment>None of the above</comment>
      <subtype specific="Level0" generic="Level1"/>
      <subtype specific="Level1" generic="Level2"/>
      <subtype specific="Level2" generic="Level3"/>
      <subtype specific="Level3" generic="Level4"/>
    </Theory>
  </Ontology>
</CKML>


Direct Conceptual Scaling


Automobile Color Logic

We start the discussion of direct scaling with a simple example: the color of automobiles. This is naturally modeled with the binary relation

<BinaryRelation type="color" srcType="Automobile" tgtType="data.RGB"/>

where the data type RGB denotes the Red-Green-Blue values for the color. For example, a red automobile has RGB value "FF0000". Now, suppose there are seven automobiles - a old Chevrolet convertible, a Dodge truck, a Ford sedan, a Honda Civic, a Jeep Wrangler, a Lotus Esprit sports car and a Volvo luxory sedan. The Chevrolet has been repainted yellow. The Dodge is a two-tone green and blue truck. The Ford is a two-tone sedan with a blue top and a black bottom. The Honda Civic is violet colored, and the Jeep is painted green. The Lotus is blue with a white top, and the Volvo is indigo. The first representation uses the binary color relation.

<CKML>
  <Collection.Automobile>
    <Chevrolet id="c"/>
    <Dodge id="d"/>
    <Ford id="f"/>
    <Honda id="h"/>
    <Jeep id="j"/>
    <Lotus id="l"/>
    <Volvo id="v"/>
  </Collection.Automobile>
  <Collection.color>
    <color src="c" tgt="FFFF00"/>
    <color src="d" tgt="00FF00"/>
    <color src="d" tgt="0000FF"/>
    <color src="f" tgt="0000FF"/>
    <color src="f" tgt="000000"/>
    <color src="h" tgt="4F2F4F"/>
    <color src="j" tgt="00FF00"/>
    <color src="l" tgt="0000FF"/>
    <color src="l" tgt="FFFFFF"/>
    <color src="v" tgt="6B238E"/>
  </Collection.color>
</CKML>

But it is natural to define a simple color theory for this situation, where the common colors are given names. This theory represents a controlled vocabulary of colors. Normally one would interpret the colors with simple conceptual scaling according to their RGB values, but for simplicity we will assume the color binary relation has target type Color and use direct conceptual scaling here. Then the extent of the color relation, the collection of automobile instances, becomes a local logic.

As illustrated below, any binary relation of OML/CKML can be "objectivized" (reified) by being defined in terms of the primitive has incidence relation and the genus type for a reifying theory.

binary (conceptual) relation       reified binary relation
 
     
Direct Conceptual Scaling
(ontology)
(located at the address http://www.example.org/ontology/)
<CKML>
  <Ontology id="example" version="1.0">
    <Theory type="Spectrum" genus="Color">
      <Object type="red"/>
      <Object type="orange"/>
      <Object type="yellow"/>
      <Object type="green"/>
      <Object type="blue"/>
      <Object type="indigo"/>
      <Object type="violet"/>
      <Object type="white"/>
      <Object type="black"/>
      <partition>
        <red/><orange/><yellow/><green/><blue/>
        <indigo/><violet/><white/><black/>
      </partition>
    </Theory>
    <BinaryRelation type="color" srcType="Automobile" tgtType="Color"/>
    <LocalLogic type="Automobile-Color" binrelType="color" theory="Spectrum"/>
    <Collection type="Collection.Automobile" genus="Automobile"/>
  </Ontology>
</CKML>
(collection)
<CKML>
  <Collection.Automobile ontology="http://www.example.org/ontology/">
    <Chevrolet id="c"/>
    <Dodge     id="d"/>
    <Ford      id="f"/>
    <Honda     id="h"/>
    <Jeep      id="j"/>
    <Lotus     id="l"/>
    <Volvo     id="v"/>
    <Automobile-Color>
      <Color.yellow obj="c"/>
      <Color.green  obj="d"/>
      <Color.blue   obj="d"/>
      <Color.blue   obj="f"/>
      <Color.black  obj="f"/>
      <Color.violet obj="h"/>
      <Color.green  obj="j"/>
      <Color.blue   obj="l"/>
      <Color.white  obj="l"/>
      <Color.indigo obj="v"/>
    </Automobile-Color>
  </Collection.Automobile>
</CKML>

Movie Genre Logic

Movie genre provides an interesting example of a binary ontological relation that can be directly used as a classification. So this is an example of the direct method of conceptual scaling. In the movie conceptual space being used by the WAVE system, movie instances can be of several genres. In the ontological metadata for movies, the genre information is modeled as a binary ontological relation.

genre v MovieXGenre

Since the binary genre relation is between an ontological category (Movie) and a controlled vocabulary (Genre), it can be considered a classification. The instances of the ontological category form the token set. This instance metadata is contained in a CKML object collection anchored at the Movie object type. The only information needed from this collection is id and display information. The controlled vocabulary forms the type set. Of course, as indicated by the above example of a movie genre controlled vocabulary, the controlled vocabulary is specified as a theory in the ontology being used. The binary relation is the classification relation

genre = hMovie,typ(Genre),|=i

where Toy Story |= Animation and Casablanca |= Romance for example. This relational instance metadata is contained in a CKML relation collection anchored at the genre relation type.

Note the fact that the controlled vocabulary is a theory has implications for the classification relation. For example, if the theory is a partial order, then the classification relation is most likely closed (on the right) with respect to this order. However, we will ignore this issue in the current discussion, focusing on just how direct conceptual scaling is handled in CKML.

Clearly, the specification form for a classification needs to contain the following information: name (or id) of classification; the token set; the type set; and the classification relation. We will use two specification forms for the classification relation.

  1. An individual incidence in the classification relation is represented as an implicit has relationship. For example, to make the claims that the movie Toy_Story_(1995) is an Animation, and the movie Casablanca_(1942) is an Romance, we use the following specification forms.
        <Animation obj="Toy_Story_(1995)"/>
        <Romance obj="Casablanca_(1942)"/>
    
    Note that these declarations do not assert the existence of the objects (tokens) involve. The hallmark of an assertion of existence is use of the id attribute instead of the obj attribute. The use of these declarations is only to make a claim that the objects are of certain types.
  2. When a large number of incidence relationships must be asserted, an abbreviated form may come in handy. This abbreviated form uses the type set of a token. The type set of a token is represented by the typ element. For example, the following specification makes a claim for three incidence relationships.
        <typ obj="Wrong_Trousers,_The_(1993)">
          <Animation/><Comedy/><Thriller/>
        </typ>
    
Direct Conceptual Scaling

As an example, consider the following classification of 10 top-rated movies. Below this is the representation in CKML using the typ element.

 

Movie Genre
(classification)
<CKML>
  <Ontology id="Movie" version="1.0">
    <BinaryRelation type="genre" srcType="Movie" tgtType="Genre"/>
    <Collection type="Collection.Movie" genus="Movie"/>
    <Collection type="Collection.Genre" genus="genre"/>
    <LocalLogic type="Movie-Genre" binrelType="genre" theory="IMDb.Genre"/>
  </Ontology>
</CKML>

<CKML>
  <Collection.genre ontology="http://www.movie.org/ontology/"/>
    <genre src="Star_Wars_(1977)" tgt="Action"/>
    <genre src="Star_Wars_(1977)" tgt="Adventure"/>
    ...
    <genre src="Citizen_Kane_(1941)" tgt="Drama"/>
  </Collection.genre>
</CKML>

<CKML>
  <Collection.Movie ontology="http://www.movie.org/ontology/"/>
    <Movie id="Star_Wars_(1977)"/>
    <Movie id="Wrong_Trousers,_The_(1993)"/>
    <Movie id="Shawshank_Redemption,_The_(1994)"/>
    <Movie id="Pulp_Fiction_(1994)"/>
    <Movie id="Usual_Suspects,_The_(1995)"/>
    <Movie id="Toy_Story_(1995)"/>
    <Movie id="Schindler's_List_(1993)"/>
    <Movie id="Casablanca_(1942)"/>
    <Movie id="Blade_Runner_(1982)"/>
    <Movie id="Citizen_Kane_(1941)"/>
    <Movie-Genre id="top-ten" ontology="http://www.imdb.com/ontology/">
      <typ obj="Star_Wars_(1977)"><Action/><Adventure/><Drama/><Sci-Fi/><War/></typ>
      <typ obj="Wrong_Trousers,_The_(1993)"><Animation/><Comedy/><Thriller/></typ>
      <typ obj="Shawshank_Redemption,_The_(1994)"><Drama/><Mystery/><Thriller/></typ>
      <typ obj="Pulp_Fiction_(1994)"><Comedy/><Crime/><Drama/></typ>
      <typ obj="Usual_Suspects,_The_(1995)"><Crime/><Film-Noir/><Thriller/></typ>
      <typ obj="Toy_Story_(1995)"><Animation/><Comedy/></typ>
      <typ obj="Schindler's_List_(1993)"><Drama/><War/></typ>
      <typ obj="Casablanca_(1942)"><Drama/><Romance/><War/></typ>
      <typ obj="Blade_Runner_(1982)"><Action/><Drama/><Film-Noir/><Sci-Fi/></typ>
      <typ obj="Citizen_Kane_(1941)"><Drama/></typ>
    </Movie-Genre>
  </Collection.Movie>
</CKML>


Simple Conceptual Scaling

Person Age Logic

The following CKML ontology and collections represent the age of people as described below.

"Terminology used in discussing the age of people includes: Minor, Young, Working, Elderly and Retired. Here 'working' means 'of working age.' One possible interpretation of these terms is that a minor is young, a young person is of working age, an elderly person is retired, and there are no people who are both working and retired."

An Age classification is created by the process of simple conceptual scaling. This process is described in more detail in the discussion about types of conceptual scales.

Theory
The age terminology is first collected into an theory that represents age as a terminological ontology. This theory lists the terminology, and uses sequents (the <subtype> and <partition> elements are sequent abbreviations) to specify an logical (abstract lattice-oriented) semantics for this terminology. This theory is indexed by the category (object type) Person, which means that the token set for the theory is the collection of all instances of type Person.
Theory Interpretation
The age terminology is next given a more concrete interpretation by attaching descriptive unary lambda expressions over data.Natno, the natural numbers data type, to each age term. These term interpretations, which modify the Person type much like adjectives modify a noun, are given as object type definitions with a lambda expression as their content. All such terminological definitions are next collected into a theory interpretation that represents age as an axiomatic ontology. By the definition of theory interpretation, these definitions are required to satisfy the constraints of the corresponding (source) theory.
Infomorphism/Classification
Next we use the state space consisting of the state description age function, specified within the Person object type. This function has a signature, whose domain is the Person object type and whose codomain is data.Natno. Composing this state space with the theory interpretation, gives an infomorphism from the classification of the theory into the event classification of the state space. The splitting classification for this infomorphism is what we are looking for.

 

Person Age TheoryPerson Age Lattice
 
Minor ` Young,  Young ` Working
Elderly ` Retired
Working,Retired `,  ` Working,Retired

    

In CKML this Person Age Theory can be specified as follows.

Person Age Theory
(ontology)
<CKML>
  <Ontology id="PERSON" version="1.0">
    <extends href="http://www.ckml.org/ontology/" prefix="CKML"/>
    <Object type="Person">
      <Function type="age" tgtType="data.Natno"/>
    </Object>
    <Theory type="Age" genus="Age">
      <comment>A theory specifying the structure of age-related types.</comment>
      <Object type="Minor"/>
      <Object type="Young"/>
      <Object type="Working"/>
      <Object type="Elderly"/>
      <Object type="Retired"/>
      <subtype specific="Minor" generic="Young"/>
      <subtype specific="Young" generic="Working"/>
      <subtype specific="Elderly" generic="Retired"/>
      <partition><Working/><Retired/></partition>
      <Interpretation type="interpretation" fnType="Person.age">
        <comment>An interpretation of the age terminology for people</comment>
        <Object type="Minor" var="person" genus="Person">
          <comment>A minor is a person whose age is less than 21.</comment>
          <Person src="person"><age order="less" tgt="data.Natno#21"/></Person>
        </Object>
        <Object type="Young" var="person" genus="Person">
          <comment>A young person is one whose age is less than 40.</comment>
          <Person src="person"><age order="less" tgt="data.Natno#40"/></Person>
        </Object>
        <Object type="Working" var="person" genus="Person">
          <comment>A working person is a person whose age is less than or equal to 65.</comment>
          <Person src="person"><age order="lessEqual" tgt="data.Natno#65"/></Person>
        </Object>
        <Object type="Elderly" var="person" genus="Person">
          <comment>An elderly person is one whose age is greater than 80.</comment>
          <Person src="person"><age order="greater" tgt="data.Natno#80"/></Person>
        </Object>
        <Object type="Retired" var="person" genus="Person">
          <comment>A retired person is a person whose age is greater than 65.</comment>
          <Person src="person"><age order="greater" tgt="data.Natno#65"/></Person>
        </Object>
      </Interpretation>
    </Theory>
  </Ontology>
</CKML>
Ideal Local Logic for a Theory

This is the local logic generated by the Age theory and denoted by Log(Age). Tokens (objects) of this logic are all consistent (binary) partitions of types called formal objects. Formal objects are created as instances of the root type of the theory being used. In CKML this local logic can be represented by adding a local logic type and a collection type to the above PERSON ontology and listing the ideal classification instance for the local logic.

<CKML>
  <Ontology id="PERSON" version="1.0">
    ...
    <Collection type="FormalObjectCollection" genus="Person"/>
    <LocalLogic type="Log(Age)" theory="Age"/>
  </Ontology>
</CKML>

<CKML>
  <FormalObjectCollection ontology="http://www.person.org/ontology/"/>
    <Person id="1"/>
    <Person id="3"/>
    <Person id="4"/>
    <Person id="12"/>
    <Person id="28"/>
    <Log(Age) id="ideal">
      <Retired obj="1"/>
      <Elderly obj="3"/>
      <Retired obj="3"/>
      <Working obj="4"/>
      <Young obj="12"/>
      <Working obj="12"/>
      <Minor obj="28"/>
      <Young obj="28"/>
      <Working obj="28"/>
    </Log(Age)>
  </FormalObjectCollection>
</CKML>
Simple Conceptual Scaling

Now let us consider how simple scaling works. Suppose we are interested in the age logic of a collection of actual objects (in this case persons) {Fred, John, Doris, George, Bill, Elaine, Carol}. Also, suppose that the age of these people is given by the following age state description function.

age(Bill) = 52
age(John) = 67
age(Doris) = 95
age(Carol) = 17
age(Fred) = unknown
age(George) = 88
age(Elaine) = 50

The local logic that results from simple conceptual scaling using the age theory interpretation and the above state description function is as follows.

In CKML this local logic can be represented as follows.

<CKML>
  <Ontology id="PERSON" version="1.0">
    <Collection type="Collection.Person" genus="Person"/>
    <LocalLogic type="Spl(age)" interpretation="Age.interpretation"/>
  </Ontology>
</CKML>

<CKML>
  <Collection.Person ontology="http://www.person.org/ontology/"/>
    <Person id="Fred"/>
    <Person id="John"><age obj="67"/></Person>
    <Person id="Doris"><age obj="95"/></Person>
    <Person id="George"><age obj="88"/></Person>
    <Person id="Bill"><age obj="52"/></Person>
    <Person id="Elaine"><age obj="50"/></Person>
    <Person id="Carol"><age obj="17"/></Person>
    <Spl(age) id="splitting">
      <Retired obj="John"/>
      <Elderly obj="Doris"/>
      <Retired obj="Doris"/>
      <Elderly obj="George"/>
      <Retired obj="George"/>
      <Working obj="Bill"/>
      <Working obj="Elaine"/>
      <Minor obj="Carol"/>
      <Young obj="Carol"/>
      <Working obj="Carol"/>
    </Spl(age)>
  </Collection.Person>
</CKML>

Several facts about this local logic should be notice. It is neither sound nor complete. It is not sound, since Fred's age being unknown gives Fred the all-zero (row) state description, which violates the covering constraint

` Working,Retired.

It is not complete, since there is no person who is young and not a minor. Or equivalently, the following unwanted constraint is valid

Young ` Minor.


Relational Scaling

Ontological relations and finite information channels are intimately involved with each other. On the one hand, underlying each finite information channel

where I = {1,2,...,n}, is an ontological relation, whose relational type is the type set typ(C) of the channel core, whose relational instances are the channel connections (tokens in the channel core), whose participants (argument domains) are the channel components {Ai | i2I}, and whose argument functions are the token maps {fi : C ! Ai | i2I} underlying the channel infomorphisms. On the other hand, any ontological relation

can be conceptually scaled by viewing it as an information channel. The latter idea is the subject of this section on relational scaling. Our thesis is the following: The ideal logic of an ontological relation can be defined and constructed as a policy constraint enrichment of the sum (apposition) of the ideal logics of its participants.

Before Reification After Reification
<Relation type="R"/>
  <argument type="f1" valuetype="A1"/>
  <argument type="f2" valuetype="A2"/>
  ...
  <argument type="fn" valuetype="An"/>
</Relation>
 
<Object type="R"/>
  <Function type="f1" valuetype="A1"/>
  <Function type="f2" valuetype="A2"/>
  ...
  <Function type="fn" valuetype="An"/>
</Object>

Consider any ontological relation type R with n argument types A1,A2, ... ,An. This is specified in a CKML ontology as above. There is a canonical method for the conceptual scaling of an ontological relation in terms of its arguments. The result of the method is the construction of a channel over the ontological relation, as depicted below. The {Ai} are classifications that represent the argument types/domains. These are given by a previous step of conceptual scaling. The {fi : Ai ! R} are infomorphisms, whose token parts are the given ontological relation argument functions {fi : R ! Ai}. The latter are implicitly defined in the collection of instances of the ontological relation type R. The former are to be constructed. The relation channel core classification R = htok(R),typ(R),|=Ri has as its token set tok(R) the instances of the ontological relation type R. The type set typ(R) and the classification relation |=R are to be constructed.

 

The method has two steps. To perform these steps adequately, one must have a good knowledge of the semantics of the relation, and one must also be proficient in the process of representing this semantics as theories over both participants and core.

Appose the Participant Constraints
The preliminary logic of the relation channel core is the apposition of the participant logics. This apposition is the inverse image of the sum of the participant logics along the tupling of the maps {fi}.
  1. Form the sum classification Si2I Ai.
  2. Define the token set of the core channel:
    tok(R) = R.
  3. Define the type set of the core channel:
    typ(R) = Si2I typ(Ai).
  4. Define the core channel classification relation to be the inverse image:
    (a1,a2,...,an|=R ai when fi(ai|=Ai ai.
  5. Form the theory based on the above sum classification. The theory constraints of this preliminary core logic are the sum of the constraints from the participant theories.
Add the Policy Constraints
Add constraints to model the semantics of the particular ontological relation being used. These special semantic constraints, which are above and beyond the constraints absorbed from the participants, set the policy for the information channel being constructed over the ontological relation. Remove rows from the classification that violate any of these new policy constraints. The result is a sound and complete (in fact, ideal) local logic at the core of the relational channel.
No reification: conceptual relation
1st reification: thematic roles
2nd reification: has relation
 
Three ways of expressing an ontological relation

There is a close connection between relational scaling and relational reification. The figure above represents an ontological relation in three ways. The top graph illustrates the ontological relation as a conceptual relation before reification. The relation is directly linked to the participant object types. Such conceptual relation types are disjoint from object types. In the latest version of OML/CKML these conceptual relations have been removed. The middle graph illustrates the ontological relation as a concept after the 1st level of reification. The relation has been "objectivized" and linked to the participants through thematic role functions. This would be the starting representation for the relation in the latest version of OML/CKML. The bottom graph illustrates the ontological relation and the thematic roles after the 2nd level of reification. The thematic roles has been "objectivized" by being defined in terms of the primitive has incidence relation and the corresponding object type for that role.

In the discussion above the ontological relation can be replaced by a lambda expression. In fact, many of these ontological relations are defined as lambda expressions.

The challenge is to see whether the channel construction can be done in a fairly "syntax-directed" fashion. Because of the need for policy constraints (a channel is more than the sum of its parts - see the following dedication in the text by Barwise and Seligman), we believe that this process will not be entirely automatic.

In the same way, the world is not the sum of all the things that
are in it. It is an infinitely complex network of connections among
them. As in the meaning of words, things take on meaning only in
the relationship to each other.
The Invention of Solitude Paul Auster

Checking the OML/CKML grammar for the definition of a lambda expression, it can be seen that the necessary ingredients include:

A starting point for this study might be to restrict to just relations, conjunction, negation and existential quantifier. The participant part of a conjunction of two relations can be handled as a pushout along the channel infomorphisms with common domains. But what about the policy constraints, and what about negation and the existential quantifier?


File Copying Logic

Taken from chapter 15 section 2 of the 1997 book Information flow: The logic of distributed systems. authored by Jon Barwise and Jerry Seligman.

This example models the simple act of copying a file. Files are modeled as objects with various properties, such as size, timestamps such as last-modification-time, icon, MIME type, content, etc. The act of copying a file should preserve some of these properties, but not others. In addition, certain access properties should either allow or prevent the act of file copying.

The distributed system FC for file copying is the following:

Here we have two classifications M and C, and two infomorphisms in and out. The file classification M represents the generic file, whereas the channel core classification C represents the event of copying a file. The tokens of the file classification M are the instances of files on computers spread out over some network. The tokens of the copy (transaction) classification C are the events of successfully copying a file from one machine to another.

Semantics
For simplicity of illustration, there are three types of M, a, b and g. The first two types represent typical, but independent, properties of files. These types should be preserve from any file being copied to its copy. The third type, independent from the other two, represents access restriction: when it is asserted no file copying is allowed. So, g = 0 means no access (file copying) allowed, and g = 1 means access is allowed. The types of C include two copies ain, bin, gin, aout, bout and gout of the types of M (a sum of classifications) labeled with their respective infomorphisms, plus a generic type d which represents all other types of C that are not definable as properties in input/output.

These classifications are specified in the top two tables below. The bottom table specifies the token maps in_ and out_ of the in and out infomorphisms. It is important to note that these maps are precisely the argument maps of the OML ontological relation copy.

Classification M Classification C
Ontological Relation copy
(token part of I/O infomorphisms in_ and out_)

We now make two assumptions.

  1. The non-I/O types of C originate from some classifications N.
  2. The classification C is definable as the apposition (sum) of the classifications (conceptual scales) of all of its participating instances, be they objects or values of a datatype.
    This means we are defining the classification C by defining its typeset and its classification relation as follows.
    typ(C) = typ(M)+typ(M)+typ(N)
    |=C = (in_,out_,out_)* o |=M+M+N.

The semantics discussed above, both the preservation semantics and the access restriction semantics, can be represented by a collection of constraints on typ(C) called file copying policy constraints.

File Copying Participant Constraints File Copying Policy Constraints

There are no nontrivial constraints.
So this is the a priori logic AP(M).
  ain `C aout,    aout `C ain,    `C gin,
bin `C bout,    bout `C bin,    `C gout

Let us first look at the participant logics. The requirement that the participating file logics be the a priori logic means that the logic M is incomplete, since the ideal classification of the a priori logic contains all formal objects (rows). In terms of constraints, the theory generated by the classification M is misleading, since it contains unwanted constraints such as

`M a,b,g,    a `M b,g,    a,b `M g,    g `M a,b

Let us next look at the core logic. As pointed out in the textbook by Barwise and Seligman, the core token c3 is not normal, since it violates the constraint

ain `C aout.

So the logic, whose classification is C and whose theory contains the participant and policy constraints, is not sound. This logic is also not complete, there are unwanted constraints such as

bin  `C  ain.

But this accidental generalization is eliminated when we add the first step of generating a preliminary core by summing the participant logics.


Transaction Logic

 

Consider an electronic commerce site that takes online orders for various products. An example is the pioneering online bookstore amazon.com. To understand the idea, we will use the (order) transaction relationship diagrammed on the right. This relation has five arguments: the Order type, the Person who is the buyer, the Product that is the item to be purchased, the Date of the transaction, and the Natural Number cost (in cents) of the purchase.

The distributed system T  for order transaction is the following:

Here we have six classifications Order, Person, Product, Date, Natno and Transaction, and five infomorphisms type, buyer, item, date, and cost.

Semantics
For simplicity we assume we have two types of orders: regular and special. Special orders are delivered faster, but have a higher cost. We will assume that costs are classified as high, medium or low. There are two types of Products: musicical items and books. Buyers can join a club that gives discounts for certain products at certain times of the year. For any clubMember, there is a discount on books during the summer months, and a special promotional discount on music in september. In the month of december (Christmas shopping) all items are high. However, in the month of january there is a sale, when all items are low. At any other (non-special) time, all items are medium. Unfortunately, any remote buyer cannot be a clubMember (and enjoy discounts) because shipping costs are too high.
From the above discussion, we assume that the types in the classifications Order, Product and Natno form a partition, whereas the types in the classifications Person and Date are only pairwise disjoint. On the left below are the theories for the individual argument classifications, and on the right below are the special constraints for the core relation channel that model our discussion above.
Transaction Participant Constraints Transaction Policy Constraints
Order:
regular,special `,  ` regular,special
Person:
remote,clubMember `
Product:
music,book `,  ` music,book
Date:
january,summer `,  january,september `,
january,december `,  summer,september `,
summer,december `,  september,december `
Natno:
low,medium `,  ` low,medium,
low,high `,  ` low,high,
medium,high `,  ` medium,high
  regular,january ` low
special,january ` medium
december ` high
regular,clubMember,book,summer ` low
special,clubMember,book,summer ` medium
regular,clubMember,music,september ` low
special,clubMember,music,september ` medium
regular ` january,summer,september,december,medium
special ` january,summer,september,december,high

The following are the idealization local logics for the relational participants. Idealization logics use the classification of a theory, which consists of all formal objects (consistent partitions) that satisfy all constraints.

Order Idealization
regular,special `,  ` regular,special
Person Idealization
remote,clubMember `
Product Idealization
music,book `,  ` music,book
Date Idealization
january,summer `,  january,september `,
january,december `,  summer,september `,
summer,december `,  september,december `
Natno Idealization
low,medium `,  ` low,medium,
low,high `,  ` low,high,
medium,high `,  ` medium,high

The theory for the Transaction logic, the relation channel core, has the disjoint union of the type sets of the participants as its type set, and has the union of the participant constraints and the policy constraints as its set of constraints. Since there are 13 types in typ(Transaction), there are 213 = 8192 possible formal objects (consistent partitions) ignoring the participant constraints. But these constraints reduce the number of tokens (objects) in the preliminary core idealization to 2X3X2X5X3 = 180. Then the collection of policy constraints reduces this number even further. The table below shows the first possible tokens listed in numerical order. The number representing a token is the base ten equivalent of the row as binary number. Both tokens 2689 and 2690 represent transactions involving a special order for a remote person of a book during non-special times at either a low or medium cost. As such, these tokens violate the policy constraint

special ` january,summer,september,december,high

So they have been crossed out. Token 2692 satisfies all policy constraints. So this token is a consistent partition (and normal token) of the idealization. Token 2697 represents a transaction involving a special order for a remote person of a book during december at a low cost. As such, this token violates the policy constraint

december ` high

So it also has been crossed out. Et cetra, et cetra.

Transaction Idealization

In practice things are not ideal. Although policy is set by the ontology, various collections may not respect that policy and actually be unsound. Consider the following situation. We have a transaction relation with three instances t1, t2 and t3.

Transaction Relation
(token part of channel infomorphisms)

So type(t1) = o1, ... , item(t2) = c2, etc. The actual (non-ideal) classification in the participants looks like the following. Token t1 represents a transaction involving an order for a club member of a book during summer at a low cost. However, it is unknown whether the order is regular or special. As a result the o1 row is all zero in the Order classification. This violates the Order participant constraint (error of omission - lack of knowledge)

` regular,special.

Token t2 represents a transaction involving an regular order for a club member of music in september at a medium cost. This violates the policy constraint (error of commission - the distributor is charging too much)

regular,clubMember,music,september ` low,

which appears in the Transaction classification. These tokens (although abnormal) have not been crossed out in the matrices, since now we are considering local logics in participants and core. These need be neither sound nor complete. Token t3 represents a transaction involving an order (special) by a (remote) person for some (music) item in december at a high cost. This satisfies all constraints, participant and policy. As such, it is a normal token everwhere. As can be seen below, the Order logic is complete but not sound, the Person and Date logics are sound but not complete, the Product and Natno logics are both sound and complete, and the Transaction logic is neither sound nor complete.

Order Classification
regular,special `,  ` regular,special
Person Classification
remote,clubMember `
Product Classification
music,book `,  ` music,book
Date Classification
january,summer `,  january,september `,
january,december `,  summer,september `,
summer,december `,  september,december `
Natno Classification
low,medium `,  ` low,medium,
low,high `,  ` low,high,
medium,high `,  ` medium,high

The following table shows the Transaction classification for this non-ideal situation. When joined with the transaction theory, this gives a local logic that is neither sound nor complete.

Transaction Classification


Theory of an Ontology

Base Ontology Logic

Any ontology has an underlying theory consisting of all ontological constituents (types, theories, intrerpretations, etc.) and their lattice-oriented relationships. We illustrate this with the CKML/OML Base Ontology. However it works for all ontologies, and represents the most fundamental penetration of the IF approach into the use of ontological methods in knowledge representation.

The following CKML ontology represents as an terminological ontology the Base Ontology of OML. This ontology has the following types: Entity, Type, Object, Relation, Function, Data, ObjectInstance, RelationInstance, Collection, Ontology, LambdaExpression, Logical Expression, etc. These are related by subtype and partition as in the diagram below. We ignore here the arguments of relations; if the relation is reified these would become functions. Also, we are representing the OML base ontology, not the CKML base ontology. The latter would also include theories, interpretations, and classifications.

<CKML>
  <Ontology id="OML" version="0.2">
    <comment>This is the base ontology for the Ontology Markup Language.</comment>
    <Theory type="OML" genus="Entity">
      <Object type="Entity"/>
      <Object type="Type"/>
      <Object type="Object"/>
      <Object type="Relation"/>
      <Object type="Function"/>
      <Object type="ObjectInstance"/>
      <Object type="RelationInstance"/>
      <Object type="Collection"/>
      <Object type="Ontology"/>
      <Object type="Data"/>
      <Data type="String"/>
      <Data type="Date"/>
      <Data type="Boolean"/>
      <Data type="Natno"/>
      <Data type="Integer"/>
      <Data type="Real"/>
      <Relation type="instance"/>
      <Relation type="subtype"/>
      <Relation type="comment"/>
      <Relation type="text"/>
      <Relation type="argument"/>
      <Relation type="uses"/>
      <Relation type="extends"/>
      <Function type="type"/>
      <Function type="source"/>
      <Function type="target"/>
      <Function type="definition"/>
      <Function type="descriptor"/>
      <Function type="argument"/>
      <subtype specific="Type" generic="Entity"/>   
      <subtype specific="Object" generic="Type"/>   
      <subtype specific="Data" generic="Type"/>   
      <subtype specific="Relation" generic="Type"/>   
      <subtype specific="Function" generic="Type"/>   
      <subtype specific="ObjectInstance" generic="Entity"/>   
      <subtype specific="RelationInstance" generic="Entity"/>   
      <subtype specific="Collection" generic="Entity"/>   
      <subtype specific="Ontology" generic="Entity"/>
      <subtype specific="LambdaExpression" generic="Entity"/>
      <subtype specific="LogicalExpression" generic="LambdaExpression"/>
      <partition>
        <Object><Function><Relation><Data>
        <ObjectInstance><RelationInstance>
        <Collection><Ontology><LambdaExpression>
      </partition>
    </Theory>
    <Theory type="Boole" genus="TruthValue">
      <Object type="True"/>
      <Object type="False"/>
      <partition><True/><False/></partition>
    </Theory>
  </Ontology>
</CKML>

As ontologies go, the CKML/OML Base ontology is rather special, since it not only has a underlying theory. but, since certain constituents are instances of other constituents, it also has an underlying classification. This is diagramed in the base ontology classification matrix below. Put together, the CKML/OML base ontology is a local logic. We will try to explain the axiomatization of the base ontology in terms of this logic.

 
Base Ontology Classification

 


Theory Sum

CG Top Ontology Sum Theory

The following CKML ontology represents as an terminological ontology the Appendix B: Top Ontology of the 1999 book by John F. Sowa entitled "Knowledge Representation: Logical, Philosophical, and Computational Foundations". This representation uses the conceptual scaling specification techniques of CKML in order to factor the Top Ontology in terms of the three distinctions: the Heraclitus distinction physical-abstract; the Peirce distinction firstness-secondness-thirdness or thing-relation-mediation; and the Temporal distinction continuant-occurrent.

Matrix of the twelve central categories of the Top Ontology
[Figure 2.7 of Sowa]

Chapter 2, the most philosophical chapter of Sowa's book, introduces the subject of ontology, which is a study of categories of existence. In particular, section 2.3 Top-Level Categories discusses principles and techniques for generating the categories in any ontology, and in particular the categories in the Top Ontology. This discussion is closely related to the subject of conceptual scaling in conceptual knowledge processing. For an historical view of conceptual scaling, see the article Conceptual Scaling by Berhard Ganter and Rudolf Wille (1989). For a modern view of simple conceptual scaling in terms of information flow, see the page on types of conceptual scales.

The subsection of chapter 2 on Contrasts, distinctions, and categories is the most relevant. The term contrast corresponds to theory, with discrete distinction corresponding to nominal theory and continuous gradation corresponding to ordinal theory. The following paraphrases an excerpt from a table in Ganter & Wille.

Standardized Theories of Ordinal Type
SymbolDefinitionNameBasic Meaning
OP(P,P,<=)ordinal theoryhierarchy
Nn(n,n,=)nominal theorypartition

The three fundamental distinctions (Heraclitus, Peirce and Temporal) can be modeled as three nominal theories. These regular theories are the closure of the following theories.

H=Heraclitus : ` Physical,Abstract,    Physical,Abstract `
P=Peirce : ` Thing,Relation,Mediation,    Thing,Relation `,    Thing,Mediation `,    Relation,Mediation `
T=Temporal : ` Continuant,Occurrent,    Continuant,Occurrent `

The Top Ontology is generated from the sum H+P+T of these nominal theories. To construct this: first, compute the (ideal) classifications of each of the individual theories, and second, take the sum of these. The type set is the disjoint union of typ(H) = {Physical, Abstract}, typ(P) = {Thing, Relation, Mediation} and typ(T) = {Continuant, Occurrent}. The token set is the Cartesian product of the token sets of the individual classifications. The (ideal) classification of the sum is displayed in the following table. The rows in this table are all of the consistent partitions (formal objects) of the sum theory.

 
Cla(H+P+T) : The (ideal) classification of the theory sum
Mathematical Fact

The Top Ontology is the concept lattice of the (ideal) classification of the sum H+P+T of the nominal theories corresponding to the three distinctions: Heraclitus, Peirce and Temporal. This is denoted

LCla(H+P+T).

This lattice has 37 = 1 + 7 + 16 + 12 + 1 formal concepts; the top concept, 7 = 3+2+2 type concepts, 16 = (3*2)+(3*2)+(2*2) binary type conjunctions, 12 = 3*2*2 binary type conjunctions, and the bottom concept. The diagram below, taken from Sowa, represents this concept lattice. For simplicity, in this diagram 10 categories (formal concepts) were left out: PhysicalContinuant (PC), PhysicalOccurrent (PO), AbstractContinuant (AC), AbstractOccurrent (AO), FormalContinuant (1C), FormalOccurrent (1O), RelativeContinuant (2C), RelativeOccurrent (2O), MediatingContinuant (3C) and MediatingOccurrent (3O).

The "generator" categories toward the top of the Top Ontology, the so-called meet-irreducible elements in the lattice of categories, are the basic types within the nominal theories in the ontology.

<CKML>
  <Ontology id="TopCGontology" version="1.0">
    <extends href="http://www.ckml.org/ontology/" prefix="CKML"/>
    <Object type="Entity"/>      <comment>root</comment>
<Theory type="Heraclitus" genus="Entity"> <comment>Heraclitus's two-way distinction<comment> <Object type="Physical"/> <comment>physis</comment> <Object type="Abstract"/> <comment>logos</comment> <partition><Physical/><Abstract/></partition> </Theory>
<Theory type="Peirce" genus="Entity"> <comment>Peirce's three-way distinction<comment> <Object type="Thing"/> <comment>1st</comment> <Object type="Relation"/> <comment>2nd</comment> <Object type="Mediation"/> <comment>3rd</comment> <partition><Thing/><Relation/><Mediation/></partition> </Theory>
<Theory type="Temporal" genus="Entity"> <comment>Whitehead's two-way temporal distinction<comment> <Object type="Continuant"/> <comment>stable</comment> <Object type="Occurrent"/> <comment>in state of flux</comment> <partition><Continuant/><Occurrent/></partition> </Theory>
</Ontology> </CKML>


Theory Cascade

Often ontologies are built up incrementally by starting with a core theory and then embedding additional theories whose root category (genus object type) is some type defined in the previously nested theory. We picture this as in the diagram on the right. One example is the well-known tree of Porphyry. Another example is the case of multilevel terminologies.

The Tree of Porphyry

The following CKML ontology and collections represent the Tree of Porphyry. The Tree of Porphyry was described in the 1999 text by John Sowa. See also the discussion in the manuscipt (work in progress) paper by John S Wilkins entitled A Taxonomy of Species Definitions: Or, Porphyry's Metatree. According to Sowa, Porphyry's Tree first appeared in the third century AD in the margin of a commentary On Aristotle's Categories by the philosopher Porphyry.

The type lattice in this example is generated by the fan-out process mentioned above - the use of theories, especially nominal theories, to expand at any taxonomic category. The categories are arranged by genus (supertype) and species (subtype). The features that distinguish different species of the same genus are called differentiae. Inheritance is the process of merging all the differentiae along a path above any category.

Tree of Prophyry (by the theories)
(ontology)
<CKML>
  <Ontology id="TreePorphyryOntology" version="1.0">
    <extends href="http://www.ckml.org/ontology/" prefix="CKML"/>
    <Object type="Substance"/>
    <Theory type="1stDistinction" genus="Substance">
      <Object type="material"/>
      <Object type="immaterial"/>
      <partition><material/><immaterial/></partition>
      <Theory type="2ndDistinction" genus="Body">
        <Object type="animate"/>
        <Object type="inanimate"/>
        <partition><animate/><inanimate/></partition>
      </Theory>
      ...
    </Theory>
    <Object type="Body"/>
      <Lambda var="x" type="Substance.material"/>
    </Object>
    <Object type="Spirit"/>
      <Lambda var="x" type="Substance.immaterial"/>
    </Object>
    <Object type="Living"/>
      <Lambda var="x" type="Body.animate"/>
    </Object>
    <Object type="Mineral"/>
      <Lambda var="x" type="Body.inanimate"/>
    </Object>
    ...
    <Collection type="Collection.Human" genus="Human"/>
  </Ontology>
</CKML>
(object collection)
<CKML>
  <Collection.Human 
    ontology="http://www.philosophy.org/ontology/prophyry/">
    <Person id="Socrates"/>
    <Person id="Plato"/>
    <Person id="Aristotle"/>
    ...
  </Collection.Human>
</CKML>

Industry Terminology

Here is an example of multi-level vocabularies. This example is terminology for Australian Industry. Here Industry is the root type, with Agriculture an immediate subtype, and Beekeeping a subtype of that. So a distinct name for Beekeeping in the AustralianIndustry ontology would be given by the pathname "Industry.Agriculture.Beekeeping".

Industry
 
Australian Industry Terminology
(ontology)
<CKML>
  <Ontology id="AustralianIndustry" version="1.0">
    <extends href="http://www.ckml.org/ontology/" prefix="CKML"/>
    <Object type="Industry"/>
    <Theory type="Industry" genus="Industry">
      <Object type="Agriculture"/>
      <Object type="Building&Construction"/>
      <Object type="Business&Personal-Services"/>
      <Object type="Communications"/>
      <Object type="Cultural-Industries"/>
      <Object type="Education&Training"/>
      <Object type="Finance&Insurance"/>
      <Object type="Fishing"/>
      <Object type="Government"/>
      <Object type="Health&Community-Services"/>
      <Object type="Information-Technology"/>
      <Object type="Manufacturing&Processing"/>
      <Object type="Mining"/>
      <Object type="Retailing"/>
      <Object type="Tourism&Recreation"/>
      <Object type="Transport&Storage"/>
      <Object type="Wholesaling"/>
      <partition>
        <Agriculture/><Building&Construction/>
        <Business&Personal-Services/><Communications/>
        <Cultural-Industries/><Education&Training/>
        <Finance&Insurance/><Fishing/>
        <Government/><Health&Community-Services/>
        <Information-Technology/><Manufacturing&Processing/>
        <Mining/><Retailing/><Tourism&Recreation/>
        <Transport&Storage/><Wholesaling/>
      </partition>
      <Theory type="Agriculture" genus="Agriculture">
        <Object type="Beekeeping"/>
        <Object type="Horticulture&Fruit-Growing"/>
        <Object type="Grain&Crop-Growing"/>
        <Object type="Dairy-Cattle-Farming"/>
        <Object type="Poultry-Farming"/>
        <Object type="Sheep&Beef-Cattle-Farming"/>
        <Object type="Other-Livestock-Farming"/>
        <Object type="Exotic-Animal-Farming"/>
        <Object type="Seed&Plant-Collector"/>
        <Object type="Hunting&Trapping"/>
        <Object type="Forestry&Logging"/>
        <Object type="Services-to-Agriculture"/>
        <partition>
          <Beekeeping/><Horticulture&Fruit-Growing/>
          <Grain&Crop-Growing/><Dairy-Cattle-Farming/>
          <Poultry-Farming/><Sheep&Beef-Cattle-Farming/>
          <Other-Livestock-Farming/><Exotic-Animal-Farming/>
          <Seed&Plant-Collector/><Hunting&Trapping/>
          <Forestry&Logging/><Services-to-Agriculture/>
        </partition>
      </Theory>
      ...
    </Theory>
  </Ontology>
</CKML>

 

Please send questions, comments and
suggestions about this page to:
Robert E. Kent rekent@eecs.wsu.edu

Last modification date: February 1999