Microtheories

  This section is a continuation of the tutorial on foundations of knowledge representation in Cyc.  Our final topic: microtheories.

A Bundle of Assertions

The Cyc Knowledge Base (KB) can be thought of as a vast sea of assertions.  A microtheory is a set of assertions from that sea, an identification of a group of assertions that we pick out from the knowledge base.

Assertions can be bundled into microtheories based on shared assumptions, shared topics, shared sources, or other features.

Avoiding Inconsistencies

  One of the functions of microtheories is to separate assertions into consistent bundles.  Within a microtheory, the assertions must be mutually consistent.  This means that no hard contradictions are allowed, and any apparent contradictions must be resolvable by evaluation of the evidence visible in that microtheory.  In contrast, there may be inconsistencies across microtheories.

Consider the pair of microtheories on the lower left of the slide (MT1 and MT2), which differ primarily in terms of the granularity considered.  In the first microtheory (MT1), the granularity is that of ordinary human perception.  In that microtheory, tables, for example, are solid objects.  In the second microtheory (MT2), the granularity is that of particle physics.  In that microtheory, tables consist mostly of space.

Opposite those two microtheories is another example: three microtheories which differ primarily in time.  In the first microtheory, the latest of the three, Mandela is an elder statesman.  In the second microtheory, which is a bit earlier, Mandela is the president of South Africa.  In the third microtheory, which is earlier still, Mandela is a political prisoner.

Every Assertion is in a Microtheory

  Every assertion in the KB falls within at least one microtheory.  Currently every microtheory in Cyc is a specific reified, or named, term; each microtheory has its own constant.   Examples include the #$HumanActivitiesMt microtheory and the #$OrganizationMt microtheory.  These microtheories give us one way of indexing all of the assertions in Cyc.

Why Have Microtheories?

Why do we want microtheories? We want them because they enable better knowledge base building and better inference.

First, microtheories allow us to focus development of the KB.  By gathering the most relevant information together,  microtheories enable the KB builder to focus on that information, rather than wading continuously through the entire KB.  This focusing power also improves inference; reasoning can be focused on the most relevant information, reducing search space and improving efficiency.

Second, microtheories enable us to use terse assertions.  For example, if we use microtheories to gather together assertions that hold throughout 1995 and in South Africa, then when we make assertions or reason within that context, we can use a nice terse assertion such as “Mandela is president.”  Without the ability to form and specify a context, we would need to explicitly state the relevant assumptions.  That is, we would need to build such contextualization into the assertions, such as “Mandela is president throughout 1995 in South Africa.”  Microtheories make knowledge base building more efficient.

Third, microtheories allow us to cope with global inconsistency in the KB.  In building a knowledge base of this scale, covering different points of view, different times and places, different theories, and different topics, some inconsistency is inevitable.  Inconsistencies, however, can make accurate reasoning impossible.  Using microtheories, we can isolate terse assertions like the above from others with which they might be inconsistent, and reason within consistent bundles.

Why Have microtheories? (cont.)

  We can allow inference to focus on the most relevant assertions, and those that share the current assumptions.

Since we use terser assertions, the inference engine has terser formulas to process, also increasing efficiency.

Because inconsistencies are isolated from each other (making the KB globally inconsistent but locally consistent), the inference engine can reason with the wide range of points of view, theories, and changes over time and space that are represented in the KB without running into inconsistencies.

Some types of microtheories

  There are many different types of microtheories in the Cyc KB.  On the slide is a sample of microtheory types which distinguish microtheories on the basis of how context-sensitive the information is.

For example, #$VocabularyMicrotheory is the collection of all microtheories which contain primarily definitional information, such as definitions of vocabulary having to do with transportation or with computer software.

#$TheoryMicrotheory is a collection of microtheories which contain substantial rules and knowledge that is stated in vocabulary from a specific #$VocabularyMicrotheory.  So for example, #$ComputerSoftwareMt microtheory might contain general principles about computer software (that it runs on computers, for example) using the vocabulary in #$ComputerSoftwareVocabMt.

#$DataMicrotheory, on the other hand, is the collection of all microtheories which contain specific individual-level information.  So for example, #$ComputerSoftwareDataMt might have assertions about specific software programs and their use, using the general principles in the #$ComputerSoftwareMt and the vocabulary in #$ComputerSoftwareVocabMt.

Some types of microtheories

  #$PropositionalInformationThing is a collection of microtheories, each of which contains the content (the information) contained in some information-bearing thing, such as a picture, movie, audio tape, or book.  For example, if we wanted to represent all of the informational content of this CycL course in Cyc, we would put it into a #$PropositionalInformationThing microtheory.  If we wanted to represent this course itself, it would be an #$InformationBearingThing and the #$PropositionalInformationThing microtheory would be related using specific #$ContainsInformation relationships to the #$InformationBearingThing.

#$CounterfactualContext is an especially interesting collection of microtheories.   Each counterfactual context is a microtheory in which at least some of the assertions in it are not taken to be true.  One specialization of #$CounterfactualContext is #$FictionalContext.  Consider, for example, #$TheSimpsonsMt, which contains propositional information presented within The Simpsons TV show.  Clearly the writers of The Simpsons do not take these assertions to be literally, factually true, nor do they intend for their audience to believe them.  They want us to consider the propositions, but in some way differently than we would factual information.  It’s important to be able to distinguish microtheories like this and treat them differently from the way we treat microtheories which are supposed to be factual.

#$CounterfactualContext is also a generalization of #$HypotheticalContext.  #$HypotheticalContext’s allow us to consider what would happen if something were true, without actually treating that possibility in the KB as if it were factually true and modifying our current representation accordingly.

Microtheory predicates: #$ist

To say that an assertion is true within a microtheory, we use the predicate #$ist.  A formula of the form (#$ist MT FORMULA) means that the formula in the second argument place is true in the microtheory specified in the first argument place.  So for example, it’s true in the #$CyclistsMt microtheory that #$Lenat is an instance of #$Person.  It’s true in the #$NaiveStateChangeMt microtheory that if you have a freezing event and you have something that’s created in that freezing event, that created object is in a solid state.

Why is it important to locate this last assertion in the #$NaiveStateChangeMt microtheory?  Because #$outputsCreated, that predicate in the second-to-last line, is restricted to use in events in which something is destroyed and something is created.  That’s the naīve view of something like freezing, where we talk about water disappearing and ice that is created.  But of course this would not be a physicist’s view of the event.  In a physicists view,  nothing is created or destroyed; rather, something undergoes a change of state.  So, this assertion is local to #$NaiveStateChangeMt.   And #$ist allows us to specify that.

Microtheory predicates: #$genlMt

To say that two microtheories are related by an inheritance relationship, we use the predicate #$genlMt.  A formula of the form (#$genlMt MT-1 MT-2) means that every assertion which is true in the microtheory in the second argument place is also true in the microtheory in the first argument place.  Another way of putting this is that MT-1 inherits from MT-2, or that MT-2 is visible from MT-1.

The first example sentence states that the #$TransportationMt microtheory inherits from the #$NaivePhysicsMt microtheory.  When you’re in the #$TransportationMt microtheory you can see all of the assertions in #$NaivePhysicsMt and use them.

The second example sentence states that #$ModernMilitaryTacticsMt inherits all of the assertions from #$ModernMilitaryVehiclesMt, so if you’re talking about tactics you can use the knowledge about vehicles.

The third example sentence states that the #$Transportation Mt is visible from the #$EconomyMt.  When you are reasoning in the #$EconomyMt, say about imports and exports, you can use the knowledge about transportation.

#$genlMt is transitive.  Notice that the first sentence says that #$NaivePhysicsMt is visible from #$TransportationMt, and the third says that #$TransportationMt is visible from #$EconomyMt.  Since #$genlMt is transitive, it follows that #$NaivePhysicsMt is visible from #$EconomyMt.

Microtheory predicates, cont’d

Here’s a sample #$genlMt hierarchy.

The #$TransportationMt microtheory inherits from the #$NaivePhysicsMt microtheory, meaning that all naïve physics knowledge is visible in #$TransportationMt.  Since #$NaivePhysicsMt inherits from #$NaiveSpatialMt and #$genlMt is transitive, all of the assertions in #$NaiveSpatialMt are also visible in #$TransportationMt.  Given the #$genlMt heirarchy on this slide, if you are writing an assertion or asking a query in #$TransportationMt, you can rely on all of the knowledge in #$NaivePhysicsMt, #$NaiveSpatialMt, #$MovementMt and #$BaseKB.

#$NaturalGeographyMt, on the lower left of the slide, inherits from #$NaiveSpatialMt as well, but doesn’t inherit from #$NaivePhysicsMt or #$MovementMt.  If you’re stating an assertion or asking a query within the #$NaturalGeographyMt microtheory, you can count on the information in #$NaiveSpatialMt and in #$BaseKB, but not the information in #$NaivePhysicsMt or #$MovementMt.

Finding the right microtheory

Microtheory placement is very important in both assertion-making and query-asking.

Consider: an assertion is visible only in the Mt’s that inherit from the microtheories in which it is placed.  When a query is answered, the inference answering the query uses exactly those assertions that are in microtheories that are visible from the microtheory in which it is asked.  In other words, the query is answered using only the information available in the current microtheory or above it in the microtheory hierarchy.  Furthermore, for an assertion or query to be well-formed (to make sense in Cyc), requires that the definitional information about the terms used in that query or assertion be visible from the microtheory where it is asked or asserted.

This gives rise to a certain tension.  If you’re making an assertion and you want it to be visible everywhere in which it might be needed, you want to place it fairly high up, not too low down.  On the other hand, if you want to make sure that your assertions are not visible where they’re not needed, so that you minimize your search space for inference, you don’t want to place your assertions too high;  you want to place them lower, more specifically.

As it turns out, this tension has different consequences depending on the application that is being developed.  If accuracy (or completeness) is more important than efficiency, KB builders will tend to place their assertions higher in the microtheory hierarchy.  If efficiency is more important, they’ll tend to place them lower and sacrifice completeness.  In either case, though, good microtheory placement is very important.

Finding the right microtheory

  There are many instances of #$Microtheory in the KB – several thousand, in fact.  At the moment, there is no substitute for familiarity with the microtheories relevant to the area in which you are working.

To understand a microtheory in the KB, the first thing to do is to read the comment.  Examining the assertions can also reveal the intent behind the microtheory, as can examining where it falls in the microtheory hierarchy.

Forthcoming Changes/Improvements

Cycorp has identified additional features as forthcoming changes or improvements.  These will enable us to get the most out of the microtheory hierarchy.

To maximize the efficiency of ontology building and inference, we want microtheories that are dynamically generated.  We don’t want to specify ahead of time which gatherings, or bundles, of assertions might be most relevant.  We want to be able to do that on the fly. according to any features that we need at the moment.

We’d like to have power tools that suggest where in the microtheory hierarchy a query or assertion can be placed.  This would assist a KB builder or application user in finding the right information without requiring them to have full familiarity with all possibly relevant microtheories.  We’d also like more specifically targeted, smaller contexts.  In other words we’d like to re-place assertions to get exactly the right place on the hierarchy to counteract some of the inexactness coming from the tension described earlier.

In order to have those features we need more explicit representation of the context features than we currently have.  We’d like to explicitly represent the topic, the level of granularity, and the time period in which a microtheory holds as well as other features that, in our experience, tend to be relevant for inference and knowledge representation.  Further, for each such feature, a deep and explicit representation of the relationship that holds between contexts that differ along that feature, for example contexts that differ in time,  is also needed.

These developments are covered under two projects.  The Rapid Knowledge Formation project includes the development of power tools to assist in microtheory placement.  The internal Context Overhaul project includes moving to dynamic generation, smaller context definition, and more explicit context definition.

Summary

  In summary, we’ve reviewed what a microtheory is: a bundle of assertions out of the Cyc KB.  We've looked at some reasons for having microtheories, and the benefits for both knowledge base building and inference.  We’ve seen some sample types of microtheories.  We’ve looked at the two foundational  microtheory predicates: #$ist and #$genlMt.  Finally, we reviewed considerations in finding the right microtheory: not too specific and not too general.