170 likes | 304 Views
Christopher J. Matheus Versatile Information Systems, Inc. Mieczyslaw M. Kokar, Kenneth Baclawski Northeastern University Jerzy A. Letkowski Middle New England College. An Application of Semantic Web Technologies to Situation Awareness.
E N D
Christopher J. Matheus Versatile Information Systems, Inc. Mieczyslaw M.Kokar, Kenneth Baclawski Northeastern University Jerzy A. Letkowski Middle New England College An Application of Semantic Web Technologies to Situation Awareness An Application of Semantic Web Technologies to Situation Awareness www.vistology.com
Overview • Situation Awareness • Ontologies and Rules • Situation Awareness Assistant: SAWA • A Simple Scenario • Lessons Learned
Our Problem Domain • Formal yet Practical Applications of Situation Awareness • Situation Awareness (SAW): • an understanding of what’s going on in an evolving situatione.g. supply logistics, financial markets, battlefields • involves fusion of object-level data from multiple sources into meaningful higher-order relations • highly context dependent and goal directed (i.e., requires domain knowledge) • Requirements for effective SAW apps: • domain knowledge about relevant objects and their properties • specification of conditions that define higher-order relations • a means for reasoning about time-dependent sensor information in the context of the given domain knowledge • much in common with SW goals of knowledge representation and processing but with real-time and uncertainty concerns
AFRL Research Focus • US AFRL supported effort to formalize and automate the identification and monitoring of relevant relations in evolving situations • Phase I: Formalization of SAW • Formal definition of situation awareness using Speckware and DAML/OWL • Phase II: SAW Assistant (SAWA) • Prototype system to support the detection and monitoring of relevant relations
General Methodology Working with Subject Matter Experts we first: • develop ontologies for describing domain-specific object classes and properties • develop rules to define complex relations that are grounded in observable data annotated by the ontologies We then: • populate an inference engine with ontologies and domain rules • establish an input stream of events describing object observations annotated using the domain ontologies • use the inference engine to process the event stream and detect evolution of higher-order relations
Ontologies and Rules • Need ways to represent domain knowledge concerning: • Situation Objects, their Attributes and their inter-Relations • OWL provides a solid basis for these needs • Formal semantics facilitates reasoning with generic reasoners (e.g. Jess with OWL axioms) • Reuse of existing of tools (parsers, consistency checkers, etc) • Main drawback: limited representational power • SWRL used to represent more complex relations • Permits representation of more complex relationships • e.g. there are two Units U1 and U2 in-region R AND U1 is a member-of a Force F1 AND Unit U2 is a member-of Force F2 AND F1 is not equal to F2 • Has advantage of formal semantics defined as an extension to the semantics of OWL DL • Easily converted into Jess rules using XSLT
SAWA Architecture SAWA Knowledge Management Runtime System ConsVISor GUI SMC RMA Consistency Checker OWL SWRL domain knowledge goals and queries Protégé RuleVISor EMC TDB SWRL Editor Ontology Editor event annotations
ConsVISor RuleVISor Protégé with ezOWL SAWA Knowledge Management
SAWA Runtime System SMC: Situation Management Comp. EMC: Event Management Comp. TDB: Triples Database RMA: Relation Monitoring Agent GUI: Graphical User Interface • Java Components (RMI) • RMA and TDB • Based on Jess inference engine • Store RDF triples in working memory • Includes OWL axioms for inferring implicit triples • Plus procedural attachments for SWRL built-ins • TDB supports OQL and What-if reasoning SMC RMA TDB GUI EMC events ontologies and rules
Supply Line Scenario Simple Scenario: hasSupplyLine • defines a unit to be in supply if a series of roads can be traced from the unit to a supply station through regions under friendly control
hasSupplyLine Rule Set <rule rlab="has Supply Line"> <body> <hsl:inRegion sub="?unit" data="?region"/> <hsl:isSuppliable sub="?region" data="true"/> </body> <head> <hsl:hasSupplyLine sub="?unit" data="true"/> </head> </rule> <rule rlab="isSuppliable"> <body> <hsl:hasSupplyStation sub="?region" data="true"/> <hsl:underFriendlyControl sub="?region" data="true"/> </body> <head> <hsl:isSuppliable sub="?region" data="true"/> </head> </rule> <rule rlab="isSuppliable2"> <body> <hsl:connects sub="?road" data="?region1"/> <hsl:connects sub="?road" data="?region2"/> <swrlb:notEqual arg1="?region1" arg2="?region2"/> <hsl:isPassable sub="?road" data="true"/> <hsl:isSuppliable sub="?region2" data="true"/> </body> <head> <hsl:isSuppliable sub="?region1" data="true"/> </head> </rule> <rule rlab="underFriendlyControl"> <body> <hsl:inRegion sub="?unit" data="?region"/> <hsl:memberOf sub="?unit" data="?force"/> <hsl:FriendlyForce ind="?force"/> </body> <head> <hsl:underFriendlyControl sub="?region" data="true"/> </head> </rule> <rule rlab="isPassable"> <body> <hsl:connects sub="?road" data="?regionA"/> <hsl:connects sub="?road" data="?regionB"/> <swrlb:notEqual arg1="?regionA" arg2="?regionB"/> <hsl:underFriendlyControl sub="?regionA" data="?force1"/> <hsl:underFriendlyControl sub="?regionB" data="?force2"/> </body> <head> <hsl:isPassable sub="?road" data="true"/> </head> </rule> <rule rlab="hasSupplyStation"> <body> <hsl:inRegion sub="?X" data="?region"/> <hsl:SupplyStation ind="?X"/> </body> <head> <hsl:hasSupplyStation sub="?region" data="true"/> </head> </rule>
Lessons Learned • OWL is very useful for base ontology representation • Pros: tools, formal semantics, extensible, triples-based • Cons: triples-based (binary predicates), lack of complex implication • Rules on top of OWL is an effective way to utilize the benefits of OWL while overcoming some of its limitations • Limitations of SWRL: • restricted to binary predicates - not always natural and work around is cumbersome • built-ins defined as axioms but are needed as functions • need gensym() and assert() to generate and assert new entities • need for negation as failure • syntax not intended for human processing • SWRL is too low level of a language for knowledge engineering – even with a graphical editor • need higher-level language(s) that can be automatically translated to low-level triples representation