Intelligent Support for Distributed Operational Decision Making

Transcription

1 A. Smirnov Intelligent Support for Distributed Operational Decision Making M. Pashkin N. Shilov T. Levashova St.Petersburg Institute for Informatics and Automation of the Russian Academy of Sciences 39, 14th line, St.Petersburg, , Russia A. Krizhanovsky Abstract An integrated technology for intelligent support for distributed operational decision making is proposed. The conceptual framework implementing the technology consists of building an ontology-based model of the problem to be solved by the decision maker, formalization of the problem with a set of constraints, instantiation with the data values provided by environmental information sources, and interpretation it as constraint satisfaction problem. The problem is modelled by two types of contexts: abstract and operational. The integrated technology embodies advanced technologies for ontology & context management, and constraint satisfaction. Keywords: operational decision support, ontology management, context management, constraint satisfaction 1 Introduction Nowadays, operational decision making faces problems of management and sharing of huge amount of information & knowledge from distributed and heterogeneous sources (experts, electronic documents, real-time sensors, etc.), personalization of decision maker support, availability of up-to-date and accurate information provided by the dynamic environment. The goal of intelligent support of operational decision making is to assess the relevance of information & knowledge to a decision, to gain insight in seeking and evaluating possible decision alternatives, and to achieve a gain in the situation awareness. Operational decisions are characterized as well-specified, ad hoc, quickly made, based on past experience and taking into account alternatives. They are made in rapidly changing, sometimes unexpected, situations. The paper addresses the information fusion problem for operational decision making purposes. The decision making deals with high-level information fusion. As an application domain health service logistics support [1] within a disaster situation has been chosen. When disaster occurs, there normally is huge amount of information and data flowing into the emergency service and thus information fusion process is needed for efficient relief action as decision making. The problem of management and sharing of heterogeneous knowledge gave rise to extensive use of ontologies as a common knowledge representation model. Ontologies facilitate information retrieval over collections of distributed and heterogeneous information sources, they help provide semantic integration of information and facilitate interoperability between heterogeneous knowledge sources at a high level of abstraction [2]. The task of integrating heterogeneous information sources put ontologies in context [3]. The main purpose of context is to supply the decision support system (DSS) to information provided by the dynamic environment. The paper proposes a technology that is work in progress. We propose to model context as a problem model based on the knowledge extracted from the application domain and formalized by a set of constraints. The set of constraints additionally to the constraints describing domain knowledge includes information about the environment and various restrictions of the user on the problem to be solved. The problem is suggested being modelled by two types of contexts: abstract and operational [4]. The problem formalised by the set of constraints can be processed by specialized solvers as constraint satisfaction problem (CSP) [5]. The result of CSP solving is one or more satisfactory solutions for the problem modelled. The rest of the paper is as follows. Section 2 outlines conceptual framework and distributed architecture of DSS built on it. Section 3 describes the integrated technology and illustrates it by examples from the case study of health service logistics support. Some concluding remarks are given in Conclusion. 2 Conceptual Framework The main idea behind the methodology framework (Figure 1) consists of (i) creation of an ontology-based

2 model of the problem to be solved by the user (decision makers, and other participants involved in the decision making process) or of the situation to be described and (ii) solving the problem as CSP. We consider a situation as the problem model where the data values change over time. In the paper the concept problem is used for either a problem at hand to be solved or a current situation to be described. As an internal ontology representation formalism the formalism of object-oriented constraint networks (OOCN) is used. The problem model represented by means of this formalism can be mapped into internal knowledge representations supported by constraint solvers and interpreted as CSP. The framework is oriented on a two-level activity dealing with decision support. The first level addresses activities User profiling Context management Ontology management over a pre-starting procedure of decision support system (DSS). The second level focuses on decision making supported by DSS. Activities carried out at these stages are described below. DSS implementing the methodology framework is proposed to have distributed architecture (Figure 2). DSS is implemented as a Web-service for the users. Main architecture items are user profile, scenario rules, ontology library, knowledge map, and a set of Web-services. Scenario rules are responsible for calling system scenarios. The scenarios are implemented as a sequence of functions called one-by-one inside the main program module. Constraint satisfaction Context management Information source Relevant information source Current information User Reference Reference Values Decision Request Request problem definition Ontology library Relevant knowledge Application ontology Abstract context Knowledge-based problem model Operational context Instantiated problem model Problem solving Set of problem solutions Capture of decisions Figure 1. Technology framework Decision makers Decision Support System Experts GUI Web Service User profile API OOCN OWL, XML, SOAP, WSDL, DBMS Mediator Web Service Ontology library Scenario rules Solver Solver Web Web Service Service Knowledge map IS 1 Information sources (IS), real-time sensors IS N (defrule Delivery?fact <- (initial-fact)=> Figure 2. DSS architecture

3 Ontology library stores ontologies imported from distributed heterogeneous knowledge sources. The ontologies are described by means of the internal ontology formalism and the vocabulary supported by the ontology library. 4) associative relationships used to model any relationships besides the listed ones; 5) class cardinality restriction used to define how many subclasses the class can have; 6) functional relations used to model functions and equations. References to the knowledge sources the ontology have been imported from are organized in a knowledge map. Besides the references, the knowledge map contains knowledge sources metadata, and information about their accessibility, location, native format, and other properties. Mediator Web Service is responsible for querying the information sources. Based on the assumption that one constraint solver is not enough to solve complex problems occurring in real-world domains the complex problems are proposed to be solved coordinating several constraint solvers [6], [7]. The solvers installed at different computers can be used while problem solving. This is the case of distributed problem solving [8]. In the proposed architecture constraint solvers are implemented as Solver Web Services. Component of DSS Domain knowledge User Environment Domain ontology Model Application ontology User profile Information source data model Tasks & methods ontology Formalism of OOCN Knowledge map and user profiles are implemented using a relational database management system (DBMS). Using graphical user interfaces, the subject experts add ontologies into the ontology library and modify them, if required; prepare representations for the information sources; align the ontologies and the information source representations; modify and validate scenario rules; and analyze information accumulated in the user profiles to define users preferences that cannot be determined automatically. 2.1 Pre-starting procedure The pre-starting procedure involves activities on creation of semantic models for DSS components; accumulating domain knowledge; coupling domain knowledge with the information sources; and application ontology creation. This level is supported by the subject experts, knowledge and ontology engineers Creation of models for DSS components The framework distinguishes environment, domain knowledge, and users in DSS components (Figure 3). All the components are represented by the formalism of OOCN [4] used for the internal knowledge representation. According to the formalism ontology (and the components, correspondingly) is represented with a set of classes; a set of class attributes; a set of attribute domains; and a set of constraints. The set of constraints comprises 1) (class, attribute, domain) relationship used to model triple of classes, attributes pertinent to them, and restrictions on the attribute value ranges; 2) taxonomical ( is-a ) and hierarchical ( part-of ) relationships used to model class taxonomy and class hierarchy respectively; 3) classes compatibility used to model condition if two or more instances can be parts of the same class; Figure 3. Models for DSS components CSP model consists of three parts: a set of variables; a set of possible values for each variable (its domain); and a set of constraints restricting the values that the variables can simultaneously take. Correspondence between the primitives of ontology, OOCN, and CSP models is shown in Table 1. Table 1. Correspondence between ontology model, OOCN, and CSP Ontology Model OOCN CSP Class Object Set of Attribute Variable variables Attribute domain (range) Domain Domain Axioms and relations Constraints Constraints Domain knowledge is modelled by ontologies of three types: domain ontology, tasks & methods ontology, and application ontology. Domain ontology represents conceptual knowledge about the domain; tasks & methods ontology formalises tasks identified for the domain and hierarchies of problem solving methods (PSMs); application ontology is a specialisation of domain and tasks & methods ontologies for a certain problem (a set of problems). Referring to the internal formalism the tasks and PSMs are represented by classes; the sets of methods arguments and argument s types are represented by sets of attributes and domains, respectively. PSMs are configured into the task in accordance with task-method decomposition structure. Methods involved in task solving are represented by part-of relationships. methods are represented by is-a relationships (Figure 4).

4 PSM 1 (IP PSM1, OP PSM1 ) Configuration (IP, OP) PSM i (IP PSMi, OP PSMi ) part-of is-a methods IP set of task / method input arguments OP set of task / method output arguments Figure 4. Structure of tasks & methods ontology Domain and tasks & methods ontologies are interrelated by relationships specifying values of which class attributes of a domain ontology serve as input arguments for the methods of a task & methods ontology. Environment is modelled as a set of data. The data are provided by environment information sources (e.g., sensors). In order to the information from these sources be processed, the sources have to be represented in a machine-readable way. Information source capabilities model is used as a means for information source representation Accumulating domain knowledge Decision making deals with complex problems expecting deep knowledge in the domain. The users do not necessarily have satisfactory knowledge. This fact is the most important at the operational level when the user has to make decisions under time pressure. Because of this, the approach relies on the availability of sufficient domain knowledge. The domain knowledge is collected before it can be used in decision making. The phase of domain knowledge accumulation consists of importing knowledge relating to the domain in question from Internet resources, representation of the imported knowledge by OOCN formalism, and saving this knowledge in the ontology library Coupling domain knowledge with information sources Information sources comprise sources data of which are used for environment modeling (sensors) and other external information sources instantiating the domain knowledge (users, Web-sites, databases, etc.). In order to obtain up-to-date information the ontologies and the information source representations are aligned. For this, attributes of ontologies from the ontology library and attributes of information source representations including the users are tied in (dashed lines in Figure 5). The links mean that the attribute of the ontology class gets values provided by the information source or user. Semantic conflicts, e.g. data representation differences are resolved with functional constraints. In Figure 5 function F 1 specifies data conversion converting relative humidity (h) direct measured the weather radar into percent humidity required in the domain ontology. Information source Domain ontology Monitoring system Weather Ground sensor Weather radar t 1 h Humidity Air t 2 (%) Set of weather temperature properties Humidity = F 1 (h) Air temperature = F 2 (t 1, t 2 ) class attribute structural constraint Figure 5. Examples of links between domain knowledge and information sources Application ontology creation Application ontology is a specialization of knowledge described in the domain and tasks & methods ontologies. An application ontology is created for a macro-situation the operational decisions can be required in (e.g., emergency situation, business, manufacturing, etc.). The application ontology integrates knowledge from the ontologies of both types. It is related with the reference relationships to the ontologies it is a specialization of. 2.2 Decision making level The starting point for the decision making level is the user request containing the formulation of the problem to be solved. Based on the result of the request recognition, knowledge relevant to it is searched for within and extracted from the application ontologies of the ontology library. This knowledge is integrated into abstract context. The abstract context is an ontology-based problem model supplied with links to representations of the information sources that will provide values for the class attributes included in the abstract context. The attributes represent both attributes of domain ontology classes and arguments of methods that come from the tasks & methods ontologies. Referring to CSP model the attributes correspond to variables of this model (Table 1). The information sources providing data values needed for the given problem instantiate the abstract context. The instantiated abstract context is operational context that is the problem model along with problem data and OOCN to be processed as CSP. Changes in the environment result in changes in the operational context. The operational context is presented to the user. The user makes decisions based on this context if it is a current situation description or based on a set of feasible solutions generated by the constraint solver if the context is a problem definition.

5 In order to enable capturing, monitoring, and analysis of decisions and their effects the contexts representing problem models and respective decisions made are retained in an archive. As a result the user is provided with reusable problem models and knowledge of similar situations and decisions made in those situations. 3 Integrated Technology This section describes the framework technologies (Figure 1) involved at the decision making level. 3.1 Ontology management For illustrative purposes a relief action as mobile hospital building is supposed to be undertaken for the given disaster. This task in the paper is represented as a simplified reformulation of the user request. The request under consideration is to build a hospital with price <= at location with x-coordinate 246 and y-coordinate 310 by time 12:00. Firstly, the request is recognized. A result of the recognition is lists of user terms, numbers, and special symbols like =, <=, >=, etc. Since the user vocabulary (the request vocabulary) and the ontology library vocabulary can be different the list of user terms and ontology library vocabulary are matched. The result of matching is the value of similarity between two terms from different vocabularies. Based on this matching a structural representation of the user concepts is created. The request representation distinguishes the user terms that can correspond to classes, attributes and values of the attributes. The result of the matching terms of the exemplified request against concepts of ontologies from the ontology library is shown in Figure 6. A list of the user concepts for the recognized request is given in Word tag. These concepts matched against ontology concepts are shown in Name tag. Calculated similarity for ontology concepts and request concepts is given in Sim tag. Then concepts of the request having similarity equal or more a threshold value are searched for in the application ontologies. In the paper an application ontology created for hospital configuration task [9] is used. The found names are shaded in Figure 6. The terms found serve as seeds for the slicing operation [10], [11], [12]. The purpose of this operation is to extract pieces of knowledge from the application ontologies, that is believed to be relevant to the request, and consequently to the problem to be solved (Figure 7). The operation assembles knowledge related to the seeds based on attributes and constraints inheritance rules. The result of the operation is a set of ontology slices containing pieces of knowledge that surround seeds. Different slices that combine knowledge representing alternative methods are considered as alternative (Figure 8). Figure 6. Matching vocabularies

6 User request Matching vocabularies Request vocabulary in user terms is-a Application ontology Slice 1 Request vocabulary in ontology terms Searching for request terms Slice 2 Slice 3 request concepts having matching with application ontology concepts Figure 7. Application ontology slicing The slices are merged so that alternative slices would become parts of different pieces of knowledge (Figure 8). The resulting pieces of knowledge will make up alternative problem models. The result of the integration is a single resulting slice if slicing algorithm has not revealed any alternative slices, or a set of resulting slices where each resulting slice is purposed to describe an alternative problem model. The resulting slice (a set of slices) checked for consistency is considered ontology-based problem model. slices constitute alternative problem models. 3.2 Context management Due to links between ontologies and information sources, the integrated knowledge is connected to those information sources and users that are supposed to provide data values for problem variables. For the task of hospital building the application ontology uses weather conditions (Figure 5) in routing problem. This problem is intended to find the most efficient ways of delivery of the hospital's components from available suppliers. Weather conditions are taken in to account for the estimation of the route availability. Information source representations that represent data values characterising weather conditions are sliced. For this, a slice of an information source of a complex data model is formed limited to the model elements representing information needed for the problem. If an information source is of a simple data model the slice is the representation of this information source. Domain ontology constituent Application ontology method 1 slice 1 Tasks & methods ontology constituent Subtask Domain ontology slice pieces of knowledge Figure 8. slices Task method 2 slice 2 Referring to Figure 5 the slice of the monitoring system representation produces the data model shown below (Table 2). Table 2. Data model for monitoring system slice Class Attribute Domain Weather radar t 1 t 1 R 100 t1 100 Weather radar h h R 0 h 100 Ground sensor t 2 t 2 R 50 t2 50 The query of DSS s Mediator Web-service to the information source in terms of the source schema is designed based on the links between attributes of the ontology and of the information source representation. The links (Figure 5) between the attribute Air temperature and the attributes t 1 and t 2 mean that Air temperature of the domain ontology integrates information from the ground sensor and weather radar. Function F 2 specified between these attributes for the average temperature value fuses values t 1 and t 2 result in the desired value. For the slice of the monitoring system representation the query (XQuery) is as follows: FOR $wr IN doc( $gs IN doc( WHERE... RETURN <humidity>{$wr/@h*100}</humidity> <AirTemperature>{avg(($wr/@t1, $gs/@t2))}</airtemperature>

7 The slices of information sources and ontology-based problem model are integrated again. The purpose of this is to find a more accurate problem model due to domain integration. The result of the integration of ontologybased problem model and information source slices is considered to be abstract context. It is an ontology-based problem model supplied with references to information sources. problem models are represented by the alternative contexts. The back screenshot in Figure 9 illustrates an application ontology slice containing concepts relevant to the routing problem (not a complete list, weather properties are not shown). The set of ontology classes is given below the tag owl:class, the list of attributes is shown in Attrs tag. For the routing problem this slice can be considered as the abstract context, whereas abstract context for the realworld task of hospital building is made up of much more slices (not presented within the paper) being merged. Operational context Abstract context Figure 9. Context creation The front screenshot in Figure 9 shows the operational context. It depicts how the user is treated as an information source. Namely, attribute values for hospital location are taken from the user request (x-coordinate = 246; y-coordinate = 310). Having the operational context a constraint solver generates a set of feasible solutions for the problem modelled. This set is presented to the user. The user estimates these solutions and chooses desirable one that is the decision. In order to support evolution of knowledge included in the contexts, allow the user to access reusable problem models, and provide the user with knowledge of similar situations and decisions made within the contexts the abstract context, operational context, a set of the generated solutions, and the decision are saved in the archive (Figure 10). The listed purposes are achieved applying techniques of context versioning and profiling. 3.3 Constraint satisfaction technology The operational context in its OOCN form is supposed to be processed by a constraint solver as CSP. If all the domains in an operational context have been instantiated, the operational context is considered as a situation description. An operational context containing noninstantiated domains means that a solution is expected. The user makes a decision based on the situation description presented in the operational context and / or on the generated set of solutions. Initially, the operational context (Figure 9) did not contain a value for the transportation route availability. So, it was treated as CSP. The result of routing problem solving is represented through the value calculated for the availability of the transportation route (availability = yes).

8 Level of responsibility = k Application ontology Changes n:1 propagation Abstract context 1:1 Operational context 1:m Set of problem solutions m:1 Decision No changes propagation Reusable for the k th level of responsibility Figure 10. Model of context archiving and versioning Conclusion The paper proposes an integrated technology framework for intelligent support for distributed operational decision making. A distributed architecture of DSS that is supposed to be implemented based on the developed technology is described. The development of the technology and architecture is work in progress. The main idea behind the technology consists of building an ontology-based model of the problem to be solved by the user and interpretation of it as constraint satisfaction problem taking into account information from the dynamic environment. For this purpose context model is applied. The problem is proposed to be modelled as context represented by means of the formalism of objectoriented constraint networks. The problem represented by a set of constraints is put into a constraint solver. In order to solve a complex problem holding problems of different types the proposed architecture offers distributed problem solving. Acknowledgments The presented research in due to the CRDF partner project # RUM ST-05 with US ONR and US AFRL, projects supported by the Russian Academy of Sciences # of the research program "Mathematical Modeling and Intelligent Systems" and # 1.9 of the research program Fundamental Basics of Information Technologies and Computer Systems, and grant # of the Russian Foundation for Basic Research. References [1] A. Smirnov, M. Pashkin, N. Chilov, T. Levashova, A. Krizhanovsky, Agent-Based Intelligent Support to Coalition Operations: A Case Study of Health Service Logistics Support, in Information & Security. An International Journal. IT in Coalition and Emergency Operations, vol. 16, V. Shalamanov, G. Johnson, J. Fay, Eds., ProCon Ltd., Sofia, 2005, pp [2] Anne-Claire, Boury-Brisset, Ontology-Based Approach for Information Fusion, Workshop on Ontology and Information Fusion of U.S Army CECOM & the Center for Multisource Information Fusion, University at Buffalo, USA, 2003, URL: conferences_and_workshops/ontology_wkshop_2/- ont_ws2_working_materials/bourybrisset- OntologyandFusion.PDF. [3] H. Wache et al., Ontology-based integration of information a survey of existing approaches, in IJCAI-01 Workshop: Ontologies and Information Sharing, H. Stuckenschmidt, Ed. 2001, pp [4] A. Smirnov, M. Pashkin, N. Chilov, T. Levashova, A. Krizhanovsky, Ontology-Driven Information Integration to Operational Decision Support, Proceedings of the 8 th International Conference on Information Fusion (IF 2005), Philadelphia, USA, IEEE Catalog Number 05EX1120C, [5] Constraints, IEEE Computer Society: Intelligent Systems and their Applications, vol. 15, no. 1, [6] P. Hofstedt, D. Seifertand, E. Godehardt, A Framework for Cooperating Constraint Solvers A Prototypic Implementation. In Workshop on Cooperative Solvers in Constraint Programming - CoSolv. At the Seventh International Conference on Principles and Practice of Constraint Programming - CP 2001, E. Monfroy and L. Granvilliers, Eds., 2001, URL: [7] H. Schlenker, G. Ringwelski, POOC - A Platform for Object-Oriented Constraint Programming, Recent Advances in Constraints, Lecture Notes in Artificial Intelligence, Springer, vol. 2627, 2003, pp [8] P. Zoeteweij, A Coordination-Based Framework for Distributed Constraint Solving, Recent Advances in Constraints, Lecture Notes in Artificial Intelligence, Springer, vol. 2627, 2003, pp [9] A. Smirnov, M. Pashkin, N. Chilov, T. Levashova, A. Krizhanovsky, Fusion-based knowledge logistics in network-centric environment: intelligent support of OOTW operations, Proceedings of the Seventh International Conference on Information Fusion, Stockholm, Sweden,, 2004, pp [10] V.K. Chaudhri, J.D. Lowrance, M.E. Stickel, J.F. Thomere, R.J. Wadlinger, Ontology Construction Toolkit. Technical Note Ontology, AI Center. Report, SRI Project No [11] T.V. Levashova, M.P. Pashkin, N.G. Shilov, A.V. Smirnov, Ontology Management, in Journal of Computer and System Sciences International, part II, vol. 42, no. 5, 2003, pp [12] B. Swartout, R. Patil, K. Knight, T. Russ, Toward Distributed Use of Large-Scale Ontologies, Tenth Knowledge Acquisition for Knowledge-Based Systems Workshop (KAW'96), Banff, Canada, 1996, URL: Banff_final_web/Banff_96_final_2.html.