Front Cover
 Title Page
 Table of Contents

Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: Database supported cooperative problem solving
Full Citation
Permanent Link: http://ufdc.ufl.edu/UF00095161/00001
 Material Information
Title: Database supported cooperative problem solving
Series Title: Department of Computer and Information Science and Engineering Technical Report ; 92-046
Physical Description: Book
Language: English
Creator: Chakravarthy, Sharma
Karlapalem, K.
Navathe, S. B.
Tanaka, A.
Publisher: Department of Computer and Information Sciences, University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: December, 1992
Copyright Date: 1992
 Record Information
Bibliographic ID: UF00095161
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.


This item has the following downloads:

199277 ( PDF )

Table of Contents
    Front Cover
        Front Cover
    Title Page
        Page i
    Table of Contents
        Page ii
        Page iii
        Page 1
        Page 2
        Page 3
        Page 4
        Page 5
        Page 6
        Page 7
        Page 8
        Page 9
        Page 10
        Page 11
        Page 12
        Page 13
        Page 14
        Page 15
        Page 16
        Page 17
        Page 18
        Page 19
        Page 20
        Page 21
        Page 22
        Page 23
        Page 24
        Page 25
        Page 26
        Page 27
        Page 28
        Page 29
        Page 30
        Page 31
        Page 32
        Page 33
        Page 34
        Page 35
        Page 36
        Page 37
        Page 38
        Page 39
        Page 40
        Page 41
        Page 42
        Page 43
        Page 44
        Page 45
        Page 46
        Page 47
        Page 48
        Page 49
        Page 50
        Page 51
        Page 52
Full Text

University of Florida
Computer and Information Sciences

Database Supported Cooperative
Problem Solving

S. Chakravarthy
K. Karlapalen
S. B. Navathe
A. Tanaka
e-mail: sharma@snapper.cis.ufl.edu

Tech. Report UF-CIS-TR-92-046
December 1992
(Submitted for publication)

Department of Computer and Information Sciences
- rG Computer Science Engineering Building
_ University of Florida
.Gainesville, Florida 32611

Database Supported Cooperative Problem Solving*

Sharma Chakravarthyt

Database Systems Research & Development Center
Computer Information Sciences Department
University of Florida, Gainesville FL 32611
email: sharma@snapper.cis.ufl.edu

Kamalakar Karlapalem

Hong Kong University of Science and Technology
Department of Computer Science
Clearwater Bay, Kowloon, Hong Kong.
e-mail: {kamal@uxmail.ust.hk}


Shamkant B. Navathe Asterio Tanaka

College of Computing
Georgia Institute Of Technology
Atlanta, GA 30332-11 '-11
e-mail: {sham,tanaka}@cc.gatech.edu

December 27, 1992

*A preliminary version of this paper appeared in the International Workshop on Cooperating Knowledge
based Systems, Keele, U.K., October 1990
tAll communication regarding this paper should be addressed to Prof. S. Chakravarthy


1 Introduction 2

1.1 Characteristics of Cooperative Problem Solving ..... . . . . . 4

1.2 Spectrum of cooperative problem solving .............. . . 6

2 Database support for cooperative problem solving 9

2.1 Modeling and Systems Support .................. .... .. 10

2.2 Functionality Support .............. . . . . . ...... 12

2.3 Categorization of Problems .................. ...... .. 16

3 Multi-staged Approach to Cooperative Problem Solving 17

3.1 Near-term (Centralized) Approach .... . . . . . . 19

3.2 Long-term (Distributed) Approach .............. . . .. .. 22

4 Architecture 24

4.1 CPS Environment Details .............. . . . . . .... 24

4.2 Functionality of the CPS System ................ .... .. 27

4.3 Faculty-Search Example ........... . . . . . .... 31

5 Modeling CPS Environment Components 32

6 Execution of Activities 36

7 Illustrative Examples 39

7.1 Process Control Systems ............. . . . . . ...... 41

7.2 Office Information Systems .................. ...... .. 43

7.3 Difficult Problems ................ . . . . . ...... 46

8 Open Issues 46

9 Conclusions 48


There are a number of problems in office environments, medical diagnosis, and plan-
ning that require cooperation among agents (either active or passive) for their solutions.
Briefly, cooperative problem solving can be viewed as a complex activity requiring
harmonious and dynamic interaction between active agents (typically humans -pro-
viding sequencing, decision making, and coordination components) and passive agents
(typically computing systems -providing inferencing, algorithmic computation, and
Data/knowledge storage). By definition, a problem in this category cannot be solved
by an individual problem solving agent without cooperation among the problem solv-
ing agents although each component (or the problem solving agent involved in problem
solving) is autonomous and is capable of sophisticated problem solving. This problem
is currently being addressed by the research community at various levels of abstraction.
Broadly, this paper analyzes the problem of cooperative problem solving from a
Database perspective and argues that recent advances in database technology (namely,
active and heterogeneous database management systems) and maturation of other con-
cepts (namely, temporal and object-oriented databases) provide us with a repertoire
of techniques and abstractions for formulating a viable solution to the above problem.
This view is based upon earlier database-centered solutions to problems such as au-
tomation of office environments that can be viewed as a special (and perhaps a simple)
case of cooperative problem solving.
Specifically, in this paper, we first analyze the problem of cooperative problem solv-
ing to identify its underlying key characteristics. Based upon our analysis, we partition
the problem space into classes along a spectrum and indicate the nature and the com-
plexity of solutions required. We propose near-term as well as long-term solutions for
cooperative problem solving that progressively enhances the functionality of Database
systems by synthesizing appropriate abstractions and techniques. Furthermore, we
identify problems, such as agent (capability) modeling that require further research to
address the most general form of cooperative problem solving. Finally, we discuss the
feasibility of our approach and present examples that exemplify our multi-staged ap-

Index terms: Problem solving agents, Active database functionality, cooperative prob-
lem solving, Coordination, Collaboration, Databases, event-based synchronization.

Abbreviations used:

CPS -cooperative problem solving
PSA -problem solving agent
PSAs -problem solving agents
CSCW computer supported cooperative work
DCPS -distributed cooperative problem solving
DAI distributed artificial intelligence
DBMS -database management system
DBMSs -database management systems

1 Introduction

There are a number of problems in office automation, medical diagnosis, and planning that
require cooperation among agents (either active or passive) for their solutions. Briefly, co-
operative problem solving (CPS) can be viewed as a complex activity requiring harmonious
and dynamic interaction between active agents (typically humans -providing sequencing,
decision making, and coordination components) and passive agents (typically computing
systems -providing inferencing, algorithmic computation, and data/knowledge storage).
By definition, a problem in this category cannot be solved by an individual problem solving
agent (PSA) without cooperation among the problem solving agents (PSAs) although each
component (or, the PSA) is autonomous and is capable of sophisticated problem solving.
The need for CPS can arise due to the distributed decision making inherent to the problem
(e.g., graduate admission and other similar problems, such as paper review, meetings) or
due to the distribution of expertise and problem solving capability (e.g., medical diagno-
sis, planning). The general problem of CPS is currently being addressed by the research
community at various levels of abstraction.

One of the objectives of this paper is to analyze the problem of CPS from a Database1
perspective, and to characterize the system and modeling support as well as the abstrac-
tions/techniques required for facilitating various degrees of CPS. We argue that recent ad-
vances in database technology (namely, active and heterogeneous database management sys-
tems) and maturation of other concepts (namely, temporal and object-oriented databases)
provide us with a repertoire of techniques and abstractions for formulating a viable solution
to subclasses of the above problem. This prognosis is supported by earlier database-centered
solutions to problems such as automation of office environments and computer supported
cooperative work (CSCW) that can be viewed as a special (and perhaps a simple) case of

Based on our analysis, we categorize the range of problems into groups requiring varying
degrees of cooperation (from none to the most general case that assumes full cooperation)
and try to map extant approaches onto this spectrum. Our review of the literature indicates
that Database oriented approaches to CPS can be characterized as bottom-up approach
wherein existing solutions to simpler problems are extended to more complex ones in an
incremental manner. Also, the emphasis in this approach is to have industrial strength
systems that integrate traditional database techniques with additional ones. In contrast,
Artificial Intelligence (AI) based approaches can be termed top-down and seem to take a

1Although we use the term database throughout the paper for readability, it should be interpreted as
data/knowledge base.

more ambitious view and address the most general problem or issues related to the most
general problem. The emphasis in this approach seems to be on new techniques that will lead
to solutions to complex/most general problems and usually prototype systems are developed
to test the feasibility of the results. It is evident that both groups are pursuing work on
this problem in different ways. This bidirectional approach with different perspectives, we
think, will be beneficial in the long-term as we are likely to have systems that integrate
results obtained from both groups and at the same time have industrial-strength systems.

Consistent with our view, we propose a Database-centered near-term as well as long-term
approach requiring enhancement of the functionality of a Database management system re-
quired for supporting some classes of CPS. We extend the existing Database architecture
with techniques and abstractions to support a number of problems requiring CPS. Further-
more, we identify new problems that require further research to address the most general
form of CPS. Capturing (the computational and collaborative) capability of an agent is one
such problem that deals with the modeling as well as the knowledge engineering aspects of
capabilities of individual agents involved in CPS. Finally, we elaborate on the feasibility of
our approach and present an example that exemplifies our multi-staged solution. We also
discuss some open issues.

Given the problem domain being investigated and the domain from which techniques
are adapted, it is useful to understand their similarities and differences. Briefly, distributed
databases have developed techniques for processing queries as well as transactions over a
distributed environment and guarantee certain properties (such as atomicity). To a large
extent, a homogeneous network of nodes/agents is assumed in contrast to work on heteroge-
neous databases where heterogeneous agents are assumed. Work on office automation and
CSCW approach the problem from the office modeling and productivity viewpoint. Co-
authorship, project management and underlying support for computer-based environments
that support collaborative interaction are the primary focus of this work. Then distributed
cooperative problem solving (DCPS) and multiagent problem solving concentrate on the
techniques/strategies for accomplishing cooperation and problem solving using the notion
of agents with and without centralized control. The distributed problem solving area and
the multiagent problem solving areas of distributed artificial intelligence deal more with
collaborative aspects of problem solving. The distributed problem solving research consid-
ers how the work of solving a particular problem can be divided among a number of PSAs
that cooperate at the level of dividing and sharing knowledge about the problem and about
developing a solution for the problem. In multiagent systems a collection of autonomous
intelligent agents work towards coordinating and sharing their goals, skills and plans to

jointly solve a problem. In case of multiagent systems not only do they share knowledge
about the problems but also must reason about the type of coordination required among
the agents to solve the problem.

Although it appears that the above classes of problems may not have anything in com-
mon, a finer characterization of CPS brings out the relationship among the above classes of
problems as discussed below.

1.1 Characteristics of Cooperative Problem Solving

A large number of activities carried out by humans require cooperation between humans
and systems commonly termed problem solving agents or PSAs. Although each PSA is
autonomous and is capable of sophisticated problem solving, the problem faced by a set of
PSAs cannot be completed without cooperation. These cooperative activities also involve
extensive access to information repositories, computation, inferencing, and decision making.
Salient characteristics of CPS can be summarized as:

decision making/inferencing using a set of criteria within a PSA (e.g., selecting can-
didates to be called for interview, selecting the computing environment for a project),

computation using a variety of systems and tools (e.g., searching a database to select
referees, computing the optimum layout of components in circuit design),

collaboration inferring the capability of participating PSAs and the dynamic devel-
opment of the problem solving strategy. That is, reasoning about problem solving
and coordination by the system, and

coordination synchronization and execution of the plan based on the causal relation-
ships and actions performed by individual PSAs.

The last two essentially differentiate a cooperative problems solving environment from
other environments. It is interesting to note that there is a large, separate body of work
on Distributed Cooperative Problem Solving [3] in Distributed Artificial Intelligence (DAI)
which distinguishes distributed problem solving from multi-agent problem solving [4] where
the latter need to reason about the process of coordination among the agents. Briefly, the
main issue in collaboration is the solicitation of contributions from participating agents (as
opposed to problem decomposition and independent evaluation) so that the problem can
be solved jointly by the group where as coordination is necessary for resolving conflicts,

allocate limited resources, searching in global space based on local information. Concep-
tually, collaboration can be viewed as planning phase whereas coordination corresponds to
execution of a plan (either pre-defined or dynamically developed).

There are some aspects of CPS that need to be highlighted although they can be grouped
under the last two categories. One is the notion of the PSA's capability modeling, that
is how to model self (in terms of domain knowledge, capability, intentional knowledge, and
evaluative knowledge) and other participating agents. Another aspect of this problem is the
representation of domain knowledge and techniques/mechanisms for their use in problem

Other problems, such as coherence -how the system behaves as a unit along some
dimension of evaluation, efficiency -the system's overall efficiency in solving a problem,
uncertainty -having imperfect information (either about the state, action, or plan) about
various aspects of problem solving, need to be considered in a CPS environment. Also, one
of the underlying assumptions made in most of the approaches is that the PSAs cooperate
in a positive manner in solving a problem. It is entirely possible that there could be PSAs
who are not trustworthy or PSAs who pretend to be cooperative but are not contributing
to the overall problem solving. We will assume positive cooperation and will not address
either conflicting or untrustworthy PSAs as it is beyond the scope of this paper.

From the above, we can infer that collaboration and coordination are two key charac-
teristics of CPS. In order to support CPS, it is imperative that the underlying computing
environment2 be capable of providing support for each of the characteristics identified.
Many day-to-day activities in the world fall into the above category. For example, the grad-
uate student admission process in a university environment, typically, involves cooperation
among several autonomous PSAs: the graduate admissions office, one or more departmental
graduate offices, a graduate coordinator, and a graduate admissions committee. Perhaps
diagnosis of an ailment involving multiple autonomous medical experts exemplifies the prob-
lem of CPS and all of its facets. Finally, office automation, a specific example of CPS, also
exhibits most of the characteristics mentioned above. In order to underscore the complex-
ity of these problems, it is useful to contrast them with conventional problems carried out
using extant computing environments and tools. Most of the conventional activities fall
into one of the following two categories: computation-intensive, where there is very little
interaction with the outside agent (e.g., wind-tunnel simulation, finite element analysis)
and one-on-one interaction with an agent and the system (interactive applications, such as

2By underlying computing environment, we refer to the kind of support an operating systems provides
for a general problem solving environment or even the support a DBMS provides for the management and
manipulation of data.

design, querying an information repository etc.).

On the other hand, a problem requiring cooperation is likely to use varying degrees of
collaboration as well as coordination among a large number of agents as well as systems
and agents. Currently, a significant part of cooperation -both among systems, and sys-
tems and agents -is done by the (active) agents. As a consequence, human agents are
an integral part of the loop performing required activities most of which need to be rele-
gated to the underlying computing environment. In order to assist human agents in this
process, the functionality of the underlying systems need to be augmented. Our goal is to
suitably enhance the functionality of the underlying components to support the execution
of cooperative activities.

In order to get a good understanding of problems that require cooperation, we describe
the different classes of problems that encompass a broad spectrum of issues.

1.2 Spectrum of cooperative problem solving

Various problems addressed in the literature can be classified with respect to the degree
of coordination and collaboration that exist among PSAs. Both can vary from none to
complete collaboration and coordination. The latter takes us into the realm of psychology,
sociology, and cognition to model group interaction and a human as an individual PSA.
Figure 1 shows the categorization of problem classes along these two dimensions drawn as
X- and Y-axis, respectively. Figure 2 shows the characteristics of the extremes for the type
of collaboration and coordination that can arise in CPS.

Distributed databases (and to a large extent distributed computing) have very little or
no collaboration and all the coordination is known a priori. The agent capability model-
ing problem is reduced to that of populating and maintaining a data dictionary containing
extensional knowledge stored in each node as well as system capability. Most of the coordi-
nation is generated using the information maintained as part of the data dictionary by the
distributed query processor and the distributed transaction management subsystem. Hence
the kind of collaboration reduces to data exchange, and the coordination is accomplished
by the system components using commit protocol and other techniques. In addition, a
problem is decomposed and individual subproblems are sent to various PSAs (nodes in
the distributed network). The nodes in the network are assumed to be homogeneous and
possess the same functional capability.

Heterogeneous databases (also known as federated or multidatabases) are similar to
distributed systems with some differences. There is no explicit collaboration but the coor-

High ems

a Office

b i\utomation

o Federated

Low Centralized
Low High
Coordination High

Figure 1: Classification of Problems in the Cooperative Problem Solving Environment

System Oriented Cognitive Oriented
Coordination Coordination
Data Intensive Knowledge Intensive

Forced (or pre-defined) Unforced (or seeking)
Collaboration Collaboration

Figure 2: Range of Complexity of collaboration and coordination

dination takes place over heterogeneous PSAs (instead of homogeneous ones) and as a result
PSAs need to be modeled in more detail. The coordination is still system oriented but the
commit protocol is much more complex, and in some cases may require human interaction.
Differences in the PSAs and their capability in terms of functionality are captured as part
of the data dictionary (or global data dictionary). However, current work on federated
information systems include additional systems that need not be DBMSs (e.g., spreadsheet,
expert systems) adding more complexity to the agent capability modeling problem.

Office information systems, on the other hand, do not hard code the coordination aspect
but specify them as part of the procedure/problem. Still, there is very little or no collab-
oration but the coordination aspect is different than that of the earlier two systems. The
coordination is cognitive oriented, knowledge intensive and would require lot more human
interaction. Clearly, traditional Database systems does not even provide support for this
level of coordination.

Distributed cooperative problem solving (DCPS) [3] goes a step further in adding com-
munication between PSAs during problem solving. Although the solution is arrived at as
a group, each node possesses sufficient overall problem-solving knowledge that its partic-
ular expertise can be applied and communicated without assistance from other nodes in
the network. Each node also possesses significant expertise in communication and control
strategies. This knowledge frees the network from the bounds of designed protocols and
allows nodes the flexibility to develop their own communication and collaboration strategies
dynamically. In this case the extent of agent capability modeling depends on whether we
are dealing with a set of homogeneous agents (like in flexible manufacturing systems) or a
set of heterogeneous agents (like in planning, scheduling). In case of homogeneous agents
it will require less amount of agent capability modeling compared to heterogeneous agents.
It will require lot more agent capability modeling if the agent were a human rather than
a system. For example, in case of office information systems it is very important to model
the interaction between humans.

Distributed AI (DAI) and multiagent problem solving can be viewed as the most general
form of CPS where both collaboration and coordination play significant roles in solving
a problem. The agents in a multiagent scenario must also reason about the process of
coordination among the agents. In multiagent problem solving the agents are supposed
to be intelligent, therefore the agent capability modeling is complicated. Moreover, the
collaboration and coordination are cognitive oriented, and very knowledge intensive (right
extreme of Figure 2). There is uncertainty in identifying the set of agents for solving a
problem, as well as in knowing whether the problem can be solved. It is very difficult to
model agents' capability. Moreover, these agents coordinate among themselves with possibly
no global control (open systems). In this scenario, it is uncertain whether the problem can
be solved or even whether a coordination among agents can be achieved.

In this paper, we delimit ourselves to problems for which the coordination and collab-
oration components can be specified. Lesser [24] defines two kinds of distributed problem
solving systems namely: CA/NA -completely accurate nearly autonomous systems and
FA/C functionally accurate cooperative systems. Our approach falls in the domain of
CA/C completely accurate and cooperative systems. The PSAs in our approach may
be autonomous or cooperative. Our approach will work for either case. But if the PSAs
cooperate, then their coordination plan is completely accurate and well defined. That is,
there is a strict protocol for communication among agents. Finally, the focus of this paper
is to provide a solution to the class of problems including DCPS if not the problems that
require full multiagent solution approach.

The structure of the paper is as follows. In Section 2, we present the limitations of
the current database systems and briefly review the extensions required. In section 3, we
present a multi-staged architecture that includes new techniques and their role in solving
various classes of problems. Section 4 gives details of the architecture, its modules and their
functionality. Section 5 describes our approach to the capability modeling aspect of agent
modeling. Section 6 provides the run time interaction of the modules. Section 7 provides
some examples of problems that can be modeled using the approach presented in this paper.
Section 8 has conclusions and a brief discussion of open issues.

2 Database support for cooperative problem solving

In this section, we make a case for progressive enhancement of the functionality of the
Database management system to support CPS. We start with a brief description of tradi-
tional DBMSs and identify additional functionality required to enhance the ability of the

database management system to support CPS.

The role of DBMSs has traditionally been to provide shared access to large volumes of
data and support consistency, recovery and other basic aspects of sharing. The semantics
of applications is embedded in programs that execute over the database. However, there is
a definite shift in the way databases are used lately and the support/functionality expected
of them. This shift has come about for two reasons: i) the need and the utility of databases
for non-traditional applications has been recognized and ii) database management systems
have evolved by internalizing additional functionality to suit the requirements of new classes
of applications. This trend, we believe, underlies the approach proposed in this paper which
analyzes the use of newly proposed techniques for yet another non-traditional application.
Most of the applications of DAI [4] (Chapter 8) use long term memory or short term memory
to refer to the Database, and active blackboard respectively. But they concentrate more
on the collaboration and coordination aspects by means of goal processing and treat the
long term and short term memory as second class objects. In contrast, we make use of the
extended capabilities of Database management system to develop a Database supported
CPS approach.

There are some fundamental differences, between conventional databases and coopera-
tive problem solving systems, that need to be understood before proposing extensions to
database management systems to support CPS. Primary differences are: i) Traditionally,
databases have endeavored to capture mostly the static description of data (by means of a
logical data model) to be managed and maintained by the system, ii) the transaction model
used in database management systems is based on a paradigm that views concurrent trans-
action as ."..'ip. i g" for resources rather than "cooperating" to solve a specific problem.
This new perspective is central to the near- and long-term architectures proposed in the
next section, and iii) coordination among constituent nodes is pre-defined and the problem
decomposition uses a known coordination structure.

2.1 Modeling and Systems Support

The above differences as well as the collaboration and coordination issues discussed in the
previous section lead to the identification of the following for supporting CPS. We also
summarize the promising results obtained so far for each problem.

PSA Capability modeling: CPS requires PSAs to be able to reflect their role in problem
solving as well as the roles of others involved in problem solving. However, one of the
open problems '-] is the type of knowledge that need to be captured (about self

and others) and maintained, the process of capturing the knowledge, and the use of
knowledge for interaction and problem solving.

There is consensus about the types of knowledge that need to be captured i-*] i)
Domain knowledge -facts and relationships about the environment in which the
problem solving is taking place, ii) State information -about the problem being
solved with respect to self and others, iii) Capability knowledge -problem solving and
interaction (communication/coordination) capability of self and others, iv) Intensional
knowledge -what an PSA intends to do; usually described in terms of plans, and v)
Evaluative knowledge -which permits PSAs to distinguish between PSAs which offer
similar services. It may include, in addition to other things, a competence rating for
skills, a measure of reliability attached to information coming from a particular PSA,
or a measure of timeliness in a time-critical environment.

Of all the types of knowledge listed above, we propose that, as a first step, the capabil-
ity knowledge is captured in a capability data/l I...l. 1.1. base. A capability database
stores the capabilities of the PSAs in the CPS environment. The capabilities of the
PSAs are defined by means of a capability definition language which when compiled
generates both intensional and extensional data of the capability database.

In order to solve a problem (whether using the centralized or distributed problem
solving approach), selecting the relevant PSAs is an important first step, the next
step being coordinating these PSAs to solve the problem. Capability database may
either be centralized or distributed. Conceptually, it may be thought of as a single
repository. In an actual implementation it may be distributed and even replicated.

Of course, the extent and the type of information that need to be captured while mod-
eling a PSA is also dependent upon whether the plan being generated is centralized
or a multiagent plan or a distributed plan.

Activity specification and management: We refer to a problem that needs coopera-
tion among the PSAs to solve it as an activity. An activity can be decomposed (either
statically or dynamically) into a set of tasks3 that coordinate with each other to solve
the problem. These tasks are known as subactivities. Examples of activities are: the
process of hiring a faculty candidate, manufacturing a product using a set of CNC ma-
chines on a factory floor, and querying some information from a set of heterogeneous
information sources. Whenever an activity is given to this system it decomposes
this activity into a directed acyclic graph (DAG) of sub activities each of which is
completely within the scope of some PSA. This requires niutchi'lalki between the
3tasks and subactivities are used interchangeably in this paper.

requirements (data, knowledge and solution techniques) of the subactivities and the
capabilities of the PSAs. This is a very significant difference between the solution
approaches in distributed artificial intelligence and database oriented approach. By
storing and maintaining the capabilities of the PSAs in the database, the complex
task of choosing the right PSA for a subactivity reduces, in simple cases, to querying
the capability database. Note that any changes in number and capabilities of the
PSAs need to be reflected through changes to the capability database.

Either as part of the activity specification or as part of the problem solving pro-
cess, a coordination plan is generated for each activity. A coordination plan specifies
the temporal, data, knowledge, and synchronization dependencies between the PSAs
working on an activity. This coordination plan is generated by a module that trans-
lates the activity specification by taking into consideration task dependencies, possible
parallelism among subactivities, contingency plans in case of time-outs, failures etc.

In contrast to the notion of a transaction in a DBMS, the connotation of an activity
or a problem in the context of CPS is different. First, an activity need not subscribe
to the strict serializability and recovery criteria inherent in a transaction model. In
addition, an imperative form of activity specification (as is typical to transactions)
is not suited for CPS environment. Finally, some of the run-time issues (e.g., dura-
tion of an activity) are also different for the activities/problems to be solved in this

Heterogeneity: Agents, being autonomous computing elements (whether human or au-
tomatons), have differences in functionality, self-awareness, assumptions, problem-
solving, and reasoning. Heterogeneous databases have addressed many of the problems
that deal with disparate hardware, software, communications and modeling capabili-
ties in the context of databases. Techniques and solutions developed in the context of
heterogeneous databases with respect to communication and query processing are ma-
ture and further advances are being made in the area of global transaction processing
and coupling of systems that are not necessarily database management systems. As
the transaction requirement is not as stringent in CPS as in conventional databases, we
will assume, in the next section, a network of heterogeneous PSAs and that they can
communicate with one another (either directly or through some intermediate nodes).

2.2 Functionality Support

Below, we discuss the elemental functionality support required for CPS along with the
techniques that can be adapted to provide the functionality.

Dynamic coordination: Coordination requires at a minimum some knowledge of the ac-
tions of other PSAs, and the ability to reason about the effect of those actions. In a
CPS environment, it is unlikely that the entire plan as well as the interaction needed
among the PSAs is well-defined at the outset. It is more likely that except in simple
cases, coordination required among PSAs is dynamically derived (or compiled from
the specification with an ability to make minor changes due to changes to the en-
vironment such as failure, overload etc.) necessitating dynamic coordination. One
approach proposed in this paper for dynamic coordination is to generate rules (specif-
ically, event-condition-action or ECA rules) from activity specification that can be
used for dynamic coordination of activities.

Event-based interaction: In contrast to the traditional state-based interaction using
shared memory, we propose event-based interaction using persistent blackboards for
CPS. As coordination and problem solving need to be done in a dynamic manner,
it may not be possible to predetermine interactions among PSAs. So most of the
interaction needs to be based on the action or the sequences of actions (essentially
primitive or complex events, respectively) which entail that the underlying PSAs
need to support various types of events (external, temporal, and database or method
based). Techniques recently [8, 6, 21, 1] developed in the area of active databases can
be adapted to provide this capability.

Collaboration: In this paper, we assume that collaboration together with coordination
results in cooperative behavior. Collaboration is more than communication or even
coordination in that it requires sharing a common global goal although the tasks
carried out are local to each participant. In addition to sharing (of knowledge, goal,
result etc.), it is important to agree upon the strategy for solving a problem and
making sure that effort by each agent positively contributes to the overall objective.
Collaboration assumes that each agent either is aware of the capability of other agents
or can assess it through a dialogue.

In our approach collaboration is accomplished by evaluating and matching the capa-
bilities of PSAs (using the capability Database) to the problem at hand. An activity
is decomposed into a set of tasks and processed by the CPS system. Collaboration
is limited to selecting and assigning one or more PSAs to each of the tasks of an
activity. This is done by deriving, from the capability database, a set of PSAs that
can perform the activity, determine the availability of each PSA in the set, evaluate
any constraints associated with the PSA, and then assign a PSA for the task. In this
sense, collaboration is not totally dynamic but is determined through this selection

and assignment process although each PSA performs its task without any knowledge
of the actual activity being processed. This is termed forced collaboration. If the
PSAs had the knowledge about the activity being processed, the knowledge about
other PSAs involved in processing the activity, and directly communicated with other
PSAs to select and perform the tasks, then it corresponds to unforced collaboration.
In case of forced collaboration a module of the CPS system generates a schedule to
process the activity by assigning PSAs to each of the tasks.

Active databases can be viewed as an abstraction for elegantly supporting a variety
of database functions that were being realized using special-purpose mechanisms in
conventional DBMSs. Traditionally DBMSs have been passive; that is queries or
transactions are executed only when explicitly requested. [5] discusses the useful-
ness of rule-based active capability for supporting a variety of DBMS functions, such
as integrity and security enforcement, access control, maintenance of derived data,
materialized views and snapshots, rule-based inferencing, and dynamic coordination.

Limited active database capability can be implemented in a straightforward manner
without using rules (e.g., SYBASE [12], Symbolics-ADBMS [10]). However, the use of
rules for incorporating active capability provides several additional benefits including:
declarative specification of events, conditions, and actions, optimization of rules and
actions, use of existing rule-based systems (e.g., OPS class systems) using the active
capability, and specification of object and application semantics.

There is consensus that rules, the generic mechanism for specifying events, situations,
and actions should be first class objects in the system. Rules are generally of the
form (termed ECA rules), where
event is the specification of an happening (e.g., function invocation, time, ) when
the condition is evaluated. An event algebra [25, 8] has been developed as part
of the knowledge model for supporting the specification of different types of events
(database, temporal, and application-t *-*-. ..1 ) and for constructing complex events
using the above. If the condition evaluates to true then the action is executed. The
situation evaluation subsystem of HiPAC [5, 9] is concerned with the optimization
of rules and their efficient evaluation. The conventional transaction model (which
can accommodate only immediate execution of rules) has been extended to a flexible
execution model which can accommodate rule processing in a number of modes: as
part of the same transaction, as a sub transaction before the commit, as a separate
transaction that is causally dependent on the triggering transaction, and finally as
an independent transaction. Application semantics can exploit these modes (termed

coupling modes) to increase concurrency and availability. More recently, the active
paradigm has been incorporated into object-oriented databases [7, 1, 20, 21, 22]

In the context of CPS, the proposed active database capability can be viewed as
a persistent blackboard. Agents can write into a persistent shared space in each
PSA and the monitoring of what is posted here is done using ECA rules. The same
functionality is used for collaboration as well as coordination within a PSA and among

Basic temporal capability: Causal relationships play a central role in cooperative prob-
lem solving environments. In addition to this, there is also a need for explicit repre-
sentation of time, and in some cases processing under time-constraints. For example,
in the faculty search scenario, it is important to keep track of the availability of the
candidate for interviewing, the order in which final offers are made and even the
scheduling of interviews relative to the availability of core faculty in a specific area.
As another example, in air traffic control, computations and decisions are often made
under time constraints.

Unfortunately, most existing database systems and knowledge based systems are tem-
porally static (i.e., they represent only a snapshot view of the world as of the current
time). Changes in the real world are traditionally reflected by in-place updates to
the data/knowledge base, which results in losing old information. Some DBMSs do
time stamp data or preserve "old versions" of data for transaction management pur-
poses. However, as this information is not visible in the conceptual schema at the
user or application interface, they can neither be queried/manipulated directly by
users or application programs, nor can they be used to define temporal views of the
data/knowledge base.

Although there is a large body of work in temporal databases [15, 11, 2, 27, 30,
34, 33, 19, 29, 23], modeling of temporal aspects [17], our analysis requirements of
CPS indicates that causal relationships for synchronization, event-based interaction
(including temporal and complex events [8]) is adequate. However, if the problem itself
is temporal in nature, then the full functionality of temporal databases is required.

In this section we have identified key functional and basic support required for CPS.
The bottom-up approach proposed in the remainder of this paper essentially charts the
immediate as well as long-term needs of the underlying support for CPS and clearly outlines
the manner in which each technique need to be incorporated.

2.3 Categorization of Problems

The discussion of this section can be summarized in the following manner. The complexity
of solution to a problem requiring cooperation essentially depends upon two factors: the
extent to which an agent can be modeled (including both static and dynamic aspects) and
the clarity and precision with which the problem as well as the approach to a solution can be
specified. In the final analysis, agent modeling may be the factor that determines whether
these problems can be solved the way human experts do it currently.

Some of the categories of CPS are:

Precisely Defined:: This is the case where the cooperative activity has been pre-
cisely defined, the capabilities of the PSAs are well specified and captured as part
of agent capability modeling (e.g., distributed databases and some problems in office

Imprecisely Defined:: This is the case wherein the problem and its solution are not
precisely defined statically. The goals of the activity have to be inferred, the strategy
has to be inferred for decomposing the goal into sub-goals, and the PSAs to work
towards these sub-goals have to be identified (e.g., problems addressed in distributed
artificial intelligence, strategy development). In other words, the collaboration and
coordination aspects have to be arrived at dynamically.

Computer Supported Cooperative Work: This class of problems lie somewhere
between the above two. Many aspects of the problems and its solution can be pre-
specified but there are some decisions that need to be made at run-time. Exceptions
and contingencies have to be handled which may not be completely pre-defined (e.g.,
many office automation problems, computer aided design problems).

In the precisely defined case, the activity and its subactivities are well defined, the
problem of matchmaking reduces to simple queries on the capability database. The flexible
manufacturing system (FMS) is an example of this case. The solution approach can be
characterized as DBMS based, system intensive cooperation (less number of human agents
involved) and wherein the cooperation among the agents is achieved by enforcing it. That is,
none of the PSAs have the knowledge that they are cooperating, only the module responsible
for coordinating the subactivities uses the knowledge about the capabilities of the PSAs and
their progress in solving the subactivities.

There are many aspects of the CPS wherein the impreciseness of the problem definition

can be handled by extending this architecture. This is done by adding on PSAs that can
handle impreciseness (like theorem prover for automatic deduction, case-based reasoner, de-
ductive database system etc.). These enhancements immediately increase the capability of
the system to support classes of problems that (for example) need either automatic deduc-
tion or case-based reasoning capabilities. Thus just by storing the capabilities of the PSAs
and managing them and by adding specialized PSAs this architecture can support different
classes of problems (based on application domain or specialized capabilities required by the
problem) thus moving along the spectrum.

Large number of problems fall into the category where some tasks of the activity are
precisely defined and some tasks need human interaction. The approach proposed in this
paper can be used to atomize a precisely defined activity, and support coordination and
monitoring aspects of the imprecisely specified tasks. As most of the imprecisely specified
tasks need human intervention, humans need to be part of the problem solving process (in a
minimal way) and act as one of the agents. In case of time-constrained activities appropriate
schedule of tasks is required (for example, assigning alternate PSA to complete the tasks
on time) for an activity. For example, if the Graduate Coordinator is on leave than an
alternate Graduate Coordinator is selected and informed about the task to be performed.

Real world abounds with complex decision making scenarios (such as office information
systems, management of resources, combat planning) which require both collaboration and
coordination among various PSAs. These problems are currently solved II ....ii, any con-
certed approach" using various resources (PSAs that are systems as well as humans) in an
ad hoc manner (as illustrated in Figure 3). We have, in this paper, attempted to grasp
this problem, define its underlying characteristics, develop an approach, show its flexibility,
and present an extensible architecture. A major advantage of this approach is that it is
based on well established (Database) technology. We have endeavored to demonstrate that
the bottom-up approach, proposed in this paper, is well-suited to large class of reasonably
well-structured problems and further that it uses seemingly disparate existing technologies.

3 Multi-staged Approach to Cooperative Problem Solving

In this section, we first discuss the conventional approach currently being used for CPS
and its limitations. We contrast our proposed approach with the conventional approach.
Finally, we provide a long-term solution along with its architecture which combines most
of the concepts discussed in the previous section and is consistent with our incremental
bottom-up approach.


Figure 3: Conventional approach to cooperative problem solving

Figure 3 indicates the current approach to CPS. The main drawback of this approach is
that the agents (usually one or more humans engaged in CPS) have to provide most of the
collaboration and coordination among agents as well as among systems and agents. Systems
and tools are used as passive components capable only of performing computations. The
onus of information propagation, reminding other systems/agents, sequencing of tasks, and
checking for compatibility of solutions etc., are on the agents involved in problem solving.
Any system specific capability (such as email, talk, calendars etc.) is exploited in an ad hoc
manner to solve the problem. The problem being solved cannot be specified to the system
at a conceptual level in a way that includes all the coordination, sequencing, and data flow
requirements. Note that all of the cooperation (as well as communication) is among active

3.1 Near-term (Centralized) Approach

Our near-term approach (Figure 4) is based upon the pragmatic assumption that the sys-
tems participating in a cooperative activity are autonomous and the execution of an activity
can be coordinated by using a combination of database techniques developed for satisfy-
ing the requirements of non-traditional applications. The CPS system consists of a problem
iial~aqi r, an execution iinlaqi r and a capability miil'iaq r. The capability manager is respon-
sible for constructing, maintaining, and accessing the capability database which essentially
models agents. The problem manager has the role of taking the problem specification from
the problem posers and generating an intermediate representation of an activity by using
the capability database. This activity is then executed by the execution manager. The
execution manager is supported by an active database system. An active database system
monitors the changes to the state of a database and initiates appropriate actions. The
changes are caused by events, and effects of events are specified by condition-action pairs.
An active database provides asynchronous (through the specification of events, conditions,
and actions in the form of situation-action rules [13]) mechanism for supporting event-based
interaction among the nodes participating in CPS. We also envision, in our formulation of
an active database, both data and situation-action rules to be part of the shared database
to which transaction oriented access and manipulation are applicable.

An execution manager (which is analogous to a transaction manager of a DBMS, as
shown in Figure 4) is introduced for the purpose of coordinating the components of an activ-
ity. There is a subtle distinction between an execution manager and a transaction manager.
A transaction manager, typically, tries to avoid conflicts among concurrent transactions
whereas an execution manager, typically, tries to enhance interaction between cooperating



CPSS Administrators

Figure 4: Database supported centralized CPS Architecture



activities. In contrast to transactions which are viewed as tasks competing for the same re-
sources, the subactivities in this environment are viewed as tasks that have to cooperate to
solve a problem jointly. Furthermore, transactions have a shorter duration when compared
to the activities in this environment which are likely to span over a longer period. As a
consequence, the strict serializability routinely assumed in a DBMS environment is likely
to be too rigid here; a weaker notion than that of strict serializability is likely to be more
appropriate. The above differences are likely to lead to a different set of techniques for
the implementation of an execution manager. The combination of the active and temporal
capabilities will provide the requisite support for the coordination of component activities
among the constituent systems over which they are defined. The only assumption used in
our approach is that the execution manager be able to communicate and exchange data in
some manner with other PSAs that are part of the network. A cooperative activity will
be specified to the execution manager in an intermediate representation form which will be
translated into metadata, operations on metadata, and triggers/alerters on that metadata
as an active database by the problem manager. The active database will be accessible (for
read and write) by all the nodes in the network. Where necessary, the active database will
be used as a globally accessible storage (in fact a persistent blackboard) for posting solutions
to subproblems to have their compatibility checked. The actual execution of an activity
(including coordination and sequencing) will be handled by the execution manager which
will be responsible for information propagation, sequencing, and coordinating subactivities
and atomic activities.

The essence of our approach is that the user can now specify a cooperative activity con-
ceptually in terms of a plan (loosely, a plan can be viewed as a collection of tasks specified
using a directed graph indicating precedence among tasks and temporal constraints for each
task) along with the information required for coordination. The onus of its execution (opti-
mization, management, scheduling, non-interference, as its consistency requirements) is on
the execution manager. The execution manager, in conjunction with the active database
will execute each activity (satisfying its constraints) requesting inputs from appropriate
components (be them passive systems or active agents). Human agents involved in the
problem solving activity will play only a supervisory role in providing their inputs or deci-
sions in contrast to the situation currently used as shown in Figure 3. Note that the above
discussion does not assume that the problem has to be described to the system as a plan
by the end user. It is very likely that there will be a high level specification language which
gets translated to the input proposed above.

It is evident that the near-term approach proposed in Figure 4 is an extension of

the distributed architecture consisting of heterogeneous components with a component for
handling simple forms of CPS. There is a centralized activity scheduler (part of the execution
manager) and a centralized persistent blackboard as part of the active database component.
The active database component also provides for event-based coordination used in this
approach. The only requirement for this approach is that each node in the distributed
network is capable of communicating with the component introduced.

3.2 Long-term (Distributed) Approach

Figure 5 illustrates the next generation of CPS environment. The previous approach es-
sentially had one centralized CPS component which was responsible for coordination of
activities and their tasks among all the agents. Ideally, in a distributed environment,
each component needs to be capable of supporting cooperation which entails including a
CPS component (i.e., an execution manager and the capability manager along with their
data/knowledge bases as a minimum). This requires either extending (and to some extent
overriding the autonomy of the system) the existing components with PSAs that have the
capabilities of the execution manager as shown in Figure 4 or adding a PSA and tightly
coupling them with existing components. Figure 5 shows one PSA that has been enhanced
to include all the CPS system components including an active DBMS. The figure also shows
a document processing PSA that has been tightly coupled with a CPS system as it may
not be possible to enhance a pre-existing system to include all the functionality of a CPS
system. More research is required for this approach to become a reality as a number of
issues pertaining to distributed CPS and heterogeneous Databases need to be addressed.
Also, the autonomy assumption (as in the case of the near-term approach) is no longer valid
and as a consequence, a migration path from existing systems needs to be outlined.

In order for this approach to succeed, new models for long-running activities that are
extensions of traditional transaction models [14] or the ones being developed for heteroge-
neous systems need to be developed [16]. Also, techniques for capturing the information in
the capability database and keeping the information current is equally important.

It is more likely that, in the long-term, we will see a combination of the two types of
systems described above: some pre-existing autonomous systems that do not support the
functionality of an execution manager and some new systems that are developed using the
approach shown in Figure 5. Hence, the long-term solution needs to address merging of the
architectures proposed in Figures 4 and 5. Note also that our proposed approaches have
similarities with centralized multi-agent and distributed multi-agent approaches proposed
by the AI community as well as the work on heterogeneous databases and interoperability

... Problem Posers ....


System coupled
with an active

Figure 5: Distributed and Integrated cooperative problem solving Architecture

issues addressed by the database community.

Finally, a note about the proposed Database-centered approach. Unlike the AI approach
to modeling DCPS [3] in terms of negotiation, functionally accurate structuring, multi-agent
planning etc., we take a more pragmatic (and a bottom-up) approach in terms of defining
and solving the problem with known and viable DBMS and KBMS functionality. The AI
approach is certainly required for the complete solution of the problem whereas our approach
proposes to build working systems for the subclass of problems for which solutions are either
known or are likely to be obtained in the near term; the hope is that this bidirectional search
will not only reduce the time taken for obtaining a complete solution to the problem but
also promote cross-fertilization among AI and database researchers.

The architectures proposed also reflect the bottom-up approach. These architectures (if
they do not include collaborative strategies) assume that the problem is within the scope

of the PSAs. This contrasts with DAI approach wherein it is uncertain whether a given
problem can be solved and whether approximate solutions are acceptable. In the latter there
is uncertainty at all levels namely: problem specification, problem solution procedures, and
achieving the solution. Note that the architecture is extensible in terms of supporting
different requirements of the problems. If there is no PSA that can address a particular
requirement of the problem, then a PSA that is capable of meeting that requirement need
to be added to the CPS environment.

Finally, our approach does not preclude integrating techniques and solutions obtained by
the DAI community. In fact, collaboration strategies (such as negotiation, dynamic agent
modeling) can be incorporated into the distributed approach by enhancing the appropriate
components (such as execution manager and the capability manager, respectively).

4 Architecture

In the previous section we described near- and long-term bottom-up approaches to CPS. We
shall now briefly describe the overall architecture and the functionality of the CPS system.

4.1 CPS Environment Details

In this subsection we elaborate on the architecture proposed in the previous section and
give a brief description of the components. The environment consists of a loosely coupled
network of PSAs. Duplication of functionality among the PSAs is permitted. The goal is to
perform an activity that requires cooperation from a number of agents in the environment.
Figures 6, 7, 8 show the details of the approach shown in Figure 4. The components of
the environment are a set of PSAs, an activity coordinator which coordinates the set of
activities and subactivities generated for each activity, and an active database to store the
information about activities used by the activity coordinator.

We briefly describe some of the concepts and the functionality of the components of a
CPS system:

Problem Solving Agents 4

PSAs perform subactivities (tasks) of an activity. A human can act as a PSA having
a distinct set of roles, responsibilities, constraints, and functions. A PSA, in general,
'Problem solving agent (PSA) is not to be confused with problem statement analyzer developed at
University of Michigan by Teichroew, et al.

consists of resources (programs, accessories, peripherals, communication equipment)
and information (shared data and rules, dictionary, capabilities of itself) required for
solving a task. PSAs are typically static and passive and the specification of their
structure and functionality does not change over long periods of time. Hence, these
PSAs do not evolve but they tend to be replaced. This replacement is done mostly
to improve the functionality and/or the performance of the system.

Each PSA is autonomous in our near approach and may not be able to communicate
directly with other PSAs on the network. Hence they do their tasks independently or
locally, with minimal knowledge about the type of processing done by other PSAs.
They may have very little or no knowledge of the type or functionality of processing
done by the other cooperating PSAs. The activity coordinator acts as the mediator
for exchanging information, progress, partial solutions as well as activating and de-
activating tasks at each PSA. As a minimum, each PSA is assumed to be capable of
exchanging information with the activity coordinator.


Any problem to be solved cooperatively is modeled as an activity. An activity is
a conceptual specification of the problem expressed in terms of capabilities present
in the underlying system. An activity in general consists of a set of subactivities,
with each subactivity being processed by one or more PSAs. subactivities are disjoint
and related, and can be classified into two sets: those which can be completely done
by human PSAs, and those which can be completely done by non-human PSAs. A
subactivity is atomic if it can be done by a single PSA. The activity specification is
expanded until it can be expressed in terms of atomic subactivities.

An activity is likely to be long-lived in contrast to a database transaction which,
typically, has a short duration. To complete an activity, a subset of the resources of
the network is required and more importantly a coordination plan that involves
coordination among the PSAs at either pre-specified points in time (temporal) or
asynchronously (data-flow like) or a combination thereof is required. An activity,
such as the process of assessing a paper for publication in a journal can be expressed
as a directed graph where vertices represent receptor of data for making decisions and
edges correspond to communication and flow of data and control among receptors.
Although an activity may start with a preliminary topology (interconnection of PSAs),
the DAG topology may change during the course of an activity depending upon the
decisions made so far and the availability of resources in the network. This aspect
also differentiates a transaction from a cooperative activity.

Activity Coordinator

The activity coordinator is responsible for the execution of an activity in terms of
its subactivities and orchestrating CPS. A symphony conductor paradigm perhaps
best describes a centralized active coordinator. The activity coordinator has the
glb,,l ,i,,1 I of the type of processing that is supported by each of the PSAs
from the capability database. It also has the processing needs of each activity in
terms of subactivities and the coordination requirements among them. It uses the
active database system to keep track of the progress of an activity and how various
subactivities are scheduled in the network.

The functionality that is required to perform a (sub)activity is mapped to the capa-
bilities of the PSAs using the capability database and a plan is generated. This plan
is the model of the interaction that is required among the PSAs, the subactivities,
and between the activities and the PSAs. This plan defines the protocol that is used
by the activity coordinator in inducing the cooperation among the PSAs. The coor-
dination is carried out by means of events-condition-action rules that are supported
by an active DBMS.

Active database

The specification of subactivities and their interactions determines the structure of
the active database in order to support the plan for managing and executing the
set of activities in the environment. An active database system supports rules that
are formed by events, conditions, and actions. A condition is evaluated when the
associated event happens and if the condition evaluates to true then appropriate
action is taken. This simple mechanism has been shown to support a number of
database functionality in an elegant way [9]. The system is responsible for monitoring
the state of the database and detecting events specified to it. An active database
has the capability of monitoring temporal events as well (in addition to database
and external events [5]) and initiating a set of actions. The plan defines the set of
situations that can arise while processing a set of activities and the set of actions
that need to be taken as a result of those situations. These situations and actions are
modeled in terms of the available functionality of an active database. The capability
database is used to store the knowledge regarding the extensional and intensional
data of the PSAs and environment. Hence a methodology for implementing an active
database using design tools seems important [26, 31]. The role of the active database
is extremely critical to CPS. Without it, this functionality needs to be incorporated
into the activity coordinator, thereby unnecessarily increasing the complexity of the

---> Event Flow
<.--.> Action Flow
SData & Control Flow

Figure 6: Architecture of a cooperative problem solving system

activity coordinator.

Part of the extensional data stored in the active database can be viewed as a persistent
blackboard used for exchanging information (including data, goal, and partial result
sharing) between PSAs and synchronizing the execution of the plan generated for an
activity. A centralized blackboard is used in the near-term approach whereas it is
distributed in the long-term approach. Although blackboards that are used as scratch
pads have been extensively studied in the AI literature[18], monitoring what is posted
to persistent blackboard in an asynchronous manner is novel to our approach.

4.2 Functionality of the CPS System

The main functionality of the CPS system that need to be supported are: Activity specifi-
cation, A,. ol modeling (i.e., populating the capability database) and Activity riuirq iinrt
(i.e., sequencing, synchronization, scheduling etc.). Each of the above is supported by a
functional module in the architecture. The architecture shown in Figure 6 has three in-

terconnected modules namely, a Problem Manager, a Capability Manager and an
Execution Manager. A problem poser is either an agent or a system that has a prob-
lem to be solved by the CPS system. The role of the problem manager is to accept an
activity specification from the problem posers and transform it into a set of schedulable
subactivities, an active database schema and parts of its extensional data and a set of ECA
rules. The problem manager interfaces with the problem posers. The Capability Manager
interacts with the PSAs to maintain the capability database up-to-date. The Execution
Manager interacts with the PSAs by monitoring the blackboard (one is created for each
activity) and initiating actions to coordinate the subactivities being executed.

Problem manager consists of the problem specifier, a module that interacts with the
problem posers, to take as input the specification of a problem. This specification is pro-
cessed by the problem decomposer to generate a set of subactivities. Match maker is a module
that takes sub-problems, identifies the capabilities required to solve each sub-problem, and
queries the capability database to identify the PSAs that can solve these sub-problems.
It then produces an annotated set of subactivities, where in each subactivity is annotated
with the PSA that has the capability to solve it. This set of annotated subactivities are
processed by the activity generator to generate the intermediate representation of the sub-
activities (as a DAG, state machine, Petri net, PERT diagrams etc.), a schema for active
database to manage the run time data, a set of ECA rules to coordinate and schedule the
activity. Components of the problem manager are shown in Figure 7.

The schema for active database and the ECA rules are stored in the active database
system (which can also be used as a system catalog). The active database extension (and
the blackboard as a shared global storage for the centralized case) corresponding to each
activity is created and is populated by the execution manager while the subactivities are
being executed. The execution manager, based on the progress of the activities currently
being executed, may pose additional problems (actually a subactivity produced by the
decomposer may be decomposed further recursively) to the CPS system. This is done to
generate subactivities in case of a failure of a PSA or at the request of a PSA that has
knowledge to determine how this problem is to be solved. An example of this is the case
when one of the PSAs is itself a CPS system.

Capability manager manages the capability database of the PSAs. The capabilities
of the PSAs are modeled before the capability database is created and populated. This is
because of the complexity of interrelationships within the PSAs, between capabilities and
the PSAs, and across the levels of abstraction among capabilities, and among PSAs. The
problem of deriving the logical model of the capability database, except for simple cases, is

I Data & Control Flow

To/ Activity coordinator From Man
From Active database System

Execution Capability
Manager 1 Manager


Figure 7: Modules of problem manager

Activity Generator

Figure 8: Modules of Capability Manager and Execution Manager

non-trivial. The capability DBMS provides the necessary interface for the match maker and
the execution manager to query its databases. Figure 8 illustrates the capability manager
and its interface with other modules.

Execution manager is a key module of the CPS environment. It has an activity-event
coordinator (henceforth referred to as activity coordinator) which is a layer on top of the
active database manager. The activity coordinator traverses the specification of the activity,
and assigns tasks to the corresponding PSAs as actions to be done. The PSAs coordinate
with the activity coordinator by changing the active database, which generates the events
that initiate further actions to solve/monitor the problem. It is the responsibility of the
execution manager to monitor the progress of the tasks of the activities as they are being
executed by the PSAs. Due to failures or time constraints the execution manager may

---> Event Flow
....-> Action Flow
a Data & Control Flow

query the capability database to select additional PSA for the task or to replace a PSA.
Currently, Sentinel -an object-oriented active DBMS [1, 7] is being enhanced to support

4.3 Faculty-Search Example

In this subsection, we describe a typical problem (of faculty-search) with which most of us
are familiar and use it as a running example for the next two sections. This problem is
representative of CPS (although not computationally intensive). Informally, the problem
can be stated as follows:

1. determine the areas where faculty is needed (decision + consensus development),

2. advertise the positionss,

3. wait for the deadline,

4. evaluate the candidates, ask for references, and rank the candidates after all the input
has been received and processed,

5. schedule the interviews (may be using an automated tool).

This example also brings out another important aspect of CPS activities. They may be
open ended or arbitrarily long activities. Faculty-search process will continue each year as
long as there is a need for new faculty and information from one or more previous years
is likely to be carried over to the current year. This aspect is unlike query or transaction
processing which terminates in a finite amount of time. As a consequence, consistency,
concurrency, and possibly recovery aspects need to be reevaluated in the context of CPS.

The above problem involves a set of people (e.g., search committee, the department
Chairman), information pertaining to candidates, evaluation of each candidate by a group
of people, and rules (or knowledge) governing the hiring, travel reimbursements etc. Assum-
ing that each person can communicate with others on a network of machines (in addition
to other forms of communication) including special purpose hardware and software (e.g.,
electronic teleconferencing) and that the relevant knowledge (or rules) useful for this prob-
lem is stored in the knowledge base of the activity coordinator, we can map the problem as
an activity comprising the people involved, the systems/tools involved, and the sequencing
or partial ordering of subactivities (which makes up an activity) and atomic activities (ac-
tivities solved either by a system or a human as an atomic task) that need to be executed.

Based on the description of an activity, metadata required for the execution of that activity
will be determined and triggers and alerters on metadata will be established. For example,
the specification of an activity may be in terms of an activity DAG whose nodes indicate
either an activity, subactivity, or an atomic activity. A node may either represent a system
or computation or a role. A set of rules and triggers may also be associated with a node to
perform computation and/or data/control propagation. Edges of the DAG may be labeled
with constraints (e.g., a limit on travel reimbursements that eliminates calling applicants
from overseas). There may be some aggregation condition specified at a node when there
is more than one edge incident on it (e.g., to get majority votes).

It is perhaps true that processes such as faculty search will never get completely au-
tomated. However, real world abounds in such complex decision making scenarios. We
wish to use such illustrative scenarios as targets of cooperation so as to achieve maximum
functionality for supporting cooperation.

The above scenario also highlights the inherent limitations of the kind of cooperation
possible once the underlying systems/components to be used are specified. For example,
in the absence of an electronic teleconferencing capability, cooperation will, at best, be in
the form of support for exchanging messages and making decisions, but will never achieve
face-to-face communication.

From the above, we can formulate the problem at the conceptual level as:

1. Modeling of an activity in terms of its characteristics to a level of detail that is
amenable to automation.

2. Supporting the management and execution of one or more concurrent cooperating
activities in a consistent manner.

5 Modeling CPS Environment Components

The CPS environment consists of a set of PSAs, and a number of problem managers, ca-
pability managers and execution managers. The number of CPS systems and how they
are added to the environment depends upon whether the environment is a centralized or
a distributed one. Further, in the distributed environment, either a pre-existing system is
enhanced to include the CPS system (typical for a pre-existing DBMS) or a CPS system
can be tightly coupled to the pre-existing system (typically used for non-DBMS PSAs).
The capability manager needs to capture the functionality of the PSAs in the environment

in order to facilitate decomposition, assignment, and execution of activities submitted to
the system. This entails capturing both the intensional and the extensional data about
the components of the environment using an appropriate model. Modeling of the compo-
nents enhances the understanding of the environment as well as provides a basis for formal
specification. In the CPS environment we have three types of components that need to be

Problem solving agents

The types of information to be modeled about a problem solving agent are:

1. Role: A PSA can play many roles, and a set of PSAs may support a single
role. This role of the PSA may have a set of constraints associated with it. For
example, the same PSA may play the roles of a file server, a DBMS, an expert
system etc. in different contexts. The roles of a document processing system
may include being a work-station, a laser printer and text formatting software.
A constraint on an expert system may be that it supports only forward chaining.

2. Capability: The set of functions that the PSA can support. The capability of
the PSA is defined on the role. As an example, a capability of a laser printer
specifies whether it can print postscript files and that of text formatting system is
whether it can include figures within the text. As another example, a capability
of a Manager lists the decisions that he/she can take without approval from
his/her supervisors.

3. Constraints: The set of constraints which cover the PSA with a temporal or
non-temporal boundary in which it can take any particular role. Only under the
satisfaction of these set of constraints can the PSA undertake a given role. A
constraint on a laser printer is that it can be accesses from 7AM to 5PM and
that only people above a certain designation can use it without the page limit
coming into effect.

4. Procedural knowledge specifies how a PSA supports the set of functions defin-
ing its capability. This is essential for mapping of activities to a PSA. For exam-
ple, the procedural knowledge about an electronic mail server could be that it
uses CSNET for sending mail. This means activities which need to communicate
in confidence may not use this PSA as it is not secure enough. The procedural
knowledge may be modeled as a set of rules. The procedural knowledge gathered
may be incomplete.

5. Attributes of a PSA (location, name, identification, etc,.). This information
can be used to determine the set of currently available PSAs in the CPS system.

6. Cooperative relationships the PSA has with other PSAs. The relationship
information can model the direct interaction between various systems. For ex-
ample, the ability of a CNC machine to interface with a PC is modeled by means
of a cooperative relationship. These relationships can be at the instance level
(between a specific PC and a specific CNC machine) or at entity or class level (to
model interdependencies between two groups,such as, sales and software support
in an organization).

For the faculty search example described in Section 4, one of the systems in the envi-
ronment may be a DBMS managing the candidate database. The role of this system
will be "DBMS", capability will be "managing data about candidates", procedural
knowledge being that the DBMS is "Relational with SQL and SQL embedded within
'C' as user interface". The attributes may say that it is on the SUN work station lo-
cated in the computer science main office. The constraints may be that the database
can be accessed by only those authorized by the faculty search committee.


Types of information to be modeled regarding activities are:

1. Tasks: An activity consists of a set of tasks that need to be executed on behalf
of that activity. Each of these tasks require some functionality to be provided
by the underlying PSA. These tasks are defined by the subactivities.

2. Relationships: An activity is a graph of subactivities, which is modeled in
terms of the relationships among the subactivities. This brings about the non-
sequential nature of the relationship among the subactivities. This means that
the traditional hierarchical or tree based structures are not sufficient to model
activities. A DAG is one representation for modeling activities, where each node
of the DAG is a subactivity and each edge in the DAG denotes the relation-
ship between the subactivities. Note that the subactivities themselves may be
considered as activities and can be represented by a DAG.

3. Constraints: A set of constraints will bind the activity definition. The con-
straints need to be modeled and specified in detail as the activity coordinator
uses this information in scheduling the subactivities to be done in the environ-

4. Attributes: The activities have the set of attributes that describe it. These
attributes are name, identifier, classification, start time, expected finish time,

Again refer to the faculty search example. "Scheduling the interviews of the candi-
dates" is an activity. The set of tasks for this activity are:

1. Find the name and addresses of the candidates.

2. Come up with the dates on which the candidates are to be interviewed.

3. Communicate the dates to the candidates.

4. Schedule the interviews of the candidates based on their feed back.

5. Arrange a faculty member as a host for each of the candidates on the interview

A constraint for the above set of subactivities is that the date of the interview should
not be a public holiday. There is a relationship between subactivity 2 and 5, in that
the faculty member who is a host must be "in town" on the date of the interview
and his research interest area must match that of a candidate. The "match" may be
determined by some heuristics.

Active Database

Types of information to be modeled in the active database are:

1. Active database schema: The activity generator after processing the anno-
tated set of activities needs to generate the schema of the active database that
supports its execution. This schema has to be transformed into a logical model
to be created and populated on an active database system. For some routine
activities the activity generator directly generates the logical model of the active
database that is created and populated.

2. Situations: The pair consisting of an event and a condition is termed a situation.
The events are communication agents used by the systems to inform the progress
in processing the subactivities. Synchronization of subactivities are modeled
using event-condition-action or ECA rules. Database, temporal, and external
events are supported by an active database. The specification of the situations
is done by the activity generator and is stored in activity/event database.

3. Actions: The actions are the set of instructions given to the activity/event
coordinator by the active database based on the occurrence of events. In general,

an occurrence of an event is followed by checking of a set of conditions before
initiating a set of actions. Hence occurrence of situations initiates actions. The
specification of the actions is done by the activity generator and is stored in
activity/event database. A subactivity itself can be formulated as an action of
an ECA rule in which case it will be scheduled when the appropriate event occurs
and the condition evaluates to true. The condition may check for the completion
of other subactivities. Complex events proposed in Snoop [8] can also be used
for synchronization of subactivities.

Refer to the faculty search example. We find that the subactivities 1 an d 2 are inde-
pendent and can be processed concurrently, the subactivity 3 waits for the completion
of subactivities 1 and 2. Hence the subactivities 1 and 2 generate an event after their
completion and the activity manager waits for these events before triggering the ac-
tion to initiate subactivity 3. Thus we have illustrated by means of a simple example
the role of active database in managing events and triggers.

6 Execution of Activities

An activity is processed by a set of PSAs in the CPS environment. An activity consists
of a number of subactivities, with each subactivity to be processed by one or more PSAs.
Coordinating these subactivities is the job of the activity coordinator. Each of these PSAs
processing the subactivities interact with the activity coordinator. The type of interaction
required from the PSAs towards the activity coordinator is:

1. Wait for the request from the activity coordinator to process the subactivity.

2. Process the subactivity.

3. Report the state of processing at periodic intervals or by generating interrupts to the
activity coordinator.

4. After the processing is done, report the result of the processing (i.e success or failure
or some information) to the activity coordinator.

In the centralized (or near-term) architecture, the PSAs may not have capability to
interacting with each other. As a consequence, they process the subactivities independently
or locally, without any knowledge about the type of processing done by other PSAs. They
do not have any knowledge of the type or functionality of processing done by the other

cooperating PSAs. The maximum amount of implicit cooperation among the PSAs that
can be assumed is that the PSAs can exchange information. Even for this, a module may
be needed to transfer data from one PSA to another.

The activity coordinator has the Y/ibl,, ,i,,. 1.1,,-i, /', of the type of processing that is
supported by each of the PSAs. It also knows the processing that needs to be done as a part
of an activity. It matches the computation requirements of an activity with the capabilities
of PSAs and generates a coordination plan.

By a plan we mean that the given activity is done by a set of PSAs which need to
coordinate and cooperate among themselves. This plan consists of the following:

1. The set of PSAs involved in performing the activity.

2. The list of subactivities that need to be done.

3. The mapping between the subactivities and the PSAs. That is, which PSAs do which

4. Coordination information which ties these subactivities according to a schedule. The
coordination information includes both the information flow and the processing that
is done by each of the PSAs participating in performing the activity.

5. A set of events or interrupts that are used by the activity coordinator, and that are
generated by the PSAs, so that the activity coordinator gets to know about the status
of processing on the subactivities by the PSAs.

6. Provision for error recovery and exceptional condition processing.

The plan is generated by the activity coordinator, with the support of problem manager
and capability manager. The CPS system solves the problem as follows:

1. analyzes the activity specification and checks if it can be done within the framework
of the current set of PSAs.(Problem Decomposer).

2. breaks up the activity into a set of subactivities. The criterion for breaking up the
activity is that, each of the subactivities can be supported by one PSA. That is, the
subactivities are matched to the I, -I" alternative PSA that can process it.(Problem

3. generates the plan with the set of subactivities. It generates this schedule by taking
into consideration the time frame in which the activity needs to be done. For example,
depending upon the urgency of the activity, it may generate an entirely different
plan.(Activity Generator and Match Maker).

4. classifies the set of subactivities based on their i'p.i" tance" or "criticality" into a
critical and a non-critical set.(Activity Coordinator with Capability Manager).

5. generates the set of events and interrupt mechanisms that are needed to control and
gauge the status of the activity at any point of time. This is required to answer the
user's queries about the activities.(Activity Generator).

6. acts as a communicating agent reporting the status of each of the subactivities. (Ac-
tivity Coordinator).

7. coordinates the subactivities by explicitly inducing cooperation among the PSAs
performing the subactivities. This is done by using the support provided by the
active database. This database has the capability of storing the events or interrupts
and advising the activity coordinator in initiating the subactivities when required.
(Activity Coordinator).

8. monitors the PSAs performing the activity by monitoring the state of the active
database. The active database stores the information about the events and interrupts
used by the activity coordinator and the PSAs while communicating. Hence the status
of the activity can be gauged by looking at the history of the events generated by the
PSAs processing the activity. (Activity Coordinator).

With respect to the faculty search example from the Section 4.2 and the subactivities
listed, the plan for the activity -, I l. the interviews of candidates" is as follows:

1. Use "Candidate Database" and get the list of candidates called for interviews.

2. Use the "calendar management system" to list the dates when the Chairperson of the
department and the faculty members of the faculty search committee are in office.

3. Wait for the above two activities to be done.

4. Use electronic mail and send a letter to the candidates suggesting the date of the
interview. If candidate has no electronic mail, generate a message to department
secretary to contact candidate and input information. Otherwise ask the secretary

to use systems to -ii-:: -I alternatives. Request them to acknowledge the date of

5. Wait for the candidate's acknowledgments, and if there are any changes requested,
-i.- -. 1 them new dates and go to above step, if there are no more changes then go
to next step.

The subactivities 4 and 5 can be done by either human or non-human agents or by a
combination of both.

6. Match the interests of each of the candidates with the interests of the faculty members,
and allot the faculty member with the best fit as the host for the candidate (if the
faculty member is in town, else allot the next to best fit faculty member). Note that
this subactivity is done by a human agent.

The role of the active database is very critical in a CPS environment. Without it, this
functionality needs to be incorporated into the activity coordinator, thereby unnecessarily
increasing the complexity of the execution manager.

7 Illustrative Examples

In this section we present some examples that illustrate the classes of problems along the
spectrum shown in Figure 2, which are representative of CPS applications.

To illustrate our approach, we use the following syntactic constructs than plain narrative
explanations which are intended to make the presentation of examples compact. For the
sake of simplicity, we do not present any graphical representation of the schema constructs,
although we have worked on extensions to the Entity-Relationship model with event-rule
networks [32] to capture the behavioral aspects along with the data components of the
system. Any modeling technique capable of representing situation/action behavior could
be used as well.

A situation/action behavior is defined as a sentence of the form

::= : when

where ::={ }+

'Here we have non-sequential nature of the activity in scheduling the interviews of all the candidates

::= : [ alternative to
[ if ]
[ raise

The informal interpretation of this definition is quite simple: when the event> is detected, the rules in the are fired, which means that each
is evaluated and, if it evaluates to true, then the corresponding is performed. A
situation is characterized by the occurrence of a triggering event and the conditions that
hold after the detection of the triggering event.

The events that are relevant for CPS include database events (insertion, deletion, mod-
ification, retrieval), temporal events (at a given time, or a time unit after a specific event)
or external events, such as i. I, the faculty-candidate replies". Complex events that are
constructed from the above primitive events and operators are also useful [8]. We do not
illustrate the applicability of complex events in the examples presented in this paper. It is
easy to see how they can be used to manage concurrent sub-activities.

In the rule definition, the alternative to clause is used to specify groups of alternative
rules only one of which is to be executed, and the raise clause specifies the set of events that
result from the execution of the rule. Conditions are predicates resultant from a database
query; absence of a condition signifies that the action should be unconditionally executed.
Actions are sequences of commands that can be database operations, i.e., operations to be
performed on data objects and their attributes, or external (user defined) processes.

In general, one can specify global constraints of any complex environment by using the
given approach. The idea of using situation/action behavior with rule lists waiting for the
occurrence of the triggering event is particularly suitable to applications in which active
capability of the database is required. These include organizational computing systems in
which a set of policies must be enforced automatically whenever relevant changes of the
state of the organization occur, and battle management systems in which a situation study
is carried out every time a relevant event occurs such as a movement of the enemy or the
destruction of a strategic facility.

Here we present simple examples to illustrate our approach in two application envi-
ronments, in which the kind of dynamics captured by situation-action behavior is crucial:
process control systems and office information systems.

7.1 Process Control Systems

We start with the left end of the problem spectrum, which is characterized by precisely
defined, data/system intensive, forced cooperation. A flexible manufacturing system (FMS)
is a classical example of such a process control system. An FMS consists of a plant with
a set of machines interconnected by a palletized transportation system, a set of tools, and
a set of tool carriers. The machines may vary from single-purpose machines that use few
tools to multi-purpose machines such as machine centers that require a large set of tools.
The tools are shared among the machines, and are initially placed in a central warehouse
from where they are carried by the tool carriers to the machines and vice-versa. The tool
carriers are programmable carts with the ability of transporting tools throughout the plant.
The system operates the plant by assigning operations to machines, and by routing and
mounting proper tools. Special conveyor routes the parts from machine to machine.

We consider here only the aspect of an FMS that concerns the management of tools
shared among the machines. Machines, tools and tool carriers are the PSAs whose capabil-
ities are precisely specified to the system. It is assumed that each machine has input and
output buffers to reduce the waiting time for tool change; therefore, a machine can request
tools in advance up to the capacity of its buffers. The status of machines, tools, and carriers
can be either "idle" or "in use", and the origin and destination of carry operations may be
the tools-warehouse or machines.

The operation of the FMS is specified through an overall activity that defines the in-
teraction between the collaborating PSAs. The following set of situation/action behaviors
governs the coordination and management of machines, tools, and tool carriers, and are
specified to the active database. An ER schema with the relevant entity sets (.I.\CHINE,
CARRIER, TOOL), relationships CARRY (between CARRIER and TOOL), USE (between
MACHINE and TOOL), and their attributes is assumed.

Machine_operation :
when MACHINE.status updated or MACHINE.in-buffer updated
fire { R1 }
R1 : if MACHINE.status is "idle" and there is a tool in MACHINE.in-buffer
then Change MACHINE.status to "in-use";
remove tool from MACHINE.in-buffer; request-next-tool
raise MACHINE.status updated, MACHINE.in-buffer updated, next-tool-requested

Carryforward :

when Next-tool-requested by MACHINE
fire { R2 }
R2 : if TOOL.status is "idle" and there exists an idle tool carrier
then Change TOOL.status to "in-use"; change CARRIER.status to "in use";
insert a CARRY relationship for CARRIER and TOOL;
insert a USE relationship for MACHINE and TOOL
raise TOOL.status updated, CARRIER.status updated, CARRY inserted,
USE inserted

Tool_release :
when MACHINE operation with TOOL completed
fire { R3 }
R3 : then Change MACHINE.status to "idle"; add TOOL to MACHINE.out-buffer;
remove USE relationship for MACHINE and TOOL;
change TOOL.status to "idle"
raise MACHINE.status updated, MACHINE.out-buffer updated, USE deleted,
TOOL.status updated

Carry_back :
when MACHINE.out-buffer updated or CARRIER.status updated
fire { R4 }
R4 : if There is a TOOL in MACHINE.out-buffer and there exists an idle CARRIER
then Remove TOOL from MACHINE.out-buffer;
change CARRIER.status to "in-use";
insert a CARRY relationship for CARRIER and TOOL
raise MACHINE.out-buffer updated, CARRIER.status updated, CARRY inserted

Carriersrelease :
when Carry operation completed for CARRIER and TOOL
fire { R5 }
R5: then Remove CARRY relationship for CARRIER and TOOL;
change CARRIER.status to "idle"
raise CARRIER.status updated, CARRY deleted

This example illustrates a tightly coupled cooperative environment in which the situ-
ation/action behaviors captured by the rules are highly interdependent. There are many

common events that interconnect the different situation/action behaviors. Concurrency is
possible, but in a controlled way, i.e. the synchronization dependencies restrict the degree
of concurrency. A graphical representation of the execution model is useful as a design
analysis tool, allowing the designer to trade off between the enforcement of the constraints
implied by the rules and the degree of concurrency. Any graphical representation of this
example is likely to be densely connected.

7.2 Office Information Systems

Now we move towards the right in the problem spectrum, and illustrate a less precisely
defined application, with more knowledge/cognitive intensive cooperation than the previous
example, using an office information system. Automation of office work falls in the category
of programmable work, where the events are predictable and the responses are known.

Active capability is critical for a database approach to CPS, particularly in office and
decision support systems, due to their special characteristics such as semantic richness, time
factor, office constraints and evolution, priority scheduling and reminders, to name a few.

In this example, we model the graduate admission process as seen by an admissions
office in a university environment. Again, an ER schema is assumed with entity sets
MENT), and ADVISES (between FACULTY and STUDENT). Relevant attributes of enti-
ties and relationships are also assumed.

In this problem there are several PSAs involved in collectively deciding whether an ap-
plicant should be admitted to the graduate school or not. There is the graduate admissions
office which is the initial contact point which processes the application according to a set of
university wide constraints; one or more departments and their graduate offices for process-
ing applications and using departmental criteria for selecting the candidates; the graduate
coordinator, and the graduate admissions committee.

The graduate admission proceeds as follows. Each time a new application or new doc-
uments about an existing candidate are inserted into the database, the documents are
examined. If they are incomplete, a message requesting additional documents is sent to the
candidate and a due date is established. If the list of documents is complete, a review pro-
cess is created between the department's graduate coordinator and the candidate; the status
of the review is set initially to 1. -I.,,g" and a due date is established for the decision.
When the graduate coordinator returns a decision, the status of the review is changed, and

a letter is sent to the candidate informing whether the application was accepted or not. If
the candidate has been accepted, a new student record is created, and the candidate record
is deleted.

A timeout mechanism monitors the due dates. When the due date for additional doc-
uments expires, if the status of the documents is still incomplete, the candidate record
is deleted from the database. When the due date for the graduate coordinator's decision
expires, a reminder (message) is sent and a new due date is established.

The above procedure is modeled by the following set of behavioral sentences, that be-
comes part of the active database schema:

Documents_checking :
when CANDIDATE inserted OR CANDIDATE.documents updated
fire { R1, R2 }
R1 : if documents-status is .i ..ipl. t,"
then insert REVIEW for the graduate coordinator of the intended department,
with initial status 1. I.li"g", and establish a due-date for reviewing
raise REVIEW inserted
R2 : alternative to R1
if documents status is "incomplete"
then request additional documents, establish a due-date
raise additional documents requested, CANDIDATE.due-date updated

Additional_documents_due_date :
when Timeout(CANDIDATE.due-date)
fire { R3 }
R3 : if documents-status is "incomplete"
then delete CANDIDATE record
raise CANDIDATE deleted

Review_completion :
when REVIEW.status updated
fire { R4, R5 }
R4 : if status is "rejected"
then inform the candidate
R5 : alternative to R4
if status is ..... 1 4 "

then inform the candidate, delete CANDIDATE record, insert new STUDENT
raise CANDIDATE deleted, STUDENT inserted

Review_due_date :
when Timeout(REVIEW.due-date)
fire { R6 }
R6 : if review-status is 1'" ,n.ig"
then establish new due-date, remind graduate coordinator
raise REVIEW.due-date updated, graduate coordinator reminded

The fact that the situation/action behaviors in this example are highly disconnected (only
one event is a common output event of two rules) reveals the high degree of independence
among the rules. While this fact means that most of the subactivities by the PSAs can be
done concurrently, it may also indicate a poor design in which most of the data dependencies
are not captured, leading to a very loosely coupled solution. In such situations, a graphical
representation of the execution model may also be useful as a tool for design analysis.

This example has been overly simplified in order to bring out only important aspects of
CPS activities that were discussed in this paper. Other aspects that are important from
the application viewpoint (for example, any faculty can recommend a particular candidate
for admission and assistantship at any point, special cases where conditional admissions are
given, etc.) are ignored. Like the faculty search example, this also illustrates the fact that
activities may be open ended or take arbitrarily long time. Graduate admission process will
continue each term and information from one or more previous terms is likely to be carried
over to the current term.

The above scenario assumes that each PSA can communicate with other PSAs on a
network of machines (in addition to other forms of communication) and that the relevant
behavioral aspects useful for this problem are stored in the active database. We can specify
this problem using the notion of activities which are decomposed into subactivities and
atomic activities (activities solved by a PSA as an atomic task) and coordination among the
subactivities. As seen by a single department, the graduate admission process constitutes
only one of the activities going on within the department. Other activities such as those in
the faculty search example, student course drop/adds, new course introduction, introducing
new research grants, scheduling visitor and meetings, ordering equipment, etc. may be
concurrently in progress. The activity coordinator has to deal with the whole gamut of
activities at any given point of time.

7.3 Difficult Problems

As we move along the spectrum to the right end, we find problems that are less precisely
defined and require more knowledge/cognition intensive cooperation in their solution.

As an example, although the faculty-search problem mentioned in Section 4.2, is an
instance of decision support systems, it is less precisely defined than the graduate admission
example. Therefore, it requires more knowledge in the form of enhanced capability of the
PSAs or more human intervention for the solution.

There is a region in the spectrum where the problem definition is imprecise and as a re-
sult requires substantial extensions to the approach presented in this paper. In this region
the system must be able to tolerate and cope with incomplete and incorrect information
from PSAs, capability database, and as a consequence match-making may have to be based
on heuristics allowing backtr,. 1:; .-. also, it is not possible to generate situation/action rules
as well as the schema information statically in this case. The rules have to be changed dy-
namically as more information becomes available about the progress made on the problem.
Nevertheless, the underlying ability of an active database to support event-based interaction
will still be useful. In general, these classes of problems involve too many ambiguities and
uncertainties, and may require utility theory and psychology of choice (e.g. preferences,
heuristics, biases). Completely automated solutions to some problems, such as the jury
selection process, may be out of the scope of our approach for a while to come.

8 Open Issues

In this section, we briefly enumerate and describe some of the open problems:

Agent modeling

This is one of the most difficult problems in the context of CPS. Ideally, both the
cognitive and the procedural capabilities of a PSA need to be modeled. Because of
the complexity of the problem, the functionality provided by a database is likely to
be insufficient to capture the details of PSA.

Consider a senior manager of an organization. The manager is related with his/her
colleagues according to one schema, his superiors according to another schema, his
juniors according to a third schema. Moreover, if this manager has different roles then
for each such role we have at least three more schemas. Already there is an explosion
of the number of interrelationships a PSA is involved with. Similar situations to a

lesser extent arise when a PSA is a complex system (say a CNC machine on a factory

Activity management

Although we have identified the modules involved in managing an activity and de-
scribed their functionality, we have not presented details regarding how problem de-
composition, match making and activity generation are done. The problem decompo-
sition is based on the problem specification (which is done by specifying the capabilities
required to solve the problem) and then querying the capability database to decom-
pose the problem so that each sub-problem can be solved by a class of PSAs having
appropriate capability. This may require defining equivalent classes of PSAs based on
"similar problem solving capability". A PSA can have many capabilities and hence
can belong to many equivalent classes. Ideally any PSA from the equivalent class can
be used to solve a problem requiring the capability of that class. This allows us to
keep the problem under control and use this technique in replacing the PSAs during
execution of the problem due to failures and for meeting time-constraints.

Match making

The match making proposed in this paper is purely syntactic in nature. In order to
structure the process of match making, the match maker needs to query the capability
database for the list of PSAs and generate the annotated set of activities. The match
maker needs to rank the PSAs based on their availability and constraints on their
functionality. This problem is not trivial as it involves generation of queries to the
capability database, processing its output and annotating the activities with PSAs.
Further a confidence measure can be provided as part of the capability information in
which case the match maker has to use that information judiciously when assigning
tasks to PSAs.

Activity generation

The activity generator has to process annotated activities, consult the capability
database, generate the intermediate representation of activity and the plan as well
as the schema for the active database along with the situation/action rules. This pro-
cess needs to be automated. This would have to be done by syntactically processing
the annotated activity specification. This is yet another problem whose solution is
(though with in the scope of the currently available techniques) laborious and would
require clear understanding of the problem domain.

Distributed Architecture issues

There are number of architectural issues that remain to be addressed. These deal
with multiple CPS systems where capability database may be distributed, distributed
execution of the activities, management and coordination of the distributed activity
execution, comparison of types of architectures for domain specific problems, perfor-
mance studies at both quality of the solution provided by the system, and the actual
performance in terms of the time saved by the users in solving the problem.

Our aim in outlining the above is to encourage further research on some of the challenging
issues that have come out of our preliminary work on this interesting problem. It needs to
be emphasized that any approach to CPS needs to relate problems with the capabilities of
available PSAs. Often we do this unconsciously without even realizing it. The essence of
CPS is in relating the problem to the capabilities of the PSAs irrespective of the approach
taken to solve the problem. This is particularly true to the precisely defined problems.

9 Conclusions

In this paper, we have: i) analyzed the requirements of CPS, ii) classified the problem
along different dimensions, iii) identified the enabling technologies, and iv) proposed near-
as well as long-term architectures. We have argued that a bottom-up approach has distinct
advantages and in addition facilitates immediate transfer of techniques developed using the
top-down approach (by the AI community). In the process of developing the architectures,
we have shown how the current Database technology can be leveraged for providing systems
support for a new class of problems. We have proposed the notion of an activity as an
underlying mechanism for modeling the problem specification and a plan derived from an
activity as the script for executing problems that require cooperation. Finally, we have
indicated how an agent can be modeled in the context of the approach proposed in this

We have proposed two architectures for CPS -one near term and one long term
taking into consideration the feasibility and viability of the currently available technology.
For a Database supported CPS system, we have presented the functional components,
interactions among the components, and interactions between the components and the
rest of the system. We have described our approach for executing an activity by means
of a plan which is dynamically scheduled by the activity coordinator. We have illustrated
the salient features of our approach by means of application scenarios. Currently, we are
developing methodologies for modeling, languages for logical specification, and algorithms
for executing activities using the approach presented in this paper.

We hope that we have accomplished, through this paper, our primary objective of stim-
ulating novel ways of approaching a problem. In the long-run, we strongly feel that a
synthesis of seemingly disparate mature technologies will be useful for a number of prob-
lems as demonstrated in this paper.

Finally, in this paper, we have tried to contrast the approach taken by the DAI com-
munity with that of the approach typically taken by the Database community. Most im-
portantly, we hope we provide a perspective that is beneficial to both the communities
and one that helps foster cross fertilization of ideas and techniques leading to horticultural
approaches to cooperative problem solving.


[1] E. Anwar. Supporting complex events and rules in an oodbms: A seamless ap-
proach. Master's thesis, Database Systems R&D Center, CIS Department, University
of Florida, E470-CSE, Gainesville, FL 32611, November 1992.

[2] G. Ariav. A temporally oriented data model. AC I1 Transactions on database Systems,
11(4), 1','

[3] A. Barr, P.R. Cohen, and E.A. Feigenbaum. The Handbook of A, l', '",l Intelligence,
vol.IV. Addison-Wesley, 1','I

[4] A.H. Bond and L. Gasser. Readings in Distributed A l'p, '",l Intelligence. Morgan
Kaufmann, 1''"

[5] S. Chakravarthy et al. HiPAC: A Research Project in Active, Time-Constrained
Database Management, Final Report. Technical Report XAIT-89-02, Xerox Advanced
Information Technology, Cambridge, MA, Aug. 1','-

[6] S. Chakravarthy and S. Garg. Extended relational algebra (era): for optimizing situa-
tions in active databases. Technical Report UF-CIS TR-91-24, Database Systems R&D
Center, CIS Department, University of Florida, E470-CSE, Gainesville, FL 32611, Nov.

[7] S. Chakravarthy, E. Hanson, and S.Y.W. Su. Active Database Research at the Univer-
sity of Florida. To appear in IEEE Quarterly Bulletin on Data E,-i,',, '",.I January

[8] S. Chakravarthy and D. Mishra. An event specification language (snoop) for active
databases and its detection. Technical Report UF-CIS TR-91-23, Database Systems

R&D Center, CIS Department, University of Florida, E470-CSE, Gainesville, FL 32611,
Sep. 1991.

[9] U. S. Chakravarthy. Rule management and Evaluation: An Active DBMS Perspective.
Special issue of AC I! Sigmod Record on rule processing in databases, 18(3):20-28,
September 1'i'i

[10] U. S. Chakravarthy and S. Nesson. Making an Object-Oriented DBMS Active: Design,
Implementation and Evaluation of a Prototype. In Proceedings International Confer-
ence on Extended Data Base Technology, pages 482 Il0,' April 1990.

[11] J. Clifford and D.S. Warren. Formal semantics for time in databases. AC I/ Transac-
tions on Database Systems, 6(2), 1I',.;

[12] M. Darnovsky and J. Bowman. TRANSACT-SQL USER'S GUIDE. Document 3231-
2.1, Sybase Inc., 1'I" .

[13] U. Dayal. Active Database Management Systems. In Proceedings ",I1 International
Conference on Data and Knowledge Bases Jerusalem, Israel, June 1''"-

[14] U. Dayal, M. Hsu, and R. Ladin. A transaction model for long-running activities. In
Proceedings 17th International Conference on Very Large Data Bases, pages 103-112,
Barcelona (Catalonia, Spain), Sept. 1991.

[15] U. Dayal and J.M. Smith. Probe:a knowledge-oriented database management system.
In Proceedings of the Islamorada Workshop on Large Scale Knowledge Base and Rea-
soning Systems, 1'I"".

[16] A.K. Elmagarmid, editor. Database Transaction Models for Advanced Applications.
Morgan Kaufmann Publishers, San mateo, CA, 1992.

[17] R. Elmasri and G. Wuu. A temporal model and query language for e-r databases. In
Proceedings 5th International Conference on Data E,.-',, i ',,i 1990.

[18] R. Engelmore and T. Morgan, editors. Blackboard Systems. Addison-Wesley Publishing
Company, 1'I',

[19] S.K. Gadia. A homogeneous model and query languages for temporal databases. In
Proceedings .',,l International Conference on Data E,.-i',, i ', 1'l1'

[20] S. Gatziu and K. r. Dittrich. SAMOS: an Active, Object-Oriented Database System.
To appear in IEEE Quarterly Bulletin on Data E,,-i ', i ',. January 1993.

[21] N. H. Gehani and H. V. Jagadish. Ode as an Active Database: Constraints and
Triggers. In Proceedings 17th International Conference on Very Large Data Bases,
pages 327-336, Barcelona (Catalonia, Spain), Sep. 1991.

[22] N. H. Gehani, H. V. Jagadish, and O. Shmueli. Event Specification in an Object-
Oriented Database. In Proceedings International Conference on M,,, .i, ,. ,of Data,
pages 81-90, San Diego, CA, June 1992.

[23] Seung-Kyum Kim. A Formal Appproach to Two-Dimensional Temporal Databases.
Master's thesis, Department of Computer & Information Sciences, University of
Florida, Gainesville, FL 32611, December 1992.

[24] V. R. Lesser and D. D. Corkill. Functinally accurate cooperative distributed systems.
IEEE Trans. Syst. Man Cybern.,, 1981.

[25] D. Mishra. Snoop: An event specification language for active databases. Master's
thesis, Database Systems R&D Center, CIS Department, University of Florida, E470-
CSE, Gainesville, FL 32611, Aug. 1991.

[26] S. B. Navathe, A. K. Tanaka, and S. Chakravarthy. Active Database Modeling and De-
sign Tools: Issues, Approach, and Architecture. To appear in IEEE Quarterly Bulletin
on Data E,.i',.,, ',-i January 1993.

[27] S.B. Navathe and R. Ahmed. A temporal relational model and a query language.
I f,,, '. I ', Sciences, 47(2), 1'i I

i-"] C. Roda, N. R. Jennings, and E. H. Mamdani. ARCHON: A Cooperative Framework
for Industrial Process Control in Ci ,,, I,,-i, Knowledge Based Systems 1990. Spinger
Verlag, 1991.

[29] N.L. Sarda. Extensions to sql for historical databases. IEEE Transactions on Knowl-
edge 6 Data E,.-',, i ',.- 1990.

[30] R. Snodgrass. The temporal query language,tql. AC I1 Transactions on Database
Systems, 12(2), 1'-"7.

[31] A. Tanaka. On Conceptual D,.sip, of Active Databases. PhD thesis, Georgia Institute
of Technology, College of Computing, December 1992.

[32] A. Tanaka, S. B. Navathe, S. Chakravarthy, and K. Karlapalem. Er-r: An enhanced er
model with situation-action rules to capture application semantics. In Proc. 10th Int.
Conf. on Entity-Relationship Approach, 1991.

[33] A.U. Tansel. Adding time dimension to relational model and extending relational
algebra. Ifr I', Systems, 13(4), 1'l'i.

[34] A.U. Tansel and J. Clifford. On a historical relational algebra:two views. In Proceedings
AC if SI(C I[OD Conference on i.... i /. I. of Data, 1' ".

University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs