380 likes | 402 Views
OntoMorph: A Translation System for Symbolic Knowledge. Hans Chalupsky Loom/PowerLoom Group USC Information Sciences Institute. Overview. Motivation Translation Problem OntoMorph Overview OntoMorph Applications Conclusions. Motivation. Observations
E N D
OntoMorph: A Translation Systemfor Symbolic Knowledge Hans Chalupsky Loom/PowerLoom Group USC Information Sciences Institute
Overview • Motivation • Translation Problem • OntoMorph Overview • OntoMorph Applications • Conclusions
Motivation • Observations • Ontology development collaborative but independent • Repeated merges/imports are the norm • Different tasks solved using different KR systems • different syntax, knowledge models, expressivity • Different tasks require different modeling styles • Translation problem is ubiquitous • Merging of semantically overlapping ontologies • Distributed heterogeneous agent communication • Integration of independently developed K-based systems • Porting of K-based systems to different KR infrastructure
Some Opinions • “We need standards, KIF, OKBC, HPKB upper structure, etc. to minimize translation needs….” • “We’ll never decide on that standard representation language, everybody has their own favorite…” • “People will hack through any representation available…” • “We better learn to live in a world where everybody represents things differently…” • “What’s the big deal, I can write any X-to-KIF translator in 5 Prolog clauses/minutes” • “Writing translators is not really difficult…” • Sound familiar?
Target KB Source KB The Translation Problem • KBs describable in some linear syntax • sentence-based translation • single expression to whole KB • arbitrary semantic shift allowed morphing
Translation Dimensions • KR language syntax • KIF, Loom, PowerLoom, MELD, SNePS, OntoLingua, … • KR language expressivity • quantification, negation, defaults, sets, modals, ... • Modeling conventions • class distinction vs. attribute relations, argument order, argument reification, naming conventions,... • Model coverage and granularity • Representation paradigms • time, action, plans, causality, propositional attitudes, ... • Inference system bias • collections vs. individuals, subclass-of vs. =>, ...
Example: Syntax Differences Loom: (defconcept Automobile “The class of passenger cars.” :is-primitive Road-Vehicle) MELD: (#$isa #$Automobile #$Collection)(#$genls #$Automobile #$RoadVehicle)(#$comment #$Automobile “The class of passenger cars”) KIF: (defrelation Automobile (?x) “The class of passenger cars” :=> (Road-Vehicle ?x))
Example: Model Differences Ontology A Ontology B Vehicle Automotive-Device WheeledVehicle TrackedVehicle M-1 tracked traction-type M-151 wheeled traction-type M151 HMMWV M1 M60 maxSlopeRange max-gradient (AngleRange -60 45) 45
Traditional Translation Methods • Manual translation is • slow • tedious • error-prone • hard to repeat • hard to document and trace • often simply not practical • Special-purpose translators are • tedious to write • hard to maintain • not easily reusable
Need: Translation Tool • Desiderata: • Translate arbitrary KR languages • No fixed knowledge model • Concise, declarative specification of transformations • Support for automatic, repeatable translations
Solution: OntoMorph Rapid and concise specification of KB translators via • Syntactic rewriting • pattern-directed rewrite rules • sentence-level transformation of syntax trees • based on pattern matching • Semantic rewriting • modulates syntactic rewriting • uses integrated PowerLoom KR system • based on (partial) semantic models • uses logical inference
OntoMorph Rewrite Engine • Pattern language and execution model similar to PLisp (Pattern Lisp), Lisp-70 Pattern Matcher • Features • Rapid generation of ontology and KR language translators • Rewrites arbitrary syntax trees • Powerful pattern language for concise specification and destructuring of expressions • Full backtracking (can parse Type-0 languages) • Named rule sets provide modularization and search control • Seamless integration with PowerLoom facilitates semantic rewriting • Available in Lisp, C++ and Java (written in STELLA)
Pattern Language • Literals match themselves: • foo, hans, 2, (a (b c) d), etc. • Variables match complete subtrees: • ?x, ?bar, ? • Sequence variables match tree subsequences: • (??x foo ??y), ?? • Grouping (AND) matches a sequence of tokens: • {a ?x c} • Alternatives (OR) match alternative token sequences: • {a|(b ?x)|c d} • Optionals match optional token sequences: • {a [b c]}
Pattern Language, cont. • Repetition matches a pattern multiple times: • {a|b}+, {a|b}*1-2 • Binding input matched by a pattern to a variable: • ?x := {a|(b ?y)|c} matched against (b d) binds ?x to (b d).
Example Pattern Match key-value pairs in any order: (defconcept ?name{?is := {:is | :is-primitive} ?def | :characteristic ?cha | :annotations ?ann := {(documentation ?doc) | (:and ?? (documentation ?doc) ??) | ?}}*0-3) Example pattern instance: (defconcept Dog :annotations (:and Object-Type (documentation “Canine”)) :is-primitve Animal)
Basic Operation • Rewrite Rule Syntaxpattern=>result • Execution Model Example Rule:(isa ?i ?c) => (?c ?i)Input stream: ( isa car1 Ford ) ( speed car1 ………
Basic Operation • Rule Syntaxpattern=>result • Execution Model Example Rule:(isa ?i ?c) => (?c ?i)Input stream: ( isa car1 Ford ) ( speed car1 ………
Basic Operation • Rule Syntaxpattern=>result • Execution Model Example Rule:(isa ?i ?c) => (?c ?i)Input stream:( Ford car1 ) ( speed car1 ………
Named Rule Sets and Recursion • Rule Set Syntax (defrulesetnamepattern1=>result1 ...patternN=> resultN) • Function calls and rule recursion • Rule sets and functions can be invoked recursively • Arguments are consumed and results pushed back onto the input stream. {<Term> ?result} <Term ?x> <is-atom? ?x>
Rewrite Rule Example Rule definition: (defrulesetTerm(?op:={\+|-|\*|/}?x ?y) =>(?op<Term?x> <Term?y>) (1\+ ?x) => (\+ <Term?x> 1) (1- ?x) => (- <Term?x> 1)(square?x) => (\* <Term?x><Term?x>)?x=>?x) (defrulesetCondition(lt ?x ?y) => (negative? (- <Term?x> <Term?y>))(gt ?x ?y) =><Condition (lt ?y ?x)>) Rule application: (rewrite (gt (/ (1+ M) N) (square N)) Condition) => (negative? (- (* N N) (/ (+ M 1) N)))
Rewrite Rule Example: Turing Machine (defrulesetTuring(?p := (??x (?s ?h ?act ?ss) ??y) ?s (?l ?h ?r)) =><Turing (?p ?ss <Move-Head ?act (?l ?h ?r)>)>(?prog ?state ((??l) ?h (??r))) => (??l ?h ??r) ) (defrulesetMove-Head{R ((??l) ?h ())}=> ((??l ?h) $ ()){R ((??l) ?h (?r ??rt))}=> ((??l ?h) ?r (??rt)){L (() ?h (??r))}=> (() $ (?h ??r)){L ((??lt ?l) ?h (??r))}=> ((??lt) ?l (?h ??r)){?new (?l ?h ?r)}=> (?l ?new ?r) ) Compute f(x) = x + 2:(rewrite ( ((s1 $ R s2) (s2 1 R s2) (s2 $ 1 s3) (s3 1 R s3) (s3 $ 1 s1)) s1 (() $ (1 1 1)) ) Turing) => ($ 1 1 1 1 1)
Semantic Rewriting • Syntactic rewriting very useful but limited:(defrulesetConflate-Truck-Types ({Light-Truck | Heavy-Truck | ... } ?x)=> (Truck ?x) ) • Instead, use semantic test:(defrulesetConflate-Truck-Types{(?class ?x)<ask (subset-of ?class Truck)>}=> (Truck ?x) ) • Semantic rewriting via integration with PowerLoom KRS
Two-Pass Translation Scheme Source KB Pass 1: Import Rules PowerLoom KB Pass 2: Translation Rules Target KB
Rewriting Non-Lisp-Style Expressions • Lisp-style s-expressions for tree representation. • Rewriting not limited to Lisp-style languages. • Rewrite engine operates on input stream of tokens. • Currently, STELLA reader serves as tokenizer. • Other tokenizers can easily be substituted. • Rewrite engine could specify tokenizers. • special-purpose tokenizers will be much more efficient.
OntoMorph Input Translation for COA Critiquer
Fusion Output to EXPECT:Translation Issues • Different Names(defrulesetRename-Collection FixMilitaryTask => FIX{ProtectingSomething | Protecting…Region}=> PROTECT Translation-LocationChange => MOVE … … …)
Fusion Output to EXPECT:Translation Issues cont. • Different Syntax: MELD/KIF => Loom • (isa task1 Fix-MilitaryTask)=> (Fix task1) • (isa COAMt COASpecificationMicrotheory)=> (COA COAMt) • (relationInstanceExistsCount subOrgsDirect unit1 ArmoredSpec)=> (:about unit1 (:exactly 2 subOrgsDirect ArmoredSpec)) (defrulesetRewrite-Frame-Predicate (relationInstanceExistsCount ?rel ?inst ?type ?count) => (:ABOUT <Rewrite-Term?inst> (:EXACTLY ?count <Rename-Relation ?rel><Rename-Collection ?type>)) )
Fusion Output to EXPECT:Translation Issues cont. • Different Representations • (taskHasPurpose BlueDivisionTask (thereExists ?p (isa ?p (CollectionSubsetFn ProtectingSomething (TheSetOf ?obj (and (objectTakenCareOf ?obj Boundary1) (performedBy ?obj BlueDivision1)))))))=>(and (Protect protect-000) (Purpose-Action Protect-000) (purpose-of BlueDivisionTask Protect-000) (action-obj Protect-000 Boundary1) (who protect-000 BlueDivision1))
Fusion Output to EXPECT:Translation Issues cont. (defrulesetRewrite-Purpose-Pattern1{(taskHasPurpose ?task (thereExists ?var (isa ?var (CollectionSubsetFn ?type (TheSetOf ?action ?body)))))<Generate-Skolem-Name?type>?purpose} => (AND (<Rename-Collection?type> ?purpose) (PURPOSE-ACTION ?purpose) (PURPOSE-OF ?task ?purpose)<Rewrite-Purpose-SetOf-Body?body ?action ?purpose> )
Fusion Output to EXPECT:Translation Issues cont. • Missing Representations • Some COA structure was not explicitly represented • EXPECT critiquer needed task / subCOA associations • Some essential COA structure was embedded in comments (defrulesetTrack-COA-Assertion (unitAssignedToTask ?task ?unit)=><!ASSERT (AND (Term ?task) (Term ?unit) (unitAssignedToTask ?task ?unit))>) (defrulesetGet-Task-Assigned-To-Unit{?unit <RETRIEVE \?t (= (unitAssignedToTask \?t) ?unit)> ?task}=> <OBJECT-NAME ?task> )
Fusion Output to EXPECT: Summary • File-based translation of Fusion output - MELD to KIF to Loom • Required ~30 rewrite rule sets • Tree destructuring capability very useful for rewriting complex purpose representations • Semantic rewriting needed to recover unrepresented COA structure
M Rosetta Translation Service Rosetta PLANET Plan Ontology (HPKB) aN a2 Agents Agent Capabilities Ontology aN a1 CoABS Grid Operators Domain Model Operators Domain Model Mapping KB a1 a2 Agent Model Agent Models
Capabilities/ requests Rosetta Translation Service Agent2 model Agent1 model Capabilities/ requests KB of representation reformulation rules Requested service by Agent1 Capability of Agent2 Rosetta Wrapper Wrapper Agent1 Agent2
ForMAT to Prodigy Translationvia Rosetta ForMAT request:(:goal (G-144 :send-hawk ((force 42nd-Hawk-Battalion) (geographic-location Big-Town)))) Format-To-Rosetta translation:(find (object Plans) (for (Objective-Based-Goal (send-unit (object 42nd-Hawk-Battalion) (to Big-Town))))) Rosetta goal representation translation:(find (object Plans) (for (State-Based-Goal (is-deployed (object 42nd-Hawk-Battalion) (at Big-Town))))) Rosetta-To-Prodigy translation:(:find-plans (is-deployed 42nd-Hawk-Battalion Big-Town))
Without Rosetta: helicopter wrappers had to turn route segments into areas and issue query in SQL message sent: :content select distinct s.LAT, s.LON from SAMSITE s where s.LAT< 29.3843 and s.LAT> 29.355 and s.LON< 48.0399 and s.LON> 48.011 :receiver ARIADNE_TEAMCORE :sender TEAMARIADNE With Rosetta: helicopter wrappers form request using route segments message sent: :content find SAMSITES from DP_A to LZ_A :sender TEAMARIADNE :receiver Rosetta Using Rosetta with CoABS TIE 1:Ontology-Based Transformations Problem: Diverse views and languages (e.g., helicopters had segments, SAMSITE finder queried with SQL about regions)
Conclusion • Translation is a common problem with K-based systems • OntoMorph tool makes it easier to write translators • OntoMorph applications so far: • Within HPKB to translate Fusion output • Within CoABS/HPKB TIE to implement Rosetta ontology-based agent translation services (joint work with Y. Gil and J. Blythe) • Future Work • Develop library of operators to support common transformations • Semi/Automatic generation of translators (some related work in database integration community, but larger schemas, higher expressivity, inconsistency, etc.) • Rewrite rule compiler