Part II is about using Amine to build ontologies.
As you will already know from having read the Ontology chapters in Module I, an ontology is a catalog of the categories that exist in some domain of interest.
Amine is a whole suite of applications. However, in this part, we will only deal with the ontology-builder of Amine.
Next, we show how to get started with Amine.
When you run Amine, you will get a window like this:
To start the LexiconsOntology tool, which is what we will concentrate on in this module, click its icon:
Do so now.
When you start the LexiconsOntology tool, you will get a an empty screen like this:
You now have two choices:
Each of these has its own shortcut on the toolbar:
For now, we wish to create a new ontology. Therefore, click the "New" button:
What starts now is a "Wizard" of sorts. Its purpose is to set some basic parameters that are needed for creating an empty ontology.
The "wizard" has four steps:
We will explain before each step what happens in the step and why.
Please go through these in order.
The first step of the wizard sets the language(s) that are going to be used with the ontology. Amine supports using several languages (e.g., English, French, Danish) in the same ontology.
However, in this module we shall not use the multilingual capabilities of Amine, but rather concentrate on English as the sole language in which to express our ontologies.
The first step of the wizard starts out with an empty dialog box like this:
In order to add a language (e.g., English), press the "Add" button:
Do so now.
You will be presented with the following dialog box:
Write "English" (without the quotes) in the dialog box, and click "OK".
The first dialog box will now look like this:
One could have added another language now, but we shall not need to do so in this course, so please don't do it.
In order to go to the next step of the "Wizard", click "OK":
Do so now.
Step 2 of the wizard sets the main language to be used with the ontology.
Since we have only added one language in the previous step, this is easy: There is only one to choose from.
To move on, simply press "Select":
Do so now.
Step 3 of the wizard chooses the "top" or "root" of the ontology.
As you will know from having read the Ontology Part of Module 1, ontologies are often organized in lattices or trees, and lattices and trees always have a "top" node which is "highest" in the hierarchy.
In Amine, ontologies are almost lattices. They share, at least, the property with lattices of having a "top". The details of why ontologies are only almost lattices are quite obscure and need not concern you.
What is important now is that you need to specify what the "top" node of the ontology will be.
The top of ontologies are often called one of the following:
For now, please call the top "Universal" (without the quotes):
And click "OK".
Step 4 of the wizard selects the top of the Relation Hierarchy.
As you will know from having read about Relation types in Module 1, relations are organized in a Relation Hierarchy similar to the type hierarchy of Relation Hierarchy is part of the same ontology as the concept type hierarchy. However, it must still have its own top.
This top is then placed as an immediate subtype of the top of the ontology. Amine then knows that it must treat subtypes of the Relation Hierarchy top specially, as relation types and not as concept types.
The most natural name for the top of the Relation Hierarchy is "Relation". Therefore, write this in the dialog box (without the quotes):
Then click "OK".
You're done with the "New" Wizard. What you have now is an empty ontology:
Note how the "Universal" node is the top, and as an immediate subtype, we find the Relation Hierarchy top "Relation".
Before we go any further, we need to know how to save and open/load an ontology.
It isn't completely trivial, which is why we cover it.
In order to save an ontology, select the "File" menu and then "Save".
Do so now.
You will be presented with a standard Windows "Save" dialog. Navigate to where you want to save the ontology (e.g., your Documents folder), and write its name.
You must give the filename an extension of either ".xml" or ".ont":
If you don't, you will be asked to do so:
and then you have to start over again.
We recommend that for the purposes of this course, you use .xml instead of .ont. The XML version is more likely to work even with future versions of Amine.
In order to open a file, select the "File" menu, and select "Open".
A standard "Open File" dialog box will appear. Navigate to where the desired ontology is, select it, and press "Open".
OK, that was trivial, but hey, it's there for completeness :-).
This follows standard procedures for saving a file, but with one catch: You have to specify the file extension (".xml" or ".ont") together with the name. We recommend that you use ".xml".
This follows the standard procedures for opening a file.
Next, we look at how to actually build an ontology.
In this chapter, we shall look at how to actually build an ontology with the Amine LexiconsOntology tool.
The ontology won't have a lot of fancy bells and whistles; some of those are saved for a later chapter.
We assume that you have a running Amine LexiconsOntology tool, and that you have gone through the New Wizard.
Now you should have a completely blank ontology, with "Universal" as the root (or top) node and "Relation" as the Relation Hierarchy root:
We start by adding the type "Physical".
One of the earliest ontological distinctions made in philosphy was that between "Physical" and "Abstract". It was made by the Greek philosopher Heraclitus.
On this page, we'll add the "Physical" concept type as an immediate subtype of the "Universal" type.
Later, we'll add the "Abstract" type.
Start by clicking on "Universal" to highlight it.
Then right-click it.
A pop-up menu will appear:
From the pop-up menu, choose the "Insert" submenu:
Then select the "(Sub)Type" menu-item.
You will be asked to give the new subtype a name.
For now, give it the name "Physical":
Then click "OK".
The result looks like this:
Note how "Physical" is now a sub-type of "Universal". This is shown by the tree-like structure.
The next thing, of course, is to add the "Abstract" type as an immediate subtype of "Universal", alongside "Physical". That way, we make it clear that the two are a dichotomy.
In the dialog box that appears, type the name "Abstract":
Then click "OK".
You should now have an ontology that looks like this:
The Physical/Abstract dichotomy has been codified and formalized. This is the first step to a coherent ontology. Congratulations!
It's time for you to try your ontology-building skills! Use what you have learned on the two previous pages to build the following ontological top:
Now is a good time to save the ontology. Do so now, if you haven't done so already. You can call it whatever you like.
Now we'll diversify our ontology with some "Objects".
An "Object" is a Physical thing which exists in itself (Peirce would say "a firstness"), and which endures over time, i.e., it has existence beyond a mere transient moment.
Add these three types as immediate subtypes of "Object":
An artefact is a man-made object or thing, like a car or a hammer.
In this ontology, we wish to make the distinction that "Human" is not an "Animal". If we had wished to make a Human an Animal, we would have placed "Human" as a subtype of "Animal".
There are valid reasons for not doing so, e.g., if we wish to draw the distinction for narratological purposes, or for religious/philosophical purposes.
Add "Car" as an immediate subtype of "Artefact".
Add "Man" as an immediate subtype of "Human".
(Feel free to add "Woman" underneath "Human" as well, if you like.)
Or ontology is beginning to be meaningful. Next, we add acts. This will pave the way for some interesting CG operations later.
On this page, we'll add "Act" underneath "Process", and and "Drive" underneath "Act".
A "Process" is something physical that takes only a brief time, relative to some time-scale. (Depending on the time-scale, mountain-erosion can be seen as a process, as can a balloon popping, albeit with a different time-scale).
"Acts" are Processes. Examples of "Acts" include "Drive", "Eat", "Sleep", "Travel", "Speak (a sentence)", etc.
Note, however, that this is not the definition of "Process" that Sowa uses in his 2000-book. Instead, Sowa would probably call "Drive", "Eat", etc. "Situations". However, we shall keep things simple and call them "Processes".
Add "Act" as an immediate subtype of "Process", and "Drive" as an immediate subtype of "Act":
Now we can nearly use our ontology for something interesting. However, we need some relations and individuals before we can really get going, so please stay tuned and go to the next page.
As you'll recall from having read Module I, relations relate concepts to each other.
Module I gives a sample list of relations that are in common use in the CG community.
On this page, we'll add our first relation, "agnt".
We already know how to do this:
Then write the name of the relation:
and click "OK".
The result looks like this:
Very familiar, really.
You may be wondering why a relation is a "(Sub)Type" just like a concept type.
The answer is that the relation hierarchy is a type-hierarchy just like the hierarchy of concept types.
A relation type, just like a concept type, has a place in a type-hierarchy with a supertype and possibly subtypes.
Thus, a relation is a "conceptual structure" just like a concept type.
Also, in Amine, the relation hierarchy is part of the overall ontology. By singling out one conceptual structure as the root (or top) of the relation hierarchy (in the "New" wizard), the conceptual structures beneath this relation "root" are made special:
They are relation types, not concept types. But still subtypes of the relation "root". Hence we produce them in exactly the same way as the concept types.
Now we need to add some more relations, to make our ontology useful.
Add the following as immediate subtypes of "Relation":
It is a good idea to familiarize yourself with these relations if you have forgotten what they mean. Use the links above.
The result looks something like this:
Note that the order does not matter. What matters is that they are all immediate subtypes of "Relation".
On the following pages, we will need to refer to "Male" and "Female" as subtypes of "Sex". Therefore, you should add them now:
You have already added Schema as a subtype of "Abstract".
"Attribute" as a subtype of "Schema", and
"Sex" as a subtype of "Attribute"
"Female" as a subtype of "Sex"
"Male" as a subtype of "Sex"
On this page, we will add the individual "Alfred" underneath the type "Man".
Recall that there is a distinction between individuals and types.
A type always only exists in the abstract, and is a name we give to a category of individuals that are similar.
For example, "Dog" is a type, whereas "Pluto" and "Odie" are individuals of the type "Dog".
Similarly, "Man" is a type, whereas "Alfred" is an individual of type "Man".
Then write "Alfred" (without the quotes):
And click "OK".
The result should look something like the following:
The final product should look something like this:
If the order is not the same, try:
This should reorder the nodes in alphabetical order.
If you have an ontology that does not look like this, please add the parts you are missing.
Or alternatively, download this ready-made version and save it somewhere where you can find it.
Inserting a subtype proceeds like this:
Inserting an individual proceeds in the same manner as inserting a subtype, except that one chooses "Individual" in step 4 instead of "(Sub)Type".
The distinction between "Physical" and "Abstract" goes back to the Greek philosopher Heraclitus. It is fundamental in many ontological frameworks.
An Object is a Physical thing which has independent existence and which endures over time. Examples include humans, cars, animals, and stars.
A Process is a physical thing which takes place in a time-span that is shorter than that of an object.
An Act is a Process. Examples include "Drive", "Eat", "Walk", "Shower", and "Read".
In Module 1, there is a whole catalog of standard relations, some of which we have added to our ontology.
All relations are subtypes of the special "Relation" conceptual structure. We could have organized the relations in a hierarchy with subtypes and subtypes of subtypes, but for simplicity's sake, we have chosen to make them all immediate subtypes of "Relation".
A type is a category or group of individuals with similar traits.
"Pluto", "Odie", and "Fido" are individuals of type "Dog", whereas "Alfred" could be an individual of type "Man".
The previous chapter dealt with the basics of building ontologies with Amine.
This chapter will build on that foundation by showing how conceptual graphs can be added to the conceptual structures in the ontology.
The advantages of adding conceptual graphs include:
Thus adding conceptual graphs to our ontology will make it richer and more useful for formalising texts and reasoning about them.
In the following, we will:
The syntax for writing CGs is almost the same as for Prolog+CG.
However, as it is only almost the same, and as we don't need all the Prolog+CG information, the next pages summarize how to write CGs.
In the context of formal languages (CGs are a formal language), the syntax of the language consists of the formal rules that make up the language.
On the following pages, we show the syntax for writing CGs.
The plan is:
A token in formal language theory is a unit of text which is individisible, and which carries a specific meaning. For example, in natural language, words are usually taken to be tokens, but so are "commas", "semicolons" and "periods".
In Amine's CGs, tokens include:
All these are treated as units that each has a special meaning.
But what is an identifier?
An identifier is a token that consists of:
And further, the first two characters must be letters.
However, the following all fail to be identifiers. Can you spot why, given the above definition?
A concept looks like one of the following:
[Man: super Alfred]
[Sex = Male]
[Situation = [Act: Drive]-agnt->[Man: Alfred]]
A concept conforms to these rules:
Right after the opening '[', there must be a concept type which is an identifier. The concept type must exist in the type hierarchy.
After the concept type, there can optionally be a colon (':') followed by "something". This "something" can be either "super", "x_source", "y_target", an identifier, or any combination of these.
There can then optionally be an "equals sign" ('='), followed by a value, either an identifier or a nested graph.
The concept must end with ']'.
Note: These aren't the complete rules: Amine allows more than the above, but this will suffice for our purposes.
Relations must be identifiers, and they must exist in the relation hierarchy.
Relations are always dyadic, meaning that they always have one incoming and one outgoing arc.
Arcs can turn one of two ways. Using the "agnt" relation as an example:
[Source Concept]-agnt->[Target Concept]
[Target Concept]<-agnt-[Source Concept]
Note how there is as "dash" ('-') on one side, and an "arrow" on the other ('<-' or '->'). You cannot have an arrow on both sides!
If a concept has two relations attached, it is possible to write it all in one line:
[Man: Alfred]<-agnt-[Act: Drive]-thme->[Car]
Note how the "[Act: Drive]" concept has two arcs attached.
If a concept has more than two relations, it is necessary to split the graph over several lines.
This is done by placing a dash ('-') after the concept that has more than two arcs attached, then using a newline, then placing each new relation on a fresh line, with commas in between.
If the list of attached arcs is to end, one can optionally use a semicolon (';') instead of a comma.
It works like this:
[Act: Say]- -agnt->[Woman: Cleopatra], -thme->[Proposition = [Act: See]- -agnt->Woman: Cleopatra], -thme->[Fate]- <-poss-[Country: Egypt], -attr->[Heavy];, -manr->[Large] ]
This is Cleopatra's classic line from "Asterix and Cleopatra":
"How large I see the heavy fate of
(Danish: "Grant skuer jeg Ægyptens tunge skæbne.")
Cleopatra as an agent of "[Act: Say]" and the proposition as its theme are each on a separate line, with a comma in between.
There is a semicolon after "[Heavy]" to signal that the string of relations that go back to "[Fate]" is ended.
There is then also a comma, signalling that the old string of relations going back to "[Act: See]" is to be continued with "-manr->[Large]".
A token is an indivisible textual unit which carries a meaning.
An identifier is any combination of English letters (a-z,A-Z), digits (0-9) and underscores ('_') where the first two characters are letters.
Identifiers are used for concept types, relations types, and names of individuals.
Concepts are enclosed in [square brackets]. They always have a concept type which is an identifier. They optionally have a referent, which must also be an identifier, optionally mixed with "super", "x_source", or "y_target". A concept can also have a nested graph or a value, such as an individual, both of which must be preceded by an equals sign '='.
Relations must be identifiers, must exist in the relation hierarchy, and are always dyadic.
A relation must have a dash ('-') on one side, and an arrow-head ('<-' or '->') on the other.
If a concept has two relations attached, it is possible to write it all on one line.
If a concept has more than two relations attached, one can split the graph over several lines.
Start by placing a dash ('-') after the concept which must have several relations attached. Then enter a newline.
Each relation that goes back to the head concept must be on a separate line, with commas after the concepts to indicate that one more is coming.
The string of relations can be ended by a semicolon. This is useful if you need to restart an earlier string. In that case, write a semicolon followed by a comma.
Next, we start what we really came for in this chapter: Entering CGs into our ontology.
In order to be able to enter CGs into the Ontology, we need to activate a part of the GUI that we haven't seen before.
In order to do this:
The content pane will appear on the right-hand side of the window:
This is where you can write the CGs that either define or describe the conceptual structure in question.
Amine is a little quirky in some ways. One of them is that if you are showing the CG contents of a conceptual structure, you cannot show the CG contents of another conceptual structure until you have closed the content pane.
In order to close the content pane, simply click the "Close" button.
You need to do this when you are done with the content pane before you can edit the content of another conceptual structure.
Before closing, however, you need to "Set" the CG content if you have altered any CG. This is done by pressing the relevant "Set" button(s).
You may have noticed that the content pane is split in two almost identical halves. One is labelled "Definition", and the other is labelled "Canon":
So what is a "Definition" versus a "Canon"?
For example, the following would be a definition of the concept type "Man":
This is a definition and not a canon because it defines the meaning of "Man".
The following, however, would be a canon for the relation "agnt":
[Act: x_source]-agnt->[Human: y_target]
This is a canon and not a definition because it describes typical use.
What do the keywords "super", "x_source", and "y_target" mean?
super must be in the referent (i.e., after a colon) of the concept(s) that form(s) the immediate supertype(s) of a conceptual structure being defined.
In the example above, "Human" is the immediate supertype of "Man", and so "Human" gets the "super" keyword.
If there are more than one super types (multiple inheritance), all the super types get the "super" keyword. If there is only one super type, of course only that concept gets the "super" keyword.
x_source must be in the referent of the concept that is attached to the incoming arc of a relation being described or defined.
In the example above, "Act" is attached to the incoming arc, and so "Act" gets the "x_source" keyword.
y_target, conversely, must be in the referent of the concept that is attached to the outgoing arc of a relation being described or defined.
In the example above, "Human" is on the outgoing arc, and so "Human" gets the "y_target" keyword.
On this page, we will set the canon CG of the agnt relation.
Be sure to follow the instructions about opening up the contents pane. Do so for the "agnt" relation.
Then write the canon as follows:
You may need a reminder of what x_source and y_target are for.
In order to finish setting the canon, click the "Set" button:
You need to do this to make the chances permanent.
If you entered the CG correctly, you will see the following message in the "debug frame":
The "debug frame" is the white window that has been in the background ever since you opened the LexiconsOntology builder. It will tell you whether all is OK or whether something is wrong when you perform certain actions, such as setting a CG.
If the above message is not the message you see, but you see an error message, simply go back and correct whatever you were doing (the CG syntax may be wrong, for example), and try again. You will be told in the debug frame whether you did everything correctly.
After you have set the Canon CG successfully, be sure to close the contents pane, by clicking on "Close":
This will allow you to work with the contents of other conceptual structures.
a canon is a CG that describes typical usage of a conceptual structure, whereas
a definition is a CG that defines the meaning of a conceptual structure.
On this page, we will give an example of how to set the definition of a concept type, and also discuss the philosphical underpinnings of this.
Open the contents pane for "Man" (if it is currently open, close it first, by clicking the "Close" button.
Write the definition as follows:
Once you have written the definition, click the "Set" button:
This will make your changes permanent. (If you didn't do this, the definition would be lost when you closed the contents pane.)
If everythin is OK (i.e., you have written the definition correctly), you will get the following message in the debug frame:
If you did not get this message, you need to go back and ensure that you have copied the definition correctly from the above picture.
If that is not the problem, you may not have all the conceptual structures ("Human", "attr", "Sex", "Male") in the ontology. If you don't, please add them as follows, and try again:
Now that you have set the definition CG successfully, remember to close the content pane so that you can set the content of another conceptual structure.
What have we just done?
We have defined what a "Man" is, by saying that he is a "Human" (that is the supertype), and that he has an "attribute" which is "Male" (which is a subtype of "Sex").
This is Aristotle's method of definition:
You specify a genus:
and then you specify the differentiae:
which make this species ("Man") unique in relation to its genus.
The reason we put "super" after the colon is to tell Amine what the supertype is.
Granted, this could have been computed from its placement in the ontology, but to save Amine some work, we specify it directly in the definition.
Now is the time to try setting the canon and/or definition yourself for some conceptual structures.
Set the definition of "Woman" as follows:
If you don't have "Woman" and "Female" in your ontology, please add them now:
The "benf" relation (beneficiary) is typically used to connect an Act with a Human (or Animate, but we don't have that in our ontology).
Add a canon like this:
You may need a reminder of what "x_source" and "y_target" are for.
A "ptnt" (Patient) is a Physical thing which undergoes structural change as the result of a Process. This means that its canon can be set as follows:
Do so now.
You need to know how to write CGs in Amine. You may find the summary of the Syntax section useful.
A canon is a CG which describes typical usage of a conceptual structure.
A definition is a CG which defines the meaning of a conceptual structure.
The three keywords super, x_source, and y_target may be placed after the colon in a concept.
[concept type: super]
[concept type: x_source]-relation
relation-[concept type: x_source]
relation->[concept type: y_target]
[concept type: y_target]<-relation
To set the canon or the definition of a conceptual structure:
In this chapter, we have:
Recall that a type may have more than one supertype, or ancestor, or father. In such cases, we speak of multiple inheritance.
On this page, we shall see how to generate multiple inheritance in Amine.
We start with a basic ontology like this (feel free not to do anything on this page, just to watch):
The ontology has two top-level distinctions: Age and Sex. These are then further subtyped with the relevant distinctions.
If we now add "Woman" underneath "Female" in the usual way, we get an ontology like this:
We can now follow the same procedure and add "Woman" once more beneath "Adult".
This does not create a new conceptual structure (CS), but adds a link from the already-existing "Woman" CS to "Adult" so that "Woman" now has two supertypes.
This is indicated with a blue backwards arrow:
We can now do the same for "Girl":
Note how "Girl" shows up both underneath "Female" and "Juvenile".
We can now add "Man" and "Boy" in their correct places:
The ontology is complete.
It is good to reflect on this ontology briefly.
Note: This page is advanced material.
Normally, we say that the upwards link in the ontology is an "is-a" relation.
This means that we have, in this ontology, committed ourselves to the "ontological commitment" that a Man is a Male, and a Woman is an Adult.
This interpretation could be critiqued. For example, if we were to add the "Sex" supertype to "Male" and "Female", and the "Age" supertype to "Juvenile" and "Adult", the beginning ontology would look like this:
Now what would happen if we added "Woman" underneath "Female" and "Adult"?
Now we would be making the ontological commitment that a Woman is an Age and is a Sex, whereas it might be more natural to say that a Woman is a Person who has an Age.
This brings up fundamental issues of what it means "to be" something. No-one would doubt that a person's "Sex" is fundamental to that person's identity. Seen over time, the same is true for a person's "Age".
However, does this mean that the category Man "is an" Age, or "is a" Sex, in the same sense as the category Elephant "is a" Mammal?
Let us dig a little deeper. The fact that the category Elephant "is a" Mammal means that everything a Mammal is (in terms of attributes), an Elephant is also. The category "Elephant" is different from the category "Mammal" because of the fact, among other reasons, that is has more attributes than "Mammal", e.g., it has large ears and a trunk.
Thus the "is a" relation encodes a "loss of attributes" in the upwards going direction. When you go from "Elephant" to "Mammal", you could be taking about the same individual (e.g., the circus-elephant "Clyde"), but you are looking at this individual from the perspective of considering less attributes. This is because "Elephant" is everything a "Mammal" is, but has more attributes, as per its definition "by genus, species, and differentiae".
In the same way, it could be argued that "Man" is everthing "Male" is, and everything "Adult" is, but has more attributes.
However, we could end up with a contradiction in our ontology. Suppose we have a distinction in our ontology between "Physical" and "Abstract", and we have made the "ontological commitment" that this distinction is a dichotomy, i.e., nothing "Abstract" can be said to be "Physical" also. This is a standard assumption in ontology.
Suppose now that we have classified "Sex" (and therefore "Male" and "Female") as an Attribute, which we have classified somewhere beneath "Abstract". If we then wish to say that "Man" is a "Person", which belongs somewhere underneath "Object", which in turn is a subtype of "Physical", we are in trouble if we, at the same time, wish to say that "Man" is-a "Male".
This is because "Man" would then have supertypes both in the "Abstract" subiherarchy, and in the "Physical" subhierarchy.
To avoid such confusion, it may be better to categorize Man as "Person" (in the "Physical" subhierarchy) and then define "Man" with a CG as follows:
This relates "Man" to "Male" and "Juvenile" in the way that seems most natural: Not with the "is-a" relation (saying that Man "is a" Male), but with the attribute relation in the definition.
Thus we have said that "Man" (species) is-a Person (genus) and its differentiae are that "Man" has two attributes: Male and Adult.
This sidesteps the issue of whether Man "is-a" Male or Adult completely, instead relating Man to Male and Adult by means of the "attr" relation.
However, a further point of critique could be advanced against our solution: Are "Male" and "Female" really instances? Could one not say that they ought to be subtypes?
This is a long-standing debate in philosophy. It is similar to the question of whether "Red" is an instance of "Color", or a subtype of it.
One answer could be that "Red" is both a type and an instance. It is an instance of the type "Color", and as such belongs in a catalog of individuals. However, it is also a type in its own right, and as such belongs in a type hierarchy.
Therefore, types such as "Color" have been termed "Second-order types" because they have types as instances.
Something similar could be said for "Male" and "Female". They are both arguable types: Maybe they should be subtypes of "Attribute".
Yet they are also instances of the type "Sex". Therefore, "Sex" could also be termed a second-order type on a par with "Color".
However, Amine does not support second-order types, and therefore we choose to label "Male" and "Female" as individuals of type "Sex" rather than types.
Having learned how to generate multiple inheritance in Amine, we can now make use of one of Amine's niceties for navigating ontologies.
For conceptual structures with multiple inheritance, Amine allows jumping from one place in the tree to the next place in the tree (i.e., underneath the next supertype).
This is done with the "Next" feature.
The "Next" feature is accessed as follows:
You can perform the same operation on the new place to get to the next one (if there are more than two) or back to the first (if there are only two).
Amine jumps to the next occurrence:
Amine supports a special kind of conceptual structure called a Situation.
A "Situation" is a configuration of time-space, and some objects in that space. The objects may be in the process of doing something or interacting, or the "Situation" may be a "snapshot" in which nothing occurs. In such cases we say that the situation is a "State".
In Amine, we can add conceptual structures that are explicitly called "situations". It doesn't matter to which conceptual structure in the ontology you attach them, but it is a good idea to do so underneath a conceptual structure called "Situation".
On this page, we show how.
The starting point is this ontology, which you can download and save on your harddrive. Please do so now, and open it in Amine.
To add a situation, do the following:
A new conceptual structure appears, called simply "SIT":
If one inserts more situations, the next situations will be numbered.
To set the description of the situation:
Don't forget to press "Set" once you have written the CG.
If you have written the CG correctly, and all conceptual structures used (Act, Drive, Car, Alfred, etc.) are also in the ontology, you should get a success confirmation in the debug frame:
If you don't get this message, correct the deficiencies and try again.
Multiple inheritance is generated by:
In the case of multiple inheritance, you can quickly jump from one placement in the tree to the next placement of the same conceptual structure by:
A Situation is a configuration of time-space with some objects. In Amine, you can add a situation with a description by:
The ontology allows for a number of operations. These are visible from the 'Types Hierarchy Operations' pane.
In this chapter, we shall look at the operations that this pane supports.
Assume we have on ontology like the example used in chapter 11. A graphical representation of this ontology may look like the following:
Once the ontology is loaded, the "Types Hierarchy Operations" interface lets us explore the relations between concept types.
As an example, let us investigate the types 'man' and 'adult':
Load the Man-Woman-Boy-Girl example.
Click on the tab "Types Hierarchy Operations".
Write "man" and "adult" in the two edit boxes as follows:
The buttons in the lower half of the screen calls various functions.
IsSubType investigates if Type 1 is a subtype of Type 2. In this example: is 'man' a subtype of 'adult'? The result is true, whereas the inverse IsSuperType is false.
DirectSubTypes and DirectSuperTypes only apply to the first type (Type 1), and traverse the hierarchy in order to investigate the types immediately below and above the type in question. In this case, 'man' has no subtypes at all, but two direct super types: 'male' and 'adult'.
AllSubTypes and AllSuperTypes naturally perform similar actions, but reports all nodes from the type in question to the bottom and the top of the hierarchy, respectively. The type 'man' still has no subtypes, but the supertypes: male, adult, sex, age, and universal.
MaximalCommonSubType and MinimalCommonSuperType make use of multiple inheritance. MaximalCommonSubType reports the highest node in the hierarchy that is a subtype of both Type 1 and Type 2. The reverse, MinimalCommonSuperType, reports the lowest node in the hierarchy that is a supertype of both Type 1 and Type 2. If we investigate the types 'female' and 'juvenile', we find that the maximal common subtype is 'girl', and the minimal common supertype is 'universal'.