310 likes | 479 Views
GILA Explanation Component (Phase 2). Oct 5, 2008. Outline. Overview Background Conceptual Model Implementation Browser2: GILA log data browser TW OIE: OWL Instance Data Evaluation GilaExplainer: GILA log analyzer and explainer Future Work. Overview. Overview.
E N D
GILA Explanation Component(Phase 2) Oct 5, 2008
Outline • Overview • Background • Conceptual Model • Implementation • Browser2: GILA log data browser • TW OIE: OWL Instance Data Evaluation • GilaExplainer: GILA log analyzer and explainer • Future Work
Overview • GILA is a general purposed integrated multi-agent platform for learning and problem-solving • GILA aims at solving problems by learning from several examples • Currently GILA is evaluated by a conflict resolution scenario in battle field air space control domain • Each run of GILA produces an OWL log recording how agents are learning and solving problem • Explanation component is needed to show how the background knowledge and examples are used in learning and solving problems
Research Problems • GILA log validation • Overall log data connectivity validation (e.g. CC analysis on instance data) • Individual log data structure validation (e.g. check GILA log using integrity constrains from GILA ontologies ) • Explain data flow • Associate final solution with initial conflicts • Attribute the contribution of ILRs • Associate solutions with the provided knowledge
GILA Data Driven Computing • [User] asks [MRE-DM] to initiate a task • To learn from experts’ knowledge • one expert trace • several expert exercises • To solve ACO Problem • [MRE-DM] queues the tasks, i.e. learning, CPL demonstration, CPL-training, performance, and run one task a time • [MRE-DM] informs [ALL] task begins • [ALL] work with each other • [LearnerX] Ask a Problem on BB • [LearnerY] Reply with the corresponding Solution on BB • [LearnerY] Reply with No-More-Solution on BB • [MRE-DM] informs [ALL] task ends (succeed or failed)
Abstract GILA Data Flow Provided Knowledge runtime input prior input facts embedded in the input problem multi-phase iteration Experts’ execution trace 1: learning Q/A from users background knowledge Learned Knowledge problem/solution conflict priority 2. performance constraints constraint-violation Final Output final solution ExecutionTrace
Prior Knowledge from Exports • learning mode • One expert trace • execution trace • initial state • final state • CPL (demonstration; practice) mode • Several exercises • initial state • final state • performance mode • One problem, i.e. the initial state
GILA Ontology Dependency (imports) Graph Domain Knowledge GIL - ACO domain (gilaco) Constraint (cons) Abstract Steps (Asteps) Partial-plan Steps (Psteps) Sensing Steps (Psteps) World Knowledge Airspace Control Order (aco) GILA Inter-component Language (gilcore) PML-Justification (pmlj) legend General Knowledge Spatial Temporal (gkst) PML-Provenance (pmlp) new changed Data Structure (ds) unchanged
Event based Provenance Modelfor one-step in the log about … State i Input Data Input Data Agent Event Operation Time Location about State i+1 Output Data … Output Data Can be referred as PML Lite Ontology
Example ACO State i ACO WorkingACMReq1 ACO State i+1 ACO WorkingACMReq2
Browser2: GILA log data browser • GILA log consists of OWL instances, and they are interconnected • This tool let users • navigate instances by their connections • look into detailed description of instances • Note • Some links may fail because not all GILA ontologies are available on the Web.
Navigate One Instance and its related Instances type outlink Details inlinks
TW OIE: OWL Instance Data Evaluation • Motivation • Log entries are encoded as OWL instance data • As log entries are generated by ILRs and MREs, they may miss some required fields • OWL instance Data checks integrity constraints • e.g. missing property value, unspecific instance type • Currently implemented using SPARQL • http://onto.rpi.edu/demo/oie/
GilaExplainer: Explaining GILA log • Extract generic structure from log • Generate PML Lite relation from GILA log • Convert RDF graph to Instance graph • SPARQL based Explanation Template
Focus on subject of Resource (which is described) Skip classes and properties RDF graph V.S. Instance Graph ACM1_ACM2_CONFLIT Has Identifier Conflict1 hasConflictingACMs hasConflictingACMs ACM1 ACM2 Has Identifier Has Identifier “ACM F4” “ACM FUEL 1” Shape2Oval
Connectivity Analysis (Initial Results) • Goal: to check if GILA-log is well-connected • Input data • OWL file, 22M • No blank node. • Approach • Create instance graph from RDF graph • Initial results: • Many Islands, e.g. instance of constraint, not linking to any other instances • One Big connected component (2M) • Some small components (about 5K)
Multi-Step Explanation for End Users IntersectionDetails Conflict ACMReq (Initial state) ACM • Which ACMs have been changed? • via which psteps by whom? • How each conflict is resolved • by which psteps with what constraint blame ACM’ ACMReq’ (final state) Constraint Psteps <owl:Class rdf:about="http://www.mindswap.org/2006/GILA/GK/gkst.owl#IntersectionDetails">
Sparql based Explanation Template“List ID of all ACMs involved in conflict” PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX aco: <http://www.atl.lmco.com/aco.owl#> SELECT ?conflictid ?acmid FROM <http://tw.rpi.edu/2008/gila/log1/g_con.rdf> WHERE { ?acm rdf:type aco:ACMDescriptor . ?acm aco:hasIdentifier ?acmid . ?conflict rdf:type aco:Conflict . ?conflict aco:hasIdentifier ?conflictid . ?conflict aco:hasConflictingACMs ?acm . ?conflict aco:hasConflictingACMs ?acm .}
Future Work • Scalable GILA log storage and reasoning • Deal with log dumps generated by different system executions • Scalable Reasoning and Query support • Enriching Explanation • More log entries from ILRs and MREs • Finer reference to provided knowledge • User-defined explanation • Knowledge discovery • Duplicated entries • Log summary • Identify patterns of ILRs’ solutions, uncover interesting/strange behaviors • A frequent set of behavior patterns, which are explainable to end-users, shared by GILA components
Log Entity Duplication Detection • Goal: detect individual duplication using CWA. • Observations: • There could be some duplicated OWL individuals in log that can be detected by • IFP (one identical property-value pair) • Identical KEY ( multiple identical PV pairs) • Identical content ( all identical PV pairs) • We may need to ignore temporal aspect, and adhere to Close World Assumption for now • GILA ontology has not IFP defined • Directions • Efficient duplication detection using hash function? • Simple delta computation?
Log summary • Goal: Provide human operator summary (at different granularity?) • Hypothesized summary entries • Overall size in terms of bytes, triples, resources, literals… • Topology analysis, e.g. connected components • Term frequency, e.g. list of # of class instances • …