We discuss the development of an environment for formal knowledge engineering. The Sigma system is an advance over previously developed systems in that it integrates a number of modern ontology development tools, which has motivated a number of research issues. Primary components include an ontology browsing and editing environment, a first order logic inference system and a natural language to logic translator. Although largely independent of any particular ontology, it supports a number of publicly available formal ontologies.
Human knowledge is complex, and human language is very expressive. Computer systems that process natural language have been limited to a shallow level of understanding by the very complexity of the information that they are expected to handle. Conversely, systems that manage information in databases have been left to reason either in very narrow and pre-determined ways, or to perform processing tasks that must be interpreted by humans.
It is desirable to employ computer languages for
representing knowledge that are as expressive as possible,
and as close to the expressiveness of human language.
Expressiveness does have a computational burden. In the
opinion of the author, the best compromise available for
many knowledge representation efforts is first order logic.
While there are other choices, such as description logic and
higher order logic, they represent departures from a middle
ground. First order logic is undecidable, but can be made
tractable for certain kinds of reasoning, which will be
detailed later. Description logic
The Sigma system was designed to integrate several different kinds of tools for working with knowledge in first order logic.
The Sigma system contains several different sorts of browsers for viewing formal knowledge bases. The most basic component is a term browser, which presents all the statements in which a particular term appears. The statements are sorted by argument position and then the appearance of the term in rules and non-rule statements are then shown. All the statements are hyperlinked to the terms that appear in them.
Two types of tree browser are provided. One provides an automatic graph layout. Another shows a textual hierarchy. The user can chose the term to start with, the number of “levels” that should be presented from the term, and the binary relation to chose as the predicate that links the different nodes in the graph. For example, if the user asks for a graph of the term IntentionalProcess and for the subclass relation, the system will go “up” the graph to display the term Process, and down the graph to display the terms Keeping, Guiding, Maintaining etc. The user can ask for more levels up or down the graph. Note that any relation can be chosen so for example a presentation of partonomies, or attribute hierarchies is also supported by choosing the relations part and subAttribute respectively.
The editing system is currently rather rudimentary, consisting of the ability to type formulae and have some simple syntax and other error checking performed. We plan to offer a frame-based editing system similar to, or incorporating open-source components from, the Protégé (Gennari et al, 2002) system.
We have developed some more sophisticated tools for
collaborative knowledge engineering. The System for
Collaborative Open Ontology Production (SCOOP)
SCOOP addresses several types of inconsistencies. The first we term vertical inconsistency. This refers to when a set of ontologies are loaded and one ontology has a contradiction with another ontology on which it depends. Inconsistency of this type is never allowed, because from a contradictory knowledge base, any proposition can be concluded to be true. SCOOP enforces a workflow process that requires a resolution to such a situation.
The second kind of inconsistency we term horizontal inconsistency. This refers to a situation in which knowledge products created by different knowledge engineers, and which do not have a mutual dependency, are mutually contradictory. SCOOP alerts developers to such a situation, but does not require that it be eliminated. It is possible for two knowledge bases to represent different perspectives, which are contradictory, but locally valid.
We employ the KIF (Genesereth, 1991) language and
have a translator to and from DAML
Each statement can also be presented as a natural language paraphrase similar to (Sevcenko, 2003). Note that we also use Sevcenko’s language templates for English and Czech. Each term in an ontology can be given a natural language presentation form, indexed by the human language. For example, the SUMO term DiseaseOrSyndrome can be presented as “ disease or syndrome” and an Italian presentation would be shown as "malattia o sindrome". Combined with the English understanding mechanisms described below, this gives us a very rudimentary language translation capability.
Although presentation of terms is straightforward, presentation of statements is more complicated, and roughly patterned after C-language printf statements. For example the relation “ part” , which states that one object is a part of another, has the corresponding language generation template “ %1 is %n a part of %2” . The first argument to the logical relation is substituted for %1 etc. Note that this substitution is recursive, so that complex statements with nested formulae can be translated effectively. The %n signifies that if the statement is negated, that the negation operator for the appropriate human language should be inserted in that position.
We currently have language templates for English, Czech, German and Italian. Some work has been done on Hindi, Telugu, Tagalog and Russian.
We take a restricted language approach to natural language understanding. Deep understanding of unrestricted human languages is too hard with present technology. Our approach is to create a restricted version of English, which is grammatical but more limited than true natural language. Statements must be present tense singular. Although different tense and number can be accepted, the system paraphrases such sentences into a present tense singular form. Ambiguous word choices default to the most popular sense of the word, with an escape mechanism for the user to select a different sense. Anaphoric references are handled with a simple mechanical algorithm. Some kinds of quantification (every, some, all) can be handled.
The current system is capable of taking simple English
sentences and translating them into KIF, using terms from
our SUMO upper ontology (described below). We have
mapped all 100,000 WordNet (Miller, et al, 1993) word
senses (synsets) to SUMO, one at a time, by hand over the
period of a year
Our approach is presented more fully in
One basic issue is that of allowing variables in the predicate position. While the general case of this results in expressions being beyond first order logic, there is a slightly more restricted case, which is first order. A statement with a variable in the predicate position is only higher order if a quantifer ranges of all possible relations, rather than the finite set of relations in a particular knowledge base. Since prepending another relation in front of every statement makes everything first order for such a restricted practical case, this therefore must mean that the statement wasn’t really higher-order in the first place.
There is also an issue with prohibiting statements as arguments to relations. When arguments to relations are statements, then such a statement is higher order. We could either have a quote operator or define a Statement class and require all predicates have their argument types defined (which would allow us to know in advance whether an argument is a Statement, and therefore needs to be implicitly quoted). A statement that has this issue is (believes John (likes Bob Mary))
Currently, such statements are quoted, and therefore become opaque first-order objects rather than statements.
Another issue is row variables, for use in variable arity
relations. One proposed version of KIF
Also note that this "macro" style expansion has the problem that unlike the true semantics of row variables, that it is not infinite. If the macro processor only expands to five variables, there is a problem if the knowledge engineer uses a relation with six. Because of that, Sigma’s syntax checker must prohibit relations with more arguments than the row variable preprocessor expands to.
Given the example KB: (=> (instance ?X Bird) (canFly ?X)) (=> (instance ?X Penguin) (not
(canFly ?X))) (subclass Penguin Bird) We would like the second rule to override the first. The general case of default reasoning is very difficult (Schlechta, 1997). However, we believe that there is an easy way to address the most common case and get the utility we need. Given a relation (exception <formula-specific> <formula2-general>) we can implement a macro that modifies the first formula above to exclude the exception specified and generate the KB (=> (and (instance ?X Bird) (not (instance ?X Penguin)) (canFly ?X)) (=> (instance ?X Penguin) (not
(canFly ?X))) (subclass Penguin Bird)
Of course, this is only easy in the specific case where two rules have opposite conclusions and the antecedent of one subsumes the other. It’s possible that in easy cases we might be able to have Sigma even generate the (exception... clause that the macro will use.
The algorithm for the macro simply would be, given the (exception... statement, to negate the antecedent of the <formula-specific> and add it as a conjunction to the <formula2-general>. Like other macros, this has implications for proof presentation that are also unresolved.
Sigma includes several options for proof presentation. Despite the fact that most textbooks present proofs as linear structures, proofs are trees. The same sub-proof may be used several times in reaching different intermediate conclusions. While this is a byproduct of automated reasoning, it is rarely useful to the human user. Therefore, Sigma eliminates redundant paths of reasoning in order to create a linear proof.
Sigma also has options for how it presents multiple proofs. Often, the same proof, with the same proof steps, can be reached via a different search order. This means that although two tree-structured proofs may be different, they may work out to be identical when redundant paths are removed and a linear proof structure generated. Sigma supports an option for hiding such duplicate proofs.
On additional option is to suppress proofs that may have different steps but which lead to the same answer. Sometime it is useful to a knowledge engineer to see these alternate proofs, and sometime not.
One problem in a first order theorem prover with procedural attachments for arithmetic is that the equality operator masks normal unification and inference. Currently Sigma converts the SUMO term ’equal’ to ’=’ when sending assertions and queries to the theorem prover and then converts back for proof formatting. We are experimenting with changing the name to ’eval’ and mapping that string to the theorem prover’s '= '.
Our current idea is to have three predicates, one, which handles evaluation, one, which handles inference, and another, which combines the two. equalAsserted eval
equal The following examples of assertions and queries should make clear how this will work. assert: (equal (CardinalityFn Continent) 7) macro expands to: (eval (CardinalityFn Continent) 7) (equalAssigned (CardinalityFn Continent) 7) documentation allows us to alert the user when such statements are conflicting or not present.
We employ the Suggested Upper Merged Ontology
(SUMO)
A number of domain ontologies have been created that extend SUMO and can be used in the Sigma system. They include ·
A Quality of Service ontology, covering computer systems and networks An ecommerce services ontology An ontology of biological viruses A financial ontology An ontology of terrain features Ontologies of weapons of mass destruction and terrorism An ontology of government and governmental organizations Taxonomies of the periodic table of the elements and industry types
There have been a number of ontology editing
environments created including Ontolingua
The GKB editor
The author would like to thank Randy Schulz for his efforts on early versions of this system. query: (equalAssigned (AdditionFn 2 3) ?X) query: (equal (AdditionFn 2 3) ?X) macro expands to: (eval (AdditionFn 2 3) ?X) (equalAssigned (AdditionFn 2 3) ?X) The formal semantics of the macro is (=> (equal ?X ?Y) (eval ?X ?Y)) (=> (equal ?X ?Y) (equalAssigned ?X ?Y))
The Sigma system has been designed to be as independent of a particular ontology as possible, but there are many features that are available when a standard ontology is used. Current features are primarily to do with error checking. Knowing a standard method for defining argument type restrictions, class-subclass relations and