Implementation Work on SILKIE

Transcription

1 Program Structure Implementation Work on SILKIE Tom Eskridge, IHMC, 2009 While the whole system is not yet complete, much of the infrastructure of SILKIE has been implemented, including a robust parser and clause constructor, and linear unifier. Overview SILKIE uses tableau-style reasoning and unit resolution, treating them essentially as two halves of a bidirectional search strategy. The search is primarily governed by the growth of the tableau. Resolution is applied when it will shorten or truncate a potential tableau extension, and acts as a form of archiving of lemmas dioscovered during the tableau search. The search strategy is partially controlled by scripts, which are userprovided constraints upon tableau extensions. At each search point, the active scripts are consulted in order until one is found which applies to the conditions (currently determined by the values of a small number of global parameters and the state of the current open tableau branch being extended) and that determines the way that the tableau is extended. Although this is not yet implemented, we plan to allow for scripts which take control for a series of inferences, in effect running an algorithm in pursuit of a local goal; such mechanisms are appropriate for example when tracing up subclass chains. Parser Several versions of the IKL parser have been developed during the course of this project so far. Each version has had strengths and weaknesses, either from the implementation language used (C++, LISP, and Java) and from the parsing/lexing style employed (direct parsing, EBNF, LL(r)). For several reasons, the final parser/lexer chosen was a Java implementation based on the ANTLR parser generator ( These reasons include: 1. Ease of development of the lexer/parser. The ANTLR program interprets a rule-based format shown in Figs 2 & 3 to generate Java code that is capable of recognizing syntactically correct input. It also provides extensions to the recognition components that allow the generation of internal program structure that can be used for later processing. We take advantage of both of these capabilities in the implemented parser.

2 2. Portability of the resulting parser. The ANTLR community is large and very active. Thus, the resulting parser will be available and potentially useful to researchers in a wide variety of other fields. 3. Language independence of the resulting parser. ANTLR separates the issues of recognizing the language from the construction of lexers/parsers for that language. Thus, lexers/parsers can be output in several different languages, including java, C, python, C#, and ActionScript. Other more experimental language emitters are also available. 4. The quality/maintainability of the resulting grammar. Fig. 1 shows the dependency graph of the implemented grammar. The narrowness and simplicity of the graph provides a good indication of the continuing ability to test, evaluate, and extend the grammar. Researchers will be able to understand the existing code and make modifications as necessary to support future language revisions. The parsing component of the program is implemented in three sections. The first two sections are those created by the ANTLR program, the lexer and parser. The third section takes the abstract parse tree constructed by the ANTLR-generated code and normalizes the clauses read in. During the process of normalization, the code generates a network structure of term identifiers (TIDs) that are used as the basis for the linear unification algorithm. This process also populates a number of controls that can be used by the scripting language to control the direction of future processing by the resolution and/or other proof systems. Fig. 1 shows a block diagram of the parsing sections in context of the script reasoning component.

3 IKL Input Input IKL Text Lexer IKL Tokens Parser Abstract Syntax Tree Graph Construction Normalized Term IDs, Scripts Controls Reasoning Updates Script Execution Fig. 1. Block Structure Diagram. Shows the implemented parsing components (the shaded boxes) in the context of the script reasoning and execution module. Normalization Our initial implementation includes the normalization functionality discussed in (Hayes 2009.) For example, the input statement: (FredBelieves (that (forall ((x human)) (exists (y)(hasfather x y))))) can be parsed and converted into the following abstract syntax tree. FredBelieves THAT that QUANTIFIER forall

4 BINDING TYPEDBINDING x human QUANTIFIER exists BINDING BINDING y hasfather x y The normalization process eliminates the proposition names, eliminates all connectives other than conjunction, disjunction and atomic negations, and skolemizes the exposed quantifiers, resulting in three conjuncts: Conjunct 1: (FredBelieves THSK) FredBelieves THSK Conjunct 2: (or (not (THSK)) (hasfather x (SK1 x))) BOOLEAN or NEGATION not THSK nil hasfather

5 x FUNCTION SK1 x Conjunct 3: (or (not (hasfather SK2 x)) (THSK)) BOOLEAN or NEGATION not hasfather SK2 x THSK nil The result of normalization is a text of expressions which are written entirely in the CLIF dialect of common logic using only the and and or connectives and negation only applied to atomic sentences and equations, and the universal quantifier. We do not convert all the way to clausal form. Conjunctions inside disjunctions may become exposed by resolution operations, and are then treated as new expressons. This limits the search space to a moderate extent, while facilitating tableau reasoning. Matching and Unification One of our focus issues was the efficiency of the matching and unification process. We investigated a number of different approaches to this problem, first with the goal of understanding where the recent advancements in efficiency have been made, then with the goal of attempting to integrate and reuse existing software. The motivation for doing this was the idea that the most important component of a nonscriptable reasoner is its matching and unification algorithm. This algorithm is run thousands of times for even simple problems, and so any efficiency enhancement made here will affect all subsequent processing.

6 Graph Hashing One of the first techniques that we investigated to improve the speed of the matching and unification algorithm was the idea of producing a signature for each conjunct in memory, and to use that signature to determine which conjuncts will unify and which will not. Doing this will allow a simple linear test (perhaps log(n) with a shared graph structure) to determine which conjuncts in memory should be tested for unification. One signature we considered is the bloom filter (Bloom 1970). Bloom filters are probabilistic data structures that enable the constant time determination of the membership of an element in a set. Our initial experiments with Bloom filters included implementing a function to compute Bloom filters on CNF conjuncts and testing on relatively small data sets. Our conclusions from this simple experiment were that it would not be applicable for our purposes due to the false positives inherent in the Bloom filter design and the inability to remove elements from the filter. The relative lack of situations where there no unifiable conjuncts (which the Bloom filter can reliably tell) reduced the utility of including the filter enough to cause us to look at other methods. The second method for graph signatures that we investigated were based on hashing techniques (Portegys ; Cordella, Foggia et al. 1999; Cordella, Foggia et al. 2001; Plate 2003; Cordella, Foggia et al. 2004). The central idea here is that by spending time at CNF creation time to encode a hash of the conjunct, we can greatly reduce the time necessary to determine if the conjuncts are unifiable or not. We have experimented with two different implementation of the Holographic Reduced Representations (Plate 2003) and graph hashing with MD5 (Portegys ; Portegys 2009). Based on tests run, the utility of the approach appears to be promising. Linear Unification with Term Identifiers Term Identifiers (TIDs) are data structures that are constructed during the CNF normalization process to enable maximal reuse of the conjunct graph structures and to facilitate the unification process. Although there are faster unification algorithms than the one being developed here, they are also considerably more complex - both conceptually and in implementation. The method under development here draws from (Henckel 1997) and (Henckel 1993) with modifications appropriate to our implementation language and use. A Term Identifier (TID) is a small graph structure that represents the variables in a clause available for unification, and their possible substitutions. For example, the TID for the expression father-of(x,y) AND mother-of(y, z) is shown in Fig 2a. This shows two predicate terms each containing two variables, with one of them shared. Fig. 2b shows another TID, this time with literals filled in for the variables. Unifying the two clauses fills in the variable list (shown as NIL in both figures.) The shared substructure Y allows each unification step to either completely dereference a variable, or to move deeper into

7 the TID structure. Thus, if m is the number of variables in the expression and n is the number of nodes in the TID graphs, then the number of recursive unifications that will be called is m+n. father-of mother-of father-of mother-of X Y Z Tom Bob Katie T1 T2 NIL NIL (a) (b) Fig. 2. Term Identifiers. At the start of the unification process, the variable matching lists are set to NIL. Scripting the Reasoning Process One of the main ideas behind this work is the idea that the data should drive the processing to be performed. In this way, input forms which fall within a known inferential 'sweet spot' can be handled by strategies known to be of utility there. The paradigm example of course are the well-known description logic subcases of full FOL. When the IKL read into the system can be determined to be in DL form, the processing to be done should follow standard DL reasoning methods, which can be described as constraints and conditions on the underlying tableau-construction process. To recognize these as patterns in arbitrary IKL axioms, while possible in principle, is probably not feasible. We have adopted the simpler strategy of recognizing DL input encoded in a particular way using a known, fixed vocabulary and following a standard translation scheme. This of course requires users to adopt a particular axiomatic style for composing DL content in IKL (in fact, in CL) in order to enable the reasoner to use the associated search strategies, but this is still a much lower burden than being obliged to use an entirely different language, with distinct parsers and infrastructure; particularly as the axiomatic style in question closely mirrors the compact and readable 'Manchester syntax' for OWL. For example, The Manchester syntax OWL expression Person and haschild some (Person and (haschild only Man)) becomes the IKL term (AND Person (SOME haschild (AND Person (ONLY haschild Man)))))

8 in the 'standard' translation. The reasoner recognizes the use of the special function name AND (note, distinguished from the connective and) as having its own tableau extension rule and applies this directly, rather than expanding it using the recursive axiomatic definition (forall (x)((and) x)) (forall (x p)(iff ((AND p...) x)(and (p x)((and...) x) ) )) One can think of this as an efficient implementation of a form of greedy inference, in which the axiomatic defintion, once triggered, is re-run until it cannot be applied further. Currently, our scripting abilities are limited to 'switching on' a set of triggered tableau rules which are associated to a given vocabulary in this way. This enables the engine to accurately emulate a DL tableau reasoner, while retaining the background ability to perform general infernces. However, it means that one gains the efficiency of the restricted search only when the input is strictly conformant to the relevant vocabulary's usual restrictions. The result is that the system behaves more like a 'switchable' DL reasoner connected to a general-purpose resolution reasoner, and is not able currently to take advantage of the DL reasoning in a fully opportunistic way. We plan to experiment with more sophisticated strategies, based more explicitly upon the use of the underlying recursive definitions, in future work. Global parameters We currently compute a number of global parameter values of the input set and the set of resolutions generated. Work on propositional reasoners has shown that the ratio of numbers of clauses to numbers of propositions is a highly predictive measure of the likelihood of satisfiability, especially for large set of propositions. We hope to be able to compute estimates of this ratio for the set of all possible instances of the expressions currently in use, to help focus the search towards those expressions which are more likely to increase the 'propositinal density' of the instance space. There are a number of features that can be extracted from the IKL structures that may be accessed from a scripting language to control the reasoning process. Some of these are: 1. # of individual TIDs (negated/not negated) 2. # of shared TIDs (negated/not negated) 3. # reasoning steps so far 4. # reasoning steps on current branch The scripts themselves are basically control statements that are used to determine what priority to give each open branch of the tableau and to filter possible extensions to the branch, i.e. to select from the logically possible extensions provided by the sentences in the theory under consideration.

9 In future work, we plan to use (an expanded) such a vector of features as the 'genome' of a genetic learning process which to learn new search strategies. Bibliography Bloom, B. H. (1970). "Space/time trade-offs in hash coding with allowable errors." Communications of the ACM 13(7): Cordella, L. P., P. Foggia, et al. (1999). performance Evaluation of the VF Graph Matching Algorithm. Proceedings of the 10th ICIAP, IEEE Computer Society Press. 2: Cordella, L. P., P. Foggia, et al. (2001). An Improved Algorithm for Matching Large Graphs. Proceedings of the International Workshop on Graph-based Representation in Pattern Recognition, Ischia, Italy. Cordella, L. P., P. Foggia, et al. (2004). "A (sub)graph isomorphism algorithm for matching large graphs." Pattern Analysis and Machine Intelligence, IEEE Transactions on 26(10): Henckel, J. (1993). Theorem prover with natural language interface. Computer Science, University of Minnesota. M.S. Henckel, J. (1997). "An efficient linear unification algorithm." Retrieved Nov 11, 2008, from Plate, T. A. (2003). Holographic reduced representation : distributed representation for cognitive structures. Stanford, Calif., CSLI Publications. Portegys, T. E. General Graph identification with Hashing. Normal, IL, Illinois State University. Portegys, T. E. (2009). "General Graph Identification by Hashing." Retrieved Feb 12, 2009, from