Journal of Knowledge Management Practice, September 2003

Use Of Ontologies To Enhance The Design Of A Framework

 For Multi-Party Collaboration And Decision-Making:

The Case Of Situation Room Analysis

Bob Roberts, Kingston University and Adamantios Koumpis, ALTEC S.A.

ABSTRACT:

Work presented in this paper forms part of a wider research in defining a methodological framework for Situation Room Analysis (SRA), and its deployment for complex (business enterprise) systems study. In our approach, we propose the use of ontologies as a powerful means to support the implementation of multi-party collaboration and decision-making activities that build on the paradigm of a Situation Room (SR). The approach is complementary to others in the area of business planning and is characterised as top-down in that the SR paradigm is conceptualised through three related models: the Situation Room Model (SRM), the Information Management Model (IMM) and the Situation Analysis Model (SAM). The ontology-based approach includes the semantic features of the exchanged decision-making information thus offering the integration of the SRA framework with existing corporate decision-making grids.


1.         Setting The Stage: Situation Room Essentials

Work presented in this paper forms part of a wider research in defining a methodological framework for Situation Room Analysis (SRA), and its deployment for complex (business enterprise) systems study. In our approach, we propose the use of ontologies as a powerful means to support the implementation of multi-party collaboration and decision-making activities that build on the paradigm of a Situation Room (SR). The latter term is broadly used in the context of military operations and has specific semantical connotations. These connotations are deliberately exploited in order to propose an analytical scheme based on it, which aims to assist planning initiatives and decision making in a particular application domain.

We recognize a unique opportunity to consider the attempt to organise enterprise-wide SR in direct connection with KM efforts that a company or an organisation is planning to undergo; in this case, SRA may provide the means to organise KM practices, while the SR may provide a concept that will be subject to valuation with respect to performance indicators, both at the micro (i.e. for a given situation and how the company or the organisation has performed with respect to it) and the macro levels (i.e. how for a longer term horizon the company has organised its resources to respond to external stimuli and demands for action that are regarded as situations, and how this helped increase the knowledge capital of the company for the given matters).

Like all systems of notation and semantics, Situation Room Analysis can never be anything but a model; it is a map to a territory, whose validity may be evaluated by reference to that underlying reality in the ‘real world’. Historically speaking, a Situation Room is considered as the intelligence analysis centre used to stay abreast of the latest intelligence reports and updates. Such intelligence allow an army’s or an army unit’s senior officers to make informed command decisions and / or stay current on news throughout the federation of other units and beyond. Within this aim, i.e. the multi-party collaboration and decision-making activities from within the Situation Room Analysis framework, it is easy to see that the latter should be data-driven. In this respect we can consider the case of, for example, a company planning to create a virtual market response Situation Room to improve how it collects and assesses information regarding its own and / or competitors’ products. Such an approach would enable stakeholders to obtain important data in a more timely and effective manner.

The SRA framework as presented by Koumpis and Roberts in (Koumpis, 2003) emphasises the idiosyncratic characteristics of the ICT sector such as innovation, technological change, transfer of technology and technology diffusion. These require the development of a design space where different scenarios will be subject to in vitro assessment and evaluation. The employment of the framework may take place during any phase of the life cycle of an ICT service or product, i.e. from the early design phases up to the phase of its launching into the market.

We regard our approach as complementary to others in the areas of business planning; Mandal et al (Mandal, 2003), for example, suggest that managers should “conduct a pre-alliance planning exercise to assess the compatibility of business goals of partners, determine a method for implementation, and indicate the key informational as well as cultural challenges that may arise throughout the alliance’s duration". In their work, they report on a set of key concepts related to the formation of an alliance which may prove critical for its successful execution which include the "efficient and effective decision making". They argue that actions to build and sustain a strategic alliance include, amongst others, performance indicators concerned with benchmarking, knowledge management in the team environment and decision making involved with technology management.

Collaborative business decision-making software, and all forms of business software, may be viewed as a representation or a set of symbols, for some underlying reality. An analogy may be drawn with classic double entry accounting systems that may be seen as providing both a methodology and metadata framework capable of representing different kind of business transaction and financial state change that can exist in the business problem space (See for instance the work of Baruch Lev as reported in his book Intangibles: Management, Measurement and Reporting, Brookings Institution, June 2001.). Similarly, there is a need for a systems to describe corporate decision making activities that builds on (elementary) information management transactions. Howeer, such a system also needs to represent subtle relationships and hierarchies and it is at that point that the need to exploit the expressive power of ontologies comes to the foreground.

2.         Use Of Ontologies

According to Hahn (Hahn, 2003), semantic web technologies and management tools can be used to link the model entities of a distributed model. More specifically, two integration concepts have been used:

      file-based where the information is stored in a XML representation enriched with meta-information expressed in RDF (Resource Description Framework), and

      online, where tools can provide the information online with an interface implemented as a Web Service.

A promising approach, which we propose exploits semantic indexing techniques. The latter, though not new, is a sophisticated indexing schema, which allows us to support the kinds of operations necessary in an efficient way.

The employed indexing scheme is based on ontologies: taxonomic information with additional links that represent associated properties. While some ontologies represent very general knowledge, others specifically target a particular domain (Ankolekar, 2001).

In order to use ontologies for indexing we have to establish links between the data in the SR data warehouse and the concepts in the ontology. All pairs of attributes and values in the database are mapped to concepts in the ontology. An example is given in the Figure below. The solid links are ontological links and the dashed links are indexing links.

 

 

      Figure 1: Use Of Ontologies For Indexing Data / Information Entities Used For SRA

The aim is to provide support for queries such as: “Which actions are effective against 80% of situations sharing commonality element A.1 with the situation we are facing today?”

The integration of ontologies into corporate legacy information and database systems is of growing interest as they can increase the efficiencies of the way a company uses existing information (re)sources. For instance, in the case of a company that uses a traditional division of their activities into different cost or profit or value centres, each centre is related to different tasks and the aims it is expected to fulfil relate to different elements of the corporate objectives (see Figure below). To address this, each department or business unit uses a particular ontology, which provides the communication means for assisting coordination of its core business.

 

 

Figure 2: Organisation And Mapping Of Semantics For The Different Cost/Profit/Value Centres With Ontologies

Such a local ontology may heavily vary from centre to centre. For example, the introduction of a new product relates to profitability aspects for the Finance Dept and invokes the possibility of stopping any further production and selling of older products that have reached their maturity in the market. It also raises questions related to campaigning, competitors attitude, e.t.c. for the Marketing Dept, as well as minimisation of production costs and waste for the Production Dept.

From the above, it is clear that there is need for a treatment of the semantics for each different notion as this appears at the local ontology level; this is the role that can be assigned to the Global Ontology, which affects the entire corporate process grid.

Before going into a deeper level of analysis for the use of ontologies in our framework, we provide some background information on modelling aspects of the Situation Room Analysis frameworks as well as some basic services it is expected to provide to SR participants, and for which the use of ontologies is considered as a contributing factor to overall efficiency.

3.         Modelling Aspects Of The Situation Room

This section includes some additional information on the models pertaining to the SR concept. Our goal is to support high-level corporate operations, such as planning and project programming, by means of defining the Situation Room Analysis as an expressively powerful vehicle to support this need. The main entities for defining the basics of Situation Room Analysis are related with:

      the concept of the Situation Room per se,

      the managed information within the SR, and

      the main items of the conducted analysis which in our case focus on products and services in the IT market.

In regard to all three of them three corresponding models are defined, namely:

      The Situation Room Model (SRM),

      The Information Management Model (IMM), and

      The Situation Analysis Model (SAM)

They all concern descriptive conceptualisations of entities and activities, annotated with the interactions and possible relationships amongst them, which results in a super-model namely the Situation Room Analysis. Furthermore, we elaborate on this by providing the specifications for setting up the implementation of this to an IT framework using emerging technologies (XML, software Agent, Semantic Web and ontology technologies) and established system design approaches (UML). In both modeling and interpreting the impact of information in the context of the virtual network the research is also informed by game theory and transaction cost theory (Friedman, 1991) and (Casson, 1991).

In the table below we provide a description of the supported actions on a given information entity as this is realised within the Information Management Model of the SRA framework:

 

Nr

Identifier

Action type

Description

1

RM

Remove

It is destroyed as if it never came under consideration within a set structure under use in the Situation Room. This is not a usual or recommended practice, but may simplify procedures in several situations. A more recommended practice is to justify reasons for its irrelevance and ignore it (see below). However, and as long as logging of events is taking place, tracing back to this state is possible.

2

IGN

Ignore

It exists but is not used for any current inferences made within a set structure under use in the Situation Room. This is the case of trying to simplify a problem by ignoring (temporarily or permanently) a set of information regarding specific aspects of the subject under consideration.

3

LN

Link

With some other piece of information within a set structure under use in the Situation Room. How? By means of choosing one of the enabled link types:

3a

LN_TO

As above

Link as related to with a unidirectional link to the other information entity

3b

LN_FROM

As above

Link as related to with a unidirectional link from the other information entity

3c

LN_BOTH

As above

Link as related to with a unidirectional link for both information entities

3d

LN_ONL

As above

Link "only" to the other information entity without any further pre-defined relationship between them

3e

CUST_LN

As above

This type enables user defined link types to be created by means of enabling users of the system to develop their own link categories, which may be domain- or user-specific and which may vary amongst each of the users or usage types.

3f

LN_LN

As above

This forms an important type of linkage as it provides the means to link one link with another link.

4

ADD

Add it

It concerns the insertion of a particular information entity to a set structure under use in the Situation Room.

5

CRT

Create

Creation of a new placeholder

 

Table 1: Potential Supported Actions On An Information Entity

Note that in regard to the above Table, one possible difficulty in the implementation, which may result in consistency and constraint satisfaction problems is this of the space of Link type relationships: in our description we define this to be between two entities. It is easy to see for instance that especially for 3d, 3f and 3e it is essential to support linkage with more than one information entity. For implementation reasons, we propose that the system design might proceed in the definition of a Group action which enables groupings. However, such an action is included in the design but aims to facilitate aggregation operations for information entities. Thus, the approach we would propose is one of implementing a generic type of link that support tuples of 2, 3 or N information entities. Bearing in mind existing development environments and programming languages, this is trivial to support. However, 10 years ago it would have necessitated the development of a mechanism to handle this as a separate activity

As seen from the above, the central notion for an information entity within the Information Management Model is this of linking it to other entities. Furthermore, also important are the "placeholders" in which a specific entity will be input. These may either be predefined if we expect specific entities to populate them, or realised ad hoc. Such ad hoc creation of a placeholder often takes place under time and resource pressure and therefore its results are usually suboptimal. For this reason it is essential that placeholders are reconsidered on a periodic schedule and - if needed - adapted, renamed or consolidated with others.

In regard to the placeholders the same actions hold as for the information entity. There is, however, an exception and this is for the creation of a new placeholder. The reason for this is that while a piece of information has arrived and we recognise its existence, a placeholder is an artificial artifact for which we are solely responsible for its construction. It has been considered as out of the scope of our research to further investigate this aspect. However, this is not always the case: there is frequently the case of information creation, based on synthesis of other (previously existing) information or even ‘out of nothing’ (the latter is also the case of making some hypothesis because we simply want to make it or need to make it).

A further important aspect of the Information Management Model relates to the ability for representing all actions performed or attributed to particular information entities. In this respect, what is actually needed is a ‘device’ that guards some conditions and performs some actions when the conditions are true. This idea is not new in the Computer Science theory and practice as it is expressed by well-known metaphors like demons in AI and triggers in databases, and it has been widely used in several modelling languages and development environments (see for instance Widom & Ceri (Widom, 1996)). Our notion of a linker element (in brief: linker) realises this idea in a slightly different fashion. While normally, the condition is defined by a universal predicate, which means that the guard needs to observe the whole, or a large part of a database to find any place where the condition is true, our linker works locally, as it guards only its own operands.

According to our approach the linker is the only way:

To express relationships amongst information entities, be they passive or active relationships. Thus, we use the same notion for describing both static information entities and actions to them. The uniformity allows treating actions in the same way as static links, i.e. we can add and delete actions in the same way as we add and delete static relationships during a database transaction.

To define actions on information entities. In this respect, any action that takes place within the SR to enrich or explain an information entity is simply linked to the previous state of the entity, providing also the last inherently proprietary characteristic of that last action.

4.         Implemention Of Ontologies Within The SRA Framework

Our approach builds on the adoption of a widely adopted service oriented architecture that encompasses the simplicity and scalability of the Web services model (see Figure 3 below).  Besides the simplicity of implementation, the advantage of modularity also enables the "repackaging" of any existing SRA services into new, composite services. This increases the added value of the framework and should encourage companies to invest in its usage and population with new situation data. Preliminary developments that we have been experimenting with took place across a network of workstations emulating the conditions of a realistic Situation Room.

      Figure 3: Adoption Of The Web Services Model For The Provision Of Basic SRA Services

As a result of this, we identify the need for introducing semantics in our approach as:

      synonyms of situations in various corporate contexts,

      equivalent situation types in various corporate contexts,

but also for:

      Synonyms of situations in the same corporate context,

      Equivalent situation types in the same corporate context.

It is in this respect that there is need to support semantic level processing for the collaborative SRA services to be delivered through the underlying application. For this, the technical goal is to provide a transparent system architecture acting as a broker between cross-Cost / Profit / Value Centres that will automatically handle the inconsistencies amongst the different situations and coordinate inter Cost / Profit / Value Centre process management.

Based on the above, it is obvious that we need declarative forms of scripting complex web services, which would also enable composition of scenarios that represent real-world coordination amongst the different members of the SR, also taking into account temporal and synchronization aspects.

Ankolekar et al. (Ankolekar, 2001) describe DAML-S, a DAML+OIL ontology, designed by the DARPA Agent Markup Language (DAML) Services Coalition, to specify the capabilities of Web Services. DAML+OIL provide a semantic and further expressive power to the Extensible Markup Language (XML) and the Resource Description Framework (RDF). Furthermore, DAML-S provides service descriptions in three conceptual areas:

      the profile, which describes what the service does,

      the process model, which depicts how the service works and

      the grounding which states how the particular service is used.

4.2.      Representative SRA Services

In this section we describe three basic services that are provided by the framework and which have been implemented using the aforementioned approach.

We used our services by means of building and adapting three of the “essential products” of the C4ISR Architecture Framework which are indicative of the expressive power of the SRA model, thus providing the means of application domain- and context-specific customisation of it.

4.2.1.   Situation Synopsis

The Situation Synopsis facility addresses essential aspects of a situation considered by means of providing answers to questions related to Who? What? When? Where? How? of a particular situation under consideration. In this respect, it may facilitate the initial phases of planning. It is easy to recognize the need for it to be provided in a consistent form that will allow quick reference and comparison amongst other situations, thus disabling error proneness with respect to linkings with the ‘wrong’ situations. It is upon the Situation Synopsis that indexing and retrieval operations will be based. It is time-dependent, i.e. as time goes by it may change – after the completion of a situation, it is still important that this has been appropriately documented in the Situation Synopsis.

The following apply when providing the Situation Synopsis:

Identification. Provide a unique descriptive name for the situation, identify the person responsible for its handling (: the "Account" manager for that particular situation), identify involved units, e.t.c.

Purpose. Explain why the SRA is needed, what it is intended to achieve, the types of analysis expected to be applied to it, who is expected to perform the analysis, what decisions are expected to be made on the basis of that analysis, who is expected to make those decisions, and what actions are expected to result from the architecture.

It is highly possible that the answers to these questions cannot be given from the beginning – it is however imperative that the person responsible for the situation will try to provide answers.

Of course, a situation that was initially identified to be related with a cause X might be attributed to cause Y; and the interactions with some other entities may have been initially erroneously attributed to some reasons Z. For this reason it is essential that the Synopsis will enable enrichments and further – continuous - updates.

Scope. Identify the situation views and implications and its particular temporal nature, such as the time frame covered, e.g. whether by specific years or by designations such as ‘as-is’, ‘to-be’, ‘transitional’, e.t.c.

Context. Describe the interrelated conditions that compose the setting in which the situation exists. Include such things as doctrine, relevant goals and vision statements, concepts of operation, scenarios, and environmental conditions. Identify the tasking that led to the architecture’s development, and known or anticipated linkages to other situations.

Document-specific assumptions and constraints regarding the situation analysis effort, and identify authoritative sources for the rules, criteria, and conventions that were followed in developing the particular syllogisms.

Findings. State the findings and recommendations that have been developed based on the above. Examples of findings include recommended actions, identification of shortfalls or successful implementations, and opportunities for reaction.

Tools and file formats. Identify the tool suites to be used to support the SRA exercise. Identify the system and file names, and location of the data and appropriate resources including also human actors.

4.2.2.   Integrated Situation Dictionary (ISD)

There is considerable textual information in the form of definitions and metadata (i.e., data about an item) associated with the various situations encountered. The Integrated Situation Dictionary provides a central source for all these definitions and metadata, including those that may be provided for convenience within another architectural component as well. At a minimum, the Integrated Situation Dictionary is a glossary with definitions of terms used in a given situation description. The Integrated Situation Dictionary makes the set of components capable of standing alone and allows a set of situation related documents to be read and understood without reference to other documents.

Each labeled item (e.g., terms, phrase, or acronym) in the situation literature should have a corresponding entry in the Integrated Situation Dictionary. For instance, when we speak about a Sales downsizing the ISD provides a unique explanation for this. The same also applies when speaking about a Sales downscaling – whatever this may mean too. By using specific terminology, actions and reactions can be standardized and this saves time, decreases error rates etc.

The type of metadata included in the Integrated Situation Dictionary for each type of item will depend on the type of the component from which the particular service item is ‘taken’. For example, the metadata about a labeled input/output connector from an activity model will include a textual description of the type of input/output information designated by the label.

The contents for the Integrated Situation Dictionary entries for each component type should be regarded as evolving, as is the case for any dictionary of a natural language. SR participants should use standard terms where possible (i.e., terms from existing, approved situation dictionaries). However, in some cases, new terms and/or modified definitions of existing terms may be needed. This can happen when new concepts are devised. In those cases, the new terms contained in a given architecture’s Integrated Situation Dictionary should be submitted to the maintainers of the SR for approval. All definitions that originate in existing dictionaries should provide a reference to show the source, which may be the first situation in which a particular term was used. Furthermore, indicative references to a term may be used for helping the comprehension of the particular term(s). In this respect, the terms Sales downsizing and Sales downscaling might have been used for the first time in situations ABC and XYZ respectively, while the ‘best’ example for conceiving their notion may be situations abc and xyz respectively. Indexes and thesauri that provide support for synonyms, or other type of processing of the particular semantics of a term is not considered as part of the Integrated Situation Dictionary.

4.2.3.   Situation Concept

The Situation Concept is the most general of the architecture-description service components and the most flexible in format. Its main utility is as a facilitator of human communication, and it is intended for presentation to SR participants and decision makers. This kind of service can also be used as a means of orienting and focusing detailed discussions. A possible template may show generic icons that can be tailored as needed and used to represent various classes of actors in a particular situation under consideration. The icons could also be used to represent missions or tasks. The lines connecting the icons can be used to show simple connectivity, or can be annotated to show what information is exchanged.

How the template is tailored depends on the scope and intent of the implementation, but in general a Situation Concept should be capable of communicating to interested parties some basic information regarding causality and time dependencies, as well as interactions amongst the various actors involved.

5.         Conclusions

The fast growth of innovations in the last 20 years (coming mainly from the service and engineering disciplines) exposes companies and their shareholders to varied risks and different types of risk that may be difficult to quantify. Though extended report-centric infrastructures have been set (companies investing several thousands of Euros on them on an annual basis) these often result in extensive yet largely meaningless statements enumerating every possible risk yet still exhibit insufficient specific risk disclosures.

The problem with business process modeling the way it is often currently done by companies is that it is not an integral part of the development process. It is rather more of a pre-development process where a model of how the business works is produced independently of the developers. From the developers’ perspective such a model has no relevance as a development artifact. The challenge is to produce modelling artifacts which are an integral part of the development process and which automatically generate the supporting applications, as well as the respective application protocols. The concept of Situation Room Analysis (SRA) is proposed as a means of achieving this level of integration.

In the paper we have proposed the usage of an ontology-based approach that offers inclusion of the semantic features of the exchanged decision-making information thus improving the quality of integration of the SRA framework with existing corporate decision-making grids. Our approach was verified building representative applications by means of Web services and the DAML-S language. Furthermore, in our SR family-specific modelling approach, the particular models as well as their instantiations are made up of elements representing notions that are part of the addressed corporate decision making domain world, not its implementation in the software code world.

References

Koumpis A. (1997), Situation Room Analysis in the Information Technologies Market, in Communications of the ACM, Vol. 40, No. 3, March

A. Ankolekar, M. Burstein, J.R. Hobbs, O. Lassila, D.L. Martin, S.A. McIlraith, S. Narayanan, M. Paolucci, T. Payne, K. Sycara, H. Zeng (2001), DAML-S Semantic Markup for Weeb Services, Proc. Of the First Semantic Web Working Symposium (SWWS ’01), Stanford, The SAML Services Coalition

Friedman J. W. (1991), Game Theory with Applications to Economics, Oxford University Press, London

Casson M. (1991), The Economics of Business Culture: Game Theory, Transaction Costs and Economic Performance, Clarendon Press, Oxford

Widom, J., Ceri, S. (1996), Active Database Systems: Triggers and Rules for Advanced database processing, Morgan Kaufmann, New York

Mandal, P., Love, p.E.D., Irani, Z. (2003), Pre-alliance planning: development of an information system infrastructure to support strategic alliance activities, Management Decision, Vol. 41, No. 2.

Koumpis, A., Roberts, B. (2003), A framework for Situation Room Analysis and exploration of its application potential in the IT sector, in First International Conference on Performance Measures, Benchmarking and Best Practices in New Economy – Business Excellence '03, University of Minho, Guimaraes, Portugal, June 10-13

Hahn, A. (2003), Integration and Knowledge Management Platform for concurrent engineering, in 9th International Conference of Concurrent Enterprising (ICE2003), Espoo, Finland, June 16-18


About The Authors:

Dr Bob Roberts BSc (Hons), Msc, PhD is leader of the e-commerce group in CARIS and course director of the MSc in E-Commerce at Kingston University. After graduating from the London School of Economics, he worked in IS/IT consultancy for BT and then General Electric Information Services supporting their EDI services in Europe. Since joining Kingston University research interests have focused on the use of electronic commerce to support information sharing between trading partners and the design implications of integrating electronic commerce capabilities into existing information systems.  Recent research and consultancy activities cover a range of e-commerce projects in the telecoms, health, construction and electronic sectors. This includes DTI funded projects for researching the use of electronic commerce by SMEs. Other external e-commerce related activities include being a member of TradeUK (DTI) Best Practice Working Party on Electronic Commerce and Internet Marketing and also member of the Internet Working Group of the Centre For Study of Financial Innovation. He may be contacted at: R.Roberts@kingston.ac.uk

Adamantios Koumpis heads the Research Programmes Division of ALTEC S.A., which he founded at 1996 (then as independent division of Unisoft S.A.). His research interests include quantitative decision making techniques and Info Society economics. He successfully lead many commercial and research projects in Greece in the areas of E-Commerce, public sector and business enterprise re-organisation and information logistics, concerning linking of data/information repositories with knowledge management and business engineering models. Mailto: akoumpis@unisoft.gr