Context-aware decision support systems based on typical knowledge integration models

ISSN 1064�2307, Journal of Computer and Systems Sciences International, 2014, Vol. 53, No. 4, pp. 530–541. © Pleiades Publishing, Ltd., 2014.Original Russian Text © T.V. Levashova, A.V. Smirnov, 2014, published in Izvestiya Akademii Nauk. Teoriya i Sistemy Upravleniya, 2014, No. 4, pp. 63–75.

530

INTRODUCTION

Modern information systems operate in environments with a large number of different distributedresources. An integral part of such systems is the integration of the knowledge obtained from the resources.Here, the knowledge resources are all kinds of resources that provide structured and unstructured content(information) as well as knowledge of a problem domain. The set of the resources required for the infor�mation system at a certain time can be modified depending on the current system goals, availability of cer�tain resources in the location of the system (which is especially important for mobile systems), and otherrestrictions. In order to formalize the above conditions, a context model is used. This is the model whereinknowledge and information become interpretable with respect to a given situation and, therefore, can beintegrated. The systems using the context model are referred to as context�aware.

Today, the considerable experience of constructing the context�aware systems is accumulated [1–6].So, it is important to generalize this experience. In this paper, we propose to use the typical models thatgeneralize the synergetic integration of the knowledge available in context�aware systems [7] are used forspecifying the requirements for information placed by context�aware systems. The synergetic knowledgeintegration is the integration that leads to a fundamentally new result (the synergetic effect manifestsitself).

Information requirements provide the basis for most methodologies for designing information systems[8–12]. The purpose of this work is the design of the methodology for creating context�aware systemsbased on the consistency between the functional requirements for the context�aware decision support sys�tem placed by users and the requirements for information and knowledge placed by the system. The pro�posed methodology is exemplified by a context�aware decision support system developed for the emer�gency management problem domain.

The results can be used in the design of information systems for creating or configuring the systemswith respect to user requirements.

1. CONTEXT�AWARE DECISION MAKING BASED ON SYNERGETIC KNOWLEDGE INTEGRATION

The context and the environment in which decisions are made strongly affect the final decision. Thisfact gave rise to context�aware decision support systems. The context allows the volume of data to be ana�lyzed to be reduced and information to be unambiguously interpreted.

The classical decision�making model [13] involves three stages: problem identification, generation ofalternative decisions, and selection of a satisfactory decision. The use of the context model, whichdescribes the decision situation, in the decision support system reduces the dependence of a decision

Context�Aware Decision Support Systems Based on Typical Knowledge Integration Models

T. V. Levashovaa and A. V. Smirnova, b

a St. Petersburg Institute for Informatics and Automation, Russian Academy of Sciences, St. Petersburg, Russiab University ITMO, St. Petersburg, Russia

e�mail: [email protected] December 11, 2013; in final form, February 18, 2014

Abstract—A methodology for designing context�aware decision support systems based on typicalknowledge integration models is proposed. These models describe the functional capabilities of thesystem at different stages of its usage. The models are used to specify requirements for information andknowledge from the side of the context�aware system. The comparison of these requirements with theuser requirements for the system functional capabilities and user restrictions allows us to obtain thefunctional capabilities that are available for a given user.

DOI: 10.1134/S1064230714040108

ARTIFICIAL INTELLIGENCE

JOURNAL OF COMPUTER AND SYSTEMS SCIENCES INTERNATIONAL Vol. 53 No. 4 2014

CONTEXT�AWARE DECISION SUPPORT SYSTEMS 531

maker (DM) on the external factors that affect the final decision. Using this model, the DM is involved inthe decision making at the final stage, i.e., the selection of a satisfactory final decision.

Within the framework of the context�aware decision support methodology [14], the two�level repre�sentation of a situation by means of the context model is used. At the first level, the situation is representedby an abstract context which is an ontological intensional model that integrates the knowledge relevant formaking a decision in the current situation. This knowledge is extracted from an application ontology ofthe problem domain. This ontology involves knowledge of the two following types: the domain knowledgethe problem solving knowledge of the problems arising in the problem domain [15]. As in the case of theapplication ontology, the abstract context integrates knowledge of the two above types. At the second level,the situation is represented by an operational context which is an extensional of the abstract context(its instantiation for the current conditions). The operational context is generated by the information andcomputational resources of the environment where the context�aware decision support system operates.The operational context contains all the information required for solving problems represented in theabstract context. These problems are solved as constraint satisfaction problems using the environmentresources. As a result of the problem solving, the system provides the DM with a set of alternative decisionswhich can be made in the current situation. The task of the DM is to select a final decision from this set.The correspondence between the classical decision�making model and the context�aware approach areshown in Table 1.

The analysis of the literature on the synergetic knowledge integration shows that there are few studieson revealing typical models of such integration. The following typical models described in differentsources can currently be outlined: unstructured integration [16], convergence and fractal integration [17],and recombination [18].

The unstructured integration model is distinguished by analyzing knowledge transfer processes. Dur�ing the analysis, two classes of processes are considered: structured and unstructured transfer of knowl�edge. The unstructured integration model belongs to the process unstructured knowledge integration.In [16], besides this model, a several more integration models are distinguished: structured integration(search, study, application, and memorization) and unstructured integration (unstructured copying andunstructured adaptation); however, these models do not provide the synergetic effect. Therefore, only theunstructured integration model is considered here. This model arises when the available knowledge isinsufficient for solving a given problem (answering a question of interest) or this knowledge cannot be useddirectly. The model is reduced to dynamically combining individual knowledge by creating a group ofexperts for the purpose of interchanging their special knowledge. As a result of such an interchange, a fun�damentally new knowledge unavailable in the individual knowledge can be generated.

The recombination model involves two typical models: synergetic knowledge integration and knowl�edge reconfiguration. The synergetic integration model describes the interaction of individuals and directinterchange of opinions between them. In this model, different opinions are clashed to produce funda�mentally new ideas. The essence of the model is in the application of approaches used in other domainsto a given base. Such a base can be an idea, technology, service, etc. In order to incorporate this knowledgeinto the base, the base is completely reconfigured to produce a new result.

The convergence model describes the process that requires a certain technology for new service func�tions. In the course of convergence, the required technology is joined with other technologies (for exam�ple, the integration of electronics into the machining technology has resulted in numerical controldevices). The convergence model is akin to the reconfiguration model. In the fractal integration model,two different technologies are combined to create a fundamentally new technology (for example, thecombining of the digital, radio, transceiver, recorder, and some other technologies resulted in the technol�ogy of mobile telecommunication systems). The convergence and fractal integration models describe cog�nitive processes. The integration of technologies begins when a person with one cognitive map for a certain

Table 1. Classical Simon’s decision�making model and the used model

Stage Stage content Processes Context�aware approach

Intelligence Search, identification, and formu�lation of a problem to be solved or a situation where a decision is needed

Understanding the problem. Making a conclusion about the decision to be made

Creating the abstract context. Generating the operational con�text

Planning Proposing feasible decisions Searching for alternatives Generating the set of efficient al�ternative decisions based on the constraint satisfaction technology

Selection Selecting a satisfactory decision Estimating the alternatives and selecting the final decision

532


LEVASHOVA, SMIRNOV

technology interacts with a person having another cognitive map. Their interaction results in the cooper�ative learning to produce new knowledge.

In the synergetic knowledge integration models considered above, human plays an important role.In these models, the synergetic effect emerges from the human interaction. Such an interaction cannot bewell�formalized. In this work, we consider the synergetic integration of explicitly specified knowledgebased on the knowledge integration processes proposed in [7] and described in the form of typical knowl�edge integration models. These models introduce the typification of knowledge integration processes andgeneralize these processes from the viewpoint of the state of the knowledge sources involved in the inte�gration and the results of the integration. The features of preserving (changing) the autonomy and struc�ture of the knowledge sources as well as integration results are used as the generalization features.

By the structure of a knowledge source we mean a conceptual structure used by the given source forknowledge representation. In this work, the concept of autonomy is limited by the consideration of rela�tionships between the knowledge sources. If a knowledge source is not related to other sources, then it isconsidered to be autonomous. The knowledge provided by this source can be changed at any time withoutmaking changes in the other sources. If a knowledge source is related to one or more sources, then thesesources are considered nonautonomous. Changes in a nonautonomous source may require changes inother sources related the former one. The change of the autonomy state of knowledge sources does notimply changes in their structure.

The results of integration in the typical models are represented by two constructs of the specificationlanguage. The first construct describes the integration result in the form of the result obtained by analyzingthe knowledge integration processes. The second construct maps the integration result into the ontologi�cal paradigm and, thus, places the result to the abstract level of knowledge representation. Nowadays,ontologies are regarded as the most promising method of knowledge representation [15].

The specification language for knowledge integration models uses concepts of the initial and targetsources for specifying the knowledge sources involved in the integration. The initial knowledge sources arethe sources from which knowledge is integrated to produce a new knowledge (the result of the integra�tion). The target knowledge sources are the sources that include the new knowledge.

2. CONTEXT�AWARE DECISION SUPPORT SYSTEM FOR EMERGENCY MANAGEMENT

In the context�aware decision support system (CADSS), the two�level representation of a situation isused for emergency management. At the first level, the emergency situation (ES) is represented by anabstract context which is an ontological intensional model that integrates the knowledge needed for thedecision making in the current ES and is extracted from the application ontology of the emergency man�agement problem domain. The abstract context integrates knowledge of two types: the domain knowledgeand the knowledge of methods for solving the problem of planning emergency response actions. Examplesof the domain knowledge are the knowledge of ES (type, location, severity, etc.), knowledge of the infra�structure of the region, etc. In the abstract context, this knowledge is represented at the conceptual level;i.e., only characteristics (properties) of real world objects to which values are to be assigned are specified(Fig. 1).

At the second level, the ES is represented by the operational context, which is the extensional of theabstract context (its instantiation for the current settings) (Fig. 2). The operational context is generated bythe information and computational resources of the environment where the CADSS operates. For thispurpose, a resource network is configured that specifies the order in which the functions provided by theresources are called. Initially, the operational context is a copy of the abstract context, where there are novalues of the real world objects’ properties or default values of the properties are assigned. The operationalcontext arises when the values are assigned using the available CADSS resources to all the properties. Thiscontext includes representations of real world objects and, completely or partially, values of input argu�ments of methods for solving the planning problem. In the operational context, the dynamic propertiesand parameters are updated as they are changed. For example, the transport situation is regularly updatedand the ES severity level, the location of mobile teams, etc. may be changed.

The problem of planning the emergency response actions is also solved using CADSS resources. In theanalyzed system, this problem is solved as a constraint satisfaction problem. The result is a set of actionplans that are feasible in the current ES. An action plan is a set of executive resources with schemes ofmoving the mobile executive resources and schedule for executive resources (Fig. 3). The executiveresources are organizations and people (hospitals, emergency teams, fire teams, etc.) that can participatein the response actions. The set of executive resources is determined by the ES type, infrastructure, andgeography of the region.



−

+

−

−

−

−

−

−

− ThingEmergency situation

Fire

Emergency managementEmergency aid

Air transportatioGround transportation

Resource

ExecutorMobile

Emergency teamFire brigade

Organization

Emergency serviceFire service

Hospital

Transportation facility

Ambulance car

Fire vehicle

Fire helicopterRescue helicopter

Role.+

Fig. 1. Fragment of the abstract context that describes the fire ES.

Fire brigade using the fire helicopterFire brigade using the fire vehicleEmergency team using the rescue helicopterEmergency team using the ambulance carHospitalRoad closed to traffic

Fire

Fig. 2. Operational context.

534


LEVASHOVA, SMIRNOV

The set of action plans is offered to the DM, who chooses a decision that becomes a guide for the exec�utive resources involved in the selected operation plan. In order to simplify the selection procedure, theDM is provided with optimization criteria (minimum cost of operation, minimum time of operation, anda compound criterion).

Upon completing the operation of emergency response, the abstract context, operational context, rep�resentations of CADSS resources, set of alternative decisions, and the selected decision are placed into anarchive. The operational context and the representations of CADSS resources are archived in those states(with those values of properties and arguments) in which they were at the time of generating the set ofdecisions.

In [7], typical models for context�aware stages of the CADSS usage are presented. These modelsdescribe the functional capabilities of the system at a particular operational stage. At the stages of workingwith the abstract context, there are three typical knowledge integration models: simple integration (cre�ation of the abstract context), extension (refinement of the abstract context), and configuration (reuse ofthe abstract context). At the stages of working with the operational context, we distinguish the followingtypical models: instantiated integration (generation of the operational context), “flat” integration (gener�ation of decisions), and adaptation (implementation of decisions). At the stage of managing the archivedknowledge, the “historical integration” typical model is distinguished. In this work, we give an example ofthe selective integration model (see below). This model describes the processes occurring at the stage ofconstructing the application ontology.

Name: selective integration.Purpose: creation of the knowledge model for a problem domain.Solution: integration of multiple knowledge fragments from the set of heterogeneous ontologies.Initial knowledge source: set of ontologies.Target knowledge source: application ontology.Initial autonomy: the initial knowledge source is autonomous, and autonomy is not determined for the

target knowledge source.Synergetic result: new knowledge source that represents knowledge.Result in the ontological paradigm: ontology of the new�type.Final states: the structure of the initial knowledge source is preserved; the structure of the target knowl�

edge source is new; the initial knowledge source is autonomous; and the target knowledge source is auton�omous.

Graphical representation: see Fig. 4.Stage: creation of the application ontology.

Hospital 1 (4 vacant places)Hospital 2 (4 vacant places)Hospital 3 (2 vacant places)Hospital 4 (3 vacant places)Hospital 5 (3 vacant places)

Fig. 3. Example of the action plan for emergency aid in ES.



B b1

b2 b3b4

a1

a2 a3

a4

a5

ApplO

D

N

...

d1

d2d3

n1

n2n3

n4

Fig. 4. Graphical representation of the selective integration model: ApplO is the application ontology; В, D, …, N are theinitial ontologies; bn, dn, …, nn are the concepts used in the ontologies; — is the relationship; are the integratedfragments of knowledge; and is the new knowledge.

Table 2 describes the parts of the typical models that are important for specifying information require�ments from the side of CADSS. The application ontology, abstract context, operational context, informa�tion and computational resources of CADSS, and other knowledge sources produced by the integrationare considered as knowledge sources.

The place of the knowledge integration models in the scenario of planning fire response is shown inFig. 5. Here, the selective integration model is used to create the application ontology. The creation of thisontology is independent of the type of a particular ES. The input of the selective integration model is(1) the set of problem domain ontologies that represent the knowledge related to various ESs and (2) theset of problem ontologies that represent the knowledge related to the problem of planning the emergencyresponse. The application ontology represents the knowledge of the emergency management problemdomain.

The output of the selective integration model (application ontology) is the input of the simple integra�tion model. The simple integration model is used to construct the abstract context. The abstract contextis constructed for a given ES type (fire in the scenario under consideration). This context is the intensionalontological model of the situation caused by fire. The output of the simple integration model (abstractcontext) is the input of three models.

The first model, which uses the abstract context as the input, is the extension model. This model is usedwhen the logical inference can be constructed over the knowledge represented in the abstract context.In the considered scenario, a new functional relationship that links the representations for the mobileexecutive resource and the routing method is deduced. In the extension model, the abstract context is theinput and the output of the model.

The second model, in which the abstract context is used as input, is the configuration model. Thismodel is applied when the abstract context is reused, i.e., when the existing abstract context is used in thesituation with a new (previously unused) set of environment resources. The resources must generate a pic�ture of the ES and a plan of response actions in this ES. In the scenario of planning fire response actions,the abstract context is reused when there is no resource (sensor) that provides information about the hos�pital location in the form of coordinates. However, the set of environment resources involves another twoother resources. These resources provide methods that, being executed one after the other, can compen�sate for the missing resource. One of the resources provides the recommended institutions method, whichoutputs addresses of hospitals in the form of a postal address. The other resource (conversion) converts thepostal addresses into coordinates. The successive execution of the recommended institutions and conver�sion methods provides an alternative for the unavailable resource. The specification of this sequence isentered to the abstract context, which serves as the input and output of the configuration model.

The third model, which uses the abstract context as the input, is the instantiated integration model.This model is applied for producing the operational context that is the human�understandable dynamicrepresentation of the fire situation. The operational context is generated by the resource network that isconfigured using the abstract context. The operational context is the output of the instantiated integrationmodel.

In addition to the fact that the operational context is a representation of the fire situation, it specifiesthe problem of planning fire response actions. This specification shows which information represented inthe operational context is used for solving this problem. The operational context is the input of the flatintegration model. This model is used for solving the planning problem. Its solution is a set of alternative

536


LEVASHOVA, SMIRNOV

Table 2. Fragments of specifications of the typical synergetic knowledge integration models

Generalization feature Initial knowledge source Target knowledge source

Selective integration

Set of ontologies Application ontology

Initial autonomy Autonomous Not defined

Degree of preserving the structure Preserved New

Finite autonomy Autonomous Autonomous

Simple integration

Application ontology Abstract context

Initial autonomy Autonomous Not defined



Extension, configuration

Abstract context Abstract context

Initial autonomy Autonomous Autonomous

Degree of preserving the structure Modified Modified


Refinement

Abstract context Operational context

Initial autonomy Autonomous Not considered


Finite autonomy Autonomous Nonautonomous

Flat integration

Operational context Knowledge source that links the operational context with the set of alternative decisions

Initial autonomy Nonautonomous Not considered

Degree of preserving the structure Modified Not considered

Finite autonomy Not considered Autonomous

Adaptation

Knowledge source that represents the decision; executor profiles

Knowledge source that represents the decision; executor profiles

Initial autonomy Nonautonomous Nonautonomous

Degree of preserving the structure Modified Modified

Finite autonomy Nonautonomous Nonautonomous

Historical integration

Operational context Application ontology

Initial autonomy Nonautonomous Autonomous

Degree of preserving the structure Preserved Modified

Finite autonomy Nonautonomous Autonomous



response action plans. The output of the flat integration model is a new knowledge source that combinesthe representation of the current ES and the set of plans. After the decision is made by the DM (an actionplan is selected from the set of alternative plans), only the selected plan combined with the representationof the current ES is represented in the new knowledge source.

The output of the flat integration model (knowledge source representing the action plan) is the inputof the adaptation model. This model is used when the executor involved in the action plan cannot partic�ipate in the response actions for some reason, and the actions planned for this executor should be redis�tributed among other executors participating in the plan. If there are executors that are ready to acceptextra duty, then the plan is adjusted and the profiles of new executors are completed with the new elementsfor representing extra actions (new competences). When the plan is corrected, modifications are made inthe knowledge source representing the plan. The executors’ profiles are another input of the adaptationmodel. In this model, the knowledge source representing the action plan and the profiles of executors arethe inputs and outputs.

The set of operational contexts that provided basis for the decisions ever made are stored in the archive.These contexts are the foundation for the inductive inference of new knowledge using available but not

Stage Set of ontologies that represent the knowledgerelated to the ES problem domainand the set of ontologies of problems

Selectiveintegration

Simpleintegration

Extension

Resource

Configuration

Instantiated

Flat integration

The application ontology“emergency management”

Conceptual structure forsolving the problem of

planning fire response actions

New functionalrelationship that links the mobile executive

resource with the routing method

Sequential execution of therecommended institutionsand conversion methods

instead of the location method

Picture of thefire situation

Plan for fireresponse actions

Adaptation

Profiles of executive resource

Newcompetence

Historical integration

New “belong to” relationship between the

hospital and emergency teamArc

hiv

ed

kno

wle

dge

man

agem

ent

Imp

lem

en�

tati

on

of

the

dec

isio

n

Gen

erat

ion

of

dec

isio

n

Gen

erat

ion

of

the

op

erat

ion

al

Reu

se o

f th

eab

stra

ctco

nte

xt

Ref

inem

ent

of

the

abst

ract

con

text

Co

nst

ruct

ion

of

the

abst

ract

co

nte

xt

Cre

atio

n o

f th

eap

pli

cati

on

on

tolo

gy

network

integration

con

text

Fig. 5. Using the typical knowledge integration models when planning fire response actions.

538


LEVASHOVA, SMIRNOV

explicitly specified knowledge. For this purpose, the historical integration model is used. The set of accu�mulated operational contexts is the input of this model. If the inference produced new knowledge, thenthe corresponding specification for representing this knowledge is added to the application ontology. Theapplication ontology is the output of the historical integration model. In the scenario of planning fireresponse actions, a new relationship (belong to) between a hospital and an emergency team is generated.This relationship shows that the emergency team participating in various emergency response actions isassigned to the hospital which occurs together with this team in different contexts.

3. DESIGNING CONTEXT�AWARE SYSTEMS WITH REGARD TO USER REQUIREMENTS

As has already been mentioned, information requirements are the basis for the majority of methodol�ogies for designing information systems. In this paper, we consider information as an integral part ofknowledge. The typical knowledge integration models described above make it possible to specify require�ments for knowledge sources and information from the side of CADSS.

In this paper, we propose a methodology for designing context�aware systems based on the CADSSinformation requirements with regard to user requirements. The information requirements imposed bythe system are developed based on the typical knowledge integration models. These requirements aredetermined by the system functional capabilities at different operational stages. The methodology involvesthe following stages: (1) specification of requirements to the CADSS functional capabilities placed byusers side; (2) specification of the information requirements imposed by the CADSS; (3) correspondencebetween the CADSS requirements and the user requirements; and (4) determination of the CADSS func�tions achievable for a given user.

For example, for the CADSS considered in this work, its functions are related to the typical knowledgeintegration models; these functions are presented in Table 3 with regard to the degree of autonomy andvariability of the initial and target knowledge sources that reflect real states of the knowledge sources usedby the particular system.

This work considers requirements for initial knowledge sources only. The set of the requirements forboth the initial and target sources is used to analyze information flows in the CADSS between differentstages and between the typical models. The requirements for the initial sources of knowledge and infor�mation are presented in Table 4 (see CADSS requirements) for general cases. Here, the following desig�nations are used: a is an autonomous knowledge object; na is a nonautonomous knowledge object; m is amodifiable knowledge object; nm is a unmodifiable knowledge object; / is the logical OR; and & is the log�ical AND. The network of information and computational resources is considered as a single reconfig�urable object with no changes within the resources being assumed (the structure of the resources is notmodified). The autonomy (nonautonomy) of the resource network assumes the autonomy (nonauton�omy) of the network itself, while the resources are always nonautonomous.

In order to demonstrate the functional requirements for CADSS imposed by the user, we consider thefollowing scenario. Suppose that the user has no application ontology available. However, there is anunmodifiable abstract context representing an abstract situation with which the user constantly deals.Also, a certain known set of information and computational environment resources to executor profilesare authorized to the user’s needs. The user restrictions for this example are shown in Table 4 (see userrestrictions). The not specified value means that the user has no specific requirements for the initial knowl�edge source or constraints on using this source. The system designers may specify these requirements attheir own discretion. In this work, the designers’ requirements intended to provide all the functions of thesystem.

The applicability of typical model column in Table 4 allows one to make a conclusion on the applicabil�ity of typical models by comparing the CADSS requirements for the initial source with the user restric�tions. Table 4 shows that the flat integration, instantiated integration, and adaptation models are fullyapplicable for the considered example. In the case of these models, the requirements for all the initialknowledge sources imposed by the user and by the system coincide. The configuration and historical inte�gration models are partially applicable (requirements for only one initial knowledge source coincide). Theapplicability of the configuration model is limited by the ability to configure the resource network. More�over, if alternative resources are found, then new relationships that formalize these alternatives cannot befixed. The historical integration model allows the inductive inference to be used but cannot memorize theresults of the inference because the application ontology is unavailable for the user. The other typical mod�els for the restrictions of this user are inapplicable.



Table 4. Requirements for the system functions based on the typical models

Typical knowledge integration model

CADSS requirements User restrictions Applicability of the typical modelinitial knowledge source parameter value parameter value

Selective integration Set of ontologies a/na/m/nm Not available Not applicable

Simple integration Application ontology a/na/m/nm Not available ″

Decision Abstract context a/na&m nm ″

Configuration Abstract context ″ ″ ″

Resource network a/na/m/nm a/na&m Applicable

Instantiated integration Abstract context ″ nm ″

Resource network na&m/nm a/na&m ″

Flat integration Operational context na&m Not specified = na&m ″

Resource network na&m/nm a/na&m ″

Adaptation Decision na&m Not specified = na&m ″

Set of executor profiles ″ na/a&m ″

Historical integration Set of operational contexts a/na/m Not specified = a/na/m ″

Application ontology a/na&m Not available Not applicable

Table 3. CADSS information requirements

Stage Functions Initial knowledge source Target knowledge source Typical model

Creation of application ontology

Creation of knowl�edge model of the problem domain

Set of autonomous ontolo�gies

Autonomous applica�tion ontology

Selective integra�tion

Construction of the ab�stract context

Creation of the in�tensional model of the current situation

Autonomous application ontology

Autonomous abstract context

Simple integra�tion

Refining the abstract context

Logical inference of new (context�de�pendent) knowledge

Autonomous modifiable abstract context

Autonomous abstract context

Extension

Reuse of the abstract context

Reconfigurion of the resource network with respect to the new situation

Autonomous modifiable abstract context.Autonomous config�urable resource network

Autonomous abstract context.Autonomous resource network

Configuration

Generation of the oper�ational context

Creation of the dy�namic model of the current situation

Autonomous abstract context. Resources for which the loss of autono�my is allowed

Nonautonomous modifiable operational context.Nonautonomous re�source network

Instantiated in�tegration

Generation of the set of alternative solutions

Providing DM with the set of alternative decisions

Nonautonomous modifi�able operational context.Resources for which the loss of autonomy is al�lowed

New autonomous knowledge source.Autonomous resource network

Flat integration

Decision implementa�tion

Acquisition of new competences by ex�ecutors

Nonautonomous modifiable knowledge source that provides the decision. Nonautonomous mod�ifiable executor profiles

Adaptation

Archived knowledge management

Inductive inference and formalization of new knowledge

Set of nonautonomous operational contexts.Autonomous modifiable application ontology

Autonomous applica�tion ontology

Historical inte�gration

540


LEVASHOVA, SMIRNOV

Based on the analysis of the applicability of the typical models, the user can be offered a system withthe following functional capabiities. The system can repeatedly use the abstract context. The introductionof any new knowledge into this context is impossible. The abstract context can only be used in the envi�ronment with a constant set of information and computational resources. The new configuration of theresource network has no sense because it cannot be specified in the abstract context. Based on the abstractcontext and resource network, the system can generate the operational context (dynamic picture of thecurrent situation) and set of alternative decisions that can be made in the given situation. Since the usercan manage the executor profiles, the system can provide the user with the functions of controlling theimplementation of his decision. The set of operational contexts can be archived and the inductive infer�ence over this set can be performed; however, the results of the inference cannot be saved. When transfer�ring the proposed functionals to the level of the problem, it can be stated that the user can work with thesame problem by substituting different data from the same resources (sources) into the problem, obtainnew results (decisions) depending on the data, and control the implementation of the decisions.

CONCLUSIONS

The methodology for designing CADSS based on typical synergetic knowledge integration models isproposed. The methodology allows one to develop and adapt such systems with regard to the requirementsfor the system functions imposed by a particular user and user restrictions on the use of information andknowledge sources involved in the integration.

Presently, the proposed methodology can take into account only requirements for the sources that pro�vide initial information and knowledge for the integration. In the future, we plan to take into account theset of requirements for initial sources and target sources obtained as the result of the integration. This willprovide a more accurate determination of the achievable functional capabilities due to the considerationof variants of using the sources that are not explicitly specified as target ones but include information andknowledge required at a given stage of the system operation.

ACKNOWLEDGMENTS

This work was supported by the Russian Foundation for Basic Research (project nos. 13�07�12095,13�07�13159, 14�07�00345, and 14�07�00427), by the Presidium of the Russian Academy of Sciences(project no. 213), by the Department of Nanotechnologies and Information Technologies of the RussianAcademy of Sciences (project no. 2.2), and by the Government of the Russian Federation (projectno. 074�U01).

REFERENCES

1. M. Baldauf, S. Dustdar, and F. Rosenberg, “A survey on context�aware systems,” Int. J. Ad Hoc UbiquitousComput. 2, 263–277 (2007).

2. M. Miraoui, C. Tadj, and C. Amar, “Architectural Survey of Context�Aware Systems in Pervasive ComputingEnvironment,” Ubiquitous Comput. Commun. J. 3 (3), 68–76 (2008).

3. J.�Y. Hong, E.�H. Suh, and S.�J. Kim, “Context�aware systems: A literature review and classification,” ExpertSyst. Appl. 36, 8509–8522 (2009).

4. C. Perera, A. Zaslavsky, P. Christen, and D. Georgakopoulos, “Ca4iot: Context awareness for Internet ofthings,” in IEEE Int. Conf. Internet of Things (iThing), Besanon, France, 2012, pp. 775–782.

5. P. Makris, D. Skoutas, and C. Skianis, “A survey on context�aware mobile and wireless networking: On network�ing and computing environments' integration,” IEEE Commun. Surveys Tutorials 15 (1), 362–386 (2013).

6. Context�Aware Systems and Applications, Ed. by P. C. Vinh, N. M. Hung, N. T. Tung, and J. Suzuki, in LectureNotes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering (Springer,Berlin, 2013), Vol. 109.

7. A. V. Smirnov and T. V. Levashova, “Principles and models of context�aware knowledge integration,” Inform.Tekhnol. Vychisl. Sist., No. 4, 17–32 (2013).

8. A. P. Sage, Decision Support Systems Engineering (Wiley, New York, 1991).

9. I. Vessey and S. Conger, “Learning to specify information requirements: The relationship between applicationand methodology,” JMIS 10 (2), 177–201 (1993).



10. G. Elliott and J. Strachan, Global Business Information Technology: An Integrated Systems Approach (AddisonWesley, Harlow, 2004).

11. MDA—The Architecture of Choice for a Changing World, http://www.omg.org/mda/. Accessed November 22,2013.

12. E. Shahbazian, L. Pigeon, J. Krtaft, and É. Bossé, “Building technology�enabled decision support applica�tions,” in Prediction and Recognition of Privacy Efforts Using Collaborative Human�Centric Information Systems,Ed. by É. Bossé, E. Shahbazian, and G. Rogova (IOS Press, Amsterdam, 2013), pp. 98–108.

13. H. A. Simon, The New Science of Management Decision, 3rd ed. (Prentice�Hall, Englewood Cliffs, 1977).

14. A. V. Smirnov, A. A. Kashevnik, T. V. Levashova, and N. G. Shilov, “Theoretical and technological foundationsof building context�aware systems for the support of daily decision�making in the open information environ�ment,” Mekhatronika, Avtom., Upr. 99 (3), 72–77 (2009).

15. A. V. Smirnov, M. P. Pashkin, N. G. Shilov, and T. V. Levashova, “Ontology management,” J. Comput. Syst. Sci.Int. 42, 621–633, 744–756 (2003).

16. J. Chen and R. J. McQueen, “Knowledge transfer processes for different experience levels of knowledge recip�ients at an offshore technical support center,” Inf. Techn. People 23 (1), 54–79 (2010).

17. K.�R. Lee, “Patterns and processes of contemporary technology fusion: The case of intelligent robots,” AsianJ. Technol. Innov. 15 (2), 45–65 (2007).

18. L. Y. Lin and Y. J. Lo, “Knowledge creation and cooperation between cross�nation R&D institutes,” Int. J.Electron. Bus. Manage. 8 (1), 9–19 (2010).

Translated by Yu. Kornienko

Documents

Context-aware decision support systems based on typical knowledge integration models