This paper reviews my definition of context, and then discusses context errors which occur in the real world. Common types of errors are identified, along with general methods of correcting these errors. Several real world examples are presented.
Every proposition has a context, which is a list of other propositions. The “view” attribute names that proposition list. A context may have “space”, “time” subcontexts which specify where, when actions occur.
The goal to strive for: a genus-differentia definition for every concept.
A context is represented as an entity-characteristic-proposition (ECP) hierarchy, which is the fundamental knowledge unit (knit).
The goal to strive for: fully characterize all actions, without suppressing any important information.
All of the above principles have been implemented in the MKR language. MKR is a user-friendly RI (“Real Intelligence”) language. MKR uses terse English-like propositions to help a human user focus on the essentials, and avoid floating abstractions.
The MKE program is the core of a knowledge base (KB) system which uses the MKR language as a user interface. MKE includes an intelligent knowledge assistant (ke) which helps the user record/change/search knowledge, checks the knowledge for inconsistencies, and executes user commands.
The rest of this paper discusses the kinds of errors that occur and how those errors are corrected, and gives several real world examples.
MKE classifies every concept in its input stream. If the user doesn’t specify a genus, MKE classifies the concept as unknown.
MKE checks every concept to see if a genus-differentia definition has been specified. If not, the concept is undefined.
MKE checks the genus of each concept. If it has more than one genus, it is ambiguous.
If a concept (which is an abstraction) has also been specified to be an individual (which is a concrete thing), MKE flags it as an error.
Since loops in the ECP hierarchy can cause infinite loops in inference programs, MKE flags any loops as errors.
The internal structure of the ECP hierarchy uses many double-linked lists (for faster KB processing). Some MKE “bugs” will delete one of these links. MKE checks itself by flagging broken links as errors.
Ambiguous concepts usually indicate that two distinct concepts were inadvertently given the same name. The solution is easy – give each distinct concept a distinct name.
Sometimes an unknown concept is simply the result of “reference before definition”. The MKE command
do check od unknown done;
checks for this case (concept has one other genus besides unknown), and reclassifies the concept. If the concept has more than one other genus, then it is ambiguous.
If the user notices that a concept has the wrong genus
concept iss wrong genus;
it can be corrected by adding this statement to the KB
concept isd right genus;
If a new concept needs to be inserted into the KB, it can be done with
new concept isi species1, species2, … ;
Ambiguous concepts may arise from merging several “partial” contexts. Often, the ambiguity can be resolved by keeping only the most specific reference to the concept. For example, the hierarchy
can be replaced by
The MKE command
do simplify lattice od car done;
automatically makes any changes of this type in the car subhierarchy.
In the MKR knowledge base, the first use of “man” is in the broad philosophical sense, as used by Aristotle.
man iss animal with rational;
which corresponds to the hierarchy
This differs from the every day use of animal and man, which
Corresponds to the hierarchy
Merging these two contexts, we get the hierarchy
MKE automatically detected the ambiguity in man. We can “correct” man by differentiation.
man isd person;
In the early version of MKE, set had two different meanings: the verb which denotes assignment, and the mathematical group.
set charformat = column;
set iss group with inclusive, no order;
MKE automatically detected this ambiguity, and I decided to use set and Set for these two concepts. More recently, I decided that I would rather use the conventional lower case name for the mathematical group, so I changed the names to let and set.
These are MKR verbs which denote unary, binary, ternary, n-ary relations. When I began to work with the OWL language, I needed to distinguish the different types of OWL properties in order to translate between OWL and MKR. I assigned a chartype attribute to each OWL property. For example
rdfs:subClassOf has chartype = brel;
MKE immediately rejected this statement – it’s a syntax error, because brel is a verb.
So I changed my description to
Rdfs:subClassOf has chartype = relation, arity=2;
The current definition of owl:Class is based on non-well-founded set theory. When MKE processes an OWL ontology, it detects two types of errors: infinite loops and “strange things” which are both individuals and classes. For all of my work with OWL, I replace owl:Class (the class of all Classes) with owl:ClassSet (the set of all Classes), which produces a language governed by well-founded set theory.
I often volunteer to help users who are trying to “debug” their ontologies. MKE is very helpful in these situations. It provides many error checks, useful KB statistics, and “pretty-prints” the ECP hierarchy with a simple command
Thing isc* ?;
Sometimes, MKE “confuses” the user, because the entities and properties of ke (and its ECP hierarchy) are merged together with the entities and properties of the user’s ontology. Some of this confusion must be tolerated. If you delete the properties of ke, you have deleted its self-knowledge, and it is no longer an “intelligent” assistant.
There is one simple “trick” which I have used to ease the confusion. I mark the ke properties as “hidden”, so that they are not displayed when the user’s hierarchy is displayed.