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
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.
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
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