| OpenCyc Tutorial : An Introductory Walk Through Ontological Engineering Version 0.7 |

Contents

Introduction

Step One: Find Relevant, Already-existing Constants

Step Two: Create New Constants

Step Three: Make Assertions On New Constants in your own Microtheory

Step Four: Testing in your own Microtheory

### Introduction

In this tutorial you will witness the creation of two new constants, and the making of some simple assertions on those constants.

Suppose that you have just acquired two kittens (who shall be referred to as "Billy" and "Peter") and they are so enchanting that you feel they should be represented in your version of the OpenCyc KB. Here is how one ontologist would go about such a process, described in first-person terms. I encourage you to follow me as I walk you through the steps I would take, using your browser. Ontological engineering - like any other engineering - is an intensely practical (albeit virtual), task which can really only be learned by doing it.

The process I will go through can be broken down into four main steps. Ok, let's begin.

### Step One: Find Relevant, Already-existing Constants

First of all, I will try and find relevant, already-existing constants - constants that I will be able to use to make the assertions about Billy and Peter that I want to make. Of course I could create every constant I wish to use to talk about Billy and Peter, but why reinvent the ontological wheel? (Beware: this task is often harder than it looks...many a cyclist has torn out hair having just worked hard to create a new constant which they perceived as filling a hole in the ontology (say..." `moneyAmountOfCoin` "), only to find an equivalent lurking in the KB under a name they did not expect (say..." `tenderValue` ")).

First and most obviously, I guess I will want to say that Billy and Peter are kittens. That is probably the most salient piece of information I have about them. Is there a Cyc term that means "kitten"?

Enter the word "kitten" in the text field next to the "Complete" button in the top frame and click on the "Show" button... [ Show me ]

Unfortunately this turns up nothing. There is no constant called `#$Kitten` in the OpenCyc KB.

What does the '#$' in front of "#$Kitten" mean?

What does the '#$' in front of "#$Kitten" mean?

Maybe, instead of saying that Billy and Peter are kittens, I can say that they are juvenile cats. So now let's try "cat".

Enter the word "cat" in the text field next to the "Complete" button in the top frame and click on the "Show" button.

No luck there, either....In cases such as this, my next step will be to try something more general. Hmmmm....how about "pet"?

Enter the word "pet" in the text field next to the "Complete" button in the top frame and click on the "Show" button.

Cyc presents a choice of two constants:

`
    DomesticPet
    NonPersonAnimal
`

How does Cyc produce these two constants from a string ("pet") which is different than both of them? The answer lies with Cyc's 'natural language support'. For example, the KB contains the following two "assertions" (or facts) related to #$DomesticPet:

    Mt : GeneralEnglishMt
      (denotation Pet-TheWord SimpleNoun 0 DomesticPet)
      M(multiWordString ("domestic") Pet-TheWord SimpleNoun DomesticPet)

The first assertion above relates the word "pet" to the Cyc constant "#$DomesticPet". The second on relates the phrase "domestic pet" to the same Cyc constant.

Further reading on Cyc NL

`#$DomesticPet` is a more specific constant than `#$NonPersonAnimal` , since `#$DomesticPet` is a specialization of `#$DomesticatedAnimal` , which is a specialization of `#$TameAnimal` , which is a specialization of `#$NonPersonAnimal` .

Note: More specific collections 'inherit' the information that exists on the collections they are specializations of, and have further information as well. This hierarchy is ordered using the predicate #$genls.

`#$DomesticPet` is therefore better for me to use to describe Billy and Peter. The reason for this may be summarized in the 'Maxim of Efficient Ontologizing':

The Maxim Of Efficient Ontologizing: Be as specific as possible without being false.

I should say that, strictly speaking, this maxim applies to the writing of individual assertions (which state facts) and not to the writing of rules (which allow Cyc to deduce things from the facts it knows). When it comes to rules, the more general you can be (without being false) the better! But this is an introductory tutorial and we will therefore be confining ourselves to individual assertions.

`#$DomesticPet` is a collection, so to use this constant to make assertions about Billy and Peter I am going to have to assert that they are both members of this collection.

What are some other things I am likely to want to say about Billy and Peter? Well, another interesting fact about them is that they are brothers. Does this mean that, as was the case with `#$DomesticPet` , they should be asserted to be a member of a collection called, say, `#$Brother` ? (There is actually a problem with this. Can you see what it is?)

What's wrong with making a collection called #$Brother?

Billy and Peter are not just brothers per se, they are brothers of each other. Such relationships between two or more things are handled in Cyc using predicates rather than collections.

Further reading on Predicates

Specific relationships between two or more things are handled in Cyc using predicates rather than collections.

Is there a predicate called `#$brothers` ?

Enter the word "brothers" in the text field next to the "Complete" button in the top frame and click on the "Show" button.. [ Show me ]

No there is not.

Again, I realize that I better back up and try something more general. What is a more general version of the concept of brotherhood? Billy and Peter are...related to one another, i.e. they are relatives. Let's try "relatives"....

Enter the word "relatives" in the text field next to the "Complete" button in the top frame and click on the "Show" button.

Yes, there is a `#$relatives` ! However, don't forget the Maxim of Efficient Ontologizing. Perhaps there is something a bit more specific, if not as specific as "brothers" would be, that we can use.

From the "2 possible terms" page, click on the relatives link to get to view the details of `#$relatives` . With `#$relatives` up, look at the left-hand frame (the "Term Index Frame"), under Arg2, and click on "genlPreds". [ Show me ]

How do I use the Term Index Frame?

This presents a list of all the predicates which are direct specializations of `#$relatives` , as follows:

`
    Mt : BiologicalSocialVocabularyMt
      (genlPreds grandchildren relatives)
      (genlPreds cohabitingFamilyMembers relatives)
      (genlPreds children relatives)
      (genlPreds coreRelatives relatives)

    Mt : BiologyVocabularyMt
      (genlPreds siblings relatives)
      (genlPreds biologicalRelatives relatives)
`

Note: Just as Cyc collections are arranged in an information-inheriting hierarchy ordered using the predicate #$genls, Cyc predicates are arranged in an information-inheriting hierarchy ordered using the predicate #$genlPreds.

Tutorial lesson on predicates and the predicate hierarchy

Aha! `#$siblings` is more specific than `#$relatives` , and it is also true of Billy and Peter. So we can use that.

What else do I want to say about Billy and Peter? They like each other a lot (though they also roll around on the floor a lot biting each other...). So the next thing to do (which should not by now be too surprising) is to type in "likes", to see if there is some term (probably a predicate) I can use to say that Billy and Peter like each other.

Enter the word "likes" in the text field next to the "Complete" button in the top frame and click on the "Show" button. [ Show me ]

You should see Cyc produce a constant with the somewhat bizarre name of `#$likes-Generic` . Some background information is in order here: making a name of the form "[X]-generic" is something of a Cyc convention which means that the constant in question tops a hierarchy of terms regarding [X], which have been defined more specifically.

A constant with a name of the form "[X]-generic" tops a hierarchy of more specifically defined terms regarding [X].

In our case, obviously, [X] will be something to do with 'liking'). Such a term is often an 'umbrella term', designed to gather together more specific terms, rather than having actual assertions made on it. Let's therefore look for something more specific. With `#$likes-Generic` up, let's see how its comment echoes my remark above:

The right frame should say "Predicate : likes-Generic" at the top. Scroll down in the right frame until you reach "comment:". [ Show me ]

`
    (likes-Generic SUBJ OBJ) means that SUBJ likes OBJ. This
             is a very general liking relation which is most useful for
             organising liking relations and for use during inference; for
             representation purposes, use a spec-Pred.
`

So let's find the appropriate 'spec-Pred' (this is Cyc-talk for 'more specialized predicate') for `#$likes-Generic` .

'Spec-Pred' is Cyc-talk for 'more specialized predicate'.

Here we could just do what we did for `#$relatives` , which was to look at the left-hand frame, under Arg2, and click on "genlPreds".

With #$likes-Generic still up , look at the left-hand frame, under Arg2, and click on "genlPreds". [ Show me ]

You should see just one assertion:

`
    Mt : AgentGVocabularyMt
      (genlPreds likesObject likes-Generic)
`

What is this `#$likesObject` ? Let's have a look:

Click on the word "likesObject" in the assertion. [ Show me ]

`
    Mt : AgentGVocabularyMt
    comment : "(likesObject AGT OBJ) means that when the sentient agent
    AGT is interacting in some way with OBJ, that agent feels some measure
    of Enjoyment --- that is, (feelsEmotion AGT Enjoyment). The kinds of
    interactions that produce Enjoyment depend largely on what kind of thing
    OBJ is. Thus, `Joe likes the Mona Lisa' implies that Joe feels Enjoyment
    when viewing the Mona Lisa. But `Joe likes pizza' implies that Joe feels
    Enjoyment when eating that kind of food. There are some specialized
    predicates of likesObject that give more information about the kind of
    interaction between AGT and OBJ that results in Enjoyment; see, e.g.,
    #$likesSensorially and #$likesAsFriend."
`

I'm not sure that I want to assert `#$likesObject` of Billy and Peter. Billy doesn't quite like Peter in the way that Joe likes pizza (Billy's frequent biting of Peter notwithstanding). Hmmmm.....And what are these `#$likesSensorially` and `#$likesAsFriend` that appear in the comment? Why did they not appear when I clicked on "genlPreds"? (Can you figure it out?)

In fact the answers are different for the two different predicates. The answer for `#$likesSensorially` is that it is a Cyc constant that was not made public - it thus does not exist in the OpenCyc KB. (You can tell this because it is printed in black, not clickable blue).

The Cyc constants you see which are not links were not made public and therefore do not exist in the OpenCyc KB.

The answer for `#$likesAsFriend` is a little more complicated. Merely clicking on the "genlPreds" under "Arg2" produces all assertions directly made of the form `(genlPreds ?X likes-Generic)` , but a list of all such ?X is not a list of all the spec-Preds of `#$likes-Generic` . This is because `#$genlPreds` is a transitive predicate (i.e. if X is a spec of Y and Y is a spec of Z then X is a spec of Z). So there can be many more specs of a given constant than there are 'direct specs' (specs linked to that constant by specific assertions).

#$genlPreds is a transitive predicate (i.e. if X is a spec of Y and Y is a spec of Z then X is a spec of Z). So there can be many more specs of a given constant than there are 'direct specs' (specs linked to that constant by specific assertions).

There is actually a cool tool for viewing all the specs of a given constant, though. If you look slightly to the right of the "genlPreds", you will see a green plus.

Click on the green plus slightly to the right of "genlPreds". [ Show me ]

You should see the following:

`
    Last query in AgentGVocabularyMt :
    (genlPreds ?ARG1 likes-Generic)

    3 answers for ?ARG1 :
    likes-Generic   likesAsFriend   likesObject
`

Now `#$likesAsFriend` appears.

Why does #$likes-Generic also appear in the list?

By the way, you probably noticed that as well as the green plus next to "genlPreds", there is also a red diamond . This is in some ways an even cooler tool. You might like to click on it and see what it does....

So let's have a look at `#$likesAsFriend` :

Click on the word "likesAsFriend" in the main frame of the KB browser. [ Show me ]

`
    Mt : AgentGVocabularyMt
    comment : "(likesAsFriend AGT1 AGT2) means that AGT1 enjoys
    interacting socially with AGT2. See also the #$FeelingAttributeTypes
    Friendliness. Note: this predicate does not imply that AGT1 likes AGT2
    only as a friend -- there may be romantic feelings, and other feelings, as
    well."
`

This sounds more like Billy and Peter to me, if "interacting socially" is not just restricted to human society and also covers such activities as eating together and rolling around on the floor chewing one another's ears. This does seem plausible to me. To be sure, let's check what are called the 'argument-constraints' on `#$likesAsFriend` . If this predicate is intended only to apply to human beings, then next to the `#$arg1Isa` and `#$arg2Isa` predicates in the main frame for `#$likesAsFriend` (assuming it has been well-ontologized) `#$Person` should appear. Let's check that...

Look immediately above the comment I just quoted and find arg1Isa and arg2Isa. [ Show me ]

In fact `#$Person` does not appear there, only `#$PerceptualAgent` . Will Billy and Peter meet this criterion? Yes they will, once they have been asserted to be members of the collection `#$DomesticPet` , as `(#$genls #$DomesticPet #$PerceptualAgent)` is true. (Can you verify this? Hint: you can do this using the green plus you just learned about). So I will use `#$likesAsFriend` .

Lastly, how about saying how old Billy and Peter are? They are currently 11 weeks old. Let's type in "age".

Enter the word "age" in the text field next to the "Complete" button in the top frame and click on the "Show" button.

There is an `#$age` ! It too turns out to be a predicate. Here are some of its defining assertions:

`
    Mt : BaseKB
    arg1Isa : SomethingExisting
    arg2Isa : Time-Quantity
    arg1Format : SetTheFormat
    arg2Format : IntervalEntry
`

What does this mean? It means that the predicate `#$age` takes two arguments and the first argument (the thing which has the age) must be an instance of `#$SomethingExisting` , and the second argument (the age of the thing) must be an instance of `#$Time-Quantity` . Are Billy and Peter instances of `#$SomethingExisting` ? Yes they are. (You might like to verify this - again, using the green plus .)

The "formats" of the two arguments are a somewhat more technical affair. The `#$arg1Format` assertion basically means that different things may occupy the `arg1` position for any given `arg2` (Thus, not just one but an arbitrary number of creatures may be, say, 10 years old at any given time). The `#$arg2Format` assertion means that the age given may be a single, discrete value, or it may be a range (say, between 3 and 4 years). See the comment on `#$IntervalEntry` for more details on this.

Further reading on argument formats (#$arg1Format)

What exactly is a `#$Time-Quantity` , though? Is '11 weeks' an instance of it? Let's take a look at this constant. I can't find any assertion of the form `(#$isa "11weeks" #$Time-Quantity)` . Hmmmm.... What I do find out, however (with the help of some considerable experience with such matters :-)) is that instances of `#$Time-Quantity` are the results of a set of functions (functions which are gathered together in a collection called `#$UnitOfTime` ). We have so far encountered collections, individual instances of collections, predicates and microtheories. A function is yet another Cyc animal (a "new beast for our zoo [of logical forms]", as Bertrand Russell once put it).

Further reading on functions in Cyc

Let's browse the list of functions collected under `#$UnitOfTime` (by looking under "Arg2" in the frame on the left, and clicking on "isa").

Enter the word "UnitOfTime" in the text field next to the "Complete" button in the top frame and click on the "Show" button.. When its definitional information appears in the main frame, look at the left-hand frame, under Arg2, and click on "isa". [ Show me ]

You should see the following:

`
    Collection : UnitOfTime
    GAF Arg : 2
    Mt : BaseKB

    (isa DaysDuration UnitOfTime)
      (isa SecondsDuration UnitOfTime)
      (isa QuartersDuration UnitOfTime)
      (isa HoursDuration UnitOfTime)
      (isa WeeksDuration UnitOfTime)
      (isa DecadesDuration UnitOfTime)
      (isa YearsDuration UnitOfTime)
      (isa MonthsDuration UnitOfTime)
      (isa MinutesDuration UnitOfTime)
`

`#$WeeksDuration` looks promising. Let's take a look at that.

Click on the word "WeeksDuration" in the main frame of the KB browser. [ Show me ]

Its comment says:

`
                "A UnitOfTime function that takes one or two real numbers as
              arguments and returns, as its value, a comparable Time-Quantity
              attribute measured in weeks. More precisely, an expression of the
              form (WeeksDuration NUM) denotes the ("point-value")
              Time-Quantity of being exactly NUM weeks in duration, and an
              expression of the form (WeeksDuration MIN MAX) denotes the
              (properly interval-like) Time-Quantity of being at least MIN
              weeks and at most MAX weeks in duration."
`

What this means is that I can use " `(#$WeeksDuration 11)` " to represent 11 weeks, and that the result of applying the function in this way will be an instance of `#$Time-Quantity` (which is what I need, since I want to plug it into an assertion using the predicate `#$age` , in the second argument position. The exact way in which this will happen will be explained in Step 3.).

Step One Summary: We have now identified the following constants which can be used to make assertions about Billy and Peter:

> - `#$DomesticPet`
> - `#$siblings`
> - `#$likesAsFriend`
> - `#$age`
> - `#$WeeksDuration`

### Step Two: Create New Constants

In the previous step, we identified some constants which can be used to make assertions about Billy and Peter. Let's now create new constants to represent Billy and Peter themselves. Before taking this step, if you are logged in as `Guest` , you will need to log in again as `CycAdministrator` , as it is not possible to create new constants as `Guest` .

You must be logged in as `CycAdministrator` in order to create new constants. In OpenCyc, `Guest` does not have the same privileges as `CycAdministrator` .

Let's start with Billy. Go to the Tools page and click on "Create".

Click on the Tools link in the left corner of the top frame. [ Show me ] This will bring up the Tools page. Click on the "Create" link in the column on the left. [ Show me ]

The first thing to do is to choose a name for the new constant. "Billy" seems a logical choice. Of course if there were other Billys, Bills, etc. already in the KB, it might be wise to differentiate this constant a little further via its name. When this is desired, a Cyc convention is to append "-The[something]" at the end of a constant name (e.g. `Othello-TheGame` , `Othello-TheMovie` ). So I could do "Billy-TheKitten".

To differentiate constants by name, a Cyc convention is to append "-The[something]" at the end of a constant name (e.g. `Othello-TheGame` , `Othello-TheMovie` ).

Enter the word "Billy" in the main frame of the KB browser. Click on the "Create Constant" button. [ Show me ]

Now, merely clicking on the button "Create Constant" is enough to give Billy a place in the ontology. I can now call up the `#$Billy` constant, just like any other Cyc constant - though if I do this, all I will see so far is 'bookkeeping assertions' - assertions about who created the constant and when it was created.

Let's now create `#$Peter` in the same way that we created `#$Billy` .

On the "Constant Create operation completed" page, click on the "Back to previous (stale) page" button. [ Show me ] This will bring you to the "Browser Tools" page. Enter the word "Peter" in the field in the main frame. Click on the "Create Constant" button. [ Show me ]

Step Two summary - We now have two new constants, one for each kitten, on which we can start making assertions (or, as it is sometimes put, 'entering knowledge').

### Step Three: Make Assertions On New Constants in your own Microtheory

In the previous step, we created some constants that we will use as we make new assertions in Step 3. If you have not yet created those new constants, please go back and complete Step 2.

The next step is to make the assertions I want to make on my new constants. Every Cyc assertion is made in some microtheory, so now we must deal with a bit with microtheories.

Every Cyc assertion is made in some microtheory.

There are actually different ways of dealing with microtheories. If you would like a more detailed explanation of how to use microtheories and where to place assertions in the microtheory hierarchy, then read the considerably longer version of this walkthrough. Otherwise, continue reading here and make a single microtheory in which we will put all of our assertions about Billy and Peter.

[MAKE YOUR MICROTHEORY HERE??? AND SET THE DEFAULT MT TO THE NEW ONE]

Tutorial lesson on Microtheories

Note: Just as Cyc collections are arranged in an information-inheriting hierarchy ordered using the predicate #$genls, and Cyc predicates are arranged in an information-inheriting hierarchy ordered using the predicate #$genlPreds, Cyc microtheories are arranged in an information-inheriting hierarchy ordered using the predicate #$genlMt.

Further reading on #$genlMt

Let's assert that Billy and Peter were both members of the `#$DomesticPet` collection (or, in Cyc-talk, 'instances of `#$DomesticPet` '). Let's go to the Tools page and click on "Assert".

Click on the Tools link in the left corner of the top frame. [ Show me ] This will bring up the Tools page. Click on the "Assert" link in the column on the left. [ Show me ]

This should bring up the assertion-making tool. The "Assert" tool is used to make one assertion at a time. It is not the only way in which assertions can be entered in the KB, but it is the easiest and most straightforward.

The Assert tool is used to make one assertion at a time. It is not the only way in which assertions can be entered in the KB, but it is the easiest and most straightforward.

Further reading on making assertions

With the "Assert Formula" page still up, enter "(isa Billy DomesticPet)" in the large text box. [ Show me ]

Look at what you just typed and note that:

> - the predicate used is "isa", not "genls". Why is that?

>   Tutorial lesson on Collections and Individuals

> - we are making the assertion on Billy only. (isa Billy Peter DomesticPet) would not be a well-formed formula. The reason for this has to do with the arity of `#$isa` . The arity of `#$isa` can be found by calling up `#$isa` on your browser and looking at what it says next to "arity".

>   Tutorial lesson on Arity

The next thing we need to do (often forgotten!) is to click on the button which is somewhat mysteriously named "Cyclify".

With the "Assert Formula" page still up, and "(isa Billy DomesticPet)" in the large text box, click on the "Cyclify" button (immediately above the large text box). [ Show me ]

This makes a " `#$` " appear in front of every term in the formula. This is necessary because "isa", "Billy", and "DomesticPet" are not terms in CycL - " `#$isa` ", " `#$Billy` " and " `#$DomesticPet` " are. (The Cyclify tool is more than just an automatic '"#$" pre-pender', by the way. It actually searches the KB for terms matching the strings in the formula, and if it does not find a CycL term matching a string, it does not prepend a "#$" to it. This way, if I inadvertently make a typo, say if I type "Blly", this will become obvious when it is not "cyclified".)

Now that we have cyclified it, we could go ahead and assert the formula (by clicking on "Assert Formula"). However, what I normally do is click "Diagnose Formula" first. This checks the formula for well-formedness of various kinds.

Click on the "Diagnose Formula" button (above Direction :). [ Show me ]

The assertion should be fine.

Let's click on "Assert".

Finish asserting by clicking on the "Back" button of the Formula Diagnosis page [ Show me ] and then clicking on the "Assert Formula" button (in the top right corner of the main frame of the Assert Formula page). [ Show me ]

Now let's go ahead and make the same assertion on `#$Peter` .

Click on the "Back to previous (stale) page" button at the top of the main frame. [ Show me ] Change "#$Billy" to "#$Peter". Click on the "Cyclify" button (immediately above the large text box). Click on the "Diagnose Formula" button (above Direction :). Click on the "Back" button of the Formula Diagnosis page and then click on the "Assert Formula" button (in the top right corner of the main frame of the Assert Formula page).

I can now try asserting that Billy and Peter are siblings, using the predicate `#$siblings` .

Let's go back to the Assert page and enter `(#$siblings #$Billy #$Peter)` , with [the name of your new microtheory] entered up in the Mt text field. (Don't forget to Cyclify!)

Click on the Tools link in the left corner of the top frame. This will bring up the Tools page. Click on the "Assert" link in the column on the left. This will bring up the Assert Formula page. Enter "(siblings Peter Billy)" in the large text box. Click on the "Cyclify" button (immediately above the large text box).

Now let's Diagnose again...

Click on the "Diagnose Formula" button (above Direction :). Our assertion is okay, so let's assert it. Click on the "Back" button of the Formula Diagnosis page [ Show me ] and then clicking on the "Assert Formula" button (in the top right corner of the main frame of the Assert Formula page). [ Show me ]

Let's assert that Billy is an animal.

Click on the Tools link in the left corner of the top frame. [ Show me ] This will bring up the Tools page. Click on the "Assert" link in the column on the left. [ Show me ] This will bring up the Assert Formula page. Enter "(isa Billy Animal)" in the large text box. [ Show me ] Click on the "Cyclify" button (immediately above the large text box). [ Show me ] Click on the "Diagnose Formula" button (above Direction :). [ Show me ] Finish asserting by clicking on the "Back" button of the Formula Diagnosis page [ Show me ] and then clicking on the "Assert Formula" button (in the top right corner of the main frame of the Assert Formula page). [ Show me ]

Now let's do the same for Peter.

Click on the "Back to previous (stale) page" button at the top of the main frame. [ Show me ] Change "#$Billy" to "#$Peter". Click on the "Cyclify" button (immediately above the large text box). Click on the "Diagnose Formula" button (above Direction :). Click on the "Back" button of the Formula Diagnosis page and then click on the "Assert Formula" button (in the top right corner of the main frame of the Assert Formula page).

Let's make another assertion with the predicate `#$likesAsFriend` .

Click on the Tools link in the left corner of the top frame. This will bring up the Tools page. Click on the "Assert" link in the column on the left. This will bring up the Assert Formula page. Enter "(likesAsFriend Billy Peter)" in the large text box. Click on the "Cyclify" button (immediately above the large text box). Click on the "Diagnose Formula" button (above Direction :). Finish asserting by clicking on the "Back" button of the Formula Diagnosis page and then clicking on the "Assert Formula" button (in the top right corner of the main frame of the Assert Formula page).

Do I now also need to assert (likesAsFriend Peter Billy)?

Finally let's assert the ages of Billy and Peter by going back to the Assert page and, in the large text field, enter `(age Billy (WeeksDuration 11))` .

Click on the Tools link in the left corner of the top frame. [ Show me ] This will bring up the Tools page. Click on the "Assert" link in the column on the left. [ Show me ] This will bring up the Assert Formula page. Enter "(age Billy (WeeksDuration 11))" in the large text box. [ Show me ]

Note the way in which the function `#$WeeksDuration` , and its single argument, `11` , are surrounded by parentheses to create a single entity which then serves as the second argument to the predicate `#$age` (which is defined as having two arguments and two arguments only). Such an entity, composed of a function and one or more arguments, is known in Cyc-talk as a NAT, which stands for "Non-Atomic Term".

Further reading on NATs

Click on the "Cyclify" button (immediately above the large text box). [ Show me ] Click on the "Diagnose Formula" button (above Direction :). [ Show me ] Finish asserting by clicking on the "Back" button of the Formula Diagnosis page [ Show me ] and then clicking on the "Assert Formula" button (in the top right corner of the main frame of the Assert Formula page). [ Show me ]

Now that you are familiar with one method of dealing with microtheories, you can either move on to Step Four to test what ypu've entered, or, if you would like a more detailed explanation of how to use microtheories and where to place assertions in the microtheory hierarchy, then read the considerably longer version of this walkthrough.

Step Three summary - we have now made a number of interesting assertions on our new constants `#$Billy` and `#$Peter` . Maybe you can think of a few more....(For instance, they are both males, surprise surprise!) We also made a new microtheory that can "see" all necessary microtheories and can hold all of the knowledge that we assert about Billy and Peter.

### Step Four: Testing in your own Microtheory

In the previous two steps, we created some constants (including a new microtheory) and we made some new assertions. In Step 4, we'll be testing Cyc to make sure that the implications of those new assertions are there. If you have not yet created those new constants and/or assertions, please go back and complete Step 2 and Step 3.

We are not done yet, however! A good engineer does not just design and build things, but also tests those things, to see if they are doing what they are supposed to do. Once again, ontological engineering is no exception.

Question: How does one test an ontology? Answer: Using the Cyc inference engine!

We will now explore Cyc's question-and-answer functionality. Let's go back to the Tools page and click on "Ask".

Click on the Tools link in the left corner of the top frame. [ Show me ] This will bring up the "Browser Tools" page. Click on the "Ask" link in the column on the left. [ Show me ] This will bring up the "Ask a Query" page.

As an ontological engineer, having finished making some assertions I will ask myself, what are some things that I would expect Cyc to know based on the information I've just entered? Of course I would expect Cyc to know `(isa Billy DomesticPet)` and `(likesAsFriend Billy Peter)` (in the relevant microtheories, of course!) as I explicitly asserted those. But what about something a little less obvious, something that will make Cyc think a bit? ...What could such a question be? What about, say, the fact that Billy takes up space?

Let's ask.

Enter "(isa Billy SpatialThing)" in the large text box. [ Show me ] Click on the "Cyclify" button (immediately above the large text box). [ Show me ] Click on the "Ask Query" button (immediately above the Mt : text box). [ Show me ]

You should see the following:

`
    Ask a Query

          [Skip to Inputs]

    Last query in ****Mt :
    (isa Billy SpatialThing)

    Query halted because : Search space was exhausted.

    Query was proven True   [Explain]
`

Yes, Cyc does know that Billy is a spatial thing! How does Cyc know this?

Click on the link "Explain" (immediately above the line that separates the result of the query and the tools for asking another query). [ Show me ]

This useful tool should produce the following:

`
    Inference Answer Detail   [Refresh]   [Continue Ask]

    Query in ******Mt :
    (isa Billy SpatialThing)

    One Justification :
    :ISA (isa Billy SpatialThing) in *******Mt
`

"ISA:" is what is known as an HL module, a specialized inference-performing module of which Cyc has a great many. Clicking on it provides a summary of the particular inferences the module performed in this case.

Tutorial lesson on Inference in Cyc

Click on the link "ISA:", under One Justification :. [ Show me ]

You should see the following:

[THIS SHOULD CHANGE, right?]

`
    HL Support Detail   [Refresh]

    Strength : Default   Module : ISA

    Mt : BiologyMt
    HL Formula :
    (isa Billy SpatialThing)

    Justification :
      (isa Billy Animal) in BiologyMt
      (genls Animal SolidTangibleThing) in TransportationMt
      (genls SolidTangibleThing PartiallyTangible) in NaivePhysicsVocabularyMt
      (genls PartiallyTangible TwoOrHigherDimensionalThing) in BaseKB
      (genls TwoOrHigherDimensionalThing SpatialThing) in BaseKB
`

Now, just out of curiosity, let's ask if Billy is a person, and see what happens. (What would you expect to happen?)

Click on the link "Continue Ask" in the upper right hand corner of the Inference Answer Detail page. [ Show me ] This will bring up the Ask a Query page. Enter "(isa Billy Person)" in the large text box. [ Show me ] Click on the "Cyclify" button (immediately above the large text box). [ Show me ] Click on the "Ask Query" button (immediately above the Mt : text box). [ Show me ]

You should see the following:

`
    Ask a Query

          [Skip to Inputs]

    Last query in **********Mt :
    (isa Billy Person)

    Query halted because : Search space was exhausted.

    Query was not proven
`

Why didn't Cyc say that this statement was false?

The Cyc inference engine never returns "false" -- but only "true" or "not proven" -- as the answer to a query.

In fact the Cyc inference engine never returns false - only true or not proven. Cyc knows a great deal but has sufficient humility not to assume that its failure to prove an assertion P is a sound basis for concluding that P is false. However, let's try asking `(not (isa Billy Person))` , i.e. "Is it not the case that Billy is a person?"

Scroll down below "Query was not proven" on the "Ask a Query" page. The query we just asked is still entered into the fields there. Insert "(not" just before "(isa Billy Person)" and add another ")" at the end of the query, so that you have "(not(#$isa #$Billy #$Person))" entered in the large text box. Click on the "Cyclify" button (immediately above the large text box). Click on the "Ask Query" button (immediately above the Mt : text box).

You should see this proven True! Why is this? Click on the link "Explain"....and again click on the link to the ISA: inference module.

Click on the link "Explain" (next to "True" and immediately above the line that separates the result of the query and the tools for asking another query). [ Show me ] From the "Inference Answer Detail" page, click on the link "ISA:", under One Justification :. [ Show me ]

You should see something that looks like this: [WON'T HIS CHANGE?]

`
    Mt : HumanActivitiesMt
    HL Formula :
    (not
       (isa Billy Person))

    Justification :
      (isa Billy DomesticPet) in HumanActivitiesMt
      (genls DomesticPet DomesticatedAnimal) in HumanActivitiesMt
      (genls DomesticatedAnimal TameAnimal) in DomesticBreedsVocabularyMt
      (genls TameAnimal NonPersonAnimal) in BiologyVocabularyMt
      (disjointWith Person NonPersonAnimal) in BiologyMt
`

This provides a summary of the inferencing which the :ISA inference module went through in this case. Can you see what went on? Basically, it followed the genls hierarchy from the collection `#$DomesticPet` (which Billy belongs to) up to the collection `#$NonPersonAnimal` . It then found an assertion that the collections `#$Person` and `#$NonPersonAnimal` are 'disjoint' - i.e. they have no instances in common (which makes sense, given their names). The module then concluded that since Billy is a member of the collection `#$NonPersonAnimal` , he cannot be a member of the collection `#$Person` .

Note that it is not the case that every query which returns "Not Proven" can be made to return "True" when negated. Consider, for example, `(isa Billy Dog)` . Try asking this both with and without a (not ...) surrounding it.

Click on the Tools link in the left corner of the top frame. This will bring up the "Browser Tools" page. Click on the "Ask" link in the column on the left. This will bring up the "Ask a Query" page. Enter "(isa Billy Dog)" in the large text box. Click on the "Cyclify" button (immediately above the large text box). Click on the "Ask Query" button (immediately above the Mt : text box).

Click on the Tools link in the left corner of the top frame. This will bring up the "Browser Tools" page. Click on the "Ask" link in the column on the left. This will bring up the "Ask a Query" page. Enter "(not (isa Billy Dog))" in the large text box. Click on the "Cyclify" button (immediately above the large text box). Click on the "Ask Query" button (immediately above the Mt : text box).

It turns out that Cyc cannot prove that Billy is or is not a dog. Cyc does not know enough about Billy to decide either way. Of course if Cyc knew that Billy were a cat then perhaps Cyc could decide this question. Remember that we did not manage to assert that Billy and Peter were cats because there was no `#$Cat` constant. And of course, the relevant inference would only go through if such a constant were intelligently ontologized.

If you would like to, go ahead and create a constant `#$Cat` (a collection, of course), assert that Billy and Peter are instances of it, make whatever assertions on it you think are required to capture the meaning of 'cat' and, in particular, make whatever `#$disjointWith` assertions are required for Cyc to be able to prove that Billy is not a dog. (Make sure you test with an actual 'Ask' to verify!)

Now, if you are up to a challenge, see if you can make whatever `#$disjointWith` assertions are required for Cyc not to conclude any analogous wrong thing about Billy....:-)

Further reading on negation in CycL

What else should we expect Cyc to be able to infer about Billy and Peter?

Here are some suggestions for further Asks:

> - Is Billy light enough to be carried around? (Can be proven True, under the right circumstances)

> - Have Billy and Peter ever met or come into physical contact? (Can be proven True, though this one is harder than the last! Hint: the relevant predicate may take some digging up.)

I encourage you to try doing some other asks, then making some other assertions, then doing still further asks....You are now on your way to becoming a Cyc-savvy ontological engineer. Have fun!!

Now that you hav completed the shorter versions of steps three and four, if you would like a more detailed explanation of how to use microtheories and where to place assertions in the microtheory hierarchy, then read the considerably longer version of this walkthrough.

Step four summary - we have performed some inference-testing and found out that Cyc does not only know what we told it in Step 3, it is able to make certain inferences based on that knowledge, which shows that it has integrated that knowledge into the larger KB.

Last update: 08/28/2002 | Copyright © 2002 Cycorp All rights reserved.