Universit` a degli Studi di Milano-Bicocca SCUOLA DI DOTTORATO DI RICERCA IN SCIENZE Dottorato di Ricerca in Informatica XIX ciclo Coordinatore Prof. Giancarlo Mauri C OOPERATION THROUGH WEBS OF DOCUMENTAL ARTIFACTS : A FRAMEWORK FOR THE PROVISION OF AWARENESS INFORMATION . F EDERICO CABITZA Ph.D. Dissertation Tutor: Prof. Stefania Bandini Cotutor: Prof. Carla Simone A.A. 2005/2006
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Universita degli Studi di Milano-Bicocca
SCUOLA DI DOTTORATO DI RICERCA IN SCIENZE
Dottorato di Ricerca in InformaticaXIX ciclo
Coordinatore Prof. Giancarlo Mauri
COOPERATION THROUGH WEBS OF DOCUMENTAL
ARTIFACTS: A FRAMEWORK FOR THE PROVISION OF
AWARENESS INFORMATION.
FEDERICO CABITZA
Ph.D. Dissertation
Tutor: Prof. Stefania BandiniCotutor: Prof. Carla Simone
A.A. 2005/2006
To my parents,
to my Apollonean youth,
and beloved Dionisy
Acknowledgements
This dissertation, as well as the work I report through it, would not exist with-
out the useful indications and continuous support provided by my advisor,
Prof. Carla Simone. While any mistakes or inaccuracies are my own responsi-
bility, it is highly likely that Prof. Simone had a hand in most of the appreciable
points of this dissertation. For all the fruitful and enriching talks we have often
had during the last three years and for all the time she devoted to my cultural,
professional and academic growth, far beyond her institutional duties, I am
and will always be deeply grateful.
I am also grateful to Prof. Stefania Bandini, for having introduced me to
her colleague and friend Carla Simone, the time I knocked to her door to
try and see whether I could access academic research and teaching after my
preliminary experiences in the private IT sector.
I also wish to thank Prof. Carlo Batini, who was my mentor for six full and
interesting months, for having opened his office door too, and for having me
know and appreciate the Art of Fugue by Johann Sebastian Bach, although it
is still an unfinished work.
I would also like to express my gratefulness to Giovanni Mattera of CoST
srl for his genuine kindness and for giving me the opportunity to look within
the bowels of its challenging prototype for a user-centered electronic patient
record. Last but not least, I’d like to give a special thanks to all the personnel
of the Manzoni Hospital for showing great interest in my research and being
willing to answer my sometime trivial questions on their daily work and prob-
lems. In particular, Rossana Pezzotta, Daniela Colombo and Dr. Roberto Bellu
have always welcomed me kindly, and made me feel at ease in every situation
I had to work with them, even wearing a white coat.
iii
Besides the professional side of my life and turning to the most personal
and private side of it, I am also obliged to acknowledge who has either enabled
me to achieve such result or shared with me the harshnesses of the path.
For the former reason, I wish to thank from the deepest of my heart my
parents, Gisa and Paolo. They have always encouraged and supported me in
pursuing whatever objective I have deemed important in my life, each time
never leaving me without either a smile or a quip, respectively.
For the latter reason, I thank Den, my travelmate, who has often had to
bear my difficulties and relieve my downheartednesses on the path to the
achievement of the Doctorate degree. I met Den at the beginning of my doc-
toral studies and she has greatly contributed in making these years the most
significant of all my life so far.
I also wish to thank some close and a little farer friends of mine: Matteo,
who has lately spurred me as much as only a jockey would have done with
his horse winning by only half a length: I thank him for trying to have me
feel those 350 km shorter. And I thank Bernardo, for his invaluable help with
LATEX and for the great and cooperative work we engaged in when we wrote
our considerations on context-aware computing and distributed inference sys-
tems: with him I’ve always worked very hard (e.g., the Master Thesis) but I
think that he has greatly contributed in making that work lighter and even
more interesting.
A last word for my lab colleagues: especially Michele, whom I had a really
great time in working and talking with, and Marcello, with whom I have often
had fun in playing sketches a la Toto and Peppino. I also thank Marco, Gigi
and Marco P. for making the place where I’ve spent almost every day of my
doctoral period a pleasant place to work and stay.
Milan, the 15th of November, 2006
iv
Contents
Acknowledgments v
1 Introduction and Main Motivations 11.1 Documenting Work and its articulation . . . . . . . . . . . . . . 2
1.1.1 Cooperative work and articulation . . . . . . . . . . . . 31.2 The need to be aware . . . . . . . . . . . . . . . . . . . . . . . 5
8 Conclusive remarks 2158.1 Summarizing the main achievements . . . . . . . . . . . . . . . 2158.2 Confronting WOAD with similar approaches . . . . . . . . . . . 2188.3 Possible directions for future works . . . . . . . . . . . . . . . . 223
A The NICU survey questions 231
References 266
vii
List of Figures
3.1 A woad plant, Isatis tinctoria in the family Brassicaceae . . . . . 443.2 Two kinds of contexts that pertain to documents in cooperative
settings and correlations among contextual items. . . . . . . . . 503.3 The two main concepts within the WOAD framework . . . . . . 573.4 Activity levels for the documental domain. . . . . . . . . . . . . 573.5 The main concepts of the WOAD framework. . . . . . . . . . . 593.6 The involvement relationship cases. . . . . . . . . . . . . . . . . 613.7 The WOAD metaphor: web threads between documental arti-
facts are relationships stemming from the fact space and depict-ing a woad plant whose leafs are documents; transitors makethe plant change, evolve, flourish. . . . . . . . . . . . . . . . . . 69
3.8 A graphical representation of the main components of theWOAD architecture. . . . . . . . . . . . . . . . . . . . . . . . . 70
3.9 A graphical representation of the architecture of a WOAD-compliant software application. At the top, we depicted thedocumental applications that are made cooperation-aware andcontext-aware by the underlying tiers. . . . . . . . . . . . . . . 79
4.1 Dynamic representation of an inference system. . . . . . . . . . 904.2 Interactions between context, represented by facts, and IS’s sen-
5.1 The most general WOAD fact structure. Self-explicative at-tributes types are indicated in the attribute column. The plusdenotes a multiplicity possibly other than one . . . . . . . . . . 109
5.2 The conceptual hierarchy between very general WOAD factsand their framework-specific extensions. . . . . . . . . . . . . . 109
ix
5.3 DJess syntax for the definition of the WOAD-fact template. Lan-guage properties are referred to template slots for the sake ofcomprehensibility. . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.4 The general structure of an entity-fact. Possible extensions ofthe entity-fact structure into application-dependent templatesare just hinted specifying a generic designer-defined property. . 111
5.5 Above, an example of DJess syntax for the definition of theentity-fact template. Below that, an example of fact definition:the person fact is defined as extension of the generic entity-fact. 111
5.6 The general structure of a document-fact. Some properties in-herited by the entity-fact (e.g., description) are reported for thesake of comprehensibility. . . . . . . . . . . . . . . . . . . . . . 113
5.7 The general structure of a awareness-fact. . . . . . . . . . . . . 1135.8 a) The general structure of a work-activity-fact. b) The general
structure of a documental-activity-fact. Properties inherited byparent facts (e.g., name and description) are reported for sakeof completeness. . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.13 DJess syntax for the definition of a WOAD convention-fact tem-plate as extension of the shared-rule template (see Section 4.3.2).122
5.14 Aspects of document-based awareness and related questions.Adapted from [Gutwin and Greenberg, 1997]. . . . . . . . . . . 124
5.15 The general mechanisms enabling interactions among themodel’s components: from left to right, the generic actor, thegeneric document, the fact space and the generic transitor. . . . 131
5.16 Mechanisms can abstract contextual data from documents andvice-versa, can inform documents of contextual elements . . . . 132
5.17 The general structure of a WOAD mechanism. . . . . . . . . . . 1335.18 Summary of WOAD primitives and their parameters. . . . . . . 1395.19 Example of DJess syntax for the definition of a WOAD correla-
6.1 A snapshot of the problem list sheet from the medical record.From the left to the right, there are reported an ID field, the de-scription of the problem, date and signature for the beginningand the cessation of the problem at hand. . . . . . . . . . . . . 163
x
6.2 A snapshot of the diagnostic/therapy plan sheet from the med-ical record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
6.3 Routine information flows (thick arrows) and data correlations(dotted and thick arrows) among documents. The main docu-ments of the medical record (above) and nursing record (be-low) have been encircled by a dotted line. . . . . . . . . . . . . 168
6.4 A snapshot of the nursing need list. . . . . . . . . . . . . . . . . 1696.5 A snapshot of the Activity Plan form for care assistants. . . . . . 1706.6 The “use” and “usefulness” of documental artifacts in support
of hospital care. In slanted figures: frequency of use, on a 5values, symmetric Likert-scale. In bold figures: effectiveness ofuse, on a 5 values, symmetric Likert-scale. Median values first,mean values between brackets. . . . . . . . . . . . . . . . . . . 174
7.1 The reference information model (RIM) as the core piece ofHL7 modelling. . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
7.4 A graphical representation of the entities and relationships in-volved in the illustrative example. . . . . . . . . . . . . . . . . . 196
7.5 A snapshot of the Laboratory Examinations Form (SLEF). Anarea for prescribing only three typologies twice (e1 and e2) isbrought into close-up, for room’s sake. . . . . . . . . . . . . . . 198
7.6 WOAD mechanism for a convention on the proper role. . . . . . 2017.7 WOAD mechanism for a convention on proper order. . . . . . . 2037.8 WOAD mechanism for a convention on proper timing. . . . . . 2047.9 WOAD mechanism for a convention on proper redundancy. . . . 2057.10 A snapshot of the Single Pharmacological Therapy Form
(SPTF). Dashed boxes indicate sections with a specific mean-ing within the clinical record. . . . . . . . . . . . . . . . . . . . 207
7.11 A snapshot of both the Single Diagnostic-Therapeutic ProcedureForm (SDTF) and the Nurses’ Fasting plan. In the latter the fourcolumns indicate, respectively, the bed-number, the name of thepatient, the examination type, and the scheduled time for theexamination. For the SDTF the six columns indicate: the order-ing doctor, the ordered exam, date of request, date of booking,(scheduled) date of execution and (scheduled) date of referralarrival. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
The work that we present in this thesis is rooted in the research field known
as Computer Supported Cooperative Work (CSCW). CSCW emerged during
the 80s as a multi-disciplinary community trying to understand the use and
design of computer-based systems as supportive technologies for complex co-
operative work setting [Schmidt and Bannon, 1992]. By drawing on the uni-
fying interest for understanding “how collaborative activities and their coor-
dination can be supported by means of computer systems” [Carstensen and
Schmidt, 1999], the CSCW field has gathered complementary contributions
from related disciplines such as computer science, information systems re-
search, human-computer interaction and sociology. Such contributions have
been aimed at positively informing the design of application systems whose
primary requirements regard how to properly and unobtrusively support peo-
ple that are mutually dependent in their work and are therefore required to
cooperate in order to get their work done [Schmidt, 1991].
Within the CSCW field, the main aim of study has then been twofold,
summarized into the terse expression “to understand, so as to better sup-
port” [Bannon and Schmidt, 1991]. On the one hand, CSCW researchers have
focussed on how work practices unfold in real work settings and are accom-
plished in traditional manners, even without the functionalities of information
and communication technologies. On the other hand, CSCW has aimed at ap-
plying the evidences collected by such studies in order to conceive, design and
deploy proper computer-based solutions that could support practitioners in
1
CHAPTER 1. INTRODUCTION AND MAIN MOTIVATIONS
working together, without being disrupted in their working habits and con-
ventions. In this introductive chapter, we aim at providing the reader with the
conceptual and motivational background that has influenced our contribution
within such research field.
1.1 Documenting Work and its articulation
Documents are used extensively by practitioners in the execution of their own
work and as a means for sharing information with others [Hertzum, 1999].
For this reason, researchers from different disciplines have been studying for
a long time the ways and extent documents are used and managed within
professional practices.
As a result, several evidences have been collected from very different set-
tings of how documents, far from being mere subsidiary tools where bits of
information are passively stored, are rather woven into work activities and
part and parcel of those activities that characterize work in its purpose and
sense (e.g., [Malone, 1983].
With the advent of computer-based systems and digitization, and of the
new functionalities that the computational processing of information can pro-
vide its consumers with, an increasing number of organizations are consid-
ering digital documents as the main way to successfully manage the flow of
information throughout the enterprise [Berry and Goulde, 1994].
On the other hand, the transition from paper-based traditional documents
— and the correlated habitual practices — to their fully digital counterparts
and to practices intended to exploit such new functionalities, has proven to be
highly problematic (e.g., [Braa and Sandahl, 1998,Sellen and Harper, 2003]).
Consequently, the role of documents in work practices have become a cen-
tral point of interest [Lortal et al., 2005] in several and complementary re-
search fields, and its analysis from observational and ethnomethodologically
informed observations a way to inform a proper design of computer-based
documental systems.
Recent studies have considered that documents are not to be regarded
as isolated artifacts, but rather as artifacts intertwined in a heterogeneous
network of people, places and other tools used to support communication and
the articulation of work activities [Braa and Sandahl, 1998].
In the research we will report in the next sections, we contextualize such
2
1.1. DOCUMENTING WORK AND ITS ARTICULATION
consideration by adopting the analytical distinction proposed by Schmidt and
Bannon between cooperative work and articulation work [Schmidt and Ban-
non, 1992].
1.1.1 Cooperative work and articulation
The common sense definition of the attribute cooperative characterizes the
work that is said to be “cooperative work” as work that involves several actors
working together in a conscious way in order to jointly perform some shared
activities. By adopting the conceptualization that of this primarily human1
phenomenon is given within the CSCW field, we recall a couple of crucial
aspects that underpin this straightforward definition.
Working together implies some extent of interaction: in a typical coopera-
tive arrangement interaction involves multiple individuals, acting in multiple
work settings and situations and exhibiting different responsibilities, perspec-
tives and propensities towards the shared goal2. These differences can result
into incommensurate perspectives and discordant motives [Schmidt and Ban-
non, 1992] that, although they could also require to be someway managed
and reconciled, can also become important resources for any individual actor
to get her work properly and timely done. Interaction is then a concept that in
the domain of cooperative work is declinable in terms of mutual dependency,
so as to include much more than mere physical influence.
Moreover, cooperation is a conscious activity, where involved actors rely
positively on the quality and timeliness of each others work [Schmidt, 1991].
This means that cooperative work is at great extent influenced by the degree
smaller, individual activities — which are accomplished toward the general
aim calling workers for cooperation — are interdependent and by the extent
they are coordinated, scheduled, aligned, meshed and integrated into an or-derly work arrangement [Strauss, 1988].
As a consequence that people engaged in cooperative work are conscious
1Although the concept of “cooperation” has been applied to several other fields, e.g. thewhole animal reign [Wilson, 1975], ensembles of computational machines [Ferber, 1999] andmany other phenomena [Axelrod, 1997], we adopt the narrower and specialistic acceptationthat CSCW researchers conventionally give the term.
2We are speaking of shared goal, instead of common goal to hint that motives calling forsome form of cooperation can be even discordant and not aimed at the very same goal. Cooper-ative work can be justified even by the common goal of having one’s individual goal achieved,once some mutual interdependency within these individual tasks is detected and acknowledged(cf. [Bannon and Schmidt, 1991]).
3
CHAPTER 1. INTRODUCTION AND MAIN MOTIVATIONS
of being mutually dependent in their work, they also feel the need to under-
take the additional activity of managing and controlling the overhead cost that
is connected with the dependencies implied in cooperative relationships. The
additional effort to articulate interdependent distributed activities in one co-
operative job is then called “articulation work”. From its simple definition, it is
pretty clear that articulation work is a distinct kind of work from cooperative
work, that conversely refers to the very ongoing activities in the field of work.
Realizing the distinct nature of these two classes of work corroborates the
argument that articulation work can be supported as an independent process
that manages the coordination of interdependent activities by abstracting from
the cooperative work setting they belong to. In that sense, the mission of the
CSCW can be declined in several complementary ways, all traceable back to
the two fundamental souls of “teamwork”: on the one hand, information tech-
nology and computational capabilities can be aimed either at augmenting the
information sharing capacities of actors (e.g., messaging, teleconferencing) or
at facilitating the exploitation of multiple work strategies and heuristics (e.g.,
project management, collaborative writing, knowledge management); on the
other hand, IT can be aimed at supporting the ordering (in the sense of or-
derly arrangement, cf. also [Schmidt and Wagner, 2004]) and the combination
of specialized and interdependent activities (e.g., work-flow like solutions);
or at fostering and reconciliating multiple perspectives and conceptions (cf.
e.g.,automatic reconcilers [Sarini and Simone, 2002] ).
In such wide range of possibilities and application domains, the two main
conceptual proposals that have influenced and inspired our research — both
in terms of design-framework and architecture — have been the concep-
tualizations of collaborative awareness [Lauwers and Lantz, 1990, Dourish
and Bellotti, 1992] and of common information space [Schmidt and Bannon,
1992, Bannon and Bødker, 1997]. Both contributions refer to two precise re-
quirements that can be considered as fundamental and indispensable in any
work arrangement: the need to be aware of what is going on within such ar-
rangement and the need to share information as a way to smoothly manage
mutual dependencies. In the following sections we treat how these two as-
pects of cooperative arrangements can inform the design of computer-based
applications that can support actors both in becoming aware and sharing rel-
evant information about their work and setting.
4
1.2. THE NEED TO BE AWARE
1.2 The need to be aware
Even in an informal context of casual observations, it is easy to recognize
that in a co-located cooperative setting, in order to interact effectively, actors
need to be aware of each other, e.g., to take heed to who is where, what is
doing, whether she can help us and so forth. In such situations, colleagues
in a given cooperative setting seem to exhibit several strategies to maintain
almost effortlessly — and sometimes even unconsciously — reciprocal aware-
ness: their ability to get a comprehensive (for their needs) picture on “what is
going on” in the surroundings is based on a number of sources like peripheral
sounds, quick glances and indirect clues, like “traces” left either voluntarily
or unwittingly in the common environment. Such environmental clues are
also the basis for the acquisition of awareness on “what went on” earlier, a
hindsight awareness that can be as useful as the mutual awareness [Benford
et al., 1994] in deciding what to do “now and next”, i.e., as a basis for asyn-
chronous coordination. We will come back to the way the environment can
provide cooperative workers with useful indications when we will explicitly
treat environment-mediated coordination and the concept of stigmergy (see
Section 1.5)
It is pretty obvious that, except these possibly meaningful traces left be-
hind by Tom Thumb co-workers sometime in the past, by moving towards
highly distributed and asynchronous work settings, the physical background
of mutual awareness would even completely lack, and with it the ability for
coworkers to keep aligned with each other and being constantly and properly
articulated towards the common goal achievement. In such contexts, informa-
tion and communication technologies have been seen either as what can be
applied to work settings in order to circumvent the shortcomings derived from
this lack of background (e.g., [Sengupta and Zhao, 1998]); or, conversely, as
those technologies that, having made these shortcomings possible, by mak-
ing at-distance work feasible, convenient and even necessary in many pro-
ductive sectors, must hence be properly tailored to fulfill the requirements of
computer-mediated cooperation [Galegher and Kraut, 1990].
1.2.1 Defining what to be aware of
Within CSCW, the role of collaboration awareness [Lauwers and Lantz, 1990]
in work settings has been highlighted by many authors presenting empiri-
5
CHAPTER 1. INTRODUCTION AND MAIN MOTIVATIONS
cal studies of cooperative work, starting from Heath and Luff [Heath and
Luff, 1992]. As a consequence of the increasing importance of information
technology in preserving and enhancing such kind of information, it is from
the beginning of 1990s that the concept of awareness has become a key one
within the CSCW field, although its interpretation and application have al-
ways been pretty far from being clear-cut and univocal [Schmidt, 2002]. As
a matter of fact awareness is often preceded by a plethora of adjectives, like
passive, mutual or workplace awareness [Dourish and Bellotti, 1992,Schmidt,
1998, Gutwin and Greenberg, 2002], that denotes but the fact coordination
in real situations is achieved on the basis of different forms of awareness re-
garding the (often) “elusive practices of taking heed of what is going on in
the [work] setting” [Schmidt, 2002], and of getting a view of “who is around,
what activities are occurring, who is talking with whom” in the daily work
environments [Dourish and Bly, 1992]. From the point of view of the design
for supportive technologies to cooperative work, awareness regards a particu-
lar “mode of coordination” pertaining to different actors’ abilities, such as the
ability of identifying a relevant information from the background, to interpret
it in a given context [Simone and Bandini, 2002] and to properly react to it
on a voluntary basis [Simone and Schmidt, 2000].
Among the very first contributions to the matter, Dourish and Bellotti pro-
posed for the concept of awareness in cooperative work domains the defini-
tion of “an understanding of the activities of others, which provides a context
for your own activities” [Dourish and Bellotti, 1992]. The authors’ greatest
merit for this first contribution to the matter was twofold. On the one hand,
they consolidated a programmatic approach by which awareness could be
somehow related to some specific information (which can be rightly called,
awareness information), an information which is “always required to coordi-
nate group activities, whatever the task domain”. On the other hand, they also
shed light both on the ways in which such information could be (even algo-
rithmically) derived from the context in which competent actors work and on
the way such actors could be provided with such information by mechanisms
through which they can inform each other of their activities.
From that seminal contribution on, the research community has been ex-
ploring how people exploit awareness information in real working situations,
for at least two main purposes. On the one hand, researchers have focussed on
finding common and recurring elements toward a comprehensive though nec-
6
1.2. THE NEED TO BE AWARE
essarily abstract classification of how such information is produced and con-
sumed in traditional (i.e., not yet digitized) settings; on the other hand, they
have tried to understand how awareness information could be automatically
provided by applications that Lauwers and Lantz first called “collaboration-
aware” [Lauwers and Lantz, 1990] to help distributed collaborators in align-
ing with each other more smoothly.
Although pretty soon most of the authors involved in such research agreed
the concept of awareness could be used to denote “those practices through
which actors tacitly and seamlessly align and integrate their distributed and
yet interdependent activities” [Schmidt, 2002], what has always differed
among these various contributions was the way in which this rather simple
concept was operationalized or which particular aspect of the whole aware-
ness phenomenon had to.
Recent surveys, only within the CSCW community, has ended up by list-
ing and describing up to nineteen different types of awareness information
(e.g., [Jang et al., 2000]). In those listings, the focus is alternatively put ei-
ther on awareness about others’ activities (what are they doing and where
are they — cf. the concept of activity awareness in [Gutwin et al., 1996]);
about each other’s availability (when can I reach them and how [Tollmar et al.,
1996]); about process (where am I in the project and on whom do I depend);
about the surroundings (cf. the concept of environmental awareness [Fussell
et al., 1998]); or even about intentions and perspectives (what are others
thinking and why are they doing that [Boland et al., 1992]).
Since the plethora of definitions proposed lead almost necessarily to con-
notations that end up by overlapping, we have adopted the approach of others
researchers (e.g., [Jang et al., 2002]) in considering first what information
needs have been exhibit in a real work domain and then trying to formulate
a framework that focuses on the conceptualization of such needs and that
enables the deployment of computational means supporting awareness pro-
motion.
A general but yet quite distinctive and important point about awareness
is that regarding its passive or active nature. The practices actors apply to im-
prove the coordination of their activities are a combination of monitoring oth-
ers’ activities and, more generally, the surrounding context of the cooperative
arrangement. Studies have reported that actors improve their coordination by
also deliberately displaying aspects of their own activities so that coworkers
7
CHAPTER 1. INTRODUCTION AND MAIN MOTIVATIONS
can be stimulated in taking heed of their activity [Heath and Luff, 1992].
Hence, awareness promotion is not always a “passive” practice but rather
could require the additional effort both in pointing out things others ought
to be aware and in personally coping with their perception. This argument
necessarily influences at great extent how to properly design technological so-
lutions supportive of both monitoring and displaying awareness information.
In our specific case, who produces content on documents is also committed
in linking data with other contextual information so that “a web of signifi-
cance” [Bossen, 2002] can be managed and used to produce awareness in the
ways we will outline in Chapter 7.
Once the preconditions to create awareness are fulfilled, two conclusive
and important issues must be considered regarding the extent awareness in-
formation can be useful and not obtrusive of the regular flow of cooperative
work. The first aspect concerns what awareness information has to be dis-
played and when. The second implication concerns how awareness informa-
tion has to be conveyed, and hence visualized. Both aspects have different but
deep implications on the design of supportive technologies.
As we will see in the course of this thesis, in our proposal we do not explic-
itly consider the second aspect, since we focus on the coordinative function of
artifacts, not their interactional one. The what and when awareness should
be provided are instead aspects that deeply characterize our proposal leading
to the concept of conventional mechanisms (or just conventions) for the provi-
sion of awareness information (see Section 5.2). The time when awareness is
to be displayed will be based on the specific conventions that within a spe-
cific domain are established on documental content and work context (see
Section 3.2). Which kind of awareness information has been derived from
the analysis of requirements collected from an observational study will be re-
ported in Section 5.2.
1.3 Artifact mediated awareness
According to a simple distinction proposed by Gutwin and Greenberg [Gutwin
and Greenberg, 1997], there are two primary mechanisms by which awareness
is maintained: communication and observation.
Communication can be either characterized along several dimensions: it
can be either direct or indirect; either verbal or nonverbal, i.e., through prox-
8
1.3. ARTIFACT MEDIATED AWARENESS
emic modalities like gestures and body language. What characterizes commu-
nicated awareness information is that actors emitting this kind of information
really mean to provide it, typically for some coordinative aim. To use an ex-
pression used by Simone and Bandini in [Simone and Bandini, 2002], com-
municated awareness is an add-on awareness, “something generated explicitly
by actors” [Gutwin et al., 1996,Heath et al., 2002] and the outcome of an ad-
ditional activity carried out on a voluntary basis by actors depending on their
evaluation of the contingent situation.
Also observation can be characterized in several ways, ranging from ca-
sual noticing to attentively watching. It can occur at any time and observed
awareness does not require actors to explicitly and consciously produce add-
on awareness: their very actions, as well as the effects of these actions can
inform their colleagues on what they have done, are doing, and even are go-
ing to do. Awareness by observation is what is also denoted as by-productawareness [Simone and Bandini, 2002] in that it “is generated in the course
of the activities actors must do in order to accomplish their cooperative tasks”
and not for sake of coordination. In this case, hence, conventions about the
intended use of space and artifacts — which include aspects concerning both
how, where, when and even why the latter are used — play an important role
in characterizing and “coloring” the articulation aspects conveyed by aware-
ness information. For instance, the classic example of inferring that someone
is going to cut something if she is seen holding some scissors [Gutwin and
Greenberg, 1997] would be groundless in a hospital context unless scissors are
conventionally associated with cutting bandages3; likewise, if a nurse knows
that scissors are used at the end of moulding a plaster cast, seeing an or-
thopaedist carrying a pair could mean to her she has to prepare the transfer
for the next patient to be plastered.
As part of the physical environment, material artifacts can be rich sources
of awareness information [Dix et al., 1993]. Whenever artifacts are used, they
‘give off information’ that indicates what is being done to and by means of
them [Hill and Gutwin, 2003], both to who uses them and to others. While
the information that an artifact gives off to its users is usually called feedback,
Dix refers to the term feedthrough to denote the particular channel of commu-
nication by which either by-product or add-on awareness information about
the artifact-mediated activities is conveyed also to others nearby and claims
3As a matter of fact, in the healthcare domain, like in the tailoring and hairdressing ones,there are a number of different scissors, each devoted to a specific task.
9
CHAPTER 1. INTRODUCTION AND MAIN MOTIVATIONS
that such communication through the artifact is often more important than
direct communication [Dix, 1997].
1.3.1 Awareness-related requirements for artifact design
Differently from the case of material artifacts that produce awareness infor-
mation almost naturally in any cooperative work setting [Hill and Gutwin,
2003], in computer-based supportive artifacts, awareness information must
be explicitly gathered, transmitted, and redisplayed. The way this is accom-
plished depends to a great extent on the intended purpose why awareness
information is provided.
Within the controversial debate regarding structured versus unstructured
flow of work, procedures versus exceptions-handling, regularity and ad-
hocness in cooperation [Simone and Schmidt, 2000, Simone and Bandini,
2002], we also consider awareness information as a feasible means to support
as naturally as possible actors that have to employ some artifact to, among
other things, smoothly and seamlessly coordinate with each other.
The commonsense acceptation of the term smoothness hints the idea of
a delicate balance any coordinative technology must reach between the con-
trasting indications of both enabling and hindering action, enhancing and af-
fecting it, and between providing the right information at the right time and
providing useless or superfluous information when it is too late or anyway
out-of-the-context.
Supporting cooperative arrangements by means of the provision of aware-
ness information regards hence providing users with useful maps (cf. [Schmidt,
1997]) of the current surroundings and representations of the environment —
in its widest acceptation — that can be used to make sense of it and take the
right decisions on what to do next and how. As stated in [Divitini and Simone,
2000], awareness is the basic kind of information that can be used to complete
a reference map into a detailed script, and interpret a detailed script as a map,
according to the needs of the contingent situation, without loosing the ‘sense
of direction’.
Informing with such insights the design of an awareness-based supportive
technology to coordination requires first to consider awareness as a mode of
coordination and, more precisely, to recognize different types of actors’ ability
about that mode. Simone and Bandini in [Simone and Bandini, 2002] pro-
pose to distinguish between (a) the ability to perceive a stimulus that can
10
1.3. ARTIFACT MEDIATED AWARENESS
make them aware of something, e.g., as the sound of a fire alarm makes the
inhabitants of a building aware that a fire could have broken out. (b) The
ability to analyze it, e.g., to identify the room in which the fire broke out and
to head towards the closest exit that is safe from fire. And finally, (c) the abil-
ity to interpret the stimulus in the given context, e.g., whether the fire alarm
refers either to a drill, or a minor danger, or a massive threat. These abilities
characterize both the users — namely who is “aware of” the stimulus — and,
consequently, any technology addressed to enhancing those abilities.
According to this ability-oriented perspectives, promoting awareness can
be traced back to the promotion of (a) its production and perception, e.g., by
suggesting or reminding what to do to convey it, or by intensifying the stim-
ulus once it is emitted; (b) its analysis, for example by aptly “presenting” the
information pertaining to the the stimulus; and finally, (c) its interpretation,
e.g., including information about the context where the interpretation has to
be carried out [Simone and Bandini, 2002]. As quite obvious, “promoting”
awareness through some supportive technology at each of these three levels
raises different requirements, in terms of medium, mechanism and content, re-
spectively.
In a cooperative settings, communication and observation are usually me-
diated by a preferential medium — or even an organized set of mediums, that
is not likely to change very often. This is because the medium implies a whole
set of practices and conventions that rely on habit and “familiarity” to reach
and maintain effectiveness and leverage on acquired expertise. This does not
mean that the medium is always and firmly “fixed”. Actors can communicate
and interact in any situated way, but the process of conceiving and designing
a particular supportive technology needs to define a particular medium for its
deployment and concentrate on the requirements that can be fulfilled in spite
of its limitations.
Awareness-related mechanisms are to be intended as the ways by which
a computational system can decide both (a) when to solicit actors for some
add-on awareness act and (b) when to provide actors with either add-on or
by-product awareness on the basis of what is going on in the cooperative ar-
rangement.
Two general requirements for functionalities associated with mechanisms
supporting coordination have been provided about the design of coordination
mechanisms [Schmidt and Simone, 1996]. Following the work by Simone and
11
CHAPTER 1. INTRODUCTION AND MAIN MOTIVATIONS
Bandini [Simone and Bandini, 2002], we also claim these requirements are
general enough to be applied to the design of functionalities for the provision
of awareness information. These requirements are malleability and linkability.
In our research we have interpreted the former in these terms: actors should beable to define conventional mechanisms to manage awareness as well as to mod-ify them according to the changing organizational normative context. This is a
requirement about how mechanisms are represented and made computable
and hence also regards the fact that any intended awareness-centered frame-
work must support a high level and abstracted (from implementation details)
representation4 of the logic by which awareness information should be pro-
moted, both at producer’s and consumer’s side.
Linkability, on the other hand, regards the possibility to link a mechanism
to other mechanisms acting in the same organizational context. The case we
have focussed on is that of awareness mechanisms that apply to a specific
artifact, like in the case of a certain document template that is used within
a greater set of documental artifacts in a cooperative arrangement. Linkabil-
ity refers to the possibility to compose individual document-specific mecha-
nisms 5 into more complex and arrangement-wide mechanisms, which repre-
sent a domain-dependent articulation of more document-wide conventions on
documental items (see Chapter 7 for some examples).
1.4 The need to share information
Borrowing a passage by Brehmer we can claim that “communication is the
cement of the organization, and the greater the need for coordination and
cooperation, the greater the necessity for communication.” [Brehmer, 1991].
Also Schmidt and Bannon pointed out that access to appropriate means of
communication is necessary for the proper articulation of the distributed activ-
ities of a cooperative work arrangement [Schmidt and Bannon, 1992]. These
two references — taken among myriads of similar ones — seem to corrobo-
rate the common-sense consideration that communication is a deeply rooted
and innate need of human beings and a fundamental factor in characterizing
their abilities to cope with ever different situations in the highly dynamic envi-
4Schmidt and Simone speak of perspicuousness of the mechanism, i.e., its accessibility andintelligibility to actors at the semantic level of articulation work.
5We will also denote those mechanisms as local, for their application is local to certainartifact.
12
1.4. THE NEED TO SHARE INFORMATION
ronment that shelters them. Even if we preventively acknowledge the ubiquity
and importance of the phenomenon of communication, envisioning really sup-
portive technologies can not leave out of consideration a reflection on the very
assumptions underlying the concept of communication.
To communicate definitely implies the exchange of thoughts, opinions, or
information irrespective of the ways such interchange is achieved, either by
speech, writing, signs, or —- as we have seen speaking of awareness —- just
by being a perceivable part of the common environment. As also the etymology
of the word seems to convincingly suggest, communication implies “to make
something common”6 and communality is indeed a ‘sine qua non’ condition
for any communication be possible, at at least two fundamental levels. In fact,
besides being common what is communicated, also what by which something
is communicated must be common: i.e., the very same system of symbols,
signs, or even behaviors that are employed to provide our interlocutors with
some information.
The sharing of proper signifiers so that also meaning can be conveyed is not
a trivial task, since sharing in this case must include also agreement, consent,
an even temporary and local conventions that are negotiated and established
by actors involved in some communicative effort. From this quite obvious but
yet important consideration, we can then see how communication enables
cooperation but also, quite surprisingly, that communication needs some will-
ingness to cooperate, some preliminary joint effort in putting something in
common and agreeing upon it. This consideration can affect the way design-
ers conceive of reliable and effective supports for cooperative arrangements.
In fact, it is much easier to facilitate, support and even foster the simple
sharing of data than the sharing of what could enable actors to make sense of
those data. The former kind of sharing is in fact where computer systems suc-
ceed more easily: file sharing, web publishing, emailing are all communication
facilities that in spite of distance have certainly changed how people interact
and work together in the recent years. That notwithstanding, providing the
mere bandwidth of the “transmission channel” is just one side of the coin and
it is still a debatable point how computer-based systems could provide their
users with a full support to communication.
The point is on the very conception of what communication is. Whereas
communication is considered akin to transmittance of information, computer-
6Communication derives from the Latin communis, literally “in common, public, general,shared by all or many”.
13
CHAPTER 1. INTRODUCTION AND MAIN MOTIVATIONS
based support can be (and actually is) declined in terms of accuracy and speed.
This assumption is in the vein of Shannon and Weaver’s [Shannon and Weaver,
1949] classic communication model by which communication is seen as the
process of transmitting a message from a source to a receiver through a trans-
mission channel that can be affected by some noise. In this conceptualization,
noise is seen as an external agent that must be attenuated not to affect the ide-
ally pure relationship between sender and receiver. If noise were eliminated,
just sharing information over a neutral medium would be enough to preserve
the full intended communicative deed.
Quite recently the main assumptions of the classic communication model
have been explicitly questioned (cf. e.g., [Winograd and Flores, 1986, Serres
and Latour., 1995, Avgerou et al., 2004]). Hayles, for instance, argues that
to separate a message from the material in which it is embedded is impossi-
ble [Hayles, 1999]. A common point to several contributions from the con-
structionist research within science and technology studies is the conception
of communication as a process of translation and transformation (cf. e.g., [La-
tour, 1999]). Transformation does not merely regard the intrinsic nature of the
information content, but it especially regards changes in its relational nature.
An entity can change character as it enters into relations with different other
entities: its identity — in the sense of its ‘sameness’ — relies on whether refer-
ences can be made to other instances in its transmission trajectory [Winthereik
and Vikkelso, 2005].
In the light of these contributions, communication can be conceived as of
the twofold sharing of both the communicated entity — as it is necessarily
drawn out of its context of production — and of elements which the receiver
can rely upon to be supported in making use of that entity in her own context
of use. From the point of view of the designer of computer-based systems, this
conception can urge the claim to also enable the sharing of the relationships
that the communicated entity has with its context as well as of the conventions
that can make that entity be transformed — and hence understood — within
the context of use. These ideas found a substantial formulation within the
CSCW community with the introduction of the concept of common informationspace.
14
1.4. THE NEED TO SHARE INFORMATION
1.4.1 The common information space
The concept of common information space (CIS) was seminally envisioned by
Schmidt and Bannon in [Bannon and Schmidt, 1991] and then fully developed
by Bannon and Boedker in [Bannon and Bødker, 1997] to contribute to alter-
native mechanisms to workflow-type support to cooperative work [Schmidt
and Bannon, 1992] and to provide indications on why simply providing a
shared access to informational resources does not necessarily imply fruitful
collaboration and sharing of information as elsewhere claimed (e.g., [Rolland
et al., 2006]).
The first acceptation of the expression was about a “space” that comprises
data, personal beliefs, shared concepts, and professional heuristics that could
allow or help people to cooperate and act as a “group” even without direct
communication and without necessarily knowing each other. The main idea
is grounded on the observation that actors, when they jointly articulate their
activities in distributed work settings, tend to construct and manage a “central
archive of organizational information” that “encompasses artifacts that are
accessible to a cooperative ensemble as well as the meaning attributed to these
artifacts by the actors” [Schmidt and Bannon, 1992].
That notwithstanding, in the context of distributed and asynchronous co-
operative arrangements, the idea of a common information space is antithet-
ical to that of a common data base containing all the relevant data from dif-
ferent parts of the organization, a conceptualization that was also opposed by
Ciborra [Ciborra, 1985] as unattainable in practice. The main difference be-
tween a data base and an information space is that in conceiving and designing
the latter the emphasis is put on the ability for users to “actively construct” it,
even at run-time, and to share within and by means of it either simple data
or complex objects all together with their intended meanings and interpre-
tations, which are therein agreed, debated and resolved, at least locally and
temporarily [Schmidt and Bannon, 1992].
Common information spaces come into existence when users can make
sense of the data shared, i.e., can be informed by them, as a consequence of
the mutual effort made by both the producer and the consumer of certain data
to understand each other’s context and “putting in common” with each other.
The information “put in common” must be shared all together with “with some
level of ’shared’ agreement as to the meaning of this information” so that
possible “differences concerning the origin and context of these information
15
CHAPTER 1. INTRODUCTION AND MAIN MOTIVATIONS
items” can be properly interpreted and consistently coped with.
“Shared agreement as to the meaning of information” are a central con-
cept of the CIS proposal: a common information space to be such can not be
constituted only by commonly available information and shared information
holding artifacts, like documents are, but rather also by interpretations of such
information. These interpretations would allow actors to use those artifacts
as a basis for mutual understanding and to really put information in common
(or at least ‘common enough’, despite the “different conceptualizations and
multiple decision making strategies”).
Bannon and Bødker [Bannon and Bødker, 1997] use the term packagingto denote the action of extending information items with some explanation
or rationale of their context and, the way round, unpacking the activity of
the reader to extract that additional information and recreate its intended
meaning.
Packaging and unpacking are not meant to denote a smooth, linear pro-
cess and can refer to a myriad of ways in which people make sense of each
other’s information, depending on the particular reference domain of coop-
erative work. Of particular interest for our research within the lively debate
concerning this concept (e.g. [Bannon, 2000, Randall, 2000]), the concept
of CIS has been also applied to the analysis of cooperative work mediated
by an official and institutionally-structured set of documents, as in criminal
courts [Elliott and King, 2005] and in healthcare settings, like hospital wards
and departments [Josefsson, 1999,Bossen, 2002,Tellioglu, 2003]. In such set-
tings, the pretty rigid structure of the organizational information that is shared
by means of the documental system and the constraints that are institutionally
imposed over its content limit to a great extent the “degrees of freedom” by
which interpretations can be conveyed in the same space of shared informa-
tion. In such contexts, the difficulties in packaging and unpacking context are
somehow exacerbated and can regard both the packer and the unpacker.
In fact, in the specific case of documents, as particular structured inscribed
artifacts [Schmidt and Wagner, 2002b], who is supposed to pack information
has inherently an incomplete sense of whether her documents will eventually
be of interest for someone else [Hertzum, 1999] and, if they will, to whom
and in what context. Moreover who packs an information has to force the full,
even manifold, correct interpretation of some data in something that is neces-
sarily univocal and narrow-intended and she has to accept even the straining
16
1.4. THE NEED TO SHARE INFORMATION
and forcing implied in simplifications and standardization. Also the task of the
unpacker is difficult. In fact, it is pretty common sense that one thing is to sym-
bolically represent some additional contextual information and quite another
is to make a full and operating sense of it, by adapting it to her context of use.
According to the conception of communication seen above, the unpacker is
rather an interpreter that has an active role in translating the message in her
own language and conventions, since no translation can be given in advance.
This consideration represents the staring point for our proposal, in which
we have investigated how to feasibly enable the creation of an “information
space” and how to make it “common”, by focussing on the conventional nature
of the interpretations that can be conveyed through such space.
For a simplification suggested by the need to make them computable and
processable by computer-based systems, we conceive of interpretations as
mere conventions, i.e. agreements on the production and use of information.
From the point of view of the designer of computer-based systems that are
informed by the concept of common information space, these conventions
can be seen as subjected to a three-step process: first they are established as
the result of a negotiation by the actors involved; then they are externalized
(cf. [Nonaka and Takeuchi, 1995]) in some appropriate description format;
and then made interpretable7 by computational machines so as to inform the
automatic provision of useful information where and when it needs. Each step
can present difficulties that are not trivial to solve in every context of appli-
cation. Even once conventions are actually observed in the field of work and
computer systems are deployed with some desired result, the externalization
of conventions necessarily implies the risk common to any decontextualiza-
tion into canonical forms [Brown and Duguid, 1991]. That notwithstanding,
the conception of communication as transformation rather than mere trans-
mission does not require externalized knowledge on conventions to be strictly
formal but, on the contrary, can advocate for it to be contextual, contain ambi-
guities — even deliberate — and require explicitly interpretation [Mulholland
et al., 2002].
7Obviously we are now using the term interpretation as the operation carried out by com-puter programs that executes other programs (i.e., interpreters).
17
CHAPTER 1. INTRODUCTION AND MAIN MOTIVATIONS
1.5 Focussing on mediated cooperation
Let us now focus on those work settings where communication is often only
asynchronously achieved, and information sharing and articulation work oc-
cur in distributed cooperative arrangements involving a large and varying
number of actors.
From its earliest contributions, the CSCW community has been constantly
collecting evidences that this particular kind of work settings poses the most
demanding challenges to computer-based support design [Carstensen and
Schmidt, 1999]. In fact, claims are made that the various and consolidated
forms of everyday social interaction appear to be insufficient [Schmidt and
Bannon, 1992] and that the design needs thorough analyses to be conducted
toward a clearer comprehension of the role that artifacts play in objectifying
the various mechanisms of interaction that actors apply so as to reduce the
complexity of articulation work [Schmidt, 1991]. Quite recently, on the basis
of a survey of contributions spanning from the end of the 80s to some years
ago (e.g. [Harper et al., 1989, Sellen and Harper, 2003]), Schmidt and Wag-
ner did not hesitate in connoting such role of artifacts as crucial [Schmidt and
Wagner, 2004].
It is somehow self-evident that actors engaged in asynchronous and dis-
tributed work settings must rely also on “something else” than the here-and-
now — the contingency of a spoken utterance — to communicate, to put some-
thing in common, or just to take heed of what they are doing. This ‘something
else’ must necessarily be something ‘out-there’, the external world, i.e., the
environment sheltering both coworkers and their activities.
The interest for reaching a comprehensive understanding of the role of en-
vironment in the ambit of coordination-oriented research is common to many
disciplines, which are some times adjacent, some other times just complemen-
tary. In particular, within the wider field of computer science, environment-
mediated coordination is a programmatic research topic within the Multi-
Agent Systems (e.g. [Parunak et al., 2003, Omicini et al., 2004]), the Human
Computer Interaction and the CSCW fields. Within the latter field, in par-
ticular, several researchers have accomplished inclusive analyses of the way
the materiality of the work setting is exploited by involved actors to effort-
lessly and fluently coordinate their individual activities (cf. e.g., [Harper et al.,
1989,Heath and Luff, 80,Suchman, 1996,Schmidt and Wagner, 2002a]).
Some CSCW contributions, e.g. [Fjeld et al., 2002,Halverson, 2002], have
18
1.5. FOCUSSING ON MEDIATED COOPERATION
also recently focussed on cognitive and social theories which explicitly take
into account the role of environment and artifacts in coordination, such as Dis-
tributed Cognition [Hutchins, 1996] and Activity Theory [Kaptelinin, 1996]
and Situated Action [Lave, 1988].
As regards these three main theoretical frameworks and their comple-
mentary contribution to system design [Nardi, 1995], Susi and Ziemke have
claimed that in relation to how they describe the role of artifacts in collabora-
tive activity, their common denominator can be traced back to the concept of
stigmergy [Susi and Ziemke, 2001]. This concept comes from the studies re-
garding how even the simplest animals 8 are capable of reaching complex lev-
els of coordination through the signs they make and perceive within a shared
environment, a phenomenon for which the French entomologist Grasse coined
the term stigm-ergy9 right to capture the notion that when an agent acts it
also necessarily ends up by leaving signs, which itself, as well as other agents,
can perceive and determine their subsequent actions upon [Theraulaz and
Bonabeau, 1999,Parunak, 2003].
The concept of stigmergy can be even further characterized into either
sematectonic or sign-based stigmergy as a useful distinction that consider, re-
spectively, whether signs or, more generically, modifications to the environ-
ment, are the unintended effect, the by-product of some task-related activ-
ity, or, conversely, they are the results of a conscious and intentional act that
makes no further contribution to the task at hand but rather is accomplished
with the aim to influence and direct its activities [Wilson, 1975]10. This dis-
tinction can be useful in drawing a parallel with the human ambit of coopera-
tive work11 and indeed it is quite similar to the distinction between by-product
8The study of how simple animals like insects (e.g., ants, termites, bees) cope with theever-changing complexity of the surrounding environment in some brilliant ways have recentlyinfluenced the research in the fields of Artificial Intelligence and Robotics (e.g., [Brooks, 1991,Steels, 1994,Ferber and Mueller, 1996]).
9The term is formed from two Greek words, stigma and ergon, standing for “sign” and“action”, respectively.
10A popular example of sign-based stigmergy comes from the well known Tom Thumb taleby the Grimm brothers.
11With this we are not meaning that transferring lessons from the biology or entomologyfields to the social and human-centered research could be in any case either a feasible orconvenient process, although some inspiring and fecund passage can not be beforehand denied.Specifically, many reservations in adopting the concept of stigmergy as it is and considering itcentral in human coordination can be raised since, obviously, human beings are not prettysimple stimuli and response animals and can make an articulated and manifold sense of signs,according to their structure, their meaning and the culture in which they are left (cf. [Bourdieu,1977]).
19
CHAPTER 1. INTRODUCTION AND MAIN MOTIVATIONS
or add-on awareness, respectively (see Section 1.3). In fact, besides the works
we have mentioned above, a number of other studies have showed how co-
operative actors even transform the physical environment [Kirsh, 1995] to
interact and represent tasks: notable examples are derived by observations
carried out in airline cockpits [Hutchins, 1995], control rooms [Heath and
Luff, 1992,MacKay, 1999] and hospital desks [Bang and Timpka, 2003].
1.5.1 Artifact mediated cooperation
In the following, we will limit our discussion on pretty well delimited, special-
ized and standardized portions of the environment, i.e., the physical artifactstherein used. According to the authoritative Oxford English Dictionary, the
word artifact entered the English language in the mid 1800s, and from then
on, it has indicated any material that has been shaped by humans through
some kind of practical skill or art12. Although Dobres has rightly noted that
the concept of artifact privileges the processes of tool creation over their actual
use [Dobres, 2000], we know from the fields of archaeology and anthropology
(e.g., [Miller, 2004]) that to recognize an “artifact” from an undifferentiated
object within the environment is akin to an interpretative act of its user, as a
member of a work arrangement where both the expectations on the artifact
and the actual use that people make of it are socially and culturally situated.
Among the very disparate purposes that can be implied by the use that
cooperative workers can make of almost any artifact at their disposal, some
contributions from the above referenced literature have concentrated on those
kinds of artifact that have been respectively denoted with the attributes cogni-tive, knowledge and coordinative.
Cognitive artifacts have been defined both with respect to their concep-
tion and their use: Norman defines them as artifacts “designed to maintain,
display, or operate upon information in order to serve a representational func-
tion” [Norman, 1991]; while Hutchins, on the utilization side, defines them
as those artifacts that are used by actors to aid, enhance, or improve their cog-nition [Hutchins, 1996]. Both these complementary characterizations stress
the function of cognitive artifacts of being supportive of the human abilities of
reflecting on things, remembering, solving problems and accomplishing com-
plex tasks, either within the personal and individual dimension where actors
interact directly with the artifact at hand, or within the collective dimension
12The word artifact is a combination of two Latin terms, ars (art) and facere (to make).
20
1.5. FOCUSSING ON MEDIATED COOPERATION
in which multiple actors work together and communicate also with the medi-
ation of their artifacts.
When artifacts are primarily used to objectify how people within an orga-
nization and community organize their “memories” about their experiences,
their work and the involved knowledge that allowed them to solve prob-
lems and make proper and timely decisions [Seiner, 2001, Bandini et al.,
2003], artifacts can be denoted as knowledge artifacts. Although the concept
of knowledge is one of those on which it is almost impossible to achieve
widespread agreement, Seiner defines knowledge artifact as any “defined
piece of recorded knowledge that exists in a format that can be retrieved to
be used by others” [Seiner, 2001]. Traditional examples of knowledge arti-
facts a la Seiner are dictionaries, thesauri, classification systems, encyclope-
dias (cf. [Headrick, 2000]) but also cooperative settings provide several ex-
amples since any manual, internal report, bulletin and circular can be consid-
ered a knowledge artifact, as long as it “incorporates” some core competencies
and “best practice” that members of a cooperative group can refer to to solve
problems and add value to their activities. Bandini et al., on the other hand,
stress on the way such externalized knowledge [Nonaka and Takeuchi, 1995]
is really shared within a certain community of practice and on the way such
artifacts are collectively defined as the result of a progressive stratification of
experiences and ad hoc practices of use [Bandini et al., 2003].
When such or similar artifacts are used for coordination purposes, the term
“coordinative artifact” was proposed in [Simone and Schmidt, 2000] to de-
note their capability to help actors in managing task interdependencies that
are too complex to be managed with ad hoc interaction and improvisation
based on mutual awareness. Coordinative artifacts can achieve such articulat-
ing capability in a number of ways (cf. e.g., [Heath and Luff, 1996a]) both
in a intra-setting dimension and in a inter-setting dimension. In the former
case, they are informational structures describing the current state of affairs
in terms of responsibilities, current activities, plans for future actions and the
like. In the latter case, they can be assimilated to the concept of boundary ob-jects [Star and Griesemer, 1989,Bowker et al., 1997], that is of objects used “at
the borderline” between different groups and communities of practice to sup-
port the articulation of activities occurring across their either physical or social
boundaries in virtue of their capability of adapting to different viewpoints and
maintaining their own identity across them.
21
CHAPTER 1. INTRODUCTION AND MAIN MOTIVATIONS
The important point about coordinative artifacts is that they exert their co-
ordinative function both in virtue of their shape and structure and of the waysthey are put in use, i.e., for the correlated practices of use. The relationship
between artifacts and coordinative practices has been articulated in [Simone
and Schmidt, 2000] into three general use modalities: coordinative artifacts
can be used by competent actors either as (a) templates, when they specify
the properties of the result of cooperative work; (b) maps when they spec-
ify interdependencies of tasks or objects in a cooperative arrangement; or
as (c) scripts when they specify a protocol of interaction. Several examples
can be given for each of these categories as they can be drawn from sev-
and Wagner, 2002b]): forms, drawings, manuals, list, spreadsheets, even MS
Word documents. The point of these reports is to shed light on the fact that
although different artifacts like product standards, organizational charts or
production schedules are used for different purposes according to the context,
that notwithstanding they all share the capability to assists actors in reducing
the complexity of coordinating their activities by either embedding, circum-
scribing or just referring to actions, in the same way as the physical and social
circumstances do [Suchman, 1987].
The conceptualization of the strict interdependency between coordinativeartifacts and cooperative practices has been further characterized by Schmidt
and Wagner when they introduced the concept of ordering system [Schmidt
and Wagner, 2004]. An ordering system is any complex cluster of interrelatedpractices and artifacts that due to their mutual entanglement do not limit
themselves in representing the material world (a function that can be exerted
also by simpler cognitive artifacts), but rather they “are in the service of im-
posing some order” on it. Ordering systems are then seen as particular sets of
inscribed coordinative artifacts13 that do not only play the mere role of repos-
itories where “actors express items of coordinative relevance in a durable and
yet mobile form” so that their colleagues can revisit such items at a later stage.
Such coordinative artifacts are rather capable of coordinating actors and ac-
tions in that they “concatenate and configure items in certain spatiographical
ways” [Schmidt and Wagner, 2004] and explicitly refer to the protocols and
13Here again, we stress on the fact that we limit our attention on inscribed coordinativeartifacts. In so doing we purposely choose not to consider as relevant for our purposes themyriads of handmade objects and tools that can be used to coordinate with each others. In thisway, moreover, we introduce our main domain of interest — the documental one.
22
1.5. FOCUSSING ON MEDIATED COOPERATION
conventions in which such orders make some sense to the intended actors.
Both artifacts, and the practices in which they are used, contribute in stipulat-
ing and mediating the articulation of distributed activities: artifacts in virtue
of their symbolic and standardized nature; and practices due to their conven-
tional and predictable nature.
Such two components are so tightly intertwined that Simone and Schmidt
coined the term coordination mechanism [Schmidt and Simone, 1996] to de-
note an artifact-practice dyad consisting of a coordinative protocol “imprinted
upon” a distinct artifact, which becomes a coordinative artifact in that it stipu-
lates and mediates the articulation of activities so as to reduce the complexity
of a certain cooperative work arrangement.
The idea that artifacts can be characterized by something “visible and exte-
rior” that is shaped and characterized by something that is therein “concealed
and interior” comes from an intuition by Norman in which he distinguishes be-
tween a ‘surface representation’ and an ‘internal representation’ of cognitive
artifacts. While the former regards displaying and interacting with inscrip-
tions, the latter can be ascribed to the protocol by which actors handle and
use the artifact in their work trajectories [Schmidt, 1994b]. The ‘surface rep-
resentation’ of a checklist, for instance, provides an adequate interface to the
‘internal representation’ in that the sequence of scheduled tasks that are pre-
scribed by the protocol is represented graphically in the tabular form of a list
and for each task there may be a check box that indicates the state of execution
of the protocol.
The seminal idea of making automatically change the ‘surface represen-
tation’ by executing the ‘internal representation’ expressed by the scripting
protocol and the requirement of making operational and computational the
concept of coordination mechanism led to the idea of embedding some com-
putational capability to coordinative artifacts, so as to make them also active.
The notion of active artifact was then proposed in [Divitini et al., 1996, Divi-
tini and Simone, 2000] to denote those artifacts that are capable of assuming
an active role in mediating information exchange and coordination among co-
operative actors. In the original proposal, active artifacts were intended to
incorporate aspects of the protocols and conventions by which information is
exchanged through the artifact itself. With such “scripting addition” artifacts
can automatically convey changes to their content that have been induced by
some actor to other actors and components of the system, in the appropriate
23
CHAPTER 1. INTRODUCTION AND MAIN MOTIVATIONS
form stipulated by the protocol iteself. The active behavior embedded in the
artifact is intended to promote both task alignment and mutual awareness, by
materializing and making visible the state of the distributed procedures and
conventions holding in the current context of a given cooperative setting. This
is achieved by providing actors with appropriate information in presence of
particular conditions in terms of either voluntary (awareness) or compulsory
(coordination) indications to follow to have the work done as expected [Si-
mone and Schmidt, 1998].
1.6 Toward a support of mediated cooperation
The main underlying idea of our proposal is that of starting from the concept
of an active coordinative artifact that embeds in itself a number of conventionspertaining to its structure, content and use. As we have already mentioned
above, we have chosen the term convention to informally denote something
akin to a descriptive — rather than prescriptive — mechanism of interaction,
i.e. to the immaterial protocol component of a coordination mechanism that
regards the very “conventions” that actors have agreed upon to manage their
local cooperative work setting.
In order to understand the nature of the information such mechanisms
could convey, we undertook an observational field study to collect real in-
formation requirements of the cooperative actors involved in a domain that
for its characteristics and challenging complexities has been widely studied
within the CSCW literature: the hospital-based healthcare14. Within this ref-
erence domain, we have recognized the often amazing abilities that practi-
tioners articulating their tasks exhibit on-the-go by relying on verbal, prox-
emic interactions and often tacit and underspecified conducts [Coiera, 2000].
And — what has also surprised researchers from almost forty years ago (cf.
Harold Garfinkel and Anselm Strauss) — we observed that such ad-hocness
and informality are coupled and cohabit with strict demands for trust and
accountability mediated by a very composite and heterogeneous ensemble of
artifacts playing a multiplicity of roles and functions.
This posed us the tough challenge to envision a generic class of computa-
tional supports that could facilitate articulation work while being almost com-
14In the following we will often refer to such domain calling it clinical domain, for our focuson actual observation and treatment of disease in patients rather than hospital experimentationor teaching.
24
1.6. TOWARD A SUPPORT OF MEDIATED COOPERATION
patible to and least disrupting of the often situated practices by which prac-
titioners align their actions and delegate tasks to each other. Consequently,
we focussed on the phenomenon of awareness and were motivated to observe
how practitioners actually retrieve from that composite “web” of artifacts the
information they feel to need to be aware of.
Our proposal also considers to put each single digital counterpart of those
artifacts into a tightly interconnected ensemble of other similar coordinative
artifacts that share their content as well as their conventions and sensibilities
to contextual elements. We have denoted such integrated ensemble a web,
both to refer to the communication flows which are enabled by the computa-
tional capabilities of the artifacts involved and to hint at the set of relation-
ships that are defined and drawn among structural and content elements that
such artifacts carry on.
This idea of putting such active artifacts in common, both as regards their
content and their local conventions of use represents the endeavor to decline
the concept of active artifact that we have just mentioned in Section 1.5.1
in the wider application domain of common information spaces, recalled in
Section 1.4.1.
The idea of calling the ensemble of interconnected artifacts a web, has also
been inspired by the research that Bardram and Bossen accomplished about
clinical work [Bardram, 2000]. They introduced the concept of “web of coor-
dinative artifacts” [Bardram and Bossen, 2004, Bardram and Bossen, 2005b]
as creative analogy by which to analyze how coordination is achieved when
practitioners do not use just one artifact, like a schedule, but rely on “sev-
eral heterogenous artifacts, like schemas, charts, lists, whiteboards [which]
all play a multitude of different roles, but are at the same time highly inter-
woven” [Bardram and Bossen, 2004]. The entangled nature of this web refers
to the fact that they offer different views upon the same information while at
the same time peculiar functionalities are provided depending on the context
and the information.
In the rest of the thesis we will focus on a particular class of coordinative
artifacts, i.e., the class of standardized and institutional inscribed artifacts that
compound a documental system: i.e. documents.
Our motivation relies on two main considerations: the former has been
mentioned when we said that structured documents pose important challenges
in the concretization of a documental common information space (see Sec-
25
CHAPTER 1. INTRODUCTION AND MAIN MOTIVATIONS
tion 1.4.1). The latter regards the evidences we collected from our obser-
vational studies that confirm other contributions from the specialist litera-
ture (e.g. [Luff et al., 1992, Berg, 1999]) reporting how documents, as flexi-
ble but yet task-constraining coordinative artifacts [Schmidt, 1997] (see Sec-
tion 1.5.1), play an essential role in coordinating work and enabling syn-
chronous as well as asynchronous collaboration [Strauss, 1985]. In addi-
tion to that, we observed how documents, as components of integrated yet
heterogeneous sets of documents (i.e., documental systems) play a whole
range of coordinative functions according to the practice they mediate [Berg,
1999,Bardram and Bossen, 2005b]; while — at the same time — they also play
the chief functionality they are used for: informing actors and providing them
archival memory for distributed and asynchronous knowledge sharing [Ban-
non and Bødker, 1997, Harper and Sellen, 1995, Star and Griesemer, 1989].
Maintaining this twofold functionality is of paramount importance when a
cooperative setting needs to transform its documental ordering systems from
paper-based traditional artifacts to their digitized counterparts.
In the following chapter, we will outline the main characteristics of the
documental domain and those aspects of the document-based practices in co-
operative work arrangement that we deemed of interest for a feasible and
unobtrusive deployment of a computational support to make sense and use of
what is recorded within official records and institutional documents.
26
Chapter 2
The documental domain
Among the myriads of artifacts that the human species has produced to shape
and tame its surrounding environment, documents are not the oldest, but cer-
tainly ones of the most versatile. A document can neither hone a lance nor
cook a fish but it can tell who reads it how to. Documents are the tools by
which the humankind reifies its voice and preserves it from the oblivious tran-
sitoriness of its verbal utterances.
Memory was only the first of the human faculties that documents were
intended to support and augment, since when the very first inhabitants of
permanent agrarian encampments began to need to count their property or
transfer that property to another individual, almost ten thousand years ago.
Across centuries, with the evolution of writing systems and the increase of the
number of people that could read them, documents have more and more ef-
fectively supported their users in generating and conveying meaning, building
and sharing knowledge, as well as in instructing and sharing information with
others in almost any sector where verbal and co-located communication is not
just enough.
Nowadays, it is very difficult to think of any productive sector of our soci-
ety, as well as of any other culture or human society, where documents are not
present in some form, and do not play the pervasive role of either silent wit-
nesses or passive support of our activities. It has been estimated that, in 2004,
white-collar workers have spent from 30 to 40 percent of their time in dis-
tributing, filing, and retrieving documents, while just seven years earlier they
spent a quarter of their time in managing documents; and that more than
85 percent of all business information exists in documental form1 [Gordon,1IN such estimates by Merrill Lynch & Co. Inc. documents are opposed to structured data
27
CHAPTER 2. THE DOCUMENTAL DOMAIN
1997,Blumberg and Atre, 2003].
Despite documents’ pervasiveness, and right because of their versatility, to
wonder “what a document is” (cf. [Buckland, 1997]) is not a futile question.
Indeed it is a fixed course toward speaking of documental systems — i.e.,
functionally integrated groups of interrelated documents — and to then be
able to propose some computational means to make such systems more and
more supportive of human work.
2.1 An operational definition of document
Contributions by researchers as Paul Otlet and Suzanne Briet — dating from
the very foundation of documental science at the beginning of last century —
proposed to consider as documents as any object (or even any expression of
human thought) that is functionally capable to inform its user by representing
a physical or conceptual phenomenon [Buckland, 1991b]. Among the several
definitions given in various domains and for different scopes, some stress the
textual dimension, while others the fact that documents are such if they fur-
nish evidence or official, first-hand information [Buckland, 1997]. In order to
avoid the risk of missing some relevant features of the documents our research
is about and of considering almost anything as a document2, we shall adopt a
narrower acceptation of document.
For our practical purposes, a document can be defined as “anything” hold-
ing some inscription that bears some relevant information. Information-as-thing, has been the suggestive definition of Buckland for documents, in that
they are particular artifacts having the specific function of imparting knowl-
edge or communicating information [Buckland, 1991a]. Materiality, indeed,
i.e., the quality of documents of being material, usually paper-based, is a re-
quirement that documents are increasingly relaxing in their ability to docu-
ment, probably as one of the many consequences of being in the so called
“digital age” where content — i.e., what only actually can be digitized — is
more relevant than medium. Accordingly nowadays, in an increasing number
of domains, a document is deemed as any “information container”, irrespec-
within databases and encompass “electronic” documents like e-mails, reports, letters, whitepapers, presentations and WEB pages.
2We note that the same risk has also been skimmed over by the term “artifact” in the variousspecialist literatures where it has been used, perhaps for their fundamental role in mouldingthe human existence.
28
2.2. DOCUMENTAL SYSTEMS AND COOPERATIVE WORK
tively of the media or format involved to convey its associated information
(e.g., audio, visual, on paper, in digital form)34 and Heath et al. rightly speak
of documents as “the artifacts, par excellence which has been transformed by
digital technology” [Heath et al., 2000].
Giving such a general definition leads us in making a preliminary but yet
important point. We acknowledge the vastness of the subject and hence waive
any claim of comprehensiveness: as said by Hughes and King, documents have
some generic properties as well as properties related to their use within par-
ticular domains [Hughes and King, 1993]. The former regard aspects that are
independent of any specific and particular context of use, like their generic
functionalities, and their interactional properties. These are properties that
account more about the work that has been done about documents, in their
design and construction, rather than about how they can reflect or record work,
i.e., how they can be of any use in a given work arrangement. Conversely, the
latter properties are socially-defined, even highly-situated and regard “gener-
alized descriptions of social practices and conventions” whose study requires a
detailed examination of the specific domains of use [Hughes and King, 1993].
2.2 Documental systems and cooperative work
Before surveying the main contributions that tried to characterize the main
generic properties that documents can have, almost irrespective of the do-
main in which they are used, we first circumscribe our discussion by explicitly
stating that we focus on documents from the peculiar perspective of CSCW,
i.e., that of documental systems that support cooperative work.
Even limiting our attention to work settings, the above mentioned defini-
tions for the term document imply considering documental work domains as
any work setting where informative artifacts like emails, textbook, manuals,
4To briefly indulge in terminological digression: originally (mid-1950s), the term documentreferred to only files created by a word processor application. After the introduction of theMacintosh by Apple in the mid-1980s, every data file was called a document, irrespective ofwhich software application created it, as long it was not an executable file. Microsoft adopted arather similar terminology and set in its worldwide operating system a ‘My Documents’ folder,where all personal data could be stored as a default (cf. Computer Desktop Encyclopedia,Computer Language Company Inc., 2006. http://www.answers.com/topic/document, accessedAugust 30, 2006.).
29
CHAPTER 2. THE DOCUMENTAL DOMAIN
invoices, accounting files, word documents, electronic presentations and even
masks to databases do have something important in common: the ability to
provide someone with information useful for some action or activity and to
enable individuals to communicate and coordinate in any way but vis-a-vis,
across and within communities and organizations.
Our reference documents are those structured inscribed artifacts that sup-
port cooperative work where some not irrelevant degree of formality, official-
ity and reference to standards are predominant. This eliminates things like
sketches, maps, vignettes, ad-hoc memos, completely unstructured notes and
the like, which though we acknowledge can play an important role in mak-
ing actors understand how to articulate their activities (see e.g. [Schmidt and
Wagner, 2002b,Bardram and Bossen, 2005b]).
Structuring and standardization, yet, characterize institutional documen-
tal domains in disparate ways and with different degrees of formality. In some
work domains, for instance, the emphasis on the role of documents is stronger,
because they are used as instruments of control and power, within and betweenorganizations [Yates, 1993]. In the former case, upper management uses doc-
uments to convey and enact procedures and rules by which processes and
individuals at lower levels are monitored and evaluated; in the latter case
documents are employed to transact business (e.g.,trade) or make official
statements that must hold true for each stakeholder, unambiguously and for
definite time spans (e.g., manufacturing standards, formal contracts5). Other
documental systems, the majority indeed, are just considered set of support-
ive tools and information management technologies, embedded in practices
where their role is not as much clear-cut and is constantly remodulated by
practitioners according to the very situation and needs at hand.
Addressing documental systems from the CSCW perspective means to fo-
cus on the coordinative role of documents and to consider which technological
solutions can be conceived in order to enhance that particular role, without
being to the detriment of other roles. In fact, several authors (e.g., [Hughes
and King, 1993,Hertzum, 1999,Braa and Sandahl, 2000]) agree on that doc-
uments do play different roles in different work settings and even for different
practitioners in the same work setting: they can assume the function of be-
5Little wonder that the first written documents in human history are trade accounts fromthe Mesopotamic plain and that the first accounts of modern languages are usually notarialacts. For the Italian language, for example, the first written evidence is one act from calledplaciti cassinesi (ca. 960 a.d.), whose text is the following “Sao ko kelle terre, per kelle fini queki contene, trenta anni le possette parte sancti Benedicti”.
30
2.3. THE MANIFOLDNESS OF DOCUMENTAL SYSTEMS
ing either cognitive, knowledge or coordinative artifacts (see Section 1.5.1).
Moreover, what emerges from our and other similar and recent researches
(e.g. [Berg, 1999, Fitzpatrick, 2004, Winthereik and Vikkelso, 2005]) is that
documents are capable of exhibiting all those different natures in the same
work settings at the very same time. Likewise, Brown and Duguid speak of cen-tral and peripheral properties [Brown and Duguid, 1994], denoting with the
former expression the primary function, the main role a document can play
in a work setting, and with the latter all the secondary, extra roles that it can
anyway play even contextually. The main point is that what is recognized as
a central or peripheral property varies either within different communities of
practice, according to the stakeholder or even to the current purpose she is
accomplishing [Braa and Sandahl, 2000].
2.3 The manifoldness of documental systems
Levy claims that documents have both fixed and fluid properties, independent
of the media they are based on [Levy, 1994]. In fact, documents are the result
of the human need to rely on some stable, external, objective communicative
resource but, at the same time, their content must also be flexible6, i.e., able
to change over time (as trivial case just by mere accumulation of data) and
being updated — or tuned — according to the actual needs of their users7.
For their contrasting aspects, Hertzum speaks of multivoicedness of doc-
uments [Hertzum, 1999], and mentions the suggestive case of the clinical
record that according to Garfinkel contains at least two clear intertwined
voices: a voice reporting which clinician did what to the inpatients; and an-
other voice attesting that clinicians have honored claims for adequate medical
care [Garfinkel, 1967]. These two voices, which we also have clearly “heard”
during our field studies on clinical records, call clinicians for a delicate balance
between under-specification and rigor, between ambiguity and detail. They re-
spectively relate with the two categories of document values that Bikson and
Frinking call evidential and informational [Bikson and Frinking, 1993]. The
evidential value of a document is its value in providing evidence, e.g., about an
organization’s structure, its procedures, the therein undergone transactions
and the like [Hertzum, 1999]. The informational value of a document regards
6Cf. the concept of ecological flexibility given in [Luff et al., 1992].7Even if content did not change, in terms of wording, the very meaning it aims at conveying
could change according to the context.
31
CHAPTER 2. THE DOCUMENTAL DOMAIN
its capability to properly instruct people, to show and tell them how certain
things are, in one word, to inform whom uses them8.
Evidence and information are two main categories of documental value that
also other authors have referred to, e.g., when speaking of the archival and ar-ticulative function of documents [Hertzum, 1993,Cabitza and Simone, 2006].
The former regards support for storage, for preserving the evidential value
of the documental content (and hence for leveraging on the fixed properties
of documents) while the articulative one regards support for action and for
enacting the informational value into a particular work setting.
The contraposition that, regarding documental systems, refers to
whether they are more passive “repositories of information” or rather
“tools at work” [Berg, 1999, Fitzpatrick, 2004] is common to other
ethnomethodologically-informed accounts from the CSCW literature [Luff
et al., 2000]. For instance, to limit on those contributions that focus on our
same reference domain — clinical work — researchers have reported how the
very same document can superimpose central and peripheral properties for
the different groups of people that work with and on it. On the one hand, in
fact, clinical records are a tool that is supportive of the everyday work of the
hospital practitioners and hence they can be at the same time very faithful and
meaningful for competent readers but also lacunose and inaccurate for peo-
ple interested in their evidential value [Berg and Goorman, 1999, Hardstone
et al., 2004, Winthereik and Vikkelso, 2005]. On the other hand, records are
also tools to depict the transaction undergone between the hospital and the
patient in accordance with agreed medico-legal practices and hence its read-
ers must be aware of what is conventionally claimed and what is omitted for
the sake of accountability.
Several evidences (e.g., [Heeks et al., 1999, Berg and Goorman, 1999,
Hartswood et al., 2003]) have been collected that reckless drives to make
the digitized version of the clinical record a better legal document and admin-
istrative tool, i.e., a better evidential tool, tend to jeopardize the articulation-
oriented role of the record for intra and inter ward communication, for hor-
izontal and vertical cooperation and for the achievement of an accountable
quality of care. This means that any process of digitization of documental sys-
tems that exhibit the same manifoldness of clinical records must be informed
by some general requirements so as to limit the risk of deploying and imposing
8The reader should note that the word document derives from latin docere causative ofdecere, that stands for ‘to properly teach, to instruct’.
32
2.4. THE COMPUTATIONAL SUPPORT TO DOCUMENTAL DOMAINS
unbalanced or partial solutions on the cooperative work setting.
Grounding on literature survey reported above and finding confirmation
in the analysis we conducted for our field studies, we propose a minimal set
of requirements that we will refer to when in the next section we will treat
in some more detail the issue of designing computationally-augmented docu-
mental systems at support of cooperative work in documental settings.
Among the main requirements, we focus our attention on the following
three:
1. the preservation of the documents’ ecological flexibility [Luff et al., 1992]
— i.e., the possibility for people to enrich and adapt documents on-the-
go to a range of situations and contingencies — so as not to determine
action causally, but rather to influence further interaction [Schmidt,
2000] by conveying suitable meanings to recorded items;
2. the preservation of the documents’ evidential value [Bikson and Frink-
ing, 1993], which, along with their informational value, can support
actors in articulating activities and not just record them for archival pur-
poses [Berg, 1999,Fitzpatrick, 2004].
3. The enhancement of the documents’ capability to support actors in ac-
cessing and reconstructing the context of production of a recorded item
as well as to facilitate the conventional expression of contextual infor-
mation for its later use; or, as it also has been formulated in [Bannon
and Bødker, 1997], the ability of computer-based documental systems
to positively mediate the process of packaging and unpacking context
and informational items together when both are put in common.
2.4 The computational support to documental do-
mains
This last consideration leads us to consider which kind of support could com-
putational systems provide to documental domains in the light of the contrast-
ing requirements exhibited by cooperative work settings.
From their very foundation in the 18th century [Beniger, 1986], modern
states and bureaucracies have made a massive use of more or less structured
documents as the basic information technology that enable them to control the
33
CHAPTER 2. THE DOCUMENTAL DOMAIN
ever increasing — both in quantity and complexity — flow of information they
cope with to survive and thrive in their specific environment.
Consequently, the advent of data digitization and automatic data process-
ing has had an heavy impact on the ways documents are used (yet even con-ceived), stored and exchanged within and among human organizations and
communities: think of the role of, respectively, office automation, database
management and networking technologies (e.g., those devoted to the Elec-
tronic Data Interchange — EDI [Charalambos et al., 1995]) in changing how
people work and organizations “manufacture” and add value to their products,
whether goods or services.
This impact has not always been positive, or has always found the easy
acceptance of the final users involved. In the cooperative work domain, if a
comparison between effectiveness and suitability of traditional and computer-
mediated practices must be drawn, the goodness of results from the past thirty
years of work on providing effective computer support for document manage-
ment appears quite debatable, and in some cases reported in the specialist
literature even quite meagre [Hertzum, 1999,Berg, 2003].
An important point in the light of document digitization is that documents
employed in cooperative domains are intrinsically cooperative: they are sel-
dom written by a single person solely for her own use9 and this raises two
main caveats against simplistic rush for exploiting the recent office automa-
On the one hand, technologies employed to make electronic documents
more flexible and practical tools in the context of personal computing seem
to lack proper ways to overcome the most important requirement in facilitat-
ing information exchange and retrieval in cooperative settings, i.e., to make
explicit context of production and correlated vocabularies [Clement and Wag-
ner, 1995,Hertzum, 1999,Mark et al., 2002b]. On the other hand, information
technologies are usually intended to improve and support documental prac-
tice according to some quality reference model [Keen, 1980]. Such models
of proper production and use of documental content, with all their intrinsic
rigidities and constraints, could be quite easily displaced within “private” doc-
uments in favor of some personal idiosyncrasies with almost no harm10 but the
9This could rather hold true for some sort of private memorandum, a case that can be harkedback to the concept of cognitive artifact that we can purposely leave out in the following.
10Just to give an example close to everyone’s experience, how many people do actually com-pile the header data of an electronic document they are authoring — such as title, author,
34
2.4. THE COMPUTATIONAL SUPPORT TO DOCUMENTAL DOMAINS
opposite usually does not hold for documents that are shared by members of a
cooperative setting. Indeed, in a domain where documents mediate collabora-
tion and communication, and must guarantee at the same time formality and
comprehensibility, trustfulness and accuracy — all quality dimensions that can
regard even conflicting strategies of use — their digitization does require par-
ticular care not to result in obtrusive practices and unfeasible requirements.
To evaluate the extent failures can be circumscribed or avoided in any pro-
cess redesign activity driven by information technology, the first step is to un-
derstand what can be effectively supported by computational means and what,instead, risk to be out-of-reach of even the most sophisticated (and expensive)
solutions. As said above, we are not interested in document management, i.e.,
in problems, solutions and methods addressing information retrieval and data
storing. We rather focus on how to conceive a design-oriented framework for
the deployment of systems that can help people in making sense of documents
within a certain cooperative effort, rather than in managing them.
This is a challenging and quite unexplored task since, as Hertzum pointed
out, “it seems that many efforts to emphasize documentation and document
management have seriously overestimated the ability of documents to con-
vey meaning” [Hertzum, 1999], while the amount of work required to make
the producer and the consumer of a document understand each other on its
informative content is generally underestimated.
Such approach allows us to consider documents as much more than mere
sets of data: data contained in a given document must actually convey a spe-
cific meaning, at least within the local document’s scope, and are bound to-
gether by at least one simple relationship, which binds them with the purposefor which the document holding them has been conceived or used. For this
reason, documents also necessarily relate with the not-ever-trivial ways and
practices by which people make sense of a text, trying to contextualize its con-
tent both in the original context of its production and in the peculiar context
of their own tasks (i.e., the context of use).
2.4.1 Supporting documental practice
Computation is intended to augment documents in several ways and enhance
the manifold functions they have had before the advent of digitization: a nec-
essarily partial account of documentary functionalities would include to sup-
keywords — even if these data are undoubtedly useful for later retrieval and cataloguing?
35
CHAPTER 2. THE DOCUMENTAL DOMAIN
port people in recalling memories, getting informed, getting proof or evidence,
being instructed and learning and, last but not least, in communicating asyn-
chronously with their fellows, i.e., the conditio sine qua non of any collabora-
tive effort distributed in space and time.
To purposely limit ourselves to the very actions in which actors and doc-
uments interact, we can consider that actors cope with documents in creatingand using them to get informed. Along these two dimensions the proposal
we will outline in the rest of the dissertation has specifically focussed on two
very simple but effective kinds of enhancement that the electronic format has
brought to the documentary support11:
Support to making sensible documents (i.e., to writing)
Examples of the “support to composition” is generally provided by office appli-
cations, like spreadsheets and word processors, which in the last thirty years
have achieved a notable level of maturity. Spreadsheets augment the human
ability to arrange data in tabular ways and carry out even complex compu-
tations on them, while word processors can support writers in both properly
presenting and amending what they compose (even on the fly, as WYSIWYG12
editors and automatic spellcheckers can do). Support to composition does not
regard automatically imputed or corrected value without human supervision
and within an official authoring activity since this has revealed itself a very dif-
ficult task to automize for the current (and probably insurmountable) limits of
computer-based systems in text understanding and interpretation (cf. [Drey-
fus, 1978,Winograd and Flores, 1986]). That notwithstanding, faint successes
are reported in the field of knowledge management regarding automatic text
summarization (e.g., [Mani and Maybury, 1999]). Simpler but much more ef-
fective supports for writers regard, for instance, form-filling in: syntax check-
ers and type constraints can make writers understand which data on the form
are mandatory to be filled in and which is their proper format; again, in the
context of form compilation certain iconographic representations can be em-
ployed to make users understand how suitable or correct is a certain datum for
11Considering also “sharing documents” as elemental activity on documents can be usefulwherever the latter is an action that is explicitly accomplished by the actor. In our contextand for the following analysis we will accomplish on the documental domain, though, we candisregard such activity and hark it back to the activities of reading and writing according to thesetting at hand.
12This is the acronym for ‘What You See Is What You Get’ editors, that is systems in whichcontent during editing appears very similar to the final product.
36
2.4. THE COMPUTATIONAL SUPPORT TO DOCUMENTAL DOMAINS
the purposes intended (even indirectly) by the document (e.g., the soundness
of a password, the correctness of an address). This kind of basic support will
be also considered in our proposal, where active code exploiting knowledge
about the external state of the world will make forms become more “situa-
tionally aware” and “prompters” more sensitive to changes in their use and in
their compilers (cf. [LaMarca et al., 1999]).
Support to making sense of documents (i.e., to reading)
While the support to composition regards “who writes” a document, the sup-
port to information gathering and retrieval— i.e., in inquiring and being prop-
erly informed — is primarily intended for the reader. Who reads can in fact
be seen as the consumer of any documental system, i.e., as the person who
needs to have access to some information stored in documents in order to be
supported in some current tasks of hers. Hyperlinking and digital annotationare the most widely used — and simple, we would dare to say — technologies,
which has been applied to documents to facilitate readers in getting more in-
formation about a word, a concept, a topic, which the document in hand is on.
The former means, i.e., embedding cross-referencing a “hypertext document”
to other documents or other resources (e.g., pictures, videos, audio tracks), is
a way to suggest the reader a possible path linking data across different doc-
uments and to allow him to selectively go into information thoroughly. The
latter, i.e., annotation, is a way to add information to information or, in other
words, to provide data with metadata that can describe or better characterize
them. Although the term annotation is still a common and widely accepted
way to indicate the act of providing critical commentary or explanatory notes
to a certain passage or item within a document, such a term is also gaining a
slightly different acceptation within the specialist literature on web languages
and unstructured database management: in the former field, annotating is
conceived as a new form of communication in terms of added comments and
“marks up” overlayed on data that can be inserted by users/readers to ex-
change information with other peers (e.g., topic-posts, wikis, comments within
pdf, MS doc, web pages. . . ), while in the latter field annotation regards the at-
tachment or superimposition of particular metadata on pieces of view data to
track their provenance and hence to assess its quality and reliability (e.g., Biol-
37
CHAPTER 2. THE DOCUMENTAL DOMAIN
ogy DBMSs) [Buneman and Steedman, 2002]13. Also annotation is considered
in our application proposal, where users have been asked to characterize what
they write in terms of either predefined or user-defined relationship to which
conventions and corresponding computational mechanism can apply. This is
obviously seen as a support for whom will access data later on, in her task
of reconstructing the intended meaning and hence the context the compiler
referred to in her notes.
Summing things up
As a matter of fact, it is a difficult, and probably fruitless task to define a clear-
cut distinction among the above just mentioned functionalities, even along the
two dimensions of composing and getting information, which for our practical
purposes can be considered exhaustive. Reading and writing and, in the com-
municative case, understanding each other, are very often tightly intertwined
activities, which it is not only vain but also misleading to consider orthogonal
or independent. The example of form filling is significant, since who is sup-
posed to fill in a form is also engaged in a writing activity where information
retrieving about which data are requested, about how properly fill in them
into the document and about what the composers of the form really intended
and needed to know from those data, is obviously a conditio sine qua non to
properly accomplish the main composing task.
As a final remark, it is also important to be aware of the contextual nature
of documental activities. In a cooperative work setting, either accessing to or
filling in documents are not ends in themselves, but rather meaningful and
intentional activities that are embedded in some other higher-level task and
work context. This consideration has also reflected in the way we addressed
the analysis of how documental systems interact and get molded within and
across multiple lines of work. In the model we will describe in the next chap-
ter, in fact, we propose to explicitly distinguish between documental activitiesand work activities. The former ones are activities that directly pertain and in-
volve documents, namely accessing them and writing on them. The latter ones
pertain to the tasks of cooperative or articulation work, which can include doc-
umental activities and actually give them their specific purpose.
13As regards annotation standards and applications are still at the early stage, but someinteresting proposals are under development and (e.g., Annotea [Kahan et al., 2001])
38
2.5. THE “VIRTUOUS CIRCLE”: OUTLINE OF THE THESIS
2.5 The “virtuous circle”: outline of the thesis
It is now time to introduce a brief outline of the following chapters of this
thesis. In the rest of our work, we will then describe our original contribution
to the design and implementation of technologies supportive of cooperative
work, where this is mainly mediated (or traditionally supported) by (even
complex and multi-layered) documental systems: the WOAD framework.
The main aim of the WOAD framework is to address and characterize some
relevant concepts that could guide the design of a reference architecture for
computer-based documental systems in which the above mentioned require-
ments — informed of traditional paper-based practices — are to be preserved
and possibly enhanced.
The main components of this reference architecture are (a) the documents
that actors use in the execution of their own work, (b) a common information
space, which is common as regards the documents’ content and the conven-
tional practices of making sense of it; and (c) the computational application
of conventional practices that make the state of documents and information
space change according to the context of work.
The development of the WOAD framework is based on a so called “virtuous
circle” [Schmidt and Simone, 1995]: (1) starting from a real case study, (2)
abstracting it and generalizing our findings into a more general framework for
documental domains, and then (3) applying it back to the case study at hand
in order to see whether the users’ requirements could be fulfilled according to
the analytic dimensions characterized at framework level14
As a first step we have then carried out an observational study of how tra-
ditional, long and well-established paper-based technologies accomplish quite
seamlessly and smoothly the twofold task of supporting actors in both accom-
plishing their individual work and in aligning it with all the other individual
works theirs relies upon. For the session of ethnographic studies we have cho-
sen a paradigmatic context-sensitive and often critical domain: the domain of
hospital care. This is usually a very complex and multilayered arrangement
of actors and resources where documents, as parts of an integrated and com-
posite clinical record, are conceived as institutional triggers of commencement
14Obviously this cycle, for its reflective nature and limited scope, is not intended to providean ever-valid and universal benchmark for the framework. Rather, such short cycle gave usethe possibility to verify with the same actors we observed the validity of the assumptions takenin generalizing the collected evidences and of the functionalities envisioned to fulfill their re-quirements as regards their cooperative needs.
39
CHAPTER 2. THE DOCUMENTAL DOMAIN
of cooperative actions, and as legal repositories of their outcome. The ob-
servational studies have allowed us to detect which informational channels
and artifacts enable hospital ward practitioners to document and reconstruct
every time the complexity of illness cases that unfold over work trajectories
spanning over multiple work shifts, different professions, overlapping respon-
sibilities and distributed locations. We report on such observational studies in
Chapter 6.
The evidences collected in these empirical studies have then driven the
analysis of some relevant aspects of the way cooperative work and communi-
cation is mediated by standardized and structured documents. We have con-
fronted our observations with some recent studies that recognize the twofold
nature of documental system in providing their users both with an archival
and representational function of what happened in a given cooperative set-
ting and with an ordering and co-ordering function in virtue of the stigmergic
nature of records. Signs, marks, inscriptions, notes — left at different times on
different artifacts either unconsciously or purposely with the aim to commu-
nicate and inform next actions — refer to each other in a thick web of cross-
references that at analysis time we have characterized in its most general and
recurring patterns. Literature contributions on the nature of documents and
their role in cooperative work are reported in this chapter and in the previous
one.
Such analysis has informed a conceptualization of context that considers it
in terms of elements that, on the one hand, refer to the information structure
and content of documents and, on the other hand, refer to the events and con-
ditions occurring within the cooperative work settings. The conceptualization
of this twofold context is reported in Section 3.2.
Then, we defined a model of articulation in which the main entities and
relationships involved in document-mediated cooperative work are detected
and characterized in terms of a minimal set of attributes. This model, namely
the WOAD model is reported in Chapter 3, and more precisely in Section 3.3.
The model has then informed the proposal of a conceptual architecture
and of a multi-layered software architecture, in which the model entities are
mapped in proper components and their relationships are defined in terms of
constructs and functionalities of lower level, up to the physical level compo-
nents that implement the conceptual architecture. The architecture is reported
in Sections 3.4 and following ones.
40
2.5. THE “VIRTUOUS CIRCLE”: OUTLINE OF THE THESIS
Then we conceived a language (namely, the L*WOAD) encompassing static
constructs by which to express the model entities, and dynamic mechanisms
to represent the possible interactions occurring between such entities. Both
the WOAD model and notation have been developed in the light of the central
requirement of facilitating the putting in common of any information docu-
mental content refers to and of correlating that information with the context
of its production and use. L*WOAD is outlined in Chapter 5.
Then, our task has been to evaluate the descriptive power of the model and
the expressive power of the correlated language in both capturing the require-
ments raised from the field of work and in translating them in computational
mechanisms that a computer-based system could execute to support the artic-
ulation of cooperative activities. To this aim, we designed a still provisional
L*WOAD interpreter to have it encode into corresponding data structures and
implementation code the model templates we constructed at a more abstract
level of description.
Then, we have had a set of distributed and asynchronous rule-based en-
gines execute the L*WOAD compliant code by exploiting the functionalities
provided by a full-fledged middleware we brought to an advanced stage of
implementation during the research activity we have undertaken in the field
of ubiquitous and context-aware computing at the same time of our studies
within the documental domain [Cabitza and Dal Seno, 2005, Cabitza et al.,
2005c,Cabitza et al., 2005a]. Such middleware software, DJess, has been also
usefully employed by other researchers for their applications in the pervasiveand collaborative ubiquitous computing domains [Boselli et al., 2005, Cabitza
et al., 2006a,Cabitza et al., 2006b]. We report about the DJess communication
middleware for the deployment of context-aware and cooperative applications
in Chapter 4.
In order to assess the response of the involved clinicians in getting ac-
quainted with the awareness-provision functionalities that we implemented
in terms of computational mechanisms, we took the opportunity “to tweak”
a prototype application of electronic clinical record that a third-party IT firm
was commissioned to produce for the Neonatology ward of the hospital where
we took our observational studies. For administrative and interoperability con-
cerns, that prototype was never actually deployed but, quite surprisingly, for
that very reason it became a sort of sandbox where the designers of the IT
firm and the head physicians of the ward experimented with no claim of of-
41
CHAPTER 2. THE DOCUMENTAL DOMAIN
ficiality or exactitude their innovative and peculiar ideas of deeply involved
stakeholders.
On the one hand, the prototype’s designers were highly motivated in re-
alizing by means of standard tools and low-cost software platforms “catchy”
and innovative tools that could allow them become solution providers into the
application domain of public and private healthcare: a market where poten-
tial buyers are countless (especially in the quite underdeveloped domain of
Italian healthcare) but no vendor (neither the main international corporate
companies) can claim to have the “perfect” and catch-all solution (and nei-
ther the “standard one”). On the other hand, the head physicians of the ward
at hand — likely for historical reasons regarding the extent technology has
always yielded many notable successes in the very field of neonatological in-
tensive care — were highly motivated in pursuing better and better tools to
effectively support clinical practice, get higher care-related outcomes and help
them in getting more qualitative records to base their research and audits on.
In this particular and highly motivating situation we proposed our
cooperation-oriented layer on top of the above mentioned prototype as ad-
ditional application at support of their informational requirements as regards
the cooperative dimension of their daily work. We report on the implemented
functionalities in Chapter 7.
Chapter 8 concludes the dissertation with a brief account of the main
achievements of our research, a comparison with other similar approaches in
the literature and an outline of the main directions in which we could develop
the WOAD framework.
42
Chapter 3
The WOAD framework
The core of our proposal results into the WOAD framework (an acronym from
Web Of Documental Artifacts and pronounced / woUd/ as the homonymous
plant – see Fig 3.1).
3.1 Main aims and assumptions
WOAD is a conceptual and design-oriented framework intended both to sup-
port (a) the analysis of the informational requirements that actors involved
in a collaborative documental domain can exhibit; (b) the development of a
document-based platform enabling “coordination-aware” and “context-aware”
applications for the use of digitally-augmented documents which, by putting
in common their content all together with the correlated meanings, could sup-
port their users in coordinating within distributed, asynchronous settings.
As such, the WOAD framework encompasses
• a model for the description of document-based articulation work that is
based on a formalization of the concepts of resource and activity. This
model has been used to be the basis of a design environment targeted to
the specific class of systems that are supportive to cooperative work by
means of awareness provision and support to work convention interior-ization [Nonaka and Takeuchi, 1995] (see below).
• a high-level and a software architecture describing the main components
of a distributed software system in which both contextual information
and conventional interpretations to such context can be shared and pro-
cessed. Such architectures have been inspired by the metaphor of web.
43
CHAPTER 3. THE WOAD FRAMEWORK
Figure 3.1: A woad plant, Isatis tinctoria in the family Brassicaceae
Accordingly, a documental system can be seen as an interconnected set
of resources (i.e., data or artifacts), where interconnections represent
relationships and flows between resources and web nodes represent the
resources themselves.
• a denotational language, denoted as L*WOAD, by which to represent
contextual information and manage specific mechanisms to provide
awareness information depending on such context.
• a set of general and application-independent requirements — like mod-
ularity, extensibility, reactivity, correlatability — which are related to the
properties of L*WOAD for the design of context-aware and awareness
providing computational systems. Such requirements are intended to in-
form the collection and analysis of application-level requirements, like
those we derived from an ethnographically-informed study of paper-
based routines in two non-computerized hospital wards.
As seen in Section 1.1.1, cooperative work is a human social phenomenon
that poses a number of partly unresolved challenges to computer science and
technology: specifically, the WOAD framework focuses on two of them, the dis-tributed and heterogeneous nature of cooperative domains. On the one hand,
collaborating actors and their interventions can be distributed, both in space
— over more settings — and time — e.g., across multiple non-overlapping
shifts — and this can lead to the impossibility to share some common con-
text and have the very context of action lost or inaccessible for any practical
44
3.1. MAIN AIMS AND ASSUMPTIONS
purpose. On the other hand, collaborating actors can be highly heterogeneous
as regards a number of aspects, like education, experience, motivation, re-
sponsibility, function and the like. This heterogeneity can lead to the need to
manage multiple perspectives within a single cooperative arrangement and
to even cope with incommensurate ones [Schmidt, 1994a]. Accordingly, the
main aim of the application of the WOAD framework to the process of design-
ing computer-based supportive tools is twofold.
On the one hand, computational systems that are conceived according to
the proposed framework would address the issue of how to support practi-
tioners and users of a complex documental system in making sense of what is
recorded within the documents. Understandability and exploitability of doc-
umental content obviously depend to a very high extent on the very content
and the very actors that use the documents at hand. That notwithstanding,
also the documental platform can play a relevant role, e.g., in its capability
to support content producers and consumers in, respectively, packaging and
unpacking context into and from data (cf. Section 1.4.1). With regard to this,
the WOAD framework puts some emphasis on correlations and provides some
explicit ways to represent and manage them by means of specific mechanisms.
In Section 3.3.3, we will see that WOAD correlations can be set both between
data either within the same or across different artifacts of the same web of
documents.
Conventions are another key concept within the WOAD framework, since
much of the meaning that producers can “package in’ and consumers “unpack”
from raw content relies on more or less officially established conventions and
agreed interpretations, the same kind of procedural “knowledge” that Wenger
says it defines any community of practice [Wenger, 1998]. Conventions can
then be defined as “rules or arrangements established in a group, common
and accessible to its members, that users need in order to cooperate effec-
tively with the system” [Mark et al., 1997]. Conventions are an important part
of articulation work, e.g., since they “enable people to keep track of, and pre-
dict processes, for example, of stages of document completion” [Mark, 2002].
They are also a valuable means to merge various perspectives and “for new
members to smoothly adapt to work, such as when a group’s membership is
dynamic”.
For all these reasons, the second main aim underlying the WOAD frame-
work proposal is to conceive and design systems that, by providing actors with
45
CHAPTER 3. THE WOAD FRAMEWORK
proper awareness information, could support them in understanding, learning
and progressively adopting the conventions that in a given community have
been established and constantly adjusted by its members in order to cope both
with documents and the working context. This would also help actors in recog-
nizing documents as coordinative artifacts that are able to link work practices
together [Braa and Sandahl, 2000], in virtue of the conventions by which doc-
uments within a physical environment and their data within the documents
themselves can “stigmergically” give useful cues about what to do next, how
and why. Under this point of view, awareness could right become “an active
learning device” [Mark, 2002] by which organizational conventions are pro-
gressively learned and aptly made ready-at-hand to counterbalance the risk of
breakdowns due to incommensurate perspectives.
The WOAD framework has also been conceived to shed some light on some
particular aspects of computer-based technologies supportive of human ar-
ticulation work. The latter is a very complex phenomenon encompassing a
myriad of different settings and situations, for which a number of approaches
have been proposed in the specialist literature. For this reason, the framework
only concentrates on some relevant aspects of the manifold coordinative role
documents play in real work settings, while it neglects many others either
unwittingly or purposely, for the sake of the uniformity and compactness of
the framework. In order to clearly circumscribe the main tenets underlying
and influencing the WOAD framework, we explicitly claim some of the main
assumptions and aims that have been born in mind during its definition.
Fist of all, the WOAD framework focusses on “traditional” artifacts and
how they support cooperative work. Let us briefly consider these two aspects
in the following.
• “Traditional documental artifacts” is a generic expression that can de-
note paper-based forms, working sheets, records, manuals, notes; but
also emails, doc files and web pages: in short, anything that documentsboth how work should be carried out and how it is really done. The
main point here is to positively inform the design of computationally-
augmented counterparts of traditional artifacts so that these new tools
would not disrupt habitual documental and coordinative practices too
much. In fact, provided that any artifact digitization — and consequent
redesign of the correlated use processes — can not do without perturb-
ing a balanced situation, we espouse one of the main points of the CSCW
46
3.1. MAIN AIMS AND ASSUMPTIONS
debate: such interventions must limit the extent habitual conventions of
use are changed or distorted in order to prevent the risk actors bypass or
misuse the digital system to get their work done [Grudin, 1988, Bowers
et al., 1995,Pollock, 2005].
• Focussing on the ways documental artifacts support coordination means
to focus on the evidential value of documents and on their capability to
be used by distributed and heterogeneous actors in aligning their work
activities [Strauss, 1988]. Obviously, also the informational value that
documents contain does play an important role in informing and influ-
encing the actions that actors perform and therefore it can not fully
disregarded when analyzing how effectively and efficiently actors suc-
ceed in combining information into some form or reusable and sharable
knowledge [Nonaka and Takeuchi, 1995]. That notwithstanding, the in-
formational value is also deeply affected by a number of factors that
just set coordination aside, like the very nature of the documented con-
tent, the content management and information retrieval capabilities of
the artifacts and, last but not least, the familiarity of the community of
their users. For all these reasons, the informational dimension of doc-
uments is just a background element of the WOAD framework which,
from the computational point of view, is addressed by researches from
other fields, like the Knowledge Management, Document Management
and Information Retrieval ones (just to mention a few). Conversely, the
first class concept within the WOAD framework is the coordinative capa-bility of documents and its main focus is on how to preserve and even
enhance it whenever documents are to be digitized or are already in
digital form.
As a second point to make about the WOAD main assumptions, we con-
sider a clear-cut distinction between interaction and articulation, in despite of
the fact that we acknowledge the way actors interact with their artifacts is
just one side of the coin of assessing how documents are used in real cooper-
ative work settings. Here we recall the point made in Section 1.2.1, in which
we claimed that the WOAD framework focusses on what kind of awareness
information to provide actors with, and when to, rather than on the multiple
ways such information can be provided through the very artifacts at hand.
Accordingly, within the framework, the capability of artifacts to conveniently
display awareness information according to their representational mediums is
47
CHAPTER 3. THE WOAD FRAMEWORK
assumed without further characterization, provided that such information has
been conveyed to the presentation layer of artifacts according to its type, the
information it refers to, and to the current context of use.
Context is the last key concept we discuss in these preliminary remarks
on the framework main tenets and assumptions. As hinted before, the WOAD
framework is about the context-aware provision of awareness information oncontext. This is far from being just a mere pun, once the context-awarenessconcept is rightly related to some “reactive capability” of the supporting dig-
ital applications to be sensitive to the situation in which they are used so as
to be capable to aptly and timely convey to their human users, the actors,
some awareness information on that context1. This is perfectly consequent to
the main WOAD aspects mentioned above: the emphasis on correlations to
reconstruct the context of work and the emphasis on the role of awareness in
the processes of convention sharing and agreeing on.
The WOAD framework calls for a sort of “enlarged” acceptation of the term
‘context’, i.e., an acceptation that gathers both what the documental content
is about and the overall situation in which that content is produced or con-
sumed. That twofold conceptualization has suggested us to refer to context
with a specific term, context2. In fact, depending on the setting’s peculiari-
ties, concerns about the definition, characterization and then management of
contextual items, must be separated. We also stress the importance of context
awareness as a means to augment the supportive abilities of regular docu-
ments in their digitized counterparts. In the following section, we then get into
some more details about what we conceive as context, context2, and context2-
awareness.
3.2 Two contexts for one sense
The common acceptation of context is suggestively twofold, and there can be
some benefit in making both these nuances more explicit, especially in a docu-
1We are then aware that the expression “context awareness” could lay itself open tosome misinterpretation. Such expression has become a standard way to refer to the context-sensitivity and context-adaptivity exhibited by a recent and still under development class ofcomputational systems, those filed under the category of Ubiquitous Computing and PervasiveComputing and other similar labels. Obviously, also human actors can be “aware of the con-text” surrounding them and contribute in richly and variously characterizing it. Our point is onfocussing on how context-aware applications can support actors in being even more and betteraware of (some elements of) their context.
48
3.2. TWO CONTEXTS FOR ONE SENSE
mental domain where text is the main resource to get or produce information.
On the one hand — as an easy etymology seems to suggest — context is the
part of a text that surrounds a particular word or passage and hence either
completely or partly determines its meaning. Obviously, documents abound
with context since any text comes with its context, literally. Within tightly con-
nected documental systems — what from Section 1.1.1 we have called “web of
documental artifacts” — the requirement of word-proximity can (or ought to)
be relaxed: a piece of information can assume its real meaning (i.e., convey
what its producer really meant it to) according to different narrative threads
or reading levels. The latter can span through sections, forms and documents,
just like a small shard can be recognized as part of a bigger shape only within
the “big picture” of the whole mosaic. We denote this kind of context as tex-tual, or in-document context, since it primarily pertains to documents and their
content.
Also another acceptation of context must be considered. This kind of con-
text pertains to the external environment where actors live, work and make
sense and use of things, among which of the documents of the documental sys-
tem they work with: to paraphrase Moran and Dourish [Moran and Dourish,
2001], we can refer to this context as “all the relevant information regarding
the physical and social situation” in which documents fulfill the needs they
have been conceived and are used for. Since this kind of context encompasses
all the relevant circumstances in which an event occurs or a certain activity
is accomplished, it can be denoted as activity context, or by a more general
and higher level term, work context. These two contexts are not disjointed:
they are gathered by the practices of reading and writing, by the acts of “pack-
aging” information with its sense-making context into written form and then
“unpacking” [Bannon and Bødker, 1997] it when that recorded piece of infor-
mation is accessed again time later.
Within the WOAD framework, hence, we denote as context2 (square-
context) (see Fig. 3.2) a set of conditions that pertain both to (a) a set of
documents and (b) the work environment where they are used. The former
dimension is that pertaining to the structure and content of documents. In the
case of “records”, this regards what happened in the work environment in the
past, was deemed relevant, interpreted and recorded in written form, as well
as the way it was recorded and, possibly, the purpose, the meaning intended
for the reader. Conversely, the latter dimension regards the current situation in
49
CHAPTER 3. THE WOAD FRAMEWORK
Figure 3.2: Two kinds of contexts that pertain to documents in cooperative settingsand correlations among contextual items.
which documents are produced, put at work and the time they are consumed
to have them “speak” and report about the past. Such set of contextual con-
ditions is compounded by conditions that have all in common the property to
enable, inhibit, influence either (a) how actors make sense of documents and
correlated actions or (b) how actors manage their work trajectories through
the use of such documents.
Although the textual context can be said inside documents and the workcontext is outside documents, these two kinds of contexts are not in any case
and always independent of each other: what a text really means within a certain
activity can be affected by conditions occurring in the external environment,
both when such text has been produced and whenever it is accessed (i.e., “con-
sumed”) to get information “here-and-now”. For instance, work accounts that
we know have been made in condition of time-criticality or emergency can in-
form us even if they look sparse and incomplete, since we know that only the
very essential data have been recorded and the rest would not deviate from
what can be given for granted and hence interpolated at reading time. Con-
versely, a procedure manual on earthquake safety conduct differently informs
its users depending on whether they are conducting a drill or managing a real
case.
The opposite can hold as well, since what documents tell to people work-
ing in the field can provide important keys or clues to making sense of what is
going on in that field. Accordingly, work context can include activities tightly
related to documents, such as those of reading, writing and sharing them.
50
3.2. TWO CONTEXTS FOR ONE SENSE
These activities, in their turn, are included in some wider trajectory encom-
passing other activities in which document-related ones have their motivations
and purposes.
The WOAD framework proposes to make explicit contextual correlations,
so that items compounding the texture of a particular category of context can
be related and connected to even multiple items of the other. In so doing,
two mutual affecting sets of contextual information can constitute a basis to
provide the functionalities considered within the framework. By means of par-
ticular WOAD relationships, which we will further characterize later, an aug-mented documental context can be produced, as resulting from all the sense-
making relationships that characterize both the documents’ content and the
activities in which such content is either produced or consumed.
For the sake of clarity, we have also to make a point about the fact that
what we denoted as work context is also the closer to what the so-called
context-aware software applications are sensitive to. In the futuristic — but
yet quite probable — scenarios of the ubiquitous computing, usually symbolic
— but in any case computable — representations of context are derived and
extracted from the environment in which some “agents” act (irrespective of
their being human, proxy of human or just non-human agents). These rep-
resentations can pertain to various levels of abstraction: some can refer to a
more physical dimension, e.g., “it’s eight o’clock!” or “John and Ellen are in the
room”; while others to a more logical or social dimension, e.g., “it’s breakfast-
time!” or “John and Ellen are husband and wife”.
According to the tenets of the context-aware computing, all these hetero-
geneous representations of context are processed so as to make computational
systems more proactive and apter in fulfilling the ever-changing needs of their
users [Weiser, 1991]. As a consequence of such a wide-ranging goal, the term
context has been used in many ways in different areas of computer science
and technology. Accordingly, in the context-aware computing field, various def-
initions of context have been given, with the aim to operatively circumscribe
what software applications must be “aware of” so as also to make their users
“aware of” it. In this multitude of definitions, a general aspect can emerge as
a common trait of several contributions from the specialist literature: the con-
text is seen as a relevant set of characteristics from the environment that can
determine the behavior of an application and have an active role in influenc-
51
CHAPTER 3. THE WOAD FRAMEWORK
ing its branches and outputs2 [Chen and Kotz, 2000]. That notwithstanding,
we can also add that contextual information can be relevant to an application,
but it is not necessarily always a critical information (this kind of information
would more likely pertain to the inputs of the application at hand). Accord-
ingly, contextual information is “information about the surrounding”, and does
not always regard a “necessity of adaptation”, but rather “an opportunity of
interest”. In other words, context can be used either within imperative scripts
that must be executed whenever something occurs; or also within maps of
events that can possibly affect the behavior of some agent, according to the
contingent nature of these occurrences [Schmidt, 1997].
The either prescriptive and descriptive nature of context well correlates
with what we said about awareness as a phenomenon occurring in coopera-
tive work settings. We conceive of applications as context-aware if their be-
havior is affected by context, even if the strong requirement of deterministic
and reactive adaptivity is relaxed in favor of more user-centered informational
needs. Accordingly, applications can also be said context2-aware if they are
supportive in providing users with cues on what is going on around them, as
well on all those documental pieces of information that could facilitate them
in becoming aware of the real meaning that is relevant at a certain level of
reading.
All that said, it is easy to see that correlations and relationships play an
important role in characterizing context. In fact, what both the considered ac-
ceptations of context do have in common is the concept of interconnection,
reciprocal influence, mutual linkage3 (see also our [Cabitza et al., 2005a]):
documents with documents, information with information, and, as it is ut-
terly important in any cooperative effort, actor with actor, the users of such
an interconnected system of artifacts and cross-references. Context can hence
be seen from the operational perspective of the so called collaborative aware-
ness [Lauwers and Lantz, 1990] in that its interconnections can be taken from
the countless things that are ready-at-hand (and actors are not aware of) to
become something that must become present-at-hand and require the users’
attention [Winograd and Flores, 1986], according to some unpredictable in-
2Consequent to that definition, some time that acceptation is denoted with the expressionof “active context”.
3In fact, the very term context derives from the Latin contextus “a joining together,” fromthe verb contexere “to weave together,” from com- “together” and textere “to weave”. Texture— a synonym for network — and context share then the same etymology (moreover, textura isLatin for web).
52
3.3. CONCEPTUAL VIEW OF THE FRAMEWORK
formational need. Accordingly, users of a documental system can be supported
in getting aware of their work as it can be perceived once mediated by doc-
uments and interpolated by the practices of reading and writing documents
(see Section 2.4).
In the following, we shall characterize the way in which within the WOAD
framework context is symbolically represented and made object of compu-
tation so as to become a transformable set of elements. We will also show
how these transformations, which are carried out at symbolic level by com-
putational machines independently of actors’ direct control, are then used to
make actors more aware of the physical context surrounding them, through
the very same affordances of the documents where the context is recorded
during multiple work trajectories. We will characterize which kinds of aware-
ness information actors can be provided with by a computationally augmented
documental system; and how such information can be modulated on the basis
of the global state of a web of documental artifacts.
3.3 Conceptual view of the framework
Models and theories concerning the nature of cooperative work have long
been recognized as an important aid in the development of Computer Sup-
ported Cooperative Work (CSCW) systems [Chen and Rada, 1996, de Farias
et al., 2000], notwithstanding a prudent acknowledgement about the limi-
tations of certain kinds of models [Bannon, 1993] and their applications. Al-
though the tension between models as formal representations of work settings
and modeled situated actions [Suchman, 1987] must be always taken into ac-
count [Robinson and Bannon, 1991], models and theories can be seen as op-
erative tools intended to help designers and developers of cooperative systems
in focussing on the most relevant issues at an as early a stage as possible and
in structuring the system in a coherent way. The result of modelling consti-
tutes conceptual frameworks in which allegedly relevant domain knowledge
is explicitly represented and some of the most important aspects that concern
both cooperative settings and supportive computer systems are consistently
captured.
We can see modelling activity be mainly based on either a top-down ap-
proach or a bottom-up one, although in many cases this generalization results
in a too course picture of how models are conceived within the CSCW commu-
53
CHAPTER 3. THE WOAD FRAMEWORK
nity (cf., e.g., [Prinz, 1994, Schmidt, 1997, Frank M. Shipman and Marshall,
1999, Simone and Sarini, 2001]). In the top-down approach, the main enti-
ties characterizing cooperative work settings are conceived having in mind no
particular domain. Concepts are rather derived by considering the work di-
mension from an as general perspective as possible and then specializing it
into domain-specific cases. In so doing, the general concept of actor can be
specialized into a less generic class of patient, to mention an example from
the healthcare domain.
Conversely, in the bottom-up approach, usually some ethnographical and
observational studies of some particular work settings are taken as source of
information to understand which aspects are to be therein highlighted and
considered for further generalization. The generalized concepts are then con-
veniently applied to different domains than the studied one wherever and to
the extent possible.
As said at the beginning of this section, the WOAD framework is intended
for the documental domain. The proposed characterization of such domain
has been strongly influenced both by a survey of theoretical models done in
the past years within the CSCW community and, especially, by the studies
we carried out in studying a particular documental system, the clinical record
system that have been conceived within a populated region of northern Italy
and applied in two wards of the same provincial teaching hospital. Lacking,
to our knowledge, a purely theoretical model related to document-mediated
cooperative work and awareness provision, we have considered what could be
taken from some of the main models proposed within the CSCW field, such
as the Coordination Mechanisms [Schmidt and Simone, 1996], Cooperation
theory [Malone and Crowston, 1990], Activity Theory [Kuutti, 1991] and Ac-
tion/interaction theory [Fitzpatrick et al., 1995]. Our task has been that of ex-
tracting from such general frameworks a minimal sets of concepts which could
better fit the requirements and peculiarities of the clinical domain we studied
and, for generalization, of cooperative documental systems having similar re-
quirements and constraints.
From the most general point of view, the WOAD framework encompasses
a way to consider cooperative documental domains both from the static point
of view, which concerns with the structural4 dimension of the model, and the
dynamic point of view, which regards how the static structures get transformed
4Some others could also say such dimension “ontological”, since it refers to the “explicitspecification of a conceptualization” [Gruber, 1993].
54
3.3. CONCEPTUAL VIEW OF THE FRAMEWORK
over time by computation. The framework considers the whole information
that is treated within and outside the documents as something that can change
as the result of two different main factors. These are called either exogenousor endogenous factors depending on whether changes are triggered by events
in the physical environment, i.e., outside the computational one, or inside the
latter.
As regards the main exogenous factor, documental content and correlated
context can change according to the document-mediated interactions occur-
ring between actors or when actors directly interacts with artifacts, i.e., when
actors act upon documents by producing or consuming some information. This
cause of transformation is denoted with the term exogenous, since actors are
modeled as first-class entities of the framework, but not further characterized
in terms of attributes or behaviors: actors interact with the system, but from
outside it, as black boxes, and provide the computational system with some
inputs to process.
As regards the endogenous factor, the information related with the
context2 can also change because of the computational application of conven-
tional practices and interpretations that someway relate to that information.
This application changes the internal status of the computational system and
provides its users with some output in terms of data or coordinative informa-
tion. For our practical purposes — and consistently with the notion of context2
as something that may influence the behavior of applications and their users —
we can conceive of conventions and interpretations related to the meaning of
a piece of contextual2 information as behaviors that can be tightly referred to
that information.
From this point on, hence, by the terms convention (and likewise con-ventional interpretation), we mean conditional relational structures that relate
in a cause-effect, or condition-action, relationship an antecedent and a con-
sequent. The former refers to some contextual2 condition — for example, a
certain datum exists, or it has got the value X —; the latter refers to some new
condition that necessarily follows the antecedent ones or some behavior, i.e.,
sets of simple actions. These actions can be either autonomously performed by
the computational system or suggested to the involved actors as alternatives
to perform on a voluntary basis.
For example, when someone refers to a “red code” within the admission
form used within an emergency consultation at a hospital triage, a WOAD
55
CHAPTER 3. THE WOAD FRAMEWORK
convention could be expressed in terms of an association between such piece
of information and the fact that some actions must be accomplished as soon
as possible, like moving the patient into an emergency room and applying her
proper resuscitation interventions. In fact, in such context, “red” means very
severe health conditions of a patient and need for immediate intervention.
Conversely, if the very same code is used in the context of a daily hospital ward
routine, a completely different, yet conventional as well, interpretation could
be associated. In fact, red codes denote that a fire has broken out somewhere
in the ward and that the first things to do are to rescue patients, activate
alarms and contain smoke. Here again, the meaning of the red code can be
operatively reduced to the very actions those color conventions refer to and as
such be conveniently managed by a computational system.
Summing things up, we can see the whole ensemble of actors, artifacts
and information resources that are managed between, within and by artifacts,
as a transition system. The global and observable state of such system can
be conceived as the union set of all the informational resources that refer
respectively to actors, artifacts and their context2, as all their instances are
rendered in symbolical structures and “documented” within the computational
system. Such state can change according to external stimuli (from the field of
work) and to the data-driven application of computable representations of
conventional interpretations to contextual2 data.
In the following, we will characterize the main concepts and entities that
are represented within the global state envisioned by the WOAD framework.
In our discussion, we will bear in mind a clear distinction between three main
levels of description:
the framework level , in which the most general and domain-independent
concepts are proposed, within the broad domain of documental systems
intended for cooperative settings.
the domain level , in which the framework level concepts are declined, char-
acterized and represented according to the particular domain of interest,
e.g., hospital care, legal offices, or organizational bureaucracy.
the application level , in which architectural solutions, implementation en-
vironments and specific applications are proposed, which could best fit
particular work settings, e.g., the ward X in the hospital Y. Within such
level, the usual distinction between schema and instance level are con-
56
3.3. CONCEPTUAL VIEW OF THE FRAMEWORK
veniently applied to indicate classes and objects from those classes, re-
spectively.
3.3.1 The WOAD entities
As regards the static, or structural, point of view, the framework considers
two main entities, which for their generality are also treated in almost each
theoretical model considered, although with some differences: the concepts of
resource and activity (see Fig. 3.3).
Figure 3.3: The two main concepts within the WOAD framework
Both the concepts can be defined by means of each other. As regards the
concept of resource, with such term we denote just everything that can be used
or employed within an activity. Conversely, the conceptualization of an activity
as an ‘entity’ reifies and includes the set of events that — at a certain level of
description — can be correlated with the actions in which one or more resourcesacts or are used.
Figure 3.4: Activity levels for the documental domain.
As anticipated in Section 2.4, the WOAD model distinguishes between doc-umental activities and work activities (see also Fig. 3.4): the former ones di-
rectly relate with documents, i.e., regard the very actions of either gaining
access to documents — or parts of them — or writing on them — filling in
their fields. The documental activity granularity, i.e., whether an activity re-
gards a portion of a document, even a single field, or rather a collection of
57
CHAPTER 3. THE WOAD FRAMEWORK
sheets pertaining to the same matter, is left at the domain specifications and
its requirements.
On the other hand, the term work activity denotes a task-related course of
action, i.e., aspects of a work process that are relevant to doing a specific piece
of cooperative work with the available resources and that can be gathered un-
der the same ‘operational intent’ [Andersen et al., 1990]. We then define workactivities as capable of “containing” a number of documental activities accord-
ing to the granularity level activities are modeled within a given domain5. The
distinction that within the WOAD model is made between these two levels of
description is rendered into two different constructs that are defined by the
WOAD language (see Section 5.1.1).
Also the general concept of resource is further specialized into those of
actor, information and artifact (see Fig. 3.5). An actor is just the human agent
that acts within a given activity, i.e., the cooperative worker; information is
just something6 that can inform an actor and influence her activity; artifacts
are just “tools” that are purposely used, produced or modified within an ac-
tivity. Although the term “artifact” has been applied to a number of different
things in different contexts, for our practical purposes, we can adopt the accep-
tation of something that concretely and interactively mediates the production or
exploitation of information by some actor. Moreover, within the WOAD frame-
work we further limit the scope of analysis about artifacts, limiting ourselves
in considering documental artifacts, or just documents.
As regards the general model, the WOAD framework purposely leaves un-
derspecified the involved entities in terms of attributes, i.e., of intrinsic char-
acteristics. For instance, we deem that which specific resources are better to
consider, how to properly characterize them, as well as the very nature of ar-
tifacts and documents would depend too heavily on the peculiarities of the
domain at hand and that a further detailing at framework level would have
hindered the general applicability of the model. A further characterization of
the resources involved must be then applied at domain-level and, obviously,
at the design time of the application. The same holds for activities: further
specialization of activities into sets of smaller actions or their generalization
5In Fig. 3.4 we have not represented a concept of strict inclusion, but rather a “belong-ing” relationship between a documental activity and the containing work activity. See alsoSection 5.1.2.
6Mind, we use the generic term “something” to hint that information is not necessarily a datavalue, in its habitual acceptation, but can also be some perceivable change in the environment,as long as that informs the thinking or action of somebody.
58
3.3. CONCEPTUAL VIEW OF THE FRAMEWORK
Figure 3.5: The main concepts of the WOAD framework.
into more general tasks is left at the domain level characterization.
In order to support the designers of a certain domain in such task of defin-
ing and characterizing the entities that their computational system must cope
with, the framework also encompasses an operational language by which de-
signers are provided with a minimal set of predefined entity attributes (see
Chapter 5). These have been selected for a basic characterization of documen-
tal domains and for the convenient definition of computational mechanisms
for awareness processing and provision. To guarantee modularity and flexibil-
ity, the WOAD language also provides designers with proper primitives and
mechanisms by which to define their own attributes according to the specific
requirements of the domain at hand.
3.3.2 The WOAD relationships
The pretty symmetric definition given to informally define the concepts of re-
source and activity hints a mutual logical dependency between such general
categories. This is reflected by the main relationship that is considered within
the WOAD model. The bidirectional relationship between the concepts of re-
source and activity is denoted as Involvement: each resource can be involved
in no, one or many activities at the same time. Likewise, each activity can
involve no, one or many resources.
The involvement relationship can be further specialized according to the
nature of the resources and activities involved (e.g., whether the former are
data or actors, or the latter are documental or work activities). We distinguish
between (see Fig. 3.6):
59
CHAPTER 3. THE WOAD FRAMEWORK
• “involvement as pre-condition”
• “involvement as input”
• “involvement as output”
• “involvement as effect”
A precondition involvement occurs whenever an activity needs as necessary
(but yet not sufficient condition) for its execution that a specific resource exists
and has a certain property true. An input involvement regards the necessity for
an activity that a certain informational resource (i.e., a datum) exists7. That re-
source is then “fed into” the activity as an input with some property — e.g.,, a
particular value, or structure — to be processed and used for its accomplish-
ment. An output involvement occurs when an activity provides others with,
or produces, some informational resource8 or causes a preexisting resource to
have some particular property (e.g., to be “lower than 5”) as a consequence
of its accomplishment and processing. An effect9 involvement occurs whenever
an activity causes a resource, other than informational, to exist and have some
property as a consequence of its accomplishment, besides the informational re-
sources it worked on. For this reason effects are also called side-effect, in that
they are concerned with the consequences the activity has had on the rest of
the context in which it was carried out (e.g., the surrounding environment).
This very general conceptualization about the dyad resource-activity
adopts the so called IOPE model. This approach dating from the first works
in computing semantics (e.g., [Hoare, 1969]) deliberately focusses on in-
puts, outputs, pre-conditions and effects and it has been recently adopted in
the definition of modelling languages and related standards for the Seman-
tic Web [Cabral et al., 2004] (e.g., OWL-S [Martin et al., 2005] and WSDL-
S [Akkiraju et al., 2005]), after its first proposals in the Computing Seman-
tics [Hoare, 1969] and the Artificial Intelligence Planning fields [Eiter et al.,
2004]. The IOPE model allows us to express interdependencies between activi-
ties as particular cases of resource-based relationships (see Section 3.3.4).
7For the generality of its definition, preconditions can be also applied to inputs, e.g., that aninformational resource, x, exists and “is not null” or “is bigger than 5”.
8Here again, we limit the concept of input and output to that of informational resource withsome value.
9Others prefer the term post-condition, to draw a symmetry with the pre-conditions (e.g.,cf. [Bock and Gruninger, 2004].)
60
3.3. CONCEPTUAL VIEW OF THE FRAMEWORK
Figure 3.6: The involvement relationship cases.
The involvement relationship encompasses all the relevant cases in which
resources and activities are mutually related, at framework level. This means
that, for our practical purposes, the WOAD framework does not need to spec-
ify whether an actor, as a resource, has an active role within an activity, i.e.,
if she accomplishes it, or if she just plays a passive role, like those played
by an archival document. As we will see in Chapter 7, these and other sim-
ilar relationships are characteristics that pertain to either the domain or the
application level and hence they must be specified according to the peculiar-
ities of the settings at hand. Therefore, besides the involvement relationship
that connects resources and activities, the WOAD framework also considers
the two generic classes of relationships that occur between resources and of
relationships that occur between activities.
relationships between data Obviously these also are to be characterized at
domain or application level, but the WOAD model explicitly encom-
passes a particular kind of inter-data relationships: what we call cor-relation. We will treat them in some details in Section 3.3.3.
relationships between activities Also this kind of relationships can be vari-
ously characterized according to the domain at hand but, at framework
level, we propose a construct expressing a generic relationship of belong-ing. This can be used either to express strict inclusion, i.e., an activity in
which — also, during the which — some other is accomplished, or just
to give the designer the possibility to distinguish into at least two differ-
ent levels of abstraction, i.e., to map actual actions and operations into
more abstract sets of activities that regard the tasks conceived within
a cooperative arrangement. In so doing, the designer can also map the
management of the context pertaining to either textual items and work
61
CHAPTER 3. THE WOAD FRAMEWORK
items into two different kinds of activities (see 5.1.2 for further details).
How we consider the relationships that indicate some kind of depen-
dency between activities, e.g., causal and temporal ones, will be treated
in Section 3.3.4, where we give such particular kind of relationships the
name “interdependencies” and show how these can be harked back to a
particular kind of relationship between resources and activities.
3.3.3 Correlations between data
Correlations are a means to attach more info on data. Within the WOAD
framework, we denote as correlation a set of relationships between data, that
users and designers can use to create annotations or particular references be-
tween data. An annotation is usually a note added to a text but also, more
generally speaking, some extra information associated with a particular point
in a document or other piece of information.
From our studies on real work settings situated in the hospital care do-
main, we have detected how, for actors coping with data from multiple and
heterogeneous sources, the capability to explicitly draw linkages and refer-
ences between them can be important10. In [Cabitza et al., 2005b], we have
denoted the additional effort that is oriented to enriching stand-alone data
with references to other data as a kind of positive redundancy of data, just
to distinguish it from the redundancy of data that is not explicitly requested
by the involved actors to support their either cognitive or coordinative tasks.
Such “negative redundancy” results in superfluous information character-
ized by verbosity or unnecessary repetition and it is often associated with
time-consuming practices that are usually perceived by clinical practitioners
as a waste of time, like filling in administrative data and other secretarial
tasks. Data redundancy, in its neutral acceptation, concerns information re-
sources used to accomplish tasks and characterizes those organizational set-
tings where either the same or similar11 data are repeated in different docu-
10This requirement can be also related to extraordinary spread of the hypertext technologyacross world-wide webs of loosely structured and digital documents, i.e., the WWW itself. Inthe web-based technology, hyperlinks are particular annotations used to connect single words,text passages or pictures with other information resources. These sort of internal connectionsamong documents are intended to give their readers the opportunity to move from one part ofa document to another or from one document to another so as to shape a particular “readingpath” among many others. Likewise, we have assimilated this need for further investigation tothe need of adding meta-information to information.
11With similar we here mean pertaining to the same information. See also next footnote onthis point.
62
3.3. CONCEPTUAL VIEW OF THE FRAMEWORK
ments.
Positive redundancy occurs whenever an information is someway enrichedby referring it to other information (that we say correlated), even if each infor-
mation singularly taken would have been sufficient to inform their intended
consumers. The main point here is that we do not necessarily associate the
term sufficiency with the efficiency-minded nuance that it does hold in the do-
main of information systems, where data redundancy is frequently associated
to waste of resources.
Indeed, we collected some evidences that positive redundancy of data de-
notes a particular need exhibited by actors for coordinative reasons, rather
than for informational reasons, e.g., to gain a comprehensive view of what has
gone on in a work setting to enable satisfactory handing over of tasks. Data re-
dundancy, i.e., the requirement that a phenomenon be described several times
or in several complementary ways within the same set of documents, can be
a condition that, depending on the actors’ needs, must be guaranteed to some
extent or maintained to allow a smooth alignment of actions and interven-
tions.
The WOAD framework encompasses four general kinds of correlations,
that can be seen either redundancy-generating or redundancy-maintaining ac-
cording to the setting’s context. This distinction has been first proposed by
Ellingsen and Monteiro [Ellingsen and Monteiro, 2003] in the information
system domain, by considering the data source or its content, and then we
adapted it to documental and artifact domains in [Cabitza et al., 2005b].
When information is identical in content but located in different sources,
data are correlated by duplication. Duplication may lead to different represen-
tations of the same information, especially if this information is represented
not only in different documents but also in different mediums, e.g., paper and
electronic forms. In this case, as in any other case of duplicated information,
the utility of redundancy is controversial. On the positive side, Hutchins ar-
gues that this kind of redundancy facilitates the robustness of work since if
“one [...] component fails for lack of knowledge, the whole system does not
grind to halt” [Hutchins, 1996]. With similar conclusions, it is stated that the
use of multiple representations of data increases the fault tolerance of the sys-
tem [Gorman et al., 2000]. On the negative side, other authors state that since
the same information is documented in different places, redundancy of infor-
mation is a latent risk: in fact, the information might become unsynchronized
63
CHAPTER 3. THE WOAD FRAMEWORK
Table 3.1: Kinds of correlations to redound information for coordination’s sake.
or inconsistent and lead to misconceptions or other human errors [Sorbya
et al., 2002].
An interesting case of redundant information mentioned by Ellingsen and
Monteiro concerns information that is not exactly the same in content, but is
still strongly related and located in different documental sources. The authors
call this case supplementary information and claim that it can be used for
different purposes, among which supporting “learning by intrusion” [Nonaka
and Takeuchi, 1995] and playing the role of boundary object [Star and Griese-
mer, 1989] across different communities. These considerations, corroborated
by the observations of our hospital ward setting, led us to articulate the notion
of correlation of data as shown in Table 3.1.
When the same data are reported in two (or more) different documents
we speak (following Ellingsen and Monteiro) of duplicated data12. However,
when the same data is reported in several points of the same artifact we pre-
fer speaking about replicated data, since they are like carbon copies made by
folding back a sheet on another13.
We speak of similar data when data refer to (usually two) different enti-
ties or concepts, which can be put in strict correspondence thanks to either
a causal, intentional or functional relationship between them14. In regards to
redundancy due to correlation of different data, then, we distinguish whether
this occurs between different artifacts or within the same one. In the latter
case, we speak of redundancy from derived data, that is of data that can be
drawn by others as, for instance, subtotals that are reported within the same
spreadsheet to make the final totals clearer. In the former case, when positive
12“Duplicare” means “to double” in Latin.13“Re-plicare” means “to fold back” in Latin.14The peculiar way to use the term similarity with such meaning should not wonder, since we
redundancy occurs across different documents, we draw on the concept of
supplementary data, in that correlated data are reported in different artifacts
in a slightly different shape to supplement each other according to contexts of
reporting and of consulting.
From Table 3.1, it is clear that correlations between identical and sim-
ilar data are a particular case of the more general case in which two data
are put in some relationship. We have focussed on this kind of relationship
(giving it the framework-specific name of correlation) because our observa-
tion of documental use for coordinative reasons have highlighted the utility
of making explicit these constructs and urged us for a dedicated kind of sup-
port (See section 7.2.1). Also other authors have recognized the validity of
positive redundancy of correlated data over different artifacts (e.g., [Bossen,
2002,Bardram and Bossen, 2004]).
The most interesting case is that of correlations between similar data, since
even small differences can reveal important cues to inform the smooth align-
ment of task and responsibilities. These differences between data and the ar-
tifacts in which they are recorded reflect different purposes and allow for a
different degree of mobility (e.g., in the hospital case, bolted whiteboards vs.
mobile work-schedules) and of concision (detailed work-schedules vs. suc-
cinct whiteboards). These different artifacts can be flexibly used to produce
overviews, to present different data differently, to reveal work status, to plan
cooperation and continuous coordination, and also to pass on messages and
notifications to provide individual work-spaces; and finally, to also facilitate
the location of people in the ward.
3.3.4 Interdependencies among activities
According to a wide scientific convention, we consider activities as units of
work that, at a certain level of abstraction, can be considered as atomic15.
Malone and Crowston [Malone and Crowston, 1994], within the so called
research area of Coordination Theory, proposed to conceive of coordination
as “managing dependencies”. We can say that between two activities there
is a dependency whenever the execution or accomplishment of an activity is
not an independent event of the execution or accomplishment of the other
activity. In the specialist literature, a number of taxonomies and analyses have
15For or practical purposes, the choice to consider activities as atomic, instead of, for instance,tasks (cf. Raposo and Fuks [Raposo and Fuks, 2002]) is purely conventional if not nominalistic.
65
CHAPTER 3. THE WOAD FRAMEWORK
been proposed for the characterization of activity dependencies within a wide
range of collaborative applications, since defining interdependencies among
activities is a way to define the set of conditions that determine the order in
which such activities are carried out, and hence to define their process.
Generally, domain-dependent dependencies between two16) activities, can
be traced back to three general cases: (a) causal, (b) temporal and (c)
resource-based dependencies.
The causal dimension regards representations that focus on the way activ-
ities follow each other and that make explicit their causal relationship (either
dependency or independency). Perhaps for the natural tendency of actors in
describing their activities in terms of reasons and motivations, the causal di-
mension turns to be very useful in representing a work arrangement since it
provides designers with the precise categories of cause, effect and concurrency
by which to conceive the unfolding of a certain work trajectory.
Accordingly, the causal dimension has gathered a lot of interest both within
the field of the theoretical computer science and within the field of business
engineering and organizational studies. The former field has contributed in
proposing a number of in-depth formalizations within the so called concur-
rency theory (e.g., petri nets and process calculi) that could be applied to
model, understand and analyze how processes are defined and applied in work
settings (e.g., [Milner, 1980,Nielsen et al., 1992,Roscoe et al., 1997]).
Some of those formalisms have also been to some extent applied to the
enactment of software application for managing business processes (the so-
called workflow management systems — WFMS), that is to have represen-
tations of the causal interdependencies between activity be object of auto-
matic computation by some machine or engine. In that case, the execution
flow between activities is articulated in terms of connectors and composite
patterns that have recently been explored by business process management
researchers and tested in several workflow applications (e.g., [van der Aalst
et al., 2000a,van der Aalst et al., 2000b,Aalst et al., 2003]).
The temporal dimension regards representations that consider time as the
discriminant element in characterizing the nature of the relationship between
two activities, e.g. whether A1 has necessarily to start before A2, or whether
A1’s duration is necessarily as long as A2’s one. Besides the extension to the
causal formalisms mentioned above (e.g., timed Petri nets [Zuberek, 1991]),
16For the sake of simplicity, we concentrate our attention on binary relationships.
66
3.3. CONCEPTUAL VIEW OF THE FRAMEWORK
one of the most notable contributions to the matter was by Allen [Allen,
1984]. He proposed a set of primitive and mutually exclusive relations that
could be applied over time intervals of unknown duration — i.e. over cou-
ples of events — and that could express temporal information considering
any pair of time intervals A and B. Other authors followed the work by Allen
on basic inter-interval relations and adapted them to the inter-task domain by
adding a couple of specialized relations [Raposo and Fuks, 2002]. In so doing,
a larger set of possibilities to create coordination mechanisms were given to
analysts and designers so that different cases of multi-workflow environments
and inter-task articulation could be handled [Raposo et al., 2000].
Obviously the causal and temporal approaches to the representation of
inter-activity dependencies can be tightly correlated: as trivial examples, the
cause must occur before the effect, and two strictly disjointed activities can
never occur at the same time. Yet, since this is not necessarily the case in every
circumstance, it is not always feasible to trace back one kind of dependency
to the other. Moreover, according to the very nature of the domain at hand, a
dimension can be left underspecified in favor of the others, or the specification
be tuned for a particular domain and result into a less than suitable one for
others. As an example, real-time control domains need fine-grained tempo-
ral specifications of the interdependencies between activities; while domains
where human work is substantially “left outside” and out-of-synch with the
computational system necessarily need coarser-grained causal specifications.
Resource-based dependencies regard whether two activities produce, use
or need some common resource17. The resource-based approach was concep-
tualized in the work by Crowston [Crowston, 1994, Crowston, 2003] within
the so called coordination theory. In such framework, two general cases are
declined in a number of more specific subcases: the case in which multiple
tasks use or produce some shared resources at the same time and the case in
which a task produces resources that are consumed by another [Malone and
Crowston, 1994].
The resource-based proposal is also influenced by the STRIPS (Stanford
Research Institute Problem Solver) model [Fikes and N.J.Nilsson, 1971], a
simple but effective18 model of action developed within the Artificial Intelli-
17We recall that, in the WOAD framework, the term resource refers not only to the actorperforming the task but it also includes anything produced or needed by a task (cf. the conceptof artifact).
18The STRIPS model, since its first proposal by Richard Fikes and Nils Nilsson in 1971, is the
67
CHAPTER 3. THE WOAD FRAMEWORK
gence and Automatic Problem Solving fields under some simplifying assump-
tions, like time atomicity and determinism of effects. In such a general model,
the atomic unit of work — in our case, the activity — can be seen as a sort
of function from a state of the world – before its execution – to another state
of the world – after its completion – and hence be fully characterized by its
preconditions and effects. The preconditions can be seen as either states of
the world or resources that must be true or available for an activity to be
carried out since they are required or consumed within that activity [Malone
and Crowston, 1994]. Likewise, effects (or post-conditions) is what is true or
available in the world after an activity has been carried out since it has been
consumed or created within that particular activity.
This brief survey of inter-activity relationships helped us in understanding
which aspects of the typical documental domain must be elicited within the
model of cooperative work expressed in the WOAD framework. The WOAD
concept of work activity closely relates to the situated work context. This
changes depending on the complexity and characteristics of the application
domain and can require the design phase to employ the most suitable model
and formalization.
In our observational studies, we could extract some recurring character-
istics of work activities that pertain to documental use: since the description
of such activities usually do not need a strictly formal approach for the ex-
pression of the abstract causal relationships within the work processes, nor
for a formal expression of time-related aspects (our aim is not to represent
real-time applications or to evaluate application performances), we found that
the resources-based approach is the more suitable for taking into account the
contextual pieces of information that can be represented into the fact space.
Moreover, since inputs and outputs considered within our framework can be
seen as particular conditions of existence over data for an activity to start and
be completely accomplished, the IOPE approach adopted within the WOAD
framework can be fully represented in terms of resource-based precondition
and effects. In Sections 5.1.1 and 5.1.2, we will see how such relationships are
rendered into corresponding constructs of the WOAD language.
base for most of the languages for expressing automated planning problem instances in usetoday.
68
3.4. ARCHITECTURAL VIEW OF THE FRAMEWORK
Figure 3.7: The WOAD metaphor: web threads between documental artifacts are re-lationships stemming from the fact space and depicting a woad plant whose leafs aredocuments; transitors make the plant change, evolve, flourish.
3.4 Architectural view of the framework
In order to describe how the WOAD conceptual tenets, entities, and relation-
ships can inform the design and implementation of real computational sys-
tems, we now characterize the so called architectural point of view of the
framework. In the following, we will first refer to a high-level architecture,
with the aim to use it as a way to introduce a software architecture (in Sec-
tion 3.5), i.e. a representation of how the framework entities and relationships
can be mapped into interfaces among the system’s software entities, and be-
tween the system and its environment.
Bearing both the high-level and software representations in mind, software
practitioners can comply with the general tenets of the framework and so be
facilitated in designing their system within a set of constraints that could steer
the implementation process in accordance with those tenets. In presenting a
WOAD-complaint architecture, we will provide a schematic representation of
a software system that (a) could reify the main entities discussed above and, at
the same time, (b) implement the idea of having documental and contextual
information as interrelated resources that compound a common information -
transition system. In such a system, the state represents a snapshot of the struc-
tures and values of all the information resources. These resources, although
pertaining to different documental artifacts, are put in common into a sort of
common repository or memory. This set of resources at a given state makes a
69
CHAPTER 3. THE WOAD FRAMEWORK
Figure 3.8: A graphical representation of the main components of the WOAD archi-tecture.
transition to a subsequent state for the intervention of either the exogenous
or endogenous factors we mentioned in section 3.3, that is either by the direct
interactions occurring between actors and artifacts or by the context-driven
computational application of conventional interpretations.
From the architectural point of view, the WOAD framework maps the first-
class concepts concerning the dynamic and static points of view into four spe-
cific components that can be considered a human, documental, informational
and computational resource, respectively (see Fig. 3.8). They are, namely:
• the actors
• the documental artifacts
• the fact space
• the transitors
3.4.1 Actors and documental artifacts
An actor is an instance of the intended users of the documental and computa-
tional systems. Documental artifacts represent the documental resources that
support actors in their work, both for their informational needs and for their
efforts to coordinate with each other.
Actors and documental artifacts share the same real, physical environment
of the work arrangement and setting where activities go on. That notwith-
standing, documental artifacts do not need to be necessarily “material”, that
70
3.4. ARCHITECTURAL VIEW OF THE FRAMEWORK
is made up by some particular material, like sheets of paper or steel door-
knobs. For documental artifacts we assume two minimal and very general
characteristics: first of all, (a) that they are capable of providing actors with
some information about their work, e.g., by documenting either what actors
are supposed to do, or by recording what they have already done; and (b)
that some kind of physical interaction with actors is possible. From this point
of view, also web pages and screen interfaces can be seen as documental arti-
facts: the WOAD framework is neutral as regards the medium as long as actors
can be informed on the basis of either data or events.
Since some interactional capability is required, for WOAD documental arti-
facts can be employed the concept of affordance19. According to Norman [Nor-
man, 1988] an affordance is a physical property or design aspect of an object
which influences and suggests how the object can or should be used. In a doc-
umental context, an affordance can either include some physical properties of
the medium or item handled — e.g., the paper medium weight and flexibility
or the color and shape of a text box — or refer to some visual clue to their
function and use — e.g., a small arrow at the bottom of a page can hint the
user to consider the opposite side either. For our practical purposes, the term
affordance can generally indicate the representational capabilities of an item
within a document, i.e., some visual hint that enables users in understand-
ing both what that item can be useful for and what to do with it in terms of
documental practices.
With the term documental practices — or, better yet, activities — we mean
just the plain activities of reading and writing, i.e., what we have called docu-
mental activities to distinguish them from those pertaining to the higher level
task in which documents are just means to retrieve or document some in-
formation (see Section 3.3.1). Actors can then read content, compose con-
tent and refer20 content items to each other, across more documents. There-
fore, documents constitute the inputting and outputting interfaces between
the computational system and the human actors. More specifically, inputs are
textual pieces of information, i.e., informational resources, that actors pro-19Both the term and concept of affordance were coined by the perceptual psychologist James
J. Gibson in 1966 and then more thoroughly discussed in his seminal book “The EcologicalApproach to Visual Perception” [Gibson, 1979]. The concept has been also used in the fields ofcognitive psychology, environmental psychology, industrial design, and human-computer inter-action, where it was introduced by Donald Norman in his book “The Psychology of EverydayThings” from 1988 [Norman, 1988].
20Referring data to other data is a particular case of writing that within the framework isconsidered pivotal and hence differentiated by the general writing.
71
CHAPTER 3. THE WOAD FRAMEWORK
duce and maintain over the documental system; outputs can be both pieces
of information processed by some automatic procedure within the computa-
tional system, much alike the case of regular spreadsheets; or awareness in-
formation, which is conveyed to actors by documents’ (augmented) pages and
screens to make them aware of (a) conventional interpretations that can be
applied to what they are writing and reading and (b) the changing status of
the field of work over time.
3.4.2 The fact space
The fact space is the architectural component where all the informational re-
sources that are at disposal of actors in a given cooperative setting and that
are expressed in a computable manner in the memory structures of their sup-
portive computational system. This includes all the content that is recorded
into the documental artifacts, as well as any other piece of information that
has been previously rendered into symbolic form to be referred to that con-
tent so that actors could be supported in making sense of it (cf. the concept of
context2 in Section 3.2).
The fact space is termed space since it is an unstructured repository of in-
formation that does not have any corresponding entity in the physical environ-
ment. The fact space is also a common space21, in that it contains information
pertaining to all the documents compounding the web of artifacts; documen-
tal inputs are rendered into facts of the fact space and, conversely, the out-
put of the computational system can be properly conveyed in terms of proper
“surface representations”22 [Dan R. Olsen et al., 1998] over the documental
artifacts. Instead of information, we have chosen to adopt the term “fact” for
some reasons. First of all, according to a common sense acceptation, facts are
just something known to exist, to have happened, or to be true. They are true,
reliable information. Moreover, facts can include more pieces of information,
according to some specific and seldom arbitrary rationale. A fact can then re-
fer to a composite set of pieces of information and represent correlated data
into some sort of synthetic notation. Finally, we mean to make an explicit ref-
21With that, we are hinting an influence played by the concept of common information space,but not suggesting any further close functional resemblance between this “common memory”and what we have outlined in Section 1.4.1. See next paragraph for further comments on that.
22Some examples of such representations could be particular affordances or additional itemsor other iconographic means like images and icons that all adapt and change according to thecontext.
72
3.4. ARCHITECTURAL VIEW OF THE FRAMEWORK
erence to the terminology that is historically used within the rule-based and
declarative programming paradigms to denote a statement that holds true in
a certain context.
Besides these nominalistic conventions, the concept of common informa-
tion space has influenced the conception of the fact space component about
more substantial features, among which, what kinds of information constitute
its content. Just to recall what we said about common information spaces, they
are “central archives of (organizational) information” “encompassing the ar-
tifacts that are accessible to a cooperative ensemble, their content [as well
as] the meaning attributed to that content by actors” [Schmidt and Bannon,
1992]. The shareability, and hence availability, of data all together with struc-
tures providing some interpretation to those data is a key tenet that deeply
characterizes common information spaces and differentiates them from mere
repository of shared data, as database are [Bannon and Bødker, 1997]. This
key feature is guaranteed by the fact space, but except for the property of com-
monality, the analogy does not have to be taken too literally. As a matter of
fact, we are aware of the metaphorical acceptation in which common informa-tion spaces are said to “contain” shared meaning and agreed interpretations to
data that actors put in common during some cooperative work.
The main tenet of common information spaces that we claim is preserved
within a fact space regards the fact that actors can rely on a resource, namely
the fact space, that is shared by all the members of a given community of users
through the use of documents compounding the same interconnected web.
Within such shared resource, data are stored and gathered by higher level
constructs, called facts, according to some logic by which data are extracted
from single documents and put in common into the fact space.
All together with facts, the fact space also contains some expression that
can be associated to conventional interpretations to data referred by facts. In
order to have some useful outputs be conveyed to actors, at the apt time, these
expressions are not to be just static expressions, like facts; they are rather to
be some code that executed by some computational machine can contribute
to the context-aware change and evolution of the fact space. In order to de-
cline the concept of meaning into computational terms, we then conceive of
a “meaning related to some content item”, as a set of conventional interpreta-tions that can be correlated to that item. As said in Section 3.3, conventional
interpretations, in their turn, are conceived of as relational structures repre-
73
CHAPTER 3. THE WOAD FRAMEWORK
senting conditional behaviors to be triggered or solicited for a given situation
on the basis of its association with the facts representing such situation. To
draw a parallel with a pivotal construct of rule-based programming, conven-
tions and conventional interpretations can be represented as simple rules, i.e.,
condition-driven structures that express some behavior to exhibit whenever
certain conditions occur. Also rules, in fact, associate a set of conditions to
particular behaviors. The latter can be intended either as the result of some
computation carried out by the software application to convey specific out-
puts through artifacts; or as conventional behaviors to conduct in a certain
cooperative arrangement that the computational system suggests to its users
or just make them aware of, according to the context. Accordingly, any fact
space characterizing a single web of artifacts contains:
Documental content Expressed in terms of set of facts, i.e., symbolic expres-
sions.
Information about context2 Expressed in terms of facts and relationships.
The latter ones, more specifically, in terms of correlations (particular
ships) and interdependencies (particular activity-activity relationships).
Agreed and shared interpretations on content Expressed in terms of con-
ditional relational structures, i.e. rules, like that holding that “if a given
datum, namely X, exists, then it means that actors must be made aware
of something, or that something must occur, or be accomplished by
someone”; or also “if X is minor than 5 hours, then it means that. . . ”
and the like.
Cooperative work conventions Expressed in terms of rules, like that hold-
ing that “if someone playing the role A has written something like X, it
means that. . . ” or “if what an actor reads is denoted as provisional, it
means that it can be edited till definite emendation, and it must be rep-
resented differently than confirmed content, and the system has to track
who annotated what and when about it, and. . . ”.
Awareness provision mechanisms Expressed in terms of rules that, on the
basis of either data or events, contextually provide actors with the proper
awareness information on the documental content they manage. An ex-
ample is provided by one of the previously mentioned conventional rules
74
3.4. ARCHITECTURAL VIEW OF THE FRAMEWORK
by which “provisional text” must be rendered differently from “definite
text”. In a real setting, this awareness information about the status of a
text would be naturally conveyed by pencil or ball-pen made jottings and
digitized ways to represent the same information are trivial to conceive.
The point about the fact that the fact space contains information about the
context2 (and hence also elements pertaining to the work context) urges us
to make a remark on the artifacts and devices that can feed information into
a fact space. As already stated, our framework concentrates on documental
artifacts. This means that documental data are the main pieces of information
compounding the fact space. That notwithstanding, the fact space can also con-
tain data that are not immediately referrable to documents, as in the case of
work context information. These data can come from other devices or applica-
tions than documents or documental applications (like word processors, web
browsers or email clients). These additional artifacts can be seen as further
“sensors” and “effectors”23 that fetch into the fact space data from the users’
environment and viceversa.
For instance, time information is a type of contextual information that can
be useful even in a fully document-based and document-intensive domain. In
a number of different situations, it can be useful to base some conventions
(and hence their computations) on the time of an agreed schedule. Time in-
formation can be used to provide both absolute and relative indications: e.g.,
“it is eight o’clock”, “it is five days since the data were entered”, respectively.
Its usefulness is clear especially with respect to the possibility to correlate time
information with other application-level information so as to derive context-
aware implications: e.g., “it is eight o’clock, hence it is breakfast time”; “it is
five days since the data were entered, hence it is time to update them”. Ob-
viously also many other pieces of information can be “extracted” about the
physical setting of a work arrangement, depending on the type and number of
the very devices that populate it and that are capable to “publish” what they
perceive and process to some network facility.
For its capability to encompass also these kinds of environmental informa-
tion, the WOAD framework can be considered suitable for the development
of context-aware applications, whereas contextual information is extracted
23We borrow these two terms from the field of robotics and domotics to indicate devicescapable of perceiving the environment and to produce an effect on it, respectively (cf. [Russelland Norvig, 1995]).
75
CHAPTER 3. THE WOAD FRAMEWORK
by several other sources, besides documents themselves. These can be made
context- and situationally-aware [LaMarca et al., 1999] by means of the “in-
ference capabilities”24 of the transitors.
3.4.3 The transitors
As said in section 3.3.1, the fact space space can only be changed by two
classes of agents. Human actors change the documents’ content as they use
documents along their cooperative work trajectories. These changes then are
“reflected” into the fact space, in those facts that are a sort of symbolical proxy
of what is read and written on the documents compounding the web of arti-
facts.
Transitors are the other entities that can make the fact space “transition” to
a new, consequent state, obviously asynchronously with respect to the human
activities. State transition is akin to a rewriting process, accomplished by dis-
tributed and asynchronous transitors. From a conceptual point of view, these
can be seen as functions δ that relate the global state at a given time, S′with a
consequent state S′′; S
′also includes the inputs coming from the documental
artifacts, while S′′
also includes the outputs that is conveyed to actors through
their artifacts.
Transitors can alternatively be seen as the computational machines (as
well as the corresponding hardware machines) that compute the δ function,
by applying rules, i.e., computable representations of conventions and agreed
meanings, to the data present within the fact space (S′). Therefore, these ma-
chines reify into the concept of controllers or computational machines the
“dynamic part” of the WOAD model, i.e., what has the capability to apply
conventional rules to the different levels of context related with documental
artifacts. In so doing, artifacts can aptly convey an up-to-date representation
of the context in which actors operate and make sense of their documents,
and hence become more supportive tools to the actors’ deeds and needs (cf.
the concept of active artifact in Section 1.5.1).
24We use such expression within the narrow acceptation of inference within the rule-basedprogramming paradigm. The term inference is therein harked back to the meaning that is givenin Logics of “process of deriving the strict logical consequences of assumed premises”, withouthinting to any particular cognitive capability of the human being.
76
3.4. ARCHITECTURAL VIEW OF THE FRAMEWORK
3.4.4 Some terminological specification
For the sake of clarity, we provide some further terminological note about the
way the above mentioned concepts of the WOAD model have been rendered
into the specific constructs of the WOAD language that we will describe in
detail in Section 5 and into the current implementation middleware that we
will describe in Section 4. We will denote by the term convention both the
conventional and agreed interpretations on documental content and the co-
operative work conventions. As said above, they are just conditional relationalstructures between an antecedent, containing some conditions, and a conse-
quent, containing some set of actions that can be applied to the fact space.
Such conventions are shared among all artifacts and transitors within the fact
space. Conventions, to be applied to the fact space by some transitor, need
to inform some correlated mechanism, the term by which we denote the exe-
cutable (i.e., applicable) representation of a convention.
In the rule-based jargon, both conventions and mechanisms are denoted
with the simple term rule; we have so far used such term according to the
common acceptation and in a quite naively manner: in the following, we will
replace it with either convention or mechanism according to whether we are
speaking of rules that are shared within the fact space (i.e., conventions) or of
rules that can be executed by transitors and whose execution can change the
fact space (i.e., mechanisms). The reason why conventions and mechanisms
— i.e., sort of “static” knowledge on the conventions of a certain work arrange-
ment and “dynamic”25 knowledge that can produce some actual effect on the
common fact space, respectively — have been decoupled will be motivated in
Chapters 5 and 7. Here we can anticipate that conventions can be embeddedinto some mechanisms or be transformed into executable mechanisms accord-ing to the context. This gives a powerful tool to modulate which conventions
should be applied according to the very situation at hand and to also modulate
the distributed nature of their application across multiple transitors.
In fact, the conventions/mechanisms whose conditional elements are con-
tinuously matched with the fact space’s content can be a smaller partition of
the overall number of conventions available and put in common by artifacts
into the fact space26. These partitions are collected within the transitors, in
25Such terms are not to be intended in the acceptation that the former cannot change whilethe latter can. Rather, the former pertains to a static characterization of the model, while thelatter pertains to the dynamic characterization that is applied to the static one.
26In Chapter 5, we will see those conventions will be rendered by the construct of convention-
77
CHAPTER 3. THE WOAD FRAMEWORK
their so called rule-sets. Convention distribution into different transitors’ rule-
sets is accomplished even at run-time, according to some rationale that is not
known a-priori and depends on the actual way the framework is applied to
some specific application domain.
This opportunity for distribution can be achieved for the intrinsic dis-
tributed nature of the domain; for instance, it can be achieved either because
the artifacts involved in the domain in hand are autonomous computational
devices or because, within that domain, data are accessed by different settings
or facilities, and hence through physically different though correlated docu-
mental applications. The correlated opportunity for parallelism — i.e., the si-
multaneous application of different conventions by autonomous transitors —
can be achieved also for a matter of separation of concerns: conventions that
cope with the same aspect of the domain can be aggregated since their execu-
tion is semantically independent27 from other rule sets coping with different
aspects. In Chapter 4, we will see that distributed and autonomous access to
contextual data is an opportunity to get a richer picture of the overall context
as it is rendered into symbolic facts within the fact space.
3.5 Software Architecture
The high-level architecture (see Fig. 3.8) describes which entities are involved
and how they relate to each other in systems that are designed and deployed
using the WOAD framework (namely, its model and language). Such systems
are obviously much more complex with respect to this abstract representation.
In fact, real systems are embedded, on the one side, in their development
framework, i.e. in a specific programming environment and user interface
management; and, on the other one, in the real and physical field of work,
in terms of domain specific applications and their data structures.
As an intermediate representation between the model abstraction and the
layered structure of the implementation, we also depict a software architecture,
where the model entities are related to software components that compound
a generic implementation of a WOAD compliant web of documental artifacts.
fact.27In this context we are not talking of strong logical independency nor of any syntactic or
functional independency. Two rules could cope with very different aspects of the same situa-tion and still refer to some common facts. DJess, the underlying middleware for distributingrule-based inference systems (see Section 4) guarantees that internal inconsistencies due toexecution interference is properly prevented.
78
3.5. SOFTWARE ARCHITECTURE
Figure 3.9: A graphical representation of the architecture of a WOAD-compliant soft-ware application. At the top, we depicted the documental applications that are madecooperation-aware and context-aware by the underlying tiers.
79
CHAPTER 3. THE WOAD FRAMEWORK
With reference to Fig. 3.9, we describe the software architecture as a multi-
tiered stack. In such representation, we consider both actors and their artifacts
(possibly running in software documental applications) with the aim to en-
compass in the same vista both aspects of the physical environment where
actors work and the actual components of the software system they use28.
Actors interact with documents where they record their notes, keep trace
of the work going on in their setting and get informed by getting access to their
informational resources. At this description level, it is not important to spec-
ify whether these documents are either paper-augmented digital documents
(e.g., cf. [Guimbretiere, 2003,Bang et al., 2003]) or desktop-like applications
on either portable devices or personal computers, once that the content of
documents has been digitized in some way29.
Either “real” documents or word processing applications (i.e., anything the
human actors really interact with) interact with the WOAD-compliant applica-
tion. The actual “pages”, which actors read or fill in, are rendered in terms of
factual representations, all together with their related conventions. The spe-
cific application logic determines the exact structure of the facts representing
documents, other contextual and environmental aspects, as well as the nature
of conventions pertaining to how to cope with records and context. The doc-
umental cooperative application is then defined by all the application-specific
data structures that the designers have conceived to represent the WOAD
model entities and relationships. Document content, conventional knowledge
and contextual representations are all stored into a common memory that is
shared among all the artifacts (i.e., either devices or applications) and their
users. The management (e.g., access control, consistency check) and the basic
functionalities (e.g., updating operations) of such shared memory is provided
by the underlying tiers.
The content of the fact space changes according to the application of mech-
anisms that embed primitives expressing the model constructs. This applica-
tion is instantiated by a middleware software providing a framework specific
execution platform. We distinguish between the layer giving the operational28In that, such representation must not be intended as a strict ISO-OSI architectural struc-
ture.29For instance, if the domain at hand does not require a strong temporal characterization and
a highly dynamic response to environmental changes, documental content could be extracted atregular intervals by means of paper scanning and optical character recognition (OCR) services,while content-related outputs could be conveyed through public wallboards or other personalelectronic devices. For a proposal in the hospital domain, see a previous work of ours [Cabitzaet al., 2004].
80
3.5. SOFTWARE ARCHITECTURE
semantics of the WOAD language (i.e., to the primitives that act on the WOAD
structures) and the layer guaranteeing both data exchange between different
documental applications (or other devices) and code execution (i.e., pattern
matching between facts and rules and rule interpretation). We denote the for-
mer as WOAD middleware, while the latter is the middleware providing the
WOAD middleware with communication and rule execution capabilities: in
the current implementation this layer is instantiated by the DJess middleware
(see Chapter 4).
Possibly multiple different and distributed physical machines can join into
a web of documental artifacts and any physical machine can host one or mul-
tiple transitors. The communication middleware, in our case DJess, hides the
complexity of the virtual machine running on each physical machine (in our
case, a Java Virtual Machine). Virtual machines implement the functions of the
communication middleware in terms of service calls to the operating system
and their underlying physical machine; the latter is connected to the others
computational machines by means of a communication network facility.
In the following chapter we will outline the current implementation of the
middleware layer that permits (a) to define and maintain the fact space shared
among more physical machines; (b) to enable distributed transitors to asyn-
chronously access and transform that common memory; (c) to implement the
WOAD language constructs and primitives and make the related mechanisms
computable (i.e., the instantiation of the WOAD middleware – see Fig. 3.9).
This implementation has been conceived as a lightweight communication mid-
dleware for distributed inference systems deployed in a context-aware com-
puting domain: DJess.
81
Chapter 4
The Rule-based middlewareimplementing WOAD
During our research on software architectures and systems by which to sup-
port cooperative work, we also engaged a cooperative research effort with the
aim to focus on the way such systems could get advantage of getting a more
comprehensive access to the context of the cooperative arrangement and of
exhibiting some inference capability on that context so as to provide a more
aptly and adequate support to the involved human actors. We surveyed the
main contributions from the specialist literature of the ubiquitous computing
field we mentioned in Section 3.2 and tried to interpret its main tenets in the
light of reaching a better support to cooperative work settings. Our aim was
then to enable the development of collaboration-aware applications that could
be also context-aware while receding into the background and not requiring
direct human interaction to provide their support.
Our first explorations in the field led us in conceiving (a) an architecture to
harmonize innovative technologies — like digital pens, electronic-augmented
paper and smart wallboards — in support of human coordination in hospital
wards (the SWIRLS project [Cabitza et al., 2004]), (b) a methodological frame-
work for the high-level management of highly interconnected devices within
“intelligent environments” [Cabitza et al., 2005a], and (c) a model and archi-
tecture to design collaborative ubiquitous computing environments [Cabitza
et al., 2006b].
To be able to develop our prototypal applications and to apply our com-
petencies on rule-based programming in the fields of context-aware and
83
CHAPTER 4. THE RULE-BASED MIDDLEWARE IMPLEMENTING WOAD
ubiquitous computing we engaged in the development of a full-fledged, yet
lightweight, communication middleware and scripting environment that could
be deployed into any Java-enabled device. We intended this middleware to en-
able programmers and designers of a context-aware application in abstracting
from some low-level and technical details so as to feel free to concentrate on
the very logic of the application and its ways to adapt to the context and pro-
vide users with “situationally-aware” services. For this reason, we adopted the
declarative programming paradigm, which focuses on the expression of whata system should do, rather than on how it really accomplishes it and conceived
the DJess middleware.
By means of DJess, programmers can represent declaratively contextual
information at application level and conceive symbolic rules that bridge data
from the lower levels (i.e., the physical context as can be perceived by the
devices’ sensors) to the higher level information (i.e., the logical context per-
taining to the work settings, the cooperative conventions and the coordinative
protocols) so as to drive the behaviors of the overall system towards the ful-
fillment of the requirements of the particular application domain.
In the following sections, we will characterize the main motivations that
led us to design the DJess middleware as we did: to that aim, we will introduce
the themes of context sharing and semantic interoperability as a particular and
effective way to get an ensemble of devices more context-aware than any of its
single parts. The focus on these themes makes also clearer why we decided to
implement our first WOAD-compliant application using the DJess middleware:
to have a heterogeneous and disjointed assemblage of digitized documents,
documental applications and other personal devices become a context2-aware
and coordinated web of artifacts that are situated in a certain work setting and
are aligned toward the common goal of timely and aptly providing their users
with useful information for their smooth and “calm” coordination [Weiser and
Brown, 2005].
4.1 The need to make access to context “ubiquitous”
A context-aware computing environment can be defined as a tightly integrated
collection of computational devices that is able to aptly assist the user when-
ever and wherever she needs it. Such a collection is inherently distributed
and heterogeneous; in fact the computational systems that compose it can
84
4.1. THE NEED TO MAKE ACCESS TO CONTEXT “UBIQUITOUS”
be either mobile and embedded in any kind of everyday object or embedded
and hidden in the infrastructure surrounding the user: Weiser has accordingly
spoken of ubiquity [Weiser, 1993], in that computation must seem just every-
where — or better yet, just where it needs. To achieve this property in quite
an unobtrusive way, the integrated collection of devices must then succeeds
in augmenting the environment surrounding the user while receding into the
background of it. In other words this augmentation must be accomplished
transparently both as regards the user and, for the intrinsic heterogeneity
of the involved devices, also as regards the integration mechanisms that al-
low the tight interoperability required by the application domain. As Ark and
Seller pointed out, this transparency regards also communication made eas-
ier and more seamless, not only between users and things, but also between
things [Ark and Selker, 1999]. For this reason designers and developers of
context-aware applications need a set of tools able to provide abstraction and
functionalities above both the single devices and the network facility techni-
calities.
4.1.1 Middlewares for the semantic interoperability
The software layer that provides developers with a simpler programming envi-
ronment in order to manage the complexity and heterogeneity of distributed
infrastructures is usually referred to as middleware [Campbell et al., 1999].
Middleware systems may vary a lot in terms of the programming abstractions
they provide and of interface they give over network and hardware functional-
ities. One of the main requirements for middlewares in ubiquitous computing
environments is that they allow these autonomous and heterogeneous sys-
tems to seamlessly communicate and interact with one another so that they
are able to align with each other more aptly towards a coherent response to
user’s activities.
The underlying assumption regarding this capability is that by means of
communication, nodes of a ubiquitous computing network might augment
their access to context, i.e., any useful information about the users’ and the
devices’ state. Only in this way, an ubiquitous computing system, as a whole,
can reach a more comprehensive understanding of the user’s current needs
and get a broader choice of responses to answer them more timely and aptly:
in the Dey’s words “by improving the computer’s access to context, we increase
the richness of communication in human-computer interaction” [Dey, 2001].
85
CHAPTER 4. THE RULE-BASED MIDDLEWARE IMPLEMENTING WOAD
We then may wonder if, by improving or just facilitating the applications’
access to context, we may increase the quality of interaction and the integra-
tion between different computational systems. Integration here means that
such devices and applications reach and maintain a low-level interoperability
as well as a high-level interoperability. The former regards the ability to share
data over a network facility and is guaranteed by any middleware employed
in ubiquitous domains by defining or supporting standard interfaces and pro-
tocols. The latter regards a tighter integration and the ability to share domain
and even situation-dependent representations, as well as with their “mean-
ing” in terms of local and global behavior according to those representations.
This interpretation derives from the definition of context we mentioned in
Section 3.2 that conceives context as a set of data regarding environmental
states that determines an application’s behavior [Chen and Kotz, 2000]. Here,
we emphasize the capability of the application to “understand” context and
react accordingly to it. The burden to gain both kinds of interoperability is
usually left to the application layer programmers, whose duty is to build ap-
plications that are both compliant with the data representation provided by
the middleware and able to understand what these data represent.
In several occasions researchers have pointed out that, once contextual
information is extracted from the environment and processed for a local re-
sponse, this can also be used afterwards by other devices [Fuentes et al.,
2004]. Separating the acquisition of contextual information from its use can
be also seen as an important requirement so that application designers can
concentrate on high-level and user-centered issues instead of worrying about
the details of a sensor and how to acquire context from it [Dey et al., 2001].
Yet when information is managed for local use, it can be in whatever format
and at whatever level of abstraction it happens to be; conversely, when infor-
mation is shared to be used by heterogenous and possibly remote applications,
high level interoperability issues arise inevitably, such as homogeneous in-
formation interchange, sound coordination mechanisms based on those data,
and high-level coordination among applications towards systemic goals. In
fact contextual information should be shared as contextualized as possible, in
that it should be enriched by high-level characteristics that make it really de-
vice independent. This bring us introducing the concept of the highest level of
interoperability, also called “semantic interoperability” [Howie et al., 1996].
In ubiquitous and context-aware computing domains semantic interoper-
86
4.1. THE NEED TO MAKE ACCESS TO CONTEXT “UBIQUITOUS”
ability can be considered as the capability of different computational systems
to understand and react to what has been previously perceived and processed
(inferred) by other computational systems, i.e., as the capability of a system
to operate on contextual data (i.e., to consume and rely on them) that are
provided by others as if they were perceived by itself, without such a medi-
ation. Semantic interoperability is then a feature characterizing a cooperativeensemble of heterogenous context-aware systems, where with cooperative we
intend that context — as a whole — is a set of data cooperatively gathered by
sub-systems that rely on each other to access context and its meaning in the
light of the shared goal of supplying an appreciated service to the user.
The fact that sharing information coupled with its interpretation is neces-
sary for an ensemble of generic “agents” to cooperate is an interesting exten-
sion into the world of computational machines of some of the tenets from the
CSCW field (cf., especially those underlying the concept of common informa-tion space given in Section 1.4.1 [Bannon and Bødker, 1997]). Such sharing
appears as a strong requirement in any domain where coordination is needed
and where simple sharing of raw data bases could not be enough to aptly
contextualize them.
To address the issue of semantic interoperability among context-aware de-
vices we developed DJess, a communication middleware by which inference
systems can represent context declaratively (facts) and programmers can con-
ceive behavior as a reactive (rule-based) activity to this context. This mid-
dleware allows heterogenous systems sharing a common inference paradigm
to share seamlessly and incrementally context representations — facts — as
well as declarative interpretations of those facts, in terms of reactive behav-
iors (rules) in response to those representations. By permitting transparent
rules sharing among inference systems, the DJess middleware enables pre-
processed perceptions to influence applications and hence to enrich their re-
sponse to context.
Such a middleware is intended to give an explicit support to application
layer programmers in achieving semantic interoperability in that it would pro-
vide the programmer at least two important features. On the one hand such
a middleware would provide the programmer with a higher-level and user-
friendly syntax that is more oriented to grasp the semantics of context repre-
sentations and more suited to couple these with the applications’ behavior. On
the other hand, it would provide the programmers of compliant applications
87
CHAPTER 4. THE RULE-BASED MIDDLEWARE IMPLEMENTING WOAD
with the built-in capability to make their application share transparently and
seamlessly both raw context and code that can interpret it in terms either of
transforming it farther or responding aptly to it. To this regard, we intend to
show how inference systems could provide context-aware applications design-
ers with an useful abstraction level so that high-level semantic interoperability
could be reached among peer applications.
In section 4.2, we first introduce the concept of distributed inference sys-tem along with the main characteristics of the DJess architecture; this will be
further outlined in the section 4.3 along with some implementation details.
Section 4.4 contains the main motivations of the project in the light of some
related works that inspired our proposal and closes the chapter dedicated to
the current implementation of the software layers underlying the WOAD mid-
dleware.
4.2 DJess-Based distributed inference systems
DJess is a Java-based tool1 that allows to deploy distributed asynchronous in-
ference systems [Ishida, 1995] and that can serve as lightweight middleware
by which distributed inference systems can share both contextual information
and reactive behaviors. To illustrate its architecture and its main functional-
ities, we first give some general terminology on inference systems and then
describe two main concepts that underlay its conception and implementation.
We then start from focusing both on inference and distribution, with the aim
to make briefly clear the advantages that can come from making inference
distributed, especially in an ubiquitous computing domain.
At the beginning of Section 4.1, we said that context-aware systems must
feature ubiquity and transparency, indeed they must also exhibit some “intel-
ligent” behavior in terms of context processing and ability to recognize and
aptly react to user actions by reasoning on knowledge that was previously
acquired or possibly learned from past experience. For such an application
domain, the deployment of distributed inference systems is a feasible and ad-
equate solution once that coordination between the distributed components
can rely on a high level (i.e., semantic) interoperability provided by a suit-
able communication middleware. As such middleware, DJess offers both spa-
tial and temporal decoupling by allowing inference systems to be directly un-
1Cf. http://java.sun.com/
88
4.2. DJESS-BASED DISTRIBUTED INFERENCE SYSTEMS
aware of each other’s identities and to run their control flows asynchronously
and even within non-overlapping lifetimes; it enables information sharing and
communication among distributed agents through hidden remote object invo-
cations (i.e., RMI) according to a generative communication model [Gelernter,
1985] — that is through a shared global memory — so that no explicit com-
municative message is necessarily exchanged; furthermore, DJess provides a
common programming abstraction across a distributed system by turning a
collection of devices into a single integrated computational environment.
4.2.1 General terminology
As regards its name, “Distributed Jess” is intended to make distributed and
tightly interacting computational systems on which a Jess2 instance is run-
ning. Jess is an acronym for “Java Expert System Shell”: it is a Rule Engine
and scripting environment that is written in JavaTM and made quite tightly
integrated with the Java language.
DJess has been developed to add to the Jess inference functionalities a set
of mechanisms that allow to transparently create and manage an integrated
collection of Inference Systems (IS) that communicate by means of a virtuallycentralized global memory with the function of a blackboard enabling collab-
orative context processing [Hayes-Roth, 1985] (see Section 4.4 for a further
analysis on this concept).
We speak of “inference system” for simplicity, where with such term we
indicate any computational system (typically a device or an application) that
is able to reason about what it perceives, and hence is able to create and ma-
nipulate knowledge about the environment and itself. Although the reader
should not mistake the WOAD middleware — a cooperation-oriented middle-
ware for the sharing of context2 — with any of its possible implementation
(e.g., DJess), we make here explicit the association between DJess-based in-ference systems and WOAD transitors. Other terminological mappings will be
given in Section 4.5.
4.2.2 Jess-based inference systems
Jess is a Java program written by Ernest Friedman-Hill to deploy fast and
flexible Rule-Based Systems (RBS) [Friedman-Hill, 2003]. RBSs are programs2Jess - the Java Expert System Shell,
http://herzberg.ca.sandia.gov/jess/.
89
CHAPTER 4. THE RULE-BASED MIDDLEWARE IMPLEMENTING WOAD
Figure 4.1: Dynamic representation of an inference system.
whose control flow can be said both event-driven and data-driven in that re-
spectively they perform some action only if some condition is true and they
are able to produce (infer) conclusions from a set of premises. Accordingly, in
the following of this chapter we use the terms rule-based systems, production
systems, and inference systems as synonyms.
As a scripting language (and an interpreter to that language) conceived to
implement RBSs, the core computational construct of Jess is the rule. In or-
dinary language a rule is (also) a set of instructions or directives that applies
in certain situations. Accordingly, computer scientists have called rules if-then
computational constructs expressing recommendation of action if some con-
dition occurs. More precisely put, a rule expressed in Jess language consists of
a conjunction of condition elements corresponding to the if-part statements of
the rule (also called the left-hand side or antecedent of the rule), and a set of
actions corresponding to the then-part of the rule (also called the right-hand
side or consequent of the rule), that are performed only if all the condition
elements of the antecedent are true according to the current context. All that
said, RBSs are but programs that select and execute available rules according
to the current context they perceive; this makes RBSs particularly suitable for
implementing reactive architectures that must be modular and easily extensi-
ble.
Like other systems implemented by similar rule-based languages (e.g.,
CLIPS, OPS5), each Jess inference system is composed of three main com-
ponents: a rule set, a Working Memory (WM), and a rule engine; in Figure 4.1
these are respectively indicated by RS, WM and E. The rule set is the collection
of all the rules that can be executed by the IS according to the current content
of the working memory. The working memory is the storage of the knowledge
nuggets; these nuggets represent the factual knowledge of the RBS and are
hence called facts: facts are like records with certain value fields called slots;the fields structure is specified by a template that defines types and default
values of the slots; for this purpose Jess uses the deftemplate construct. The
90
4.2. DJESS-BASED DISTRIBUTED INFERENCE SYSTEMS
Figure 4.2: Interactions between context, represented by facts, and IS’s sensors andeffectors.
rule engine applies rules on facts and executes their right-hand sides.
Conceptually, a RBS can quite easily be made a component of a context-
aware ensemble; practically speaking, the set of facts that constitutes a work-
ing memory can contain a symbolic and declarative description of a current sit-
uation and the rule set can be seen as the interpretable code of the IS by which
the programmer can put in relationship context conditions and devices’ behav-
ior and actions. For that to be accomplished, facts must also represent a possi-
ble connection between sensors/effectors and context producing/consuming.
As we will describe in Section 4.3, Jess allows to bind facts to Java objects:
this permits also to conceive Java programs that are sensitive to context either
thanks to an event-driven approach or by means of a reflective mechanism. In
the former case, context changes show up by means of the assertion of some
facts expressing those changes. In the latter, sensors’ and effectors’ states are
represented by some facts, whose modification corresponds respectively to
some sensed perception or some action to accomplish within the environment
(see Figure 4.2).
The inference process
The process of matching contextual instances and rules is carried out by the
rule engine — also called inference engine: a program (interpreter) that per-
forms iteratively the so-called Match-Resolve-Act (MRA) cycle over the rule set
and the working memory (as hinted in Figure 4.1 by the circling arrows inside
the engine). In a MRA cycle, at any given time, the rules of the rule set are first
selected and activated by matching them against the WM elements (Match
phase); then a rule among the activations is chosen for immediate execution
according to some selection strategy (Resolve phase) and finally executed (Act
91
CHAPTER 4. THE RULE-BASED MIDDLEWARE IMPLEMENTING WOAD
or firing phase). In the Act phase, facts can be modified or deleted, and new
facts can be added to the working memory as well. In the Jess syntax, this is
respectively obtained through the modify, retract, and assert constructs.
In choosing the scripting environment to base the DJess distributed in-
ference systems on, the possibility to deploy them across different platforms
and to rely on a well documented architecture played a decisive role. There-
fore, our choice fell upon Jess: its source code is available and it is written
entirely in Java; moreover, its rule engine has been shown to be fast and effi-
cient especially for large data sets and it is widely used within a professional
programmers’ community.
4.2.3 Distributing an inference system
The concept of distribution in Ubiquitous Computing is a key one. If compu-
tation is to be “ubiquitous”, it must be embedded into the environment and
almost hidden to human perception. For this reason, ubiquitous and context-
aware devices and applications must be highly sensitive to environment and
not consider only information explicitly provided by users [Benerecetti et al.,
2001]. In other words, these devices must be able to react aptly to any infor-
mation might come from — and could be derived from — the environment.
As noted in Dey et al. [Dey et al., 2001] context (production) is inherently
distributed: in fact one of the most challenging aspects of handling context is
due to the necessarily distributed myriad of sensors and devices involved in
sensing it. But distribution can reveal itself to be also a resource to support de-
signers in coping with other three major challenges in ubiquitous computing:
(1) the need to gather directly precise and local data on relevant entities asclose as possible to where they are and act; (2) the need for a persistent stor-
age and constant access of context information; (3) and the need to interpret
the contextual data into useful abstractions [Moran and Dourish, 2001] so
that physical information could feed device-independent reasoning and then
context could include more conceptual and domain-dependent logics.
The latter point can certainly involve automatic inference, that is it can call
for a more active role by computational and autonomous devices scattered in
the environment in gathering and processing raw data in order to create a
coherent view and interpretation of the current context. Hence distributing
inference and giving designers a middleware to support them in distributing
the process of the direct and cooperative interpretation of context can be use-
92
4.3. DJESS ARCHITECTURE AND IMPLEMENTATION
Figure 4.3: Distributed Inference System (DIS).
ful.
Distributing an inference system means both to distribute in space the in-
ference engines and to parallelize in time the inference process made on the
same contextual data. In Figure 4.3, ISs are represented by their engines, while
rule sets are not indicated for simplicity. Working memories have an overlap-
ping region to indicate that some facts (white dots) are shared, whereas others
(black dots) are not.
Generally, distribution of an inference system can be useful for two main
reasons: making the inference process faster and getting physical separation.
The former allows better performances in terms of throughput and response
time; the latter supports robustness, resource sharing, agents cooperation, and
— for what we have just said — ubiquitousness of computation. Distributing
an inference systems implies to get all these things but which aspect to favor in
the actual implementation depends on the very purpose a distributed solution
is sought. In fact, any design must come to some compromises and no optimal
solution for every application domain can be given. In designing the distribu-
tion of Jess-based inference systems, we had to face design and implementa-
tion alternatives between performance and consistency guarantee. As DJess
has been conceived for a limited set of application domains — i.e., ubiqui-
tous, context-aware and pervasive computing environments (e.g., [Aarts et al.,
2002,Lindwer et al., 2003]) — where response time is not short, the focus has
been put more on consistency than performance.
4.3 DJess architecture and implementation
DJess is a middleware that allows inference systems (a) to infer on data col-
lected by other devices as they do on their own perceptions; (b) to share
93
CHAPTER 4. THE RULE-BASED MIDDLEWARE IMPLEMENTING WOAD
transparently both physical data and refined data without need of a fixed
communicative process, since no designer could feasibly foresee any situation
in which this sharing must be done; and (c) to share, along with contextual
data also local interpretations, procedural rules, and abstract relationships by
means of which conclusions can be drawn from these contextual data and
from any possibly sensed data where necessary.
From the implementation point of view, DJess is mainly an extension of
Jess; its architecture is designed with the goal of keeping modifications of the
Jess code as few as possible, so as to cut down on development time and bugs,
and to avoid duplicate work being done on the same functionalities. DJess
adds a communication layer underneath Jess inference capabilities; Jess code
of the inference engine and the interpreter is essentially unchanged in DJess.
We take advantage of the mechanisms of inheritance and polymorphism so
that Jess unmodified code invokes DJess code whenever it operates on facts.
In this way the DJess communication layer intercepts every modification of
the working memory and propagates it to the other inference engines (see
Figure 4.4).
The WoIS and the SWM
In DJess the set of ISs that are connected together is called Web of InferenceSystems (WoIS) and is characterized by a space where facts are shared, the
Shared Working Memory (SWM). Facts in the SWM are directly manipulated
by the rules of the various ISs in the WoIS as if they were local. In effect there
is no physical common memory in DJess: every IS has a copy of each shared
fact in its own local WM and all ISs’ engines run independently of each other.
Therefore we say that the DJess WoIS is a distributed asynchronous inference
system [Ishida, 1995] where no centralized data repository is kept and facts
are transparently shared among the nodes of the network.
In a context-aware environment, DJess is used in two different ways at
the same time. For the device builder, DJess is mainly an inference engine
constituted by a set of Java classes. She develops a bridge between the infer-
ence application and the platform or device functionalities. For the distributed
application designer, DJess is mainly a rule interpreter that totally adopts the
Jess syntax, with the additional functions for creating, joining, leaving, and
destroying a WoIS, and for sharing rules across its ISs.
DJess main features are fact sharing and rule sharing. In the next sections
94
4.3. DJESS ARCHITECTURE AND IMPLEMENTATION
Figure 4.4: Jess-DJess relation
we describe in details how these are achieved, and then we take a look to the
setup of a WoIS.
4.3.1 Implementing the DJess shared memory
Generally a distributed system is said to be transparent when it is able to
ensure that “a collection of independent computers appear to its users as a
single coherent system” [Tanenbaum and van Steen, 2002]. DJess’ users are
programmers, and from their point of view DJess shared memory is transpar-
ent, as the same primitives, borrowed from Jess, are used to manipulate local
and shared facts.
A powerful Jess feature, shadow facts, is employed to build and synchro-
nize DJess shared memory. This feature allows to use Java beans (objects
whose attributes are accessible through set and get methods) as if they were
elements of the working memory; whenever an object is used in such a way,
Jess creates a fact — the shadow fact — that is dynamically linked with that
object: every modification made on the bean is mirrored on the “shadowed”
fact and vice versa. For every fact that is shared across the WoIS, a shadow
fact, and hence a shadowed java bean, is present in every node. This Java
bean is called proxy in the DJess terminology; all the proxies corresponding to
the same shared fact are linked together by means of a Java remote object that
we call ghost fact. The ghost fact has two purposes. First, it stores the state of
the shared fact, i.e., the slot values; through its proxies, modifications to its
slots are propagated to the related shadow facts in in the different working
memories. Second, it provides a single point of synchronization for the ISs,
as we explain shortly. Ghost facts could reside in any Java virtual machine,
95
CHAPTER 4. THE RULE-BASED MIDDLEWARE IMPLEMENTING WOAD
Figure 4.5: DJess facts synchronization.
but for simplicity, they reside in the Java virtual machine of their asserting IS.
In Figure 4.5 a graphical representation of the DJess synchronization mecha-
nism is given: JVMi are Java Virtual Machines; SWMi are local copies of the
shared working memory; sfi are shadow facts, representing the same shared
fact; pi are their corresponding proxy objects; and g is the ghost fact used for
the shared fact synchronization. Although shared facts are replicated in each
IS’s working memory, the coordination achieved through ghost facts permits
to conceive of the SWM as one entity.
Programmers can decide whether a fact will be private or shared at the
assertion time, using modules. Modules in Jess are just namespaces for facts
and rules. In DJess, a special module, selected at join time, is designated to
hold all shared fact; every fact asserted in that module is shared.
The use of ghost facts for the shared memory permits to keep Jess’s imple-
mentation of the Rete algorithm unchanged. The same is true for the modify
primitive. In Jess (hence in DJess), whenever modify is invoked on a shadow
fact to change some slot values, the corresponding set methods of the shad-
owed Java bean are called. So in DJess, when a set method of a proxy is called
in response to a modify, no proxy internal variable is updated; the method
just calls the corresponding ghost fact set method. In so doing, the ghost fact
updates its attributes and notifies all its other proxies of the modification by
calling their set methods; consequently the modification is shadowed in all
ISs’ working memories through the native Jess mechanism.
Asserting and retracting shared facts involves some modifications of Jess
mechanisms. When the engine of an IS encounters a deftemplate that tries
to create a new template in the shared module, the Java code for two new
96
4.3. DJESS ARCHITECTURE AND IMPLEMENTATION
classes, namely the proxy and the ghost fact classes, is generated from the
parsing of the template, so that these classes have a bean property for each
slot in the original template. The code is then compiled and sent along with
the template to all the other WoIS members, that from then on are ready to
assert shared facts using the new template or accept shared facts asserted from
another IS.
When an engine calls an assert that refers a shared template, it instanti-
ates the ghost fact class associated with the template and initializes this new
object with the slot values of the fact; it then notifies all the other engines
in the WoIS, sending them a reference to the ghost fact. Each engine creates
a new proxy bound to the ghost fact and uses it to assert a shadow fact in
its working memory. Likewise, when an engine retracts a shared fact (via a
retract), it notifies all the WoIS members’ engines, which in turn remove the
corresponding shadow fact from their memory; finally also the ghost fact is
removed from the system.
Different ISs could access the same shared fact at same time by firing some
rules, and this may cause conflicts and inconsistencies. Two rules are said to
interfere if there is a dependency of some sort between them [Acharya, 1996].
A read-write dependency (or a true data dependency) occurs between two
engines if one of them fires a rule that writes (i.e., modifies or deletes) a fact
read (contained in the if-part) by the other and a write-write dependency (or
an output dependency) occurs if both of them write the same fact [Tata et al.,
1999].
In DJess, interfering rules are prevented to fire simultaneously, using locks
associated with ghost facts and acquired in the transition from the Resolve to
the Act phase. Rule firings are treated as single indivisible units, much like
transactions (consistency through serializability): the effects of two parallel
rule firings have to be the same of some serial sequence of those firings; more-
over changes made by a rule firing cannot trigger another rule firing until the
former is finished. It is not a surprise that the system used to control concur-
rency in DJess is a frequent solution in transaction systems, the two-phase lockprotocol. In a two-phase lock scheme no further lock can be acquired after
having released any lock [Gray and Reuter, 1994]. A major difference of DJess
from the common uses of the two-phase lock protocol is that DJess doesn’t
make use of rollback, as rollbacks would disrupt the Jess mechanisms that
prevent rules from firing two times on the same activation
97
CHAPTER 4. THE RULE-BASED MIDDLEWARE IMPLEMENTING WOAD
All locks are acquired before the actual rule execution, so if the acquisition
of any lock fails, the firing can be postponed, after having released all acquired
locks, without any rollback. Rule firing execution is divided in three steps:
locks acquisition, statements execution, and locks release. In the first step, a
lock is acquired for every fact matched in the activation and for every fact
that has a binding (i.e., a variable referencing it). In the second step actions
are then performed according to the rule statements; new facts, created by
assert executions, are immediately locked, in order to prevent another engine
from firing a rule on a new fact before the asserting rule execution has been
completed. In the last step, all locks are released and if a rule has been blocked
by any of these locks, it is eventually fired.
In order to lessen the burden on performances, the default resolve strategy
of DJess is partially nondeterministic. Nondeterminism here means that if a
rule is prevented from firing due to lock contentions, the engine can choose
another rule to fire instead of blocking. Salience (a priority explicitly specified
by the programmer) is always honored.
We notice that DJess addresses only the consistency problems due to con-
currency; those possibly arising from knowledge bases integration are left to
IS designers.
4.3.2 The rule sharing mechanisms
DJess provides a load-rule function which enables to inject a rule into a re-
mote rule set; this makes DJess a (weak) mobile code environment [Fuggetta
et al., 1998] since it allows interpretable code to be transparently transferred
among different inference systems. An unload-rule function permits to re-
move rules previously sent.
Rules within a WoIS are shared in a two-step process (see Fig. 4.6, part
(b)): the actual rule sharing (1 in Fig. 4.6) and the rule loading (2 in Fig. 4.6).
In the first step, actual sharing, a sender IS embeds a rule in a special shared
fact, called shared-rule, and specifies the intended destinations for the rule,
using the corresponding slot of the shared-rule fact. A rule shared in this way
is somewhat a “dormant” rule, as it cannot fire until it is loaded in the (local)
rule base of an IS. In the second step, rule loading, the recipient ISs extract
the rule embedded in the shared fact and load it in their own rule bases. This
is accomplished by means of a special rule (i.e, a meta-rule, as it operates
on rules), which must be present in all recipient ISs, and which matches the
98
4.3. DJESS ARCHITECTURE AND IMPLEMENTATION
Figure 4.6: a) A graphical representation of the DJess Web of Inference Systems(WoIS); b) the two-step rule-sharing process: 1): sharing and 2) loading
destinations of the rule-embedding fact with the name of the IS on which it
is running; it then calls a special function, load-rule, to add the shared rule
to the local rule base. Meta-rules are nonetheless rules, and so they are under
complete control of the programmer and are not part of the DJess built-in
behavior. DJess provides just the mechanisms, i.e., the function load-rule and
the rule engine, for building arbitrarily complex policies for rule transferring,
and so an IS can filter incoming rules according to different criteria.
All rules behave in the same manner, whether they have been defined lo-
cally or have been sent from another IS; they are parsed and executed locally
by the engines, although they can act both on shared and private facts. In this
way, interpretations of shared facts can be encoded in rules, in terms of behav-
iors triggered by facts. Since DJess allows for rules to be spread throughout
the WoIS, this rule sharing mechanism facilitates the designer of the context-
aware and ubiquitous computing application in reaching and guaranteeing a
semantic uniformity across different devices.
4.3.3 The management of the WoIS
Every WoIS is supervised by a manager, which handles the registration and the
locating of ISs as they join or leave the WoIS. The use of a centralized WoIS
manager is the simplest solution for a name server, and it should not create
bottlenecks in the system, as we have assumed that in a typical ubiquitous
environment computation be mainly driven by user activity and that commu-
nication be based on broadband LANs, so the delays induced by a centralized
model are presumably not appreciable.
WoISs are distinguished by name, and a WoIS is created by launching the
WoIS manager specifying the WoIS name. The WoIS at this point is empty
99
CHAPTER 4. THE RULE-BASED MIDDLEWARE IMPLEMENTING WOAD
and the manager waits for any IS to join; the manager maintains a list of the
members and one of the shared facts, both initially empty.
Every time an IS joins the WoIS, the manager adds the new member to the
members list, and sends it the current shared facts list. The new member then
asserts a special shared fact member which specifies the new member identity
and can be used by the other ISs to “sense” the presence of the new member.
When an IS leave a WoIS, it removes its member fact and the manager
remove the IS from the members list. Shared facts (apart from the member
fact) are not touched in the process, and if there are any ghost facts on the
leaving IS, they are migrated to another IS.
4.4 Related work on distributed inference systems
As regards the general data sharing functionality characterizing DJess, we
can relate our work to the Linda coordination model [Carriero and Gelern-
ter, 1989]; this represents one of the most relevant efforts to provide hetero-
geneous distributed components with data access and information exchange.
This is accomplished through what is called a tuple space, i.e., a common data
structure which allows agents to share and retrieve data (i.e., tuples) through
some simple pattern matching mechanisms.
In this case, the underlying model — to some extent similar to the black-
board model [Hayes-Roth, 1985, Nii, 1986] — conceives a global sharing of
any data visible by any agent accessing the tuple space. This idea, although
quite relevant for certain application domains, seems less than optimal when
it must be implemented in mobile and ubiquitous applications. In fact, in these
latter cases, devices (and data) are inherently distributed and realizing a cen-
tralized place where all data are perceived could be unfeasible; rather, it is
important to consider the concept of locality of information according to the
conceptual places where computation is needed and it is performed. In other
words, ubiquitous, context-aware and mobile applications require that not all
the information must be accessible by all agents, and that some mechanisms
be provided so that information production and access can be regulated by
taking into account chunks of information that is conceptually related. Ratio-
nales according to which information is to be separated and partitioned in lo-
cal and shared one can vary depending on the pertinent application scenario;
likewise, ways to modulate explicitly the perception of the shared information
100
4.4. RELATED WORK ON DISTRIBUTED INFERENCE SYSTEMS
have given rise to models and architectures that follow different paradigms.
The mechanisms that provide a separation of information may be accom-
plished by taking into account various approaches that may be best suited
according to the pertinent application scenario.
Some approaches are more topological oriented, that is, information is
shared not for all the agents populating the environment but only for some of
them according to either their physical or conceptual location. In Lime [Mur-
phy et al., 2001], for instance, each agent carries its own tuple space and
when agents reside on the same host, their tuples space are merged. In this
way, the information sharing is related to a specific place that is represented
by a node of the network where agents reside. Other approaches extend the
idea of topology-based information sharing to the concept of diffusion of infor-
mation through fields propagation. In particular, in TOTA middleware [Mamei
et al., 2003] the content of a tuple propagates through the nodes of a network
according to a rule that reflects the topological structure of the network of the
underlying physical infrastructure. In other cases, the propagation mechanism
is made richer by considering any topological layer that reflects meaningful
conceptual structures for the chosen application scenario (like in the MMASS
model [Bandini et al., 2002]). Some other approaches determine the access to
the shared information through a more organizational approach. In Agent Co-
ordination Context [Ricci et al., 2004], for instance, the access to the shared
information space is regulated by mechanisms of access control based on roles
and institutional policies of the organization.
On the other hand, the way DJess enables the modulation of how WoIS
members access and perceive the shared space is based on rules governing
code propagation. In this way, the designer does not have to adopt a spe-
cific policy beforehand but can define a multi-tiered tower of meta-rules that,
recursively, define the policy defining the composition of behaviors at each
inference system and how the behaviors propagate from IS to IS. Although
at a first glance DJess may seem similar to the Linda model — since both al-
low all agents to share a global common information space, the tuple space
and the shared working memory — there are some important difference. On
the one hand, in DJess no global memory structure really exists. The shared
working memory is a virtual space that is replicated in each system to make
inference efficiently local and the overall system more tolerant to temporary
or permanent faults of some member. On the other hand, in DJess it is possible
101
CHAPTER 4. THE RULE-BASED MIDDLEWARE IMPLEMENTING WOAD
to provide each inference system with specific rules according to the specific
domain, without having to define beforehand a particular mechanism or ra-
tionale of modulation of the information access. This is made possible because
in DJess there is no real propagation of data, but rather data are shared and
available to all components that perceive and react to them differently accord-
ing to the rules they store in their rule base. Hence, the various mechanisms of
modulation of access to information are not imposed beforehand but depend
on how the application designers conceived the rules to be propagated in the
environment. This implements a form of flexibility because the programmer
of the context-aware application may choose one way of limiting information
access according to a specific context and accomplish it dynamically according
to the rules she decides to define for a specific device and to the way she de-
cides the rules should propagate within the web of inference systems. In other
words, data are shared and made potentially accessible to all the agents; but
the rules that each agent maintains in its knowledge base provide it with the
ability to access and process the information according to the specific applica-
tion needs.
Differently from the previously cited approaches, which mainly focus on
the sharing of data and leave application programmers to build the related
logics, in DJess the focus is on shaping the overall behavior of the ubiquitous
system starting from the shared data where the behavior of each component
is ruled according to the intentions of the designers of the overall system. For
this reason inference is a central concept in the DJess middleware and it could
not be otherwise since its core is one of the most wide-spread inference en-
gine to date. Although also other cited middlewares rely on quite powerful
forward-chaining inference capabilities (e.g., Lime), DJess permits also both
backward-chaining and pattern matching on negative conditions, both being
features quite valuable in a context-aware domain. Backward-chaining is quite
useful when there is a need to draw conclusions that are relevant to a cer-
tain goal and writing proper rules for each subgoal can be difficult [Russell
and Norvig, 1995]: when backward-chaining is employed, the programmer
does not have to explicitly write rules for all the subgoals and moreover she
does not have to worry about large amount of initial data (that is data given
from the outside, not inferred: a typical situation in ubiquitous domains) when
goals are quite well defined. Moreover, DJess — as an extension of Jess — has
the notion of negation as the non-existence of a fact called “negative condi-
102
4.4. RELATED WORK ON DISTRIBUTED INFERENCE SYSTEMS
tion”. A negative condition is an expression that succeeds if patterns in a rule
are not successfully matched. Through DJess, then, a programmer can express
non-monotonic reasoning rules [Apt and Bol, 1994] and in so doing she can
both be facilitated in expressing commonsense rules where these can grasp
more properly the user behavior and cope more flexibly with situations of in-
complete data, that is a condition that can be seen as structural of real open
systems like the ubiquitous ones.
Also other approaches encompass rule-based systems like in the Coopera-
tive Artefacts [Strohbach et al., 2004] and Sentient Object [Biegel and Cahill,
2004] model but there the focus is not on providing a general mechanism
to distribute dynamically behaviors (rules) to the agents spread in the envi-
ronment so that the agents may properly interpret the shared facts. Rather,
in these approaches rules have a scope of application to facts that is either
limited to the internal facts managed by each component or to facts which
are explicitly sent from one component to another or perceived by different
agents according to their proximity in the space. In other approaches, like the
previously cited Lime, the scope of the rules (reactions) of each agent in inter-
preting facts is limited to the facts (tuples) made shareable by all the agents
currently residing on the same host they moved to. In DJess, instead, the scope
of the rules of each inference system depends both on the antecedents of the
rules and on the facts that are available in the whole WoIS to which each IS
has joined. In this way, each agent behaves according to its internal logic as
well to the designer’s logics. These logics are conceptually modeled in terms
of rule propagation patterns within a WoIS, rather than only topologically.
In approach and aims, the closest works to DJess seem to be Dyna-
CLIPS [Cengeloglu et al., 1994] and DCLIPS [Amigoni et al., 1999]. They
are two different infrastructures for inferential code mobility and knowledge
exchange based on CLIPS [Giarratano, 1991] and used in multi-robot sys-
tems [Amigoni and Somalvico, 1998]. That notwithstanding, full and seam-
less integration with Java, the adoption of a pure generative communication
model, the transparent fact sharing and a more integrated rules propagation
mechanism make DJess quite different and more suitable for application do-
mains that must exhibit great openness and flexibility, like the ubiquitous com-
puting one.
103
CHAPTER 4. THE RULE-BASED MIDDLEWARE IMPLEMENTING WOAD
4.5 Reconciling DJess and WOAD terms
At the end of this digression on the implementation details of the current
WOAD-compliant system that we have developed to evaluate the potentialities
of the WOAD framework, we briefly summarize the terminology mappings
that run between the DJess and the WOAD middleware layers of the software
architecture depicted in Fig. 3.9. In so doing, we can “raise” again the level of
abstraction and proceed to describe the WOAD language and its application
to a real work setting in Chapters 5 and 7, respectively, .
As short recapitulation, we then recall that a WoIS, namely a web of infer-ence systems (see Fig. 4.6, part (a)) is what currently implements the actual
deployment of a WOAD, namely a web of (electronic) documental artifacts.
As said in Section 4.2.1, WOAD transitors are implemented by DJess inferencesystems, while the fact space of a WOAD is implemented by an instance of
DJess shared working memory. The DJess functionality to share rules across
inference systems of the WoIS and through the shared working memory is ex-
ploited by the WOAD middleware to have conventions be transformed into
executable mechanisms. More specifically, WOAD convention-facts (see Chap-
ter 5) are rendered into DJess shared-rules, which the load-rule function can
transform in WOAD mechanisms, i.e., rules contained within the rule-sets of
transitors representing the code that can be executed during a MRA cycle (see
Section 4.2.2).
104
Chapter 5
L*WOAD: The WOAD language
The aim of the WOAD language (L*WOAD) is to provide the designer of a
web of coordinative documents with a means by which to express computable
mechanisms so that awareness information can be managed according to the
context. We also propose such language as a way to support designers in elicit-
ing and characterizing in a structured and sound manner the information that
within the WOAD framework is deemed relevant to support actors in using
their documents for coordinative aims.
L*WOAD can then be seen as a “notation” by which the designer1 can
construct the needed mechanisms that have to be executed by a technologi-
cal platform like that we have described in Chapter 4. In fact, L*WOAD acts
as “programming interface” that allows the designer to “program” awareness
provision mechanisms at a semantic level, without being concerned with the
peculiarities of a given programming language and corresponding virtual ma-
chine. Data and algorithmic structures that designers define at notational level
are rendered in executable constructs by an interpreter. This application ren-
ders the frame-like L*WOAD constructs [Nilsson, 1980] that we will see in
this Chapter into corresponding data structures and executable code that the
WOAD middleware (currently implemented on top of DJess) can manage and
execute (cf. Fig. 3.9).
As regards the main constructs, L*WOAD is derived by the model we out-
lined in Chapter 3 and by the basic choice to leave the set of constructs as
1In the sections regarding the language the ‘reference user’ is intended as a designer, i.e.,who is supposed to model the application domain at hand and conceives the mechanism andfunctionalities by which a computer-based system can support its intended “users”. This latteracceptation is used to refer to actors that use a documental system and a WOAD-compliantapplication to be supported in their cooperative activities.
105
CHAPTER 5. L*WOAD: THE WOAD LANGUAGE
minimal as possible: each L*WOAD construct contains parameters that endow
it with high expressive power and make it an atomic component that can be
flexibly combined into higher level components (e.g., macros).
The L*WOAD encompasses three basic constructs: facts, primitives and
mechanisms2. These are constructs to express data structures (facts), to de-
fine and manipulate them (primitives) and to either specify or characterize
the flow of execution (mechanisms).
In the following, we will outline the main characteristics of the language by
means of implementation-independent frame-like representation. The frame-
based level of description could be the only one a WOAD designer would
like to cope with. That notwithstanding, in order to give useful hints about
how such notational elements are rendered into actual data structures and
the operational semantics of an implemented middleware, we also express
the very same features in the current declarative and rule-based syntax.
By reading the passages in slanted italic type, the interested reader can get
some indications about the current implementation of the WOAD middleware
on top of the DJess platform. The reader not concerned with implementation
details can easily skip the DJess code written within boxes. Conversely, the
interested reader should also mind that the reported examples are almost for
every detail “running examples”, that is, their lines of code can also be man-
aged and executed by any WOAD transitor as they are, although they look
pretty “abstract” and human-readable.
5.1 L*WOAD Facts
The term fact is the historical name by which any kind of data is represented
in the declarative rule-based programming paradigm. Each fact represents a
single and coherent piece of information; moreover, since they can be struc-
tured at an arbitrary level of detail, they can also gather different pieces of
information that relate to a single phenomenon or concept to be represented
within a computational system. The whole information available within the
system can be hence seen as the ‘union set’ of all defined and instanced facts
within the system. L*WOAD facts are constructs used to express information
that must enjoy the following properties:
2These correspond to what in almost any rule-based language is called facts, functions andrules. Within our framework, we adopted slightly different names since they are associated toa specialized syntax and semantic.
106
5.1. L*WOAD FACTS
1. facts are expressive, i.e., capable of representing relevant aspects of both
contextual3 and relational information (i.e., “what” and “how-is-related-
to-what”), as well as conventional knowledge4. The latter is intended in
terms of symbolic and human-readable expressions representing “what-
does-it-mean-if. . . ” or “what-to-do-whenever. . . ” regarding the mean-
ings or the typical behaviors the users of a documental system intend ac-
cording to either the textual or environmental context (see Section 3.2).
Facts must therefore be capable of declaratively expressing both data a
program works with, and the algorithm this program applies to process
its data.
2. facts are sharable and manipulable within the fact space. The fact space
can be seen as a blackboard [Corkill, 1991]. Within this blackboard facts
have an independent existence of their sources (cf. the generative com-munication model [Gelernter, 1985, Carriero and Gelernter, 1989]) and
they are added, retracted and modified according both to correspond-
ing changes within either the documental system, or the environment in
which such system is deployed and used, and to the application of con-
ventions by which users make sense of these changes (cf. endogenous
and exogenous factors in Section 3.3)
3. facts are object of computational inference5 within the fact space. This
property refers to the possibility to draw new facts basing solely on what
is already represented in terms of facts.
The second and third properties will be outlined when we speak of prim-
itives and mechanisms, respectively (see Section 5.3). In the following, we
consider in more details the expressive power of facts.
L*WOAD facts are labeled and structured set of attribute-value couples (see
Fig. 5.1). A specific attribute-value couple is called a property of the fact. Prop-
erty attributes are unique within each fact and their values are usually typed.
The structure of a fact is expressed in terms of a template which represents
a generic category of the reference domain. Each template is uniquely identi-
fied, specifically by a label — i.e., its name — and the name of the fact space3For the sake of readableness from now on we use the terms ‘context’ and ‘contextual’ in the
twofold acceptation of context2 as characterized in Section 3.2.4In the following we use the terms data, information and knowledge pretty candidly, with
acceptations that, for our practical purposes, can be borrowed from the common sense.5The reader could refer to the footnote in Section 3.4.2 for the technical acceptation of such
term that we mean in this context.
107
CHAPTER 5. L*WOAD: THE WOAD LANGUAGE
it belongs to (web-name, in Fig. 5.1). The name of a fact template also denotes
the type of the information associated with any instance of the fact template.
When the attributes of these structures are assigned to some values, we speak
of instances of facts, or just facts. The difference between the class level and
the object level (i.e., between structures and instances) is straightforward also
at implementation level.
In our current implementation, WOAD-facts are rendered as DJess facts; theirstructures are syntactically rendered as DJess templates. The DJess middlewarerepresents facts in a LISP-like notation, i.e., as recursive list structures, whoseproperties are syntactically rendered as particular lists called slots, acting as la-beled fields. At slot definition, both types and default values can be specified:in particular, three value types are available: atoms (i.e., just sequences of sym-bols), integers and strings (i.e., sequences of alphanumeric symbols). Fact typesand properties can be defined through the deftemplate construct, by which tem-plates with an arbitrary number of slots can be created (see Fig. 5.3). Slots areused to access properties by their name, so that each fact is made analogous to amemory structure like records of traditional procedural programming languages.At instance time, when a fact of a certain type (i.e., with a certain template) isasserted, the middleware assigns the fact with a progressive number, acting asan ID that ensures uniqueness within a given fact space. Also the web-name andclassname slots are automatically filled in. The classname slot refers to the list ofall templates of which the asserted fact can be considered an extension. It hencerepresents the implementation of the Parent-fact property (discussed immediatelybelow), by which the full hierarchical chain that binds specific classes up to theirextended root is represented.
In the L*WOAD, the distinction between contextual, relational and con-
ventional information leads to a further WOAD-fact distinction into (a) entity-facts, (b) relation-facts and (c) convention-facts, (see Fig. 5.2). Each of these
kinds of fact can be seen as a specialization of the most general L*WOAD fact.
At definition time, the designer has to define a fact structure, i.e., a fact tem-plate, in terms of another one, so that the former inherits the structure of the
latter and this can be seen as the parent fact of the new one. This hierarchicalrelationship6 is explicitly represented by means of the Parent-Fact property.
This property allows designers to conceive mechanisms that recursively apply
6With the term ‘hierarchical relationship’ between classes of objects, we mean what is ex-pressed by an ‘is-a’ relationship, and hence something also equivalent to the concept of inheri-tance and generalization.
108
5.1. L*WOAD FACTS
Figure 5.1: The most general WOAD fact structure. Self-explicative attributes typesare indicated in the attribute column. The plus denotes a multiplicity possibly otherthan one
Figure 5.2: The conceptual hierarchy between very general WOAD facts and theirframework-specific extensions.
to facts, so as to implement relationship inheritance. By recursively applying
the ‘extension principle’, any domain-dependent fact can be defined as an ex-
tension of either entity-, relation- or convention-facts.
5.1.1 Entity-fact
Entity-facts are facts that express an attribute-value representation of an as-
pect of the state of the world in terms of the entities defined within the WOAD
model, i.e., namely resources and activities. As such, their most general rep-
resentation is still in terms of WOAD-fact, extending them with some domain
or application specific property (see Fig. 5.4).
For instance, in the current implementation of L*WOAD entity-facts are ren-dered as lists, i.e., as recursive structured sequences of characters delimited bybrackets. In Fig. 5.5 the interested reader can also see how fact templates aredefined by means of the deftemplate construct. Within such construct, theextends clause lets the designer define one deftemplate in terms of another.
109
CHAPTER 5. L*WOAD: THE WOAD LANGUAGE
Figure 5.3: DJess syntax for the definition of the WOAD-fact template. Language prop-erties are referred to template slots for the sake of comprehensibility.
For their generic definition, any resource and activity of a given domain
can be rendered as an entity-fact.
In the example in Fig. 5.5, the concept of ‘person’ has been associated tothe homonomous template that has been defined as specialization of the genericWOAD entity-fact template.
Besides all the templates that designers can define by themselves to rep-
resent any relevant aspect characterizing their application domain (e.g., per-
sons, cars, offices), the L*WOAD provides such designers with the templates of
three framework-specific and domain-independent entity-facts: the document-fact, the activity-fact and the awareness-fact, to render the concepts of docu-
mental artifact, activity and awareness information, respectively7.
Document-fact A document-fact is an entity-fact that represents both the
structure and the current content of a specific document. We will see in
Section 5.3 that the language provides a direct support both in defining
such templates and in keeping documents and corresponding document-
fact “synchronized” (by means of the share primitive). The WOAD
framework does not a-priori specify the structure of any document
possibly compounding the web: that would have limited the architec-
ture in its applicability to different documental domains. The document
structure can be detailed by a domain-dependent, or even application-
7The reader may note the correspondence with the specialization of the resource and activityconcepts introduced by the WOAD model. Document-fact represents the main kind of artifactsherein considered, i.e., documents; awareness-facts the main information; activity-facts justrepresent activities
110
5.1. L*WOAD FACTS
Figure 5.4: The general structure of an entity-fact. Possible extensions of the entity-fact structure into application-dependent templates are just hinted specifying ageneric designer-defined property.
Figure 5.5: Above, an example of DJess syntax for the definition of the entity-facttemplate. Below that, an example of fact definition: the person fact is defined asextension of the generic entity-fact.
dependent8, model that structures content as much as it needs for the
domain’s requirements9.
The WOAD document construct (see Fig. 5.6) encompasses (a) a name
8As said in Section 3.3, we distinguish between framework, domain and application level:e.g., between documental, hospital care and “ABC” Hospital, respectively.
9The current implementation requires such document model be specified by means of XMLfiles, that are fetched as input data by the sharing mechanisms (see Section 5.3.2).
111
CHAPTER 5. L*WOAD: THE WOAD LANGUAGE
property, (b) a description, (c) some access rights with reference to the
relationship between domain-specific roles and the activities of reading
and writing, (d) the kinds of WOAD-specific awareness information it
can provide, irrespective of the way it does it; (e) the content of the
document; and (f) a set of conventions of proper compilation and con-
sultation, expressed in terms of convention-facts (see Section 5.1.3). The
content attribute of the document-fact represents the informational con-
tent, i.e., the very data of the represented document: its inner structure
(e.g., tree-like, strictly hierarchical or just a body of symbols) depends
on the application domain.
In the current WOAD implementation the content of a document is rep-resented by a set of nested facts, so that also the very single fields of thedocument are rendered as fact slots that can be referred within the condi-tion elements of either some convention-fact or mechanisms.
The content attribute is updated by means of WOAD mechanisms in their
content partition (see Section 5.3.1 for details).
From the implementation point of view, the hierarchical structure in whicha documental system is conceived can be expressed by means of either spe-cific entity-facts reporting for each document its name and the list of itsparents, or specific relation-facts that put in part-of relationship binders,documents, their sections and so on, till the smallest kind of document thatis rendered by means of a document-fact. If a certain document can be seenas the “leaf” of a hierarchical tree structure, the classname property, whichis automatically filled in by the middleware, can represent its relationshipswith the rest of the structured documental system.
Awareness-fact An awareness-fact represents an awareness message that is
generated depending on some contextual condition and provided for ac-
tors’ consumption at artifact level. Each awareness-fact refers to a given
class of awareness information and can be seen as an instance of that
class (awareness types will be treated in Section 5.2). From the tem-
plate point of view, an awareness-fact is a entity-fact with three prop-
erties (see Fig. 5.7): a label termed awareness-type, which corresponds
to one type of awareness from a finite set of WOAD-specific awareness
types10, whose semantics will be outlined in Section 5.2.1; a content
10That set can be either extended or reduced according to some domain-dependent rationale
112
5.1. L*WOAD FACTS
Figure 5.6: The general structure of a document-fact. Some properties inherited bythe entity-fact (e.g., description) are reported for the sake of comprehensibility.
attribute, which, at instance level, corresponds to the piece of informa-
tion actors should be aware-of; and a source attribute that, at instance
level, encompasses all those facts that constitute the “reason” for their at-
tention, the source of the awareness information. Awareness provision,
i.e., assertion and modification of proper instances of awareness-facts,
is managed within a dedicated partition within the WOAD mechanisms
(see Section 5.3.1).
Figure 5.7: The general structure of a awareness-fact.
Activity-fact To reflect the distinction between documental and work ac-
113
CHAPTER 5. L*WOAD: THE WOAD LANGUAGE
tivities, also at language level we distinguish between a documental-
activity-fact (in the following d-Activity-fact) and a work-activity-fact
(in the following w-Activity-fact). An activity-fact represents those as-
pects of activities that is necessary to consider in the conception of a
web of documental artifacts. Like in the case of awareness information,
the framework encompasses a purposely paradigmatic set of aspects that
can be further extended or limited at design time if the domain complex-
ity requires it.
The WOAD activity construct (see Fig. 5.8) considers a work activity(and the corresponding data structure) as described by a set of prop-
erties expressing its name, its description, its internal state; the explicit
indication of who is responsible for its execution11; which is its priority12;
the list of its preconditions and its effects; and conventions regarding work
execution and state transition (see below).
Documental activities are described by a slightly different set of proper-
ties: besides a name and a description, they are also associated with the
explicit indication of who has executed them (the executor) and when(a time stamp, that is obviously significative only at instance level); and
with the lists of the informational resources involved either as input or
output. Also d-activity-facts are characterized in terms of related conven-tions of “right compilation”.
The assumptions underlying the simplifications of such way to represent
activities regard what we said of activities speaking of the WOAD model
(see Section 3.3.1): i.e., the fact that work activities are in some way in-
stitutionally conceived as task-oriented abstractions of the practices oc-
curring in the field of work; and that they can contain documental activ-
ities (in Section 5.1.2 a specific relationship is presented to express such
inclusion). For this reason, we deem necessary to associate each work
activity with a responsible actor and consider that inputs and outputs
(in any case, some documental information as defined in Section 3.3.2)
can be “inherited” from the “contained” document-activities.
On the other hand, documental activities are considered pretty atomic
11This information can be related either to institutional roles or specific actors working inthe cooperative arrangement. For this reason the L*WOAD does not explicitly encompass arole-fact, which can be defined at application-level if necessary.
12This information can even be as simple as a binary indication: routine, urgency.
114
5.1. L*WOAD FACTS
and strictly bound to the documents’ content: either a data is read
as input or written as output. For this reason, we do not consider
necessary to also describe them in terms of preconditions and post-
conditions, give them a priority, an above all, associate them with some
framework-specific internal state structure, which can be defined as
domain-dependent extension of the generic WOAD structure. When a
document (or even a single field of it, depending on what is considered
input/output for a certain transactional documental task) is either read
or written, the corresponding d-activity-fact is instantiated and the ex-
ecutor and time-stamp attributes completed by the software platform.
In order to alleviate the modelling task of the designer, in the current im-plementation d-activity-facts templates are automatically created as fromthe parsing of the document structure. In this way, the designer has onlyto conceive appropriate work-activity-facts for the application domain athand and then refer the latter with the d-activity-facts according to thedocumental use occurring within each work activity.
Figure 5.8: a) The general structure of a work-activity-fact. b) The general structureof a documental-activity-fact. Properties inherited by parent facts (e.g., name anddescription) are reported for sake of completeness.
For work activities, conversely, we propose a particular model of activity
115
CHAPTER 5. L*WOAD: THE WOAD LANGUAGE
internal state13 that is compatible with our requirements of awareness
provision within the documental domain (see Fig. 5.9). Our proposal is
indeed intended as a trade-off between the necessity to capture the rel-
evant aspects of activities in a given domain and still reflect the typical
loose extent the documental activities of reading and writing can be cor-
related to work activities. Our studies have given us some evidence that
where documents are compiled and accessed outside rigid work-flow
patterns of document use, to correlate too closely data-driven events
with activity transitions can be risky. Likewise, to conceive detailed state
automata for activities that are supported by documental artifacts could
paradoxically reveal itself just like relying on a too simplistic model of
the work practices at hand for the practical inapplicability of the corre-
sponding automata14. Moreover, the WOAD proposal is also tuned for
the provision of awareness information regarding, among other things,
what is happening, at least with regard to some specific documental
data. As a result of these compromises, the WOAD generic automata
encompasses five states:
1. ready, when a certain activity template has been defined for a given
domain but it has not been instantiated yet.
2. enabled, when all the activity’s preconditions are true.
3. inhibited, when at least one of its preconditions is false, e.g.,
that expressing that a conflicting dependency with another higher-
priority activity is still present.
4. executing, when it can be inferred that an instance of an activity
has been being executed from the content of the fact space and the
model of the domain activities.
5. completed, when all the effects (i.e.,post-conditions) hold true, af-
ter that an activity has been in execution.
6. idle, a sort of pause of “parking” state, that an activity assumes af-
ter some time (to be defined) that no event in the fact space can be
13The dynamic aspects pertaining to the state transitions are left at design time, as specifiedbelow.
14For example, the state of being interrupted, that could be modeled by means of well-timedtime-outs, is unsuitable in many situations for domains where conventions on tasks schedulingare usually loosely defined and the status of the work is usually only indirectly derived fromdata produced and consumed.
116
5.1. L*WOAD FACTS
associated to it. The idle state is also proposed for all those situa-
tions that make being in some other state inconsistent.
Figure 5.9: The awareness-provision oriented finite state automata for WOAD activi-ties.
The transition functions of the finite state automata regarding the activ-
ity at hand are expressed in terms of work-related conventions into the
corresponding attribute of the w-activity-fact. These conventions make
the activity transition from a state to another. Activity preconditions,
by their definition, characterize15 the convention that triggers the en-abling of the activity: when preconditions are all true, then the activity
goes into the enabled state. Likewise, effects characterize the conven-
tion making the activity switch into the completed state: when effects
are true, then the activity changes into the completed state. Other tran-
sitions are characterized by contextual conditions occurring and being
represented within the fact space. Specifically, the transition into the ex-ecuting state depends on the activation (in terms of mere instancing) of
the d-activity-facts that belong to the w-activity-fact (see Section 5.1.2).
According to the domain- or application-dependent requirements, the
designer can conceive activity models that encompass more complex fi-
nite state automata. Complexity can imply either more states or a sparser
flow relation implying less degrees of freedom. The definition of the
flow relation requires the designer, for each kind of activity, express an
explicit correlation between contextual events — either on document-
fact, other contextual entity-fact or on temporal events — and the state
transition function of that activity into a declarative and WOAD com-
pliant form (i.e., into convention-facts). In Section 5.3.2, we will see
that activity transitions are triggered by specific partitions of the WOAD
15As it will be clear in Section 5.1.3, they constitute the if-side part of the correspondingconvention-fact.
117
CHAPTER 5. L*WOAD: THE WOAD LANGUAGE
mechanisms.
5.1.2 Relation-facts
.
Relation-facts are WOAD-facts that represent some binary relationship be-
tween two facts. Besides the attributes that they inherit from the WOAD-fact
template (i.e., those attributes that are common to all WOAD facts), relation-
facts are also characterized by a source, a target and a level attribute (see
Fig. 5.10). The source attribute indicates the fact that is in some relationship
with the target fact. The relation-level specifies whether the relationship is ei-
ther between classes or instances.
Figure 5.10: The general structure of a relation-fact. Extensions by with user-definedproperties are indicated as optional properties.
The relation-fact can express three semantically different kinds of relation-
ships.
Relationships between data As said in Section 3.3.2, WOAD distinguishes
between relationships and correlations. As a reminder, correlations are
118
5.1. L*WOAD FACTS
Figure 5.11: DJess syntax for the definition of a relation-fact template.
framework-specific and domain-independent relationship between ei-
ther elements, sections or entire document-facts that pertain to the same
or correlated aspects of what is documented (see Section 3.3.3). With re-lationship, we refer to the most generic concept of “association between
different pieces of information”, that obviously is significant at either
domain or application level. At application level, these associations can
occur either at class-level or at instance level: these different levels are
denoted by the relation-level property.
An example of the former level is given by the domain-dependent rela-
tionship “caring” between physicians (sources of the relationship) and
“patients” (targets of the relationship). The instantiation of such caring
relationship could, for example, occur between Ms. Smith (a physician)
and Mr. Jones (a patient).
Relationships between data and activities In Section 3.3.1 and then also in
Section 5.1.1, we said data can be put in relationship with both documen-tal activities — which directly write or read them — and work activities,which “include” the former ones and are part and parcel of any other
activity characterizing the work domain at hand.
If the designer needs to have input and output relationships be explicitwithin the fact space since she needs to refer to this kind of relationship forthe awareness-provision’s sake, she can have automatically created a num-ber of corresponding relationships relating specific data and work-activity-facts. These are derived by the L*WOAD interpreter from the input andoutput properties of the d-activity-facts that belong to the work activitiesconsidered. The designer can moreover specify at which level of granularityshe needs the rendering process to be applied to, according to the inter-nal structure of the content attribute of the d-activity-facts (e.g., modules,sections, paragraphs, even single fields).
119
CHAPTER 5. L*WOAD: THE WOAD LANGUAGE
For the semantics of the input/output relationships that can be rendered
through the relation-fact construct, the reader can refer to Section 3.3.2.
Relationships between activities As seen in Section 3.3.4, in the literature,
there are a number of approaches to the specification of inter-activity
relationships, whose application to a specific domain depends on both
the degree of detail needed and the very characteristics of the domain at
hand. Between the two main levels of activity proposed in Section 3.3.1,
we also propose a predefined belongs-to relationship between work ac-
tivities and documental activities. This relationship can be used to in-
dicate whether a documental activities is part of a more general work
activity, i.e., whether the latter contains, both logically and temporally,
the former.
Likewise to the case of the input/output explicitation, also other attributesof activities can be explicitly rendered into relation-facts. In particular, re-lationships representing dependencies among work activities can be syntac-tically derived from the pre-condition and effect attributes that two activ-ities share on common resources if the designer needs these be representedas single relation-facts.
5.1.3 Convention-facts
Convention-facts represent conventions applied in a certain application do-
main (see Fig. 5.12). They are represented in terms of condition-driven (i.e.,
if-then) sets of actions that can be executed according to some symbolic ex-
pression of context. Any convention-fact is a WOAD-fact that is characterized
by the attributes condition and action. Conditions are conditional elements re-
garding either the existence of some facts within the fact space or, more specif-
ically, some condition over these facts’ values. Actions refer to a sequence of
WOAD primitives that are transactionally executed to change the fact space
content. Conventions are made computable (i.e., executable, applicable at the
fact space content) when their conditions and actions are embedded, respec-
tively, in the antecedent and consequent attribute of WOAD mechanisms (see
next section).
In the current implementation of the L*WOAD, the convention-fact templateencompasses action and condition slots, that contain the code that will be ren-dered in a regular and activatable rule that DJess-based transitors can select and
120
5.2. INSIDE THE AWARENESS-FACT
execute (see Fig. 5.13): the latter represent WOAD mechanisms. The conditionslots contain conditional elements: these are either patterns or logical expres-sions. The formers are partial descriptions of fact templates or entity-fact withsome unbound variables: patterns are said to be true (or verified) if they arematched by some WOAD-facts that have been asserted into the fact space. Withthe term logical expression, we mean an expression in propositional logic whereit is evaluated some mathematical relationship upon the variables bounded toentity-facts. Also a concerns slot (actually a multislot, since it can contain moreobjects) is encompassed in the convention-fact structure: this is automaticallyfilled by the middleware with a reference to all the facts that are referred towithin the rule, i.e. to all the entities the convention applies to or is about. Thisallows to have rules that can carry out inference also on other rules. In this way,the designer can also conceive and have applied sort of meta-rules, that treat exe-cutable rules as any other kind of fact and apply to them according to what theseare concerned with.
Figure 5.12: The general structure of a convention-fact. Attribute type conventionsare explained in the implementative passage on convention-facts.
5.2 Inside the awareness-fact
The WOAD framework is intended to support actors that use a documental
system in making sense of what they read for coordinative purposes and in
producing information, while being aware of the fact their data will also be
121
CHAPTER 5. L*WOAD: THE WOAD LANGUAGE
Figure 5.13: DJess syntax for the definition of a WOAD convention-fact template asextension of the shared-rule template (see Section 4.3.2).
used for coordinative reasons. The way this support is guaranteed is by means
of the provision of proper awareness information (see Section 1.2) about both
conventions on work practices and documental practices. Within the WOAD
framework, the designer of such a supportive system is provided with a model
and a language by which to compose mechanisms that express those conven-
tions and make them computable bunches of procedural knowledge whose ap-
plication is both data- and context-driven16. Another basic idea of the frame-
work is to consider that such awareness information could be provided by
means of the very same artifacts compounding the web of coordinative docu-
ments used by actors to cooperate with each other. For this reason, the WOAD
language also encompasses predefined mechanisms to create and maintain a
bound between documental artifacts and their factual representation.
In this brief summarization, we have so far followed the path envisioned
in [Gutwin and Greenberg, 1997] backwards: in fact we have considered (a)
how to present awareness information, i.e., by means of documental artifacts;
(b) how to get that information, i.e., from the context2; (c) when to present
it, i.e., by means of conventional mechanisms that are both malleable and
linkable (see Section 1.3.1). We have now to determine “what people need to
know about others in the [same documental] workspace” [Gutwin and Green-
berg, 1997]. That is, to determine, or at least circumscribe the content, the
what (cf. Section 1.2.1) of the awareness-fact construct.
In Section 1.2.1 we have reported that a number of classifications have
16We even saw in Section 3.2 that both aspects can be harked back to a more comprehensiveacceptation of the term “context”.
122
5.2. INSIDE THE AWARENESS-FACT
been provided to be applied in different settings with various degree of gen-
eralization. From the most generic point of view, awareness deals with tak-
ing heed of “what is happening with another person, and [. . . ] where it
is happening”, i.e., with the hic-et-nunc17 dimension of cooperative work
(cf.e.g., [Gutwin and Greenberg, 2002]). In addition to that, thanks to the
concepts of convention and of mechanism that make it computable, aware-
ness information can be provided to actors with an explicit reference to the
context2. We can therefore distinguish between awareness aspects that deal
with either textual context or working context, documents and activities.
That said, any generalizing approach can be useful to detect common fea-
tures and hence extract similar requirements but one should not overlook the
domain specificity of awareness information: much of what an actor needs toknow about others heavily depends on the application domain: we agree that
“the exact information requirements can only be determined by conducting a
task analysis” [Gutwin and Greenberg, 1997].
In accomplishing our case study, we have collected the awareness informa-
tion requirements of actors involved both by interpreting what they did and
said in the light of some selected awareness aspects and by explicitly probing
them during the interview with some “key questions” related to those aspects
(see Fig. 5.14).
The questions and answers that we tried to collect in observing as actors
coordinate with each other in the real cooperative arrangements of our stud-
ies, have led to draw up a list of “kinds of awareness”. This list is far from being
comprehensive of all the nuances that could be made explicit in a specific do-
main characterization, but rather it is the result of a comparison between a
literature survey and what we saw practitioners from our field studies have
explicitly claimed are their awareness needs.
5.2.1 WOAD awareness types
Before characterizing each WOAD awareness type — i.e., what can be re-
ported in the corresponding attribute of the awareness-facts the designer de-
fines for the application domain at hand — we refer them to the context2
characterization so as to give the reader the first flavor of our terminology.
Browsing, inquiring, explanatory and alerting awareness refer to textual con-
text, more precisely to documental content that has been previously written
17A Latin expression for “here and now”.
123
CHAPTER 5. L*WOAD: THE WOAD LANGUAGE
Figure 5.14: Aspects of document-based awareness and related questions. Adaptedfrom [Gutwin and Greenberg, 1997].
124
5.2. INSIDE THE AWARENESS-FACT
within some documental activity. Provisionality, inconsistency and amendingawareness refer to textual content that is being written. Accounting awareness
is about work accomplished in the past, while coordination, enabling, inhibi-tion and reminding awareness regard work that actors are to accomplish in the
future.
In the following enumeration, we have associated each kind of awareness
with a particular and informal semantics. We intend those typologies as a sort
of “suggestion” that the computational system could convey to actors in pro-
moting awareness, irrespective of the very way the presentation/interaction
layer of the software stack architecture reported in Fig. 3.9 renders such nu-
ances in terms of either particular affordances or representational means (e.g.,
colors, highlighting, pop-up boxes and the like).
• Textual Context (in the past)
Browsing awareness : “mind that you can follow some links from this”This kind of awareness can be provided when the relationships18
that have a certain textual item (e.g., a content entry, a whole pas-
sage) as either their source or target can trigger mechanisms whose
aim is to have the actor gaining access to the textual item at hand
become aware that she can follow some links from that textual item
to a correlated one. We notice that such kind of awareness type is
provided by all the web browser applications, usually just by chang-
ing the font type, color and style of the word or item that indicates
the access to the hyperlinked resource.
Inquiring awareness : “mind that you can know more about this (butdon’t know exactly how)” This kind of awareness can be provided
when current relationships can trigger mechanisms whose aim is
to have the actor become aware that she can know more about
a certain content entry or passage but no further particular hint
is provided, so as to stimulate some inquiry. This case is different
from the previous, the browsing awareness, since in that case also
some additional resource, in terms of one or more links to follow, is
provided. So, this is a sort of vaguer and underspecified awareness
18Such relationships, in this case and in the following ones, can be drawn either at definitiontime, i.e., at schema level, by the designer between items of the documental structure; or atrun-time, i.e., at instance level, by the application users, between content items, i.e. data onthe documental artifact. On this point, please refer to Section 7.2.
125
CHAPTER 5. L*WOAD: THE WOAD LANGUAGE
that can be conveyed whenever further details are lacking. This can
happen because the person who filled in the item first did not want
or just could not provide any linked entity, but that notwithstanding
she needed to call for the attention of who would read that item
later, e.g., by relying on some implicit and tacit convention on that
item.
Explanatory awareness : “mind that there is a reason for this informa-tion” This kind of awareness can be provided when the existing
relationships can trigger mechanisms whose aim is to make the ac-
tor aware that she can know about the reason for a certain textual
item: e.g., why it was written or for which aim. This kind of aware-
ness can be also provided as outcome of mechanisms whose aim
is to provide actors with some additional motivation for fostering
commitment to some assigned task.
Alerting awareness : “mind that you have to check something about this”This kind of awareness can be provided when the existing relation-
ships between data and some other contextual condition can trig-
ger mechanisms whose aim is to make the actor aware that there is
something (that can be purposely left underspecified) that must be
checked about what she is reading or writing. The difference with
the inquiring awareness is that in the previous case it is indicated
an “opportunity of further investigation”, especially pointed out by
the compiler. In this case, instead, it is indicated the need to check
something since things are not going as expected (obviously with
respect to some convention). The purposely underspecification of
this kind of alert is conceived to find application in domains char-
acterized by openness, ambiguity and unpredictability. To give two
simple instances: let us consider the case in which the convention
of a hospital ward states that whenever the temperature of a pa-
tient is higher than forty degrees, an alert should be raised to the
accountable nurse: this case is about alerting awareness for “ab-
solute conditions”. Conversely, let us consider a “subtler” conven-
tion about “relative conditions”: such convention would state that
an alert should be raised whenever a certain vital sign, which has
been previously inserted into the documental system without rais-
ing particular warning since under the contextual conditions it was
126
5.2. INSIDE THE AWARENESS-FACT
negligible, becomes serious under some other conditions. The doc-
tors we interviewed during our field studies gave us the example
of operated inpatients, whose low blood pressure is normal unlessand until also signs of an anaemia show up, when it could be an
indication of internal hemorrhage.
• Textual Context (present)
Provisionality awareness : “mind that what you are reading/writing isstill provisional” This kind of awareness can be provided accord-
ing to conventions by which, in a given cooperative arrangement,
either data are consolidated or committed to some official reposi-
tory. Or alternatively, according to conventions by which data are
purposely conveyed as still provisional and pertaining to an unfin-
ished job19. If data are written or read after the application of the
latter conventions or just before the committing conventions are
applied, then corresponding mechanisms can be triggered to make
the writing or reading actor aware that what he is working with is
still provisional. As regards this kind of awareness, the most signifi-
cant case is when committing conventions have been only partially
or unsoundly applied by actors that meant to make then consoli-
dated.
Inconsistency awareness “mind that you have to check this, somethingcan be wrong with it” This kind of awareness can be provided ac-
cording to either some formal data representation or more local
conventions by which data are considered lacking in consistency
with respect to their type or with respect to other data previously
recorded in the documental system, respectively. In the former case,
inconsistency awareness can regard body temperature data that are
higher than fifty degrees (i.e., an impossible physical condition), or
dates of scheduled examinations earlier than today’s date and sim-
ilar cases concerning all the definition of a data type in a given ap-
plication domain. In the latter case, inconsistency can regard more
abstract aspects of an application domain, like that between some
drug administration with some particular disease or allergy, or be-
tween a patient-centered and some work-related condition (e.g. a19On the requirement that data could be explicitly conveyed as still transitory or informal,
the interested reader can refer to [Hardstone et al., 2004].
127
CHAPTER 5. L*WOAD: THE WOAD LANGUAGE
pregnant woman scheduled for a C.A.T. examination, or a meat-
based meal ordered for a vegetarian inpatient). The point that dif-
ferentiates this kind of awareness and the following, is also that
inconsistency awareness does not necessarily require an amend-
ment, since actors can anyway find a reason to cope with a partial
inconsistent state of the world, or even to supersede the model by
which a sound situation is fallaciously considered inconsistent.
Amending awareness : “mind that you have to check this, and correct iteither” This kind of awareness can be provided according to either
some formal data model or more local conventions by which data
are considered mistakes with respect to their type or data represen-
tation. This case is slightly different from the former, in that data
that the actor is filling in result in syntactic mistakes, like a date
where it is supposed to be filled in a name, an e-mail address that
is filled in without the at sign (‘@’), or even a tax number field that
is empty (where a predefined ‘not available’ value is expected for
those cases in which such number cannot be timely filled in). Ac-
cording to a foundation tenet of the WOAD framework, we prefer
limit the direct amending intervention by means of the computa-
tional system itself and prefer speaking of proper “warning” mes-
sages that are raised by some awareness-providing mechanisms ac-
cording to the constraints that are imposed to data within a certain
documental system.
• Work Context (in the past)
Accounting awareness : “mind that person X did (wrote) this” This
awareness information is provided by mechanisms that access to
the data stored within the d-activity-facts, regarding both who did
something (or was responsible for, in the case of work activities)
and when she did it. The provision of such information can be ex-
plicitly requested by the actor currently consulting the documenta-
tion, e.g., by accessing a sort of history or log of updates for a cer-
tain data field; or automatically provided by mechanisms that are
triggered by some contextual condition. According to the degree of
granularity of the work context representation, such awareness in-
formation can be characterized also in terms of other contextual in-
128
5.2. INSIDE THE AWARENESS-FACT
formation besides merely accountability and time: e.g., which was
the activity that enabled or triggered the record, where it has been
accomplished, whether it is traceable back to some routinary task
or to some handling of an exception, and the like. This kind of
awareness thus relates to the requirement to facilitate the unpack-
ing of the context of production of a certain documental value. For
instance, a convention of a hospital ward could state that if a cer-
tain item has been recorded by a nurse far later than the scheduled
end of her work-shift, this could mean that it refers to a serious
emergency handling and also that recorded items should be taken
with some caution.
• Work Context (in the future)
Enabling awareness : “mind that you can do that” This awareness in-
formation can be provided whenever an activity-fact has all its pre-
conditions made true by the current context, i.e., the current con-
tent of the fact space, that is whenever some activity convention
has triggered an activity to switch to state “enabled”. Obviously,
in order to prevent a clear problem of information overload (see
e.g., Section 7.2.4), only those activities that are very specific to a
given situation could be suggested to actors for commencement,
i.e. activities that are fine-grainedly characterized in terms of pre-
conditions.
Inhibition awareness : “mind that you could not do that” This aware-
ness information is obviously the opposite of the previous one: it
can be provided whenever an activity-fact has at least one of its
preconditions made false by the current content of the fact space,
i.e., whenever some activity convention has triggered an activity
to switch to state “inhibited”. This can happen whenever a con-
flicting activity is in execution or for a number of other reasons we
have briefly outlined in Section 3.3.4. Also in this case, the designer
has to cope with possible nagging warnings about what the actor
can not do at a given time. In order to prevent those cases to hap-
pen, such awareness information could be provided to actors only
when they are actually providing the computational system with ev-
idences that they are executing an inhibited activity. In those cases,
129
CHAPTER 5. L*WOAD: THE WOAD LANGUAGE
in order to have actors get all the information necessary to decide
whether to “roll back” to other licit activities or to persist in the
inhibited one, the system could also make explicit the conditions
that are not satisfied and that made unapplicable the activity at
hand, by conveying the corresponding information defined in the
source and condition properties of the awareness-fact and its appliedconvention-fact, respectively.
Reminding awareness : “mind that you are supposed to do somethingabout this” This kind of awareness information can be provided
either to convey a slightly stronger indication on a to-do activity
than enabling awareness. In fact, reminding awareness can be con-
veyed to point out that some task should be executed, rather that
could be executed. Alternatively, such awareness information can
be used to, namely, remind some specific actor or role that it is due
time for the execution (or completion) of a previously scheduled
task. Since in the activity model proposed within the WOAD frame-
work there is not a strict characterization of the temporal aspects
(see Section 3.3.4 for details), mechanisms providing awareness on
things to be reminded must be based on some domain dependent
specification — e.g., the definition of concepts like “diagnostic ex-
amination” that are characterized in terms of scheduled time —
and some computational capability to feed temporal information
into the fact space.
Coordination awareness : “mind that others rely on the fact you dothat” This awareness information can be provided by mechanisms
aiming at making actors aware of some activity interdependency
and hence at prompting them to actively manage it. Such mecha-
nisms could be sensitive to conditions related to either sequential
activities that must “wait” until some other has been accomplished,
thus keeping resources underutilized and practitioners waste their
precious time. Or to some w-activity-fact whose internal state has
been set to “idle” after some time-out occurred. The corresponding
awareness could be conveyed in order to make the actors involved
in the “blocking” activities feel committed and determined in sup-
porting the dependent colleagues.
130
5.3. L*WOAD PRIMITIVES AND MECHANISMS
5.3 L*WOAD Primitives and Mechanisms
A mechanism specifies when some primitives are to be executed and how they
are to be combined together so that the latter can manipulate the fact space
according to the context, the user needs and the awareness provision require-
ments.
L*WOAD mechanisms realize the basic interactions occurring between the
model’s components (namely actors, documents, fact space and transitors):
(a) share (and unshare) a document within the fact space; (b) add an infor-
mation into the fact space (c) retract an information (d) modify an informa-
tion within the fact space (e) provide awareness information to actors (see
Fig. 5.15).
Figure 5.15: The general mechanisms enabling interactions among the model’s com-ponents: from left to right, the generic actor, the generic document, the fact spaceand the generic transitor.
L*WOAD mechanisms are conditional mechanisms that are applied only
when some conditions are verified, much like are rules within the rule-based
programming paradigm20. Consequently, all WOAD mechanisms are com-
posed of two parts: an antecedent (an if-side) and a consequent (a then-side),
bound together by a strict causal relationship like cause and effect. The an-
tecedent expresses all the conditions that must be true — i.e., occur in the en-
vironment, and be mirrored in proper representations within the fact space —
for the mechanism to be applied. Whenever all the conditional elements of a
mechanism are true, then the consequent side of the mechanism can be ap-
plied by some transitor.
The consequent side contains a number of primitives by which to act ei-
ther on the web of artifacts or the fact space. The execution of mechanisms
20L*WOAD mechanisms are rendered as activatable rules within the rule sets of transitors.This equivalence and the fact that mechanisms/rules are conditional executable constructs hasan important implication. In fact, the designer does not have to worry about the time — withinthe control flow of its application — in which those mechanisms are to apply, but she has onlyto define all the conditions that can trigger the mechanism computation at the right time.
131
CHAPTER 5. L*WOAD: THE WOAD LANGUAGE
Figure 5.16: Mechanisms can abstract contextual data from documents and vice-versa, can inform documents of contextual elements
makes the fact space (its content) transition from a state S1 to a new state S2
as a function of S1. Moreover, since the fact space also contains a declarative
representation of the context in which documents are used in a cooperative
setting, mechanisms can produce facts describing the context at a certain de-
scription level by “deductively” deriving the latter from facts that describe it
at a different level: for example, mechanisms can be used to derive a more
abstract and domain level representation of context (e.g., “it’s lunchtime”)
from a data- and document-dependent level one (e.g., “it’s twelve o’clock” or
“the lunch serving checkbox is ticked off on the schedule sheet”, respectively).
Obviously, also the opposite holds true (see Fig. 5.16).
The WOAD framework provides designers with a generic mechanism tem-
plate by which to create any domain-specific mechanism (see Fig. 5.17), as
well as with some predefined mechanisms that are associated each with a spe-
cific primitive .
5.3.1 The generic mechanism template
The generic mechanism is characterized by four attributes (see Fig. 5.17): a
name, a description, an antecedent side and a consequent side. Which condi-
tional elements are expressed within the antecedent side is up to the appli-
cation designer according to the domain requirement and to the application
logic. The consequent side is further structured into three partitions; parti-
tions can be seen as sets of primitives that can be empty, except one in every
mechanism.
Each mechanism encompasses (a) a content partition (b) a work context
132
5.3. L*WOAD PRIMITIVES AND MECHANISMS
Figure 5.17: The general structure of a WOAD mechanism.
partition (c) an awareness partition. In these partitions, content transforma-
tion, work context characterization and awareness provision are considered,
respectively. This template suggests designers how to structure the design of
a WOAD mechanism and suggests them to divide concerns regarding either
document, work context or awareness “management”, respectively, by prop-
erly gathering WOAD primitives. Once that the designer has defined some
convention-fact within the convention property of the document-facts and
activity-facts that describe the work arrangement at hand, she has already
got sets of conditions and actions (i.e., primitives) to reallocate in some ex-
ecutable mechanism: conditions will characterize the antecedent property of
the mechanism, while the actions will be allocated in the proper partition ac-
cording to the type of convention.
The WOAD middleware also provides a way to automatically generate a set ofmechanisms in which each gathers different conventions that have the same con-
ditions but differ for their action side. In this way, a document-, an activity- andan awareness-related convention that are sensitive to the same condition, e.g.,
133
CHAPTER 5. L*WOAD: THE WOAD LANGUAGE
“it’s noon”, would be rendered into an activatable mechanisms, whose antecedentwould only contain the condition “it’s noon” and whose consequent would gatherall the convention-facts’ actions, each allocated in the proper partition (the con-tent, work-context and awareness partitions, respectively. This is accomplished bymeans of the spread primitive described in Section 5.3.2.
Before going into the details of WOAD primitives and predefined mecha-
nisms that make their application context-aware, we spend some word about
some aspects designers should cope with about the three different partitions
of mechanism consequent.
Content partition Within the content partition, mechanism designers should
concern about the determination of new values for the properties of the
content structure of a document. Documents can be seen as the output
interfaces of the overall WOAD system21 and hence through documents
the system can either provide, suggest, or propose actors with values
that could be used within a document. These values are derived from the
evaluation of arbitrarily complex functions contained in the consequent
part of the mechanism and their insertion be triggered by arbitrarily lay-
ered contextual conditions (i.e., conditions pertaining to different levels
of context description).
Primitives (specifically, from modification mechanisms, see
Section5.3.222) can be used to process data in order to produce
other documental data with some degree of reliability. Examples of
“content transformation” managed within the content structure can be
taken from the production of ‘copy values’ replicated across multiple
documents when some correlation for replicated data exists or the
production of new data by mathematical derivation like data processed
within a spreadsheet.
When a document-data content is modified as consequence of an output ofa d-activity-fact, the middleware automatically insert a time-stamp in thecorresponding slot of the instance fact
Work Context partition The work context partition is where the mechanism
21In the following, with ‘WOAD system’ we intend any implemented WOAD-compliant com-putational system encompassing a set of transitors sharing the fact space as their commonworking memory.
22The reader should mind that new data to a document are not added to the fact spacethrough an assertion, but rather through the modification of document-facts.
134
5.3. L*WOAD PRIMITIVES AND MECHANISMS
designers can explicitly manage activities and hence define, assert and
modify activity-facts, both work and documental ones. In this partition
of the mechanism, the system tracks the status of the current context
into activity-facts and keeps those facts up-to-date accordingly. In the
work context partition, designers should gather primitives so as to fol-
low the current status of the work: this means to track both choices and
decisions made by actors in the field of work and to consequently up-
date the current status of the corresponding activity-facts, on the base
of data actors produce or access. The antecedent side of the mechanism
by which “work is followed” would be also sensitive to data regarding
agendas and work schedules, to data-activity and inter-activity relation-
ships, to entity-facts representing the past flow of work and possibly to
entity-fact acting as time-stamp.
The track of which activity is going on would be carried out, on the one
hand, on the basis of a sort of guessing from data produced and ac-
cessed and a more or less fine-grained process schema of work activities
correlated with documental ones: e.g., which data are input or output
of an activity, which precondition is currently true and which false. On
the other hand, work tracking can be done in virtue of an explicit dec-
laration of actors about what they are currently doing or what they will
do next, which they possibly state on artifacts that specifically employed
to track the status of the work (e.g., to-do lists, work schedules, shared
agendas).
The reader should also mind that work-following is not equivalent to
proposing a structured flow of work, but just to “interpreting” what is
going on within the cooperative arrangement. Only once the system has
“interpreted” the environment in which artifacts are used, it can also
provide document readers and writers with information of either work
awareness or coordination (see next item).
Awareness partition In the awareness partition, awareness-facts are either
defined, created (i.e., asserted), modified or retracted according to the
application requirements. Awareness information can be provided either
because of something occurred about the content (i.e., the document-
facts) or about the overall work context (among which the activity-
facts). From the former point of view, mechanisms can be used to pro-
vide some sort of fulfillment-awareness, in that they can be conceived to
135
CHAPTER 5. L*WOAD: THE WOAD LANGUAGE
support users both in filling in forms and in fulfilling the implied doc-
umental quality requirements of a given form. As an example of doc-
ument filling-in, we can mention a case from our field study, the so
called “formulation problem”. This problem regards the formulation of
a correct nourishment solution to provide premature newborns with by
intravenous feeding: such problem concerns the accurate computation
of the correct nutritional supplies with respect to a certain diet regi-
men and under the constraints of a correct fluid balance, the concur-
rent assimilation of compatible drug “cocktails” and the overall condi-
tions of the inpatient. It is this multi-layered and contextual nature of
the value processing that distinguishes the formulation problem from a
mere spreadsheet computation. For this reason, it could be safer not to
make the compilation of the corresponding infusional therapy form com-
pletely automatic, but rather to provide nurses with what we defined in
Section 5.2.1 either alerting, inconsistency or amending awareness if the
system detects (by mechanism triggering) that they have made some
mistake; or alternatively, to automatically insert “correct” values into
the form while also providing nurses with either provisional or inquiringawareness so as to urge them some further verification.
As an example for quality requirements fulfilling, we have considered
in a previous work [Cabitza and Simone, 2006] how awareness can
be provided after that the goodness quality of an information has been
checked. Mechanisms can check whether an information is sufficiently
complete or pertinent with the activities that are correlated with that of
production of the data at hand, depending on the very local context of
production (e.g., text area, section, documents) and consequently pro-
vide actors with inquiring, amending or coordination awareness23.
Likewise, also possible syntactic as well as semantic (relational) mistakes
can be checked and have users be aware of. For instance, a date can be
incorrect as regards either its format or its compatibility as attribute of a
particular entity. The former case is the case of a regular syntactic checks
and of mechanisms that provide amending awareness. The latter is about
the conventional semantics of certain properties that is associated with
23In [Cabitza and Simone, 2006] we focus on this latter case, when we consider the ad-ministrative and clerical personnel of the hospital management positively rely on the extentclinicians produce accurate and complete records as necessary precondition to have their jobfeasible.
136
5.3. L*WOAD PRIMITIVES AND MECHANISMS
inconsistency awareness: e.g., today’s date could be the only correct one
for some fields, while conversely a past date and a future one are the
only feasible for anamnestic data and scheduled activities, respectively.
Awareness-fact can be associated to any sort of alerts, reminders and
other “awareness affordances” that show up on the documental artifacts
that compound the web of artifacts so as to suggest actors about what
should be better do next.
By means of proper awareness-fact and correlated mechanisms, design-
ers can have transitors suggest the possible work activities that actors
can or should perform on the basis of the current status recorded within
activity-facts and other contextual facts. Let us consider, for instance,
the alerting and enabling awareness as could be provided in the clinical
domain that we will describe in more details in Chapter 6. As regards
the former type of awareness, let us just recall the example given in
Section 5.2.1 about the “absolute condition” convention on inpatients’
body temperature: the graphical vital parameters form where actual tem-
perature values are little by little recorded can be seen as a document
whose recorded values can alert clinicians and hence enable caring in-
terventions or processes according to local ward conventions or even
world-wide clinical pathways [Berg et al., 2005, Campbell et al., 1998]
(on this last point, see Section 8.3). As regards the enabling awareness
type, let us briefly anticipate the case of the exam request form that will
be extensively treated in Chapter 7: on that form, to jot either a capital U
(standing for Urgent) or a capital R (for Routine) can trigger correspond-
ing mechanisms that either create or modify the “to-do-list” of nurses, or
that someway highlight the form’s fields to be filled-in so as to either
enable some corresponding task (cf. enabling awareness), or to remind
nurses about its completion (cf. reminding awareness).
5.3.2 Predefined mechanisms and WOAD Primitives
Predefined mechanisms are mechanisms whose antecedent side is still generic,
but consequent hosts only a primitive. For this reason, primitives can be
introduced by the corresponding mechanisms that make their application
condition-driven. We distinguish between:
definition mechanisms by which fact templates can be defined within a cer-
137
CHAPTER 5. L*WOAD: THE WOAD LANGUAGE
tain fact space, according to some run-time condition as extensions of
other templates24.
assertion mechanisms by which new facts are added to the fact space.
deletion mechanisms by which facts are deleted from the fact space.
modification mechanisms by which facts are modified and the fact space
changed according to the context and the conventions that apply to the
context.
document-sharing mechanisms by which documents are shared within a cer-
tain web of documental artifacts and hence represented within the cor-
responding fact space as document-facts.
convention-spreading mechanisms by which conventions are published and
released within a certain web of documental artifacts and hence rep-
resented both within the corresponding fact space (as convention-fact)
and within the transitors’ rule sets (as executable mechanisms).
correlation mechanisms by which correlations and relationships between
entity-facts are created at run-time.
Each mechanism is then characterized by the primitive that is employed in
its consequent side (see Fig. 5.18).
The definition mechanisms employ the define primitive. This primitive
takes three arguments as input: (1) the name of the new fact template; (2)
the woad-fact the new fact is an extension of (see Section 5.1.1); (3) the
properties to extend it with.
The assertion, deletion and modification mechanisms in their consequent
sides employ the assert, delete and modify primitives, respectively. These
permit to accomplish the sharing of some specific information into the fact
space (by asserting it in such common repository), its deletion from and its
modification within the fact space, respectively. These three primitives allow
to produce changes within the fact space, but just from the content point of
view: no change to the fact structure — i.e., their templates — can be yielded,
unless some fact whose structure must change is retracted and then redefined
with a new structure and consequently re-asserted.
24In the most general case, as extension of some woad-fact template.
138
5.3. L*WOAD PRIMITIVES AND MECHANISMS
Figure 5.18: Summary of WOAD primitives and their parameters.
These three WOAD primitives take facts as input and overwrite the homony-mous functions provided by DJess to work with memories shared by distributedinference engines25. When a fact is asserted by means of the assert primitive, itis added (written) into the fact space. The middleware provides it with a uniqueID. If that fact is either a entity-fact or relation-fact the middleware fills in theclassname slot with all the fact templates this fact refers to by inheritance26. Ifthe fact is a convention-fact the middleware fills in the concerns slot with allthe fact templates the rules refer to, either as patterns in its antecedent or asprimitives parameters in the consequent side.The modify primitive takes a factas input27 and is used by transitors to change the values of a fact according tothe information the latter refers to. Whenever a modify primitive is applied to adocument-fact, the corresponding d-activity-fact in whose output attribute suchdocument-fact is reported is updated in its time-stamp attribute and consolidated.In this way, the middleware provides also a history mechanisms, that match allthe modifications to the documental content with corresponding outputs of dif-
25As a matter of fact, in DJess the delete is called retract.26This is accomplished by means of the get-templates function.27Here again, the implementation requires just its ID.
139
CHAPTER 5. L*WOAD: THE WOAD LANGUAGE
ferent instances of documental activities so as to report their executors and times.The document-sharing mechanisms employ the share primitive. This primi-
tive recalls the concept of “sharing”, since its task is to put in common a certain
documental artifact within a certain web of artifacts. This task is accomplished
by automatically carrying out four sub-tasks28: (1) it takes a document as in-
put; (2) it defines a template of document-fact (see Section 5.1.1) structured
according to the document structure; (3) it asserts an instance of document-
fact into the fact space, inserting values that correspond to the current content
of the document; (4) creates a bind between the documental artifact and its
fact-based representation (i.e., the document-fact) within the fact space. Un-
til the corresponding document-fact is retracted, this bond is such that any
modification the user performs on the “bound” document is mirrored into the
fact representation within the fact space and vice versa, any modification the
transitors perform on the documental fact is rendered — or better yet, shad-
owed — on the artifact in terms of output.
At completion of the description of the operations accomplished by the exe-cution of the share primitive we recall the automatic creation of d-activity-factsaccording to the structure of the document at hand mentioned in Section 5.1.1.
The convention-spreading mechanisms employ the spread primitive. This
primitive is used to make computable into one or more transitor the conven-
tions represented by means of corresponding convention-facts. Once conven-
tions are spread across the transitors of the web of artifacts, these can apply
the corresponding rules according to the context. The spread primitive takes
a set of convention-facts (at least one), as well as a set of transitors as in-
put and has the latter load a corresponding mechanism into the set of all the
mechanism (i.e., activatable rules) they can apply to the fact space content.
The spread primitive can then be also used to gather more conventions into
some encompassing behavior: this is accomplished by associating a cumulative
label to a set of conventions and to make them applicable by some computa-
tional machine (i.e., some transitor) so that they can contribute in making the
fact space evolve (i.e., change) over time and according to possibly additional
aspects of the context even at run-time.
From the implementation point of view, such primitive is composed by severalcalls — a call for each transitor that must load the rule into its rule-set — of theload-rule function. This function is provided by the communication middleware
28Designers that employ such primitive do not have to worry about how this is accomplished,since the share primitive does all the job transparently.
140
5.3. L*WOAD PRIMITIVES AND MECHANISMS
to add a shared rule to the local rule base of an inference system (in our case, atransitor). See Section 4.3.2
Correlation mechanisms employ the correlate primitive. In this regard,
however, a caveat should be raised. Obviously creating correlations among
data and categories is a creative task that involves for the most part human
actors. Conversely, the correlate is a primitive that can be executed by tran-
sitors to accomplish the task of contributing in inferring new correlations or
proposing them for human validation (cf., e.g., [Mark et al., 2002a, Cabitza
et al., 2006c]). Once the WOAD designers have expressed general relation-
ships holding between categories, they can call the correlate primitive on a
pair of facts that are in some relationship and see whether some other corre-
lation can be created.
To better explain this important point, we employ two examples. The first
one regards a correlating mechanism29 that accomplishes the inheritance of
relationships. In Fig. 5.19, we see the code of a mechanism that can be de-
scribed in this high-level way: if two entity-facts are put in relationship by
means of a class-level relation-fact, all the entity-facts that are defined as ex-
tensions of these two entity-facts can be put in the same relationship, but
at object level. The second example regards the WOAD-specific correlations
occurring with data that must be replicated or duplicated within the same
web of documents (see Section 3.3.3). If the designer sets a duplication re-
lationship between two fields in two different documents, she could conceive
a mechanism that detects the presence of a datum in one of these fields, and
consequently calls the modify primitive to copycat the datum into the second
field and then the correlate primitive to create a new correlation between
the two instances.
29The painstaking reader could notice that designers can indeed generate any correlatingmechanism from that herein provided just by defining the conditional element that make themechanism applicable in a certain domain and context.
141
CHAPTER 5. L*WOAD: THE WOAD LANGUAGE
Figure 5.19: Example of DJess syntax for the definition of a WOAD correlation mech-anism.
142
Chapter 6
The reference domain:documenting the hospital ward
We take the hospital ward domain as a paradigmatic example where inter-
connected sets of heterogeneous artifacts are proficiently deployed and used
for a clear and transparent purpose: the recovery of ill or injured people. The
interconnected set of documents that support clinicians1 is called with a num-
ber of different names according to the context of analysis. In our study we
will refer to it as the clinical record2. In this chapter we will report our obser-
vational field studies that we conducted with the aim of understanding how
clinical records are compounded by a number of artifacts that are heteroge-
neous in structure and function but that still result in a highly interconnected
and cross-referenced set of documents. In so doing, we aim at making clearer
how clinical documentation could be a good example of a web of coordinative
artifacts in which then to apply the WOAD model and language to provide the
involved actors with an awareness-oriented computational support.
1Since the term ‘clinic’ denotes both the group of people working in the same healthcarefacility, and the place itself, we have chosen to denote as ‘clinician’ any qualified person whois involved in the treatment and observation of living patients, i.e., physicians as well as nurseand the like. Cf. the Random House Unabridged Dictionary, Random House, Inc. 2006.
2What we call in the following clinical record is also widely known as patient record [Dicket al., 1997], especially in those domains where it is useful to stress its patient-centered nature.In order to dispel some possible misunderstandings regarding what could be alternatively de-fined patient record, health record, medical record or even hospital record, we chose the neutralterm clinical record to refer to the set of documents pertaining to a single stay of an inpatient insome hospital-like facility.
143
CHAPTER 6. THE REFERENCE DOMAIN: DOCUMENTING THE HOSPITALWARD
6.1 Medical work at Hospital as Cooperative Work
Hospital arrangements are strongly characterized by the need for tight coor-
dination of the therein involved actors: hospital and more specifically hospital
wards are settings where artifacts are used by several and heterogeneous ac-
tors, which work together in a conscious way in the same main process of care
providing, and whose job necessarily implies a big deal of cooperation and
mutual interdependency. The very same notion of articulation work has been
originally proposed by [Strauss et al., 1985] from observational studies in the
hospitalization domain as an analytical framework to understand and explore
the interwoven nature [Nurminen et al., 1997] of the modalities by which ac-
their individual actions to achieve a common goal such as that of handling
the interrelationships involved in managing illness trajectories. With such term
Strauss et al. [Strauss et al., 1982] explicitly referred not only “to the physi-
ological unfolding of a patient’s disease but to the total organization of work
done over that course of illness” as well as to the impact involved with that
work and its organization”.
Besides providing the first settings where researchers studied the phe-
nomenon of cooperative and articulative work, hospitals still provide re-
searchers with a paradigmatic example where the dimensions pertaining to
the work of the involved practitioners are very complex and critical to cope
with, also because of their obvious and decisive influence on patients’ — and
their relatives’ — physical health and psychological comfort. Strauss again
warned against considering “the management of a course of illness [less than]
immensely difficult to rationalize” [Strauss et al., 1985]. Too many factors
play against the standardization of more than small “arcs” of trajectory and
even those standardized portions are continually subject to potential disrup-
tions. The mirage of ‘coordination of care’ — as Strauss call it — has to be
traced back to the complexities and hazards of working with and over people
but also to other aspects of hospital work that make the design and deploy-
ment of supportive technologies as interesting as much as challenging. In fact,
Strauss’s and others’ works have collected several evidences that work done
over and across patient trajectories is highly cooperative, specialized and dis-
tributed [Reiser, 1984, Strauss et al., 1985, Atkinson, 1995, Timmermans and
Berg, 2003].
144
6.1. MEDICAL WORK AT HOSPITAL AS COOPERATIVE WORK
6.1.1 Hospital actors and venues
In a hospital ward cohabit senior physicians with long-trained competencies,
younger physicians with strong ambitions, senior nurses with long-term expe-
riences, younger nurses with high professional expectations and various assis-
tants of different extractions. They are all actors that are different for a huge
number of aspects, like role — i.e., responsibility — education — i.e., com-
petencies — and experience — i.e., reliability — even aspirations and hence
motivations. Such differences in profiles and roles make this heterogeneous
group of coworkers difficult to characterize and even more difficult to for-
malize. Some authors claim that hospital ward actors have “only a limited
and superficial understanding of each other’s work” [Reddy et al., 2001]. That
notwithstanding, they still have constantly to assign, delegate and hand over
items of work to other colleagues [Berg, 1998,Berg, 1999,Engesmo and Tjora,
2006] and to rely on the fact that these colleagues do their own job well and,
not a minor detail, as they expect it to be done.
Moreover, hospital wards are teamwork settings where work trajectories
unfold across distributed locations [Bardram and Bossen, 2005a] and different
times [Reddy and Dourish, 2002] and where practitioners are consequently
and continuously moving from place to place [Luff and Heath, 1998] and take
advantage of the physical environment in different ways to articulate the dy-
namics of their activities [Gorman et al., 2000, Bang and Timpka, 2003]. As
such, these cooperative work arrangements can exhibit even divergent char-
acteristics: on the one hand, due to the complexity of overlapping work shifts
and workload variability, clinicians can end up by working together several
times in a week in some periods, but also see each other much more seldom in
other periods and cooperate either over distant shifts in time or distant wings
of the same hospital building. This is the case of, e.g., referring and consulting
physicians for the management of recurrent similar cases.
Clinicians can hence rely on verbal and proxemic communication to have
their work done as well as rely on the work accomplished and accounted by
distant colleagues in a coherent effort to contributing to the patient’s health
and recovery.
These domain characteristics also make difficult to draw a clear-cut line
between those clinicians that do share a number of conventions either on the
proper clinical conduct or on the agreed and seamless cooperative behaviors
and those clinicians that do not share these conventions. This can also be ac-
145
CHAPTER 6. THE REFERENCE DOMAIN: DOCUMENTING THE HOSPITALWARD
centuated by the fact that such conventions can have never been made explicit
or externalized [Nonaka and Takeuchi, 1995] in any written or verbal form.
The set of all possible users of a clinical documentation is much broader
than just the number of members of the ward community. In fact, the very
same documentation can be also handled by administrative clerks, secretaries,
external consultants, general practitioners, i.e., all the actors that can be in-
volved, to some extent, with the same clinical case, i.e., patient. In this case,
we adopt the term introduced in [Habing et al., 2001] where care-cluster de-
notes all actors responsible for delivering a specific type of care to a patient
and care-network the set of heterogeneous care-clusters involved in delivering
care for a specific patient.
Our point is that these two concepts can be easily mapped into our con-
ception of interconnected sets of documents. In fact, single wards are strongly
associated with a particular type of care. Consequently, the local webs of arti-
facts that are used within a specific ward also characterizes an associated care-
cluster: the cluster of practitioners that fully make sense of these documents,
as regards their structure, function and conventional practices of proper either
compiling or consulting them.
According to the extent these conventions are shared and known within
a care cluster, their members can be also considered a community of prac-
tice [Wenger, 1998], in that its members share all a concern for providing a
care of quality and for learning how to achieve a better quality of care3. In-
stead of community, we prefer speaking of clusters, networks and webs, since
such terms are more neutral with respect to the indication of either actors’ or
artifacts’ sets and also because they all exhibit the properties of scalability and
composability at any level of description and hence allows us to comprehend
also those cases in which either different communities need to collaborate, as
happens for any external referral (see Chapter 8.3), or in which members of
some subsets of the same community of practice are responsible for the man-
agement of smaller webs of documents, as in the case of nurses and doctors of
the same ward and their medical and nursing records (see next Section 6.3).
3In such a distributed and asynchronous setting as hospital wards are, moreover, this betterquality correlates to better ways of reporting and documenting the planning and performanceof care activities
146
6.1. MEDICAL WORK AT HOSPITAL AS COOPERATIVE WORK
6.1.2 Hospital artifacts
From the points made in the previous section, hospital wards can be assim-
ilated both to arrangements characterized by frantic, synchronous and co-
located collaboration, like control rooms (e.g., [Heath and Luff, 1992]); and
to settings where low intensity, asynchronous and distributed collaboration
occurs, as in waste-water plants (e.g. [Bertelsen and Bødker, 2001]). In such
settings, in order to cope with the ever arising contingencies that character-
ize clinical work, clinicians rely on well consolidated classifications, jargons
and pretty standardized procedures, as well as on a number of local con-
ventions and ad-hoc coordinative modalities that can also include occasional
workarounds and systematic trickery.
Classifications and high-level plans are reified into and supported by a
number of coordinative artifacts, such as whiteboards, forms, sheets, notes,
schemes, and documental templates [Bardram and Bossen, 2005b]. These ar-
tifacts are designed to provide order to and support the coordination of the
intertwining of multiple work trajectories.
This “web of artifacts” (cf. [Schmidt and Wagner, 2004, Bardram and
Bossen, 2005b]) guarantees the coordinative functionality through a delicate
balance between enabling and inhibiting, or also, promoting and constraining
action. Our point here is that this functionality is reached for the very inter-
connected nature of this web, which is compounded by loosely-linked tight-
structured documents and which is then characterized by a balance between
what we call fluid cross-referentiality and local rigidity, respectively.
In the expression “local rigidity”, the term local refers to the intra-
documental dimension while the term rigidity refers to the fact that doc-
uments consist of a predefined number of unmodifiable sections and that
these sections offer tabular structures that call for an ordered — and or-
dering (cf. [Schmidt and Wagner, 2004]) — compilation of data. Structur-
ing documents and their data is advocated as a necessary means to permit
interoperability among different facilities, statistical research and administra-
tive analysis [Gregory et al., 1995,Winthereik and Vikkelso, 2005]. Document
rigidity can also reflect some rationalized and standardized way to conceive
work planning and execution, which informs the design of document tem-
plates intended to support compliance and accordance to the clinical practices
proposed. Consequently, all clinical records to our knowledge are structured
in macro-sections that correspond to some general categories of some model
147
CHAPTER 6. THE REFERENCE DOMAIN: DOCUMENTING THE HOSPITALWARD
of medical work. These models constitute the basis for corresponding data and
document models.
For centuries, care notes were organized in chronological order, a prac-
tice dating to the Hippocratic school (fifth century B.C.) and its conception of
illness course as development [van Ginneken and Moorman, 1997]. From the
sixties on, also the problem-oriented approach to care recording [Weed, 1971]
began to spread in western hospitals [Tang and McDonald, 2000]. The note
structure proposed by Weed was laid out in the so called “SOAP structure”,
i.e., a structure aimed at facilitating the expression of any medical problem in
terms of “Subjective elements” (i.e., the complaint as phrased by the patient),
“Objective elements” (i.e., the findings of physicians and nurses), “Assessment”
(i.e., the test result and diagnosis); and a “Plan” for future actions and inter-
ventions on the patient [Mann and Williams, 2003]. Other models, like that
informing our case study, assume that hospitalization is a process composed
by an admission, a course and a discharge and call for clinical records with
three corresponding modules to fill in in this strict chronological order.
The local rigidity of clinical documents also allows clinicians to be sup-
ported in properly “moulding” the clinical information so that it can serve
both the informational and the coordinative function. We speak of moulding,
both from the representational and the conceptual point of view; on the one
hand, in fact, clinicians are guided in positioning data within fixed and rigid
tabular sections within which even very sparse stenography and concise data
can make sense in virtue of the schemas associated to those tables. On the
other hand, documents that are structured in ways that they either display
and request content, or request to be filled in with structured text (i.e., cod-
ified content [Henry et al., 1998]), limit the range of possible meanings a
datum can convey and, in so doing, the risk of ambiguity and misunderstand-
ing.
However, hospital domains also require a necessary flexibility to cope with
a kind of work that seldom can be considered just plain routine and that re-
quires tools that could leave practitioners with some room to handle break-
downs and make their deeds accountable and meaningful to other colleagues
in any unpredictable situation. Our point is that this degree of flexibility can
be achieved only by allowing data within documents structures to be properly
cross-referenced so as to acquire even temporary semantic connotations that
make perfectly sense only in a particular context or situation. We counter lo-
148
6.1. MEDICAL WORK AT HOSPITAL AS COOPERATIVE WORK
cal rigidity of documents with their capability to be more fluidly referenced
within a composite web of documents— i.e. at systemic level — a web where
linkages across structures and data therein stored are fluidly and dynamically
made out according to the current requirements.
Two important works on clinical practice separated by almost thirty years
[Garfinkel, 1967, Heath and Luff, 1996b] argue that medical documentation
provides flexibility because they do not carry precise descriptions but “rather
sketches, drawn through a few elements which provide a certain sense or
impression of an event” [Heath and Luff, 1996b] and which leave room for
correlation and interpolation. Interpolating a sketchy account and make sense
of succinct entries is made possible by the practice of fluid cross-referencing,
i.e., drawing either explicit or implicit linkages between data that enable at
the same time efficient and effective documental practice. According to these
studies, no single entry in a medical description can be understood on its own,
but rather the clinician has to piece together different entries in order to form
her interpretation and understanding of a given clinical fact. Heath and Luff
quote Gurwitch for the concept of Gestalt Contexture, when they claim that
medical records function as a whole and that only the relation of the parts
that constitute it define its unity, sense and its capability of being effectually
used irrespective of its intrinsic defeasibility4.
This cross-referentiality and distributed nature of medical documenta-
tion regard both the inter-documents dimension, where many documents con-
tribute together in constituting from complementary perspectives the overall
documentation pertaining to a single patient case; and the intra-document di-
mension, where many structured entries within the same note contribute by
virtue of their relationships in depicting a comprehensive picture of the evolu-
tion of a patient trajectory5.
4“The term [defeasibility] has been widely used in pragmatics and jurisprudence to describethe ways in which any rule or law, no matter how precise its formulation, will inevitable con-front circumstances, where despite their potential relevance, it is inappropriate”. (Heath andLuff, 1996, p.3)
5“By defeasing items across entries and assembling the text with regard to an impressionas to how this event is related to previous meetings concerning the particular illness, doctorsproduce careers or trajectories of illness.”(Heath and Luff, 1996, p.5)
149
CHAPTER 6. THE REFERENCE DOMAIN: DOCUMENTING THE HOSPITALWARD
6.2 The hospital web of artifacts
In order both to draw insights on real cooperative settings and to inform the
conception of the main tenets of the WOAD framework, we conducted a series
of field observations over a span of two years with different facilities of the
same hospital. Since the facilities at hand turned up with many peculiar as-
pects that to some extent appeared contradictory, we soon realized that gath-
ering a complete and detailed understanding of the setting at hand would have
been unfeasible. Therefore, we followed a “quick and dirty” approach [Hughes
et al., 1995] by which to quickly get a general picture of the setting and in-
form our further investigations on some selected aspects of its. In so doing, we
were able to recognize even pretty standardized care and coordinative activi-
ties as social actions embedded in a socially organized field of meanings and
references; from such a picture of cooperative arrangement we accordingly
selected those portions and aspects of particular importance in informing the
WOAD architecture and WOAD-compliant applications’ design.
6.2.1 The case study setting
The empirical data were chiefly collected via observations and interviews ac-
complished in two different wards of the same hospital: the Internal Medicine
and Neonatology wards of the Alessandro Manzoni Hospital. The Manzoni
Hospital is one of the largest (approximately 1000 beds and 2700 employ-
ees) and main teaching hospitals of the region at north of the city of Milan,
in Northern Italy. It is situated in Lecco, a city of 50,000 inhabitants, but it
serves a much wider provincial territory sheltering a population of more than
300,000 inhabitants. In 1995, the hospital ranked first in profitability and pro-
ductivity in Lombardy, the Italian region where one sixth of Italy’s population
lives and whose gross domestic product is the highest in the whole European
Union. In 2000, the hospital facilities moved to a brand new building where
both the clinical and administrative top managements could to some extent
partecipate in the design process to positively inform the rationalization of
space organization according to the main flows of resources within the hospi-
tal. In that new facility, we located our observational study.
150
6.2. THE HOSPITAL WEB OF ARTIFACTS
6.2.2 Two wards: two worlds, one record
The two wards were selected in order to collect and compare data and in-
dications from practitioners working in different specialties, but sharing and
using the same documental model and artifacts on a daily basis for the same
general purpose of care providing. Differences between the Internal Medicine
(IM) and the Neonatal Intensive Care Unit (NICU) are worthy of some consid-
eration since for many aspects they seem to be antithetic.
On the one hand, particular physicians, called internists, work in an IM
ward. These doctors specialize in the diagnosis and nonsurgical treatment of
a very wide range of adult diseases, and got a specific training in coping with
cases where several different illnesses may strike at the same time and it is
hence prevented a more specific hospitalization in some subspecialty ward,
like Cardiology or Nephrology.
Patients admitted to the IM ward are usually long-staying and acute ill
patients. Yet, since their average age is steadily increasing as the popula-
tion’s one, these patients tend to chronicize their disease and hence exhibit
a low level of autonomy but, at the same time, also medium/low critical-
ity needs. This kind of patients and illnesses has a peculiar impact both on
medical and nursing work. As regards the former, doctors have often to solve
puzzling diagnostic problems by evaluating and gathering symptoms that oc-
cur and change over time (the so-called “wait and see approach”) and have
hence to cooperatively share hypothesis over distant work shifts and agree on
even complex lines of probing and action across several shifts. On the nursing
side, IM patients require a lot of care work and also a big deal of sentimentalwork [Strauss et al., 1982] between care interventions.
Conversely, the Neonatal Intensive Care Unit (NICU) shelters premature
newborns with severe deficits and high criticality needs. Almost nine percent
of all newborn babies require to be admitted and be cared for in a NICU, also
because therein patients have a direct access to consultants, surgeons and an-
cillary services that allow treatment across a wide range of neonatal problems.
Stay lengths at the NICU vary depending on a number of unpredictable factors
and can range from a single day of observation to many months for the worst
complications. Since the Manzoni hospital serves a quite wide region, almost
two third of the admitted neonates come from external services and other hos-
pitals, for an approximate yearly intake of 400 critical newborns treated. All
these cases are managed by ten neonatologists and a 25-nurse staff that attend
151
CHAPTER 6. THE REFERENCE DOMAIN: DOCUMENTING THE HOSPITALWARD
premature infants by preparing and maintaining an intensive care regimen on
a 24-hour basis. This requires both physicians and nurses work hard together
and be ready to take decisions and intervene in reaction to severe and critical
events in the shortest time possible.
From the diagnostic point of view, the NICU, as any other intensive care
unit, is an example of setting where the subjective and verbal components
that physicians draw from the patient’s account of her sensations and feelings
lack completely. This component of the overall picture clinicians make of a
patient’s condition is usually compensated by an increase in collecting objec-tive facts which — although they are “objective” in that they are gathered by
precise sensors and specific machineries — must be anyway interpreted by
physicians and recognized within a number of guidelines or pathways that
the literature either substitute or consolidate from scientific evidences with
time. From the caring point of view, a NICU is a high technology-driven set-
ting where special machineries, digital equipments, sensors and incubators
support clinicians both in assessing the patients’ conditions and in providing
the needed care with increasing effectiveness over time.
These two wards are pretty different also as regards the extent artifacts’
use is distributed and communication is asynchronous. The IM ward occupies
an entire floor of the hospital building and it is divided into two symmetrical
wings of fifteen rooms each. The total capacity of the ward is 60 patients and
average stay is almost twelve days long. Each wing has its own nursing crew,
composed by twelve nurses and seven health assistants alternating in the space
of a couple of days over different work shifts. The nursing staff is coordinated
by a head nurse, whose role is mainly organizational and administrative. All
the ward activities are organized around two smaller teams composed each
by a nurse and a health assistant taking care of up to fifteen patients during
their duty shift. Teams alternate with each other over three shifts (morning,
afternoon and night) and hand over relevant information and scheduled tasks
during fifteen minute long hand-off conferences. Since wings are square blocks
of the hospital building and patients are sheltered by twos in rooms whose
beds are not easily visible from the outer aisle, nurses working in the same
shift can only occasionally see each other and have conversation only at the
admission desk, situated at the middle of each wing.
Conversely, the NICU is a single large room, divided in two smaller areas,
called “boxes”. Each box has enough room for approximately ten incubators,
152
6.2. THE HOSPITAL WEB OF ARTIFACTS
i.e., very complex units attached to various types of monitors and devices that
continuously monitor the infant conditions and guarantee dim light, constant
temperature, feeding and respiratory support. Each box is attended by small
teams of two nurses each, assisted by an additional nurse on duty till 16:00
which for this reason is called “jolly nurse” and is supposed to relieve outbursts
of workload. Also in this case, a head nurse with primarily organizational and
administrative duties plans the activities within both the boxes. Nurses of the
same team often work at arm’s distance, within the same box, and share the
same setting with up to four neonatologists that work shuttling between one
box and the other during the morning shift. Boxes are divided by a large door
that is always left open so that nurses of different teams can hear the alarms
from the other room and be aware of current workload and sudden needs just
by taking quick glances inside.
While the IM ward is open all the time to the public — i.e., to the inpa-
tients’ relatives and acquaintances — so that at rush hour the ward corridors
can be pretty “crowded”, public access into the NICU is strictly limited: staff
and visitors are required to clean their hands before admittance, as well as
wear gowns, masks and in some cases also gloves to reduce infection trans-
mission. This also has some influence on the different modalities face-to-face
communication is exchanged: while in the IM ward practitioners speak in a
regular tone of voice and it can also happen that practitioners summon each
other at the end of a corridor, NICU practitioners tend to whisper (although
there would not be strict need to): the quiet background noise of monitoring
devices working in the ever dim-lightened ambience is often interrupted by
slightly louder alarms, which each conveys a very specific meaning accord-
ing to its pitch, intensity and rhythms, that only experienced practitioners can
easily make sense of [Randell, 2004].
These differences apart, the management of the hospital had all wards and
departments adopt a very similar clinical documentation, referring to the same
patient record model established at regional level. We will come back to this
model, later, when we will describe what constitutes the clinical documenta-
tion employed in the wards at hand.
6.2.3 The nature of the study
Documents used within both the wards and the correlated activities involving
those documents have been studied relying on data coming from five differ-
153
CHAPTER 6. THE REFERENCE DOMAIN: DOCUMENTING THE HOSPITALWARD
ent types of source: (a) direct but yet unobtrusive observations, (b) semi-
structured interviews, (c) informal discussions, (d) attitude surveys and (e)
cross-documents analysis. During our observations, practitioners did not seem
bothered by being observed and were often willing to spend some further
time in explaining clinical terms and their local jargon, especially regarding
idiomatic abbreviations and shorthand expressions. We also had often the pos-
sibility to pose contextualized questions for further clarification, especially re-
garding those behaviors that looked to our eyes to have the characteristics of
tacit and informal conventions.
We clearly declared that our mission was to focus on coordination dynam-
ics involved in the articulation of caring activities and the correlated artifact
use: for this reason, we witnessed some informal coordinative meeting oc-
curred at admission desk, attended some official shift handover and observed
how practitioners use the clinical documentation to be supported in such sit-
uations [Cabitza et al., 2005b].
Taking into account privacy concerns, we deliberately did not cover bed-
side caring and did our best to avoid any contact with patients and their rela-
tives. Likewise, in collecting and surveying official documents and other ward
artifacts like notes, forms and records, we deleted all patient identifying infor-
mation.
From our informal conversations and field observations, we took sparse
field notes that we also used as starting point for the artifact analysis and the
semi-structured interviews we held with some key actors. These interviews
were pretty long and frequent meetings with the head physician and the head
nurse of the wards at hand, while they were briefer and sparser talks with
other nurses indicated by the head nurse for qualification and proneness to
being interviewed.
We asked the practitioners questions regarding the typical work day, the
most frequent cases of interruptions and routine breakdowns and the use of
artifacts in both routine and exception handling. As regards document use
some typical questions were “how do you use this sheet?”, “how often do you
use it” and “why, in your opinion, is it important you use it, and that you do
in that way?” so as to address not only the conventional side of documen-
tal practices, but also, to some extent, the motivational side and the extent
practitioners are aware of underpinning purposes and rationales.
Besides a standard list of questions we designed with the collaboration of
154
6.2. THE HOSPITAL WEB OF ARTIFACTS
an anthropologist, which also attended and leaded the first meetings, in each
interview we pretty soon let the conversation follow its own course and our
interlocutor touch her matters of concern regarding coordination within the
ward and the clinical record use (and misuse).
A thorough analysis of artifacts, and study of the correlated manuals and
operating procedures has followed the first round of preliminary interviews
and informed the next rounds. Interviews were conducted individually in ded-
icated rooms to guarantee privacy and confidentiality, so that participants
could feel free to say their personal opinions without worrying about what
their supervisor or other colleagues may think. Most of these interviews were
also recorded on tape. We asked permission to record the conversations, but
kept concealed the equipment so as not to condition the interlocutor’s natural-
ness. Recordings amounted to approximately twenty hours of selected talks.
6.2.4 Documenting the documentation
In line with the artifact-centered focus of our studies, in the following we re-
port the observations and studies accomplished over the documentation clin-
icians use to be supported in their daily work. As said above the clinical doc-
umentation is rather a scattered ensemble of loosely linked documental arti-
facts: for this reason, we will sketch the overall features of its whole first, and
then characterize its main components in some detail.
The two considered wards differ from each other in a lot of aspects, but
their staffs share an element that is of pivotal importance for the character-
ization of the WOAD framework: the same documentation. Obviously, it has
not always been so. A couple of years after the transfer of the main hospital
departments to the new location, and a couple of years before our studies, the
hospital management invested a lot of effort in defining a new organigram and
organization of the ward work. Specifically, the human resource and depart-
ment management area managed the transition from a set of unstructured and
informal artifacts to an articulated set of more structured documents, within
a more comprehensive rationalizing policy indicated by the regional health
administration.
This transition was conceived with the twofold aim to support ward work
more efficiently and to introduce unobtrusive quality verifying tools. The pro-
cess and artifact redesign activity was made with the involvement of sev-
eral ward practitioners’ representatives (including some representatives of the
155
CHAPTER 6. THE REFERENCE DOMAIN: DOCUMENTING THE HOSPITALWARD
nursing staffs) and led to new artifacts comprising the current patient record.
The sharing of the same core documents has allegedly facilitated a better in-
teroperability and articulation of activities between wards and departments
and a rationalization of service requests and provision.
As a matter of fact, we could not directly verify that the adoption of that
particular participatory approach in redesigning artifacts and practice has re-
ally facilitated the process of inclusion of these new artifacts into the everyday
caring and nursing tasks. Nevertheless we could notice that both physicians
and nurses were quite aware of the problem of being able to rely on well-
designed and structured clinical records: while it is not clear if this commit-
ment and awareness should be traced back to the preliminary involvement in
the adoption of the unified clinical record, we found that this critical ability
and good predisposition to the matter helped us both in making our goals
clearer to our interlocutors and in establishing a profitable collaboration.
Even if the core of the clinical documentation is the same in every ward,
ward-specific peculiarities and minor differences between patient records from
different wards do still exist. In fact, any medical specialty involves particular
recurrent procedures and needs, and this is reflected in the fact that the full
documentation in use in a given ward can differ from others in a bunch of doc-
uments that are added to the core set since they are specific for the treatment
and monitoring exigencies of a particular patient profile.
Besides extra-documents, we also detected differences in the very same
artifacts compounding the core set. That notwithstanding, these differences
are minor, easily circumscribable in the diagnostic and caring process (i.e.,
the phases of admission, discharge and service request are the same) and have
not hampered our task of getting a general and shared overview of the clinical
documentation employed within the Manzoni Hospital.
For instance, IM patients do not usually need to take drugs outside the
regular administration cycle, which is usually composed of four, five takes
per day. Those patients only seldom need also complex infusional therapies.
Consequently, the Single Pharmacological Therapy Form (SPTF see below)
used within the IM ward is organized according to a weekly schedule, which
is also appreciated by IM practitioners for its convenience of consultation and
updating therapies spanning across multiple days.
Conversely, NICU newborns require more complex therapy regimens,
dosages of medicines that can vary according to either laboratory exams or
156
6.2. THE HOSPITAL WEB OF ARTIFACTS
unexpected variations, and the introduction of drugs into a vein in twenty-
four hour long infusions. For this reason, NICU practitioners prefer to adopt
a daily schedule for the SPT sheet, in which they can also check and update
the regular rate of infusing. From the point of view of content, function and
structure the two versions of the SPT sheet are equivalent: they only differ in
the scope of information they can store (either hours or days) and in the way
tables and text boxes are rendered within a single A46 sheet of paper.
As a last remark before surveying the documentation at hand, the reader
should also mind that the following account is neither comprehensive nor
ever-valid, for at least two reasons.
On the one hand, many other artifacts and forms — which we purposely
overlook for the sake of conciseness —- are used even within the same hospi-
tal in other wards than the observed ones; even in the very same wards of our
study, some informal and ad-hoc artifacts can occasionally be used along with
the official and institutional ones, although for limited purposes and scopes,
both in time and use. That notwithstanding, we purposely concentrate on
some key artifacts compounding the official clinical record that we selected
for their subjectively perceived importance and frequency of use by means of
a likert-scale questionnaire (see Section 6.5 and Appendix A).
Moreover, clinical documentation should, from the ideal point of view, be
the only source of information for any informational and coordinative exi-
gences within a ward; it is the only one that is stored and consulted for any
legal or research reason even months after a patient has been discharged;
and it is the first and probably only set of artifacts that will be digitized into
an Electronic Patient Record when the hospital decides to undertake such a
project.
On the other hand, even over a structurally fixed documentation, docu-
mental practices do change over time. This can be due to either some massive
modification implied with the introduction of some standard for interoper-
ability at hospital, regional or even national level; or rather to some slight but
important adjustments locally established within a limited group of users to
better fit their needs and idiosyncrasies.
6The ISO A4 standard for paper size is a rectangle of 210 x 297 mm
157
CHAPTER 6. THE REFERENCE DOMAIN: DOCUMENTING THE HOSPITALWARD
6.3 Composing the composite artefact
As said at the beginning of this chapter, the main documental artifact used in
healthcare as the composite repository for the information concerning a sin-
gle patient is usually called clinical record. The documents compounding the
clinical record constitute the legal documentation attesting the clinical case as
a whole and this general and patient-oriented scope makes them a correlated
set of scattered artifacts used in support of clinical work (see Fig. 6.3 for a
web-centered vision of this distributed and composite artifact).
As a matter of fact, yet, the clinical record itself can be further decomposed
in two parallel records, two partly disjointed sets of documents: the medicalrecord and the care (or nursing) record. The former record is a collection of
sheets, forms and documents that pertain to the medical dimension of care
and hence mainly to the work of physicians. In that part of the clinical record,
data are mainly managed — i.e., consulted and updated — by physicians,
which can also have exclusive access to some sections of some sheets, like
the sections for pharmacological prescription. The latter record, is a usually
leaner collection of documents that pertain to the caring dimension and the
daily treatment of each inpatient, and hence primarily to the work of nurses.
For the specificity of some of the documents compounding the care record,
nurses are the only practitioners that are supposed to consult and write the
nursing record.
Both the medical and the care record support the unambiguous identifica-
tion of the patient, the treatment planning and the recording of all relevant
events regarding the illness trajectory of a certain patient. Nevertheless these
records also constitute a complementary view on the whole complexity of a
clinical case and are conceived for different purposes and under assumptions
from different conceptual frameworks.
For instance, medical records are organized around the concept of “health
problem”, which physicians are supposed to diagnose and solve by ordering
proper therapeutic interventions; care records are instead organized around
the concept of “patient need”, which nurses are supposed to detect, evaluate
and fulfill.
Besides these conceptual differences, these two records are also physically
separated in that the medical ones are stored in ring binders, each dedicated to
a different patient. Conversely, a single big ring binder holds the care records
of all the ward inpatients and colored pages separate each patient’s record.
158
6.3. COMPOSING THE COMPOSITE ARTEFACT
This fact, which obviously depends on different information retrieval needs,
also reflects a general approach that physicians and nurses have towards their
job: physicians focus each time on a single patient, or better yet, even on
very narrow aspects of the patient status in order to trace back symptoms to
diagnosis. Nurses, instead, consider the work to execute in a ward as a whole,
that is each time declined and modulated in a particular manner depending
on the patient they address.
That said, medical and care records are not intended as watertight com-
partments, at all. Indeed, although what refers specifically the nurses’ duty
is to be found in the care record, nurses update also most of the reports and
sheets compounding the medical record. This can be done under the close and
direct supervision of the physician with whom nurses are taking the morning
round or more autonomously during the rest of the day when they are sup-
posed to update the record with clear and unambiguous indications of activity
progress and completion. During their daily routine work, nurses accumulate
information as regards the overall illness trajectory of the patient and coor-
dinate with physicians in terms of feedback and confirmation of prescribed
activities.
In the following, we provide a brief overview of the most frequently and
important documental artifacts compounding the clinical record. We will de-
scribe each document in terms of the content type they usually store, the roles
that are supposed to fill in and read them, the reason why they are used — i.e.,
their function — and briefly, the representational structure and the practices
of use that depend on such structure. We will not distinguish between the
way documental artifacts are intended to be used and the way their are actu-
ally used. In our studies we obviously got a picture of both: the former could
be drawn from the internal manual that from 2002 is progressively compiled
within the Manzoni Hospital for the proper documentation of clinical work, as
well as from the statements of the practitioners we interviewed. The latter as
it was pretty naively observed during our stays at the hospital with no partic-
ular preconceived ideas about which the right way of documenting ought to
be.
Differences detected between the so called “theory”, imposed “from above”
by the hospital management, and the actual “practice” as it is actually accom-
plished in the field of work were in some rare case significant, but usually
practitioners were well aware of them and justified them as necessary devia-
159
CHAPTER 6. THE REFERENCE DOMAIN: DOCUMENTING THE HOSPITALWARD
tions from indications that were conceived to fit all wards, specialties and situ-
ations and hence had to be adapted in some ways7. For our practical purposes
this distinction blurs into the actual “proper and virtuous” use of artifacts,
which we outline in the following, irrespective of the manifest and desultory
exceptions and mistakes we seldom and occasionally observed.
The reader can refer to Fig. 6.3, where we use the following abbreviations.
6.3.1 Patient Data Sheet
The Patient Data Sheet — PD is the document in which the admitting nurse
records both registry and personal data about the patient. These data refer
both to the stay (e.g., progressive id of patient record, type of hospitalization)
and to the admitted person herself (e.g., her tax number, date of birth, home
address, main phone number). All together these data allow clinicians and
hospital administration to uniquely identify the inpatient. The structure is not
dissimilar from any other registry form used to provide personal data into any
information system.
6.3.2 Admission Reason and Anamnestic Data
The Admission Reason and Anamnestic Data — R&A Sheet is the document
in which the so called “admitting doctor” specifies both the main reason for the
hospitalization in terms of clinical problems and the problem-oriented history
(anamnesis) of the patient at hand. These indications must be able to inform
who consults this document later about the following questions: “Which is
the main reason why the the patient has been hospitalized?” and “To which
extent the current hospitalization problem relates to the previous illnesses and
the history of the patient?”
The admitting physician can detail the admission reason along several di-
mensions, for example in terms of either subjective and objective symptoms:
the former ones are reported and subjectively characterized by the patient her-
self, while the latter ones are detected from a first survey by the doctor accord-
ing to some objective and perceivable signs. All together with the anamnestic
data, the admitting doctor must also report those pieces of information drawn7We recall that the process of design and deployment of the current clinical record has been
negotiated at length between representatives of all the main stakeholders’ categories. As a con-sequence of that, the institutional, “from above” component and the “grounded”, “practitioner-based” component of the clinical record have been already reconciled at some extent approxi-mately one year before our observational study.
160
6.3. COMPOSING THE COMPOSITE ARTEFACT
from the patient’s life and habits that could constitute some risk factors in rela-
tion to the detected health problems (e.g., smoking, known allergies, adverse
drug reactions).
The document provides a set of checkboxes and wider sections with free-
text areas where the admitting physician can jot down the data she collects
by speaking either with the patient or her relatives (or both, whenever possi-
ble). This document well represents the tension between the need for coding
— necessary both to facilitate administrative processing and statistics and to
enable epidemiological and clinical research — and the need for the admitting
physician to use this document to communicate with her colleagues working in
the next shifts as many cues she deems relevant as possible to inform next di-
agnostic and therapeutic decisions. The same consideration holds, even more
notably, for the following document.
6.3.3 Preliminary Objective Examination
The Preliminary Objective Examination — Ex sheet is where the indications
from a first objective examination are reported by the admitting physician.
The objective examination is oriented to the clinical assessment of the current
status of the patient’s systems and apparatus so that sound diagnostic hypoth-
esis can be derived and an effective diagnostic and therapeutic programme
can be formulated. The extremely well consolidated classifications and tax-
onomies regarding human anatomy and physiology lead to a tabular structure
in which each apparatus has its own small free-text area (e.g., skin, heart, tho-
rax, abdomen) and some check-boxes. The physician is supposed to tick the
check-boxes off in order to explicitly indicate whether she actually assessed
the patient from that particular point of view or she has not; and if she has,
to indicate whether the drawn indications are relevant or not; if they are, the
physician is also supposed to describe her findings in the corresponding area.
Also in this case, structured coding and free-text noting coexist. While the for-
mer is intended as a way to provide both the examination with a synthetic
but systematic nature and the physician with a convenient to-do (or better
yet, a aspect-to-consider) list, the latter is the only necessary means for the
examining physician to provide her colleagues with possibly subtle and even
partly contradictory cues that could suggest uncertainty or trouble in tracing
the observed signs back to a merely true-or-false indication.
161
CHAPTER 6. THE REFERENCE DOMAIN: DOCUMENTING THE HOSPITALWARD
6.3.4 Problem List
The Problem List — PL is the artifact where clinicians describe the patient’s
problems, as they manifest themselves upon arrival. The problem list is in-
tended to document all those conditions and events that can be related to
some hypothesis and procedure. The term “problem” is purposely left vague
enough to comprise a number of factors like symptoms, any alterations to vital
signs, any difficulties encountered by the ward staff in their interventions on
the patient and all the concomitant pathologies that could affect the character-
istics or the evolution of either the current hospitalization reason or therapy
plan to comply with. This list is likely to change during the caring course:
physicians update its content with respect to the actual improvements or ag-
gravations exhibited by the patient but also with respect to the extent they
can consolidate some diagnostic hypothesis. We often observed how groups
of entries regarding signs that at admission’s time were quite unrelated or oc-
casional in nature were crossed out and substituted by an entry of diagnosis
comprising all those signs. This artifact plays a central role in the web of arti-
facts documenting the inpatient’ illness trajectory. In fact, it is not intended as
a mere recollection of things clinicians must care about, but rather as a tool
that support them in (a) making care and illness complexity manifest; (b) in
formulating diagnostic hypothesis that would be hard to consider without con-
fronting and matching together arbitrary groups of problems; (c) in adopting
therapeutic approaches that are more adequate to the individuality of each
considered case; (d) in detecting causal connections and association and (e)
in maintaining a watchful awareness about those problems that are solved and
those still persisting. From the structural point of view, the problem list is a
simple four-column table (see Fig. 6.1), where physicians are supposed to fill
in one single problem for each row, assign it a progressive number, append a
date of onset, eventually a close date, and finally to put their signature on the
entry.
6.3.5 Diagnostic Hypotheses and First Care Planning
The Diagnostic Hypotheses and First Care Planning — DTP sheet is where
the admitting physician is supposed to formulate, in order of reliability and
likelihood, at least three diagnostic hypothesis, which are pertinent to the
signs collected in the preliminary objective examination (see box a in Fig. 6.2).
162
6.3. COMPOSING THE COMPOSITE ARTEFACT
Figure 6.1: A snapshot of the problem list sheet from the medical record. From theleft to the right, there are reported an ID field, the description of the problem, dateand signature for the beginning and the cessation of the problem at hand.
The ward convention to indicate anyway at least three hypotheses is aimed at
a threefold objective. On the one hand, such — to some extent — redundant
practice is aimed at limiting the risk of laying out a diagnostic and therapeu-
tic plan that is biased by an initial misunderstanding or misinterpretation of
symptoms. Rare diseases can be only detected if they represent possible —
tough improbable — hypothesis to investigate and eventually reject. On the
other hand, physicians using such artifact “a posteriori” are convinced that an
additional plausible hypothesis is not as much misleading as it can be reveal-
ing of the internal line of reasoning by which the physician formulates the
hypothesis in that particular order.
Diagnostic indications are reported within the same document where also
a first care plan is formulated and this is not chance (see box b and c in
Fig. 6.2). In fact, the first care planning sheet is where the admitting physician
indicates, in order of relevancy, the programme of all the preliminary diagnos-
tic (e.g., tests, exams) and therapeutic (e.g., drug administrations, treatments)
procedures that are deemed necessary and adequate for the patient. Diagnos-
tic hypothesis must be verified and verification can come from a number of ap-
proaches physicians can follow: diagnostic probing through either laboratory
examination or diagnostic imaging (e.g., C.A.T., M.R.I.), the so called “wait-
and-see” approach, or more proactive approaches encompassing preliminary
cautious drug administrations are all ways employed by physicians to progres-
sively exclude or corroborate hypotheses. The most frequent examinations are
displayed by means of checkboxes so that the physician does not have to point
them out in writing on the free-text area above (see box b in Fig. 6.2) In such
artifact, guidelines and clinical pathways reported in the specialist literature
or taken from internal documentation must be explicitly referenced, especially
whenever the plan diverges from those recommendations. Any modification to
the programme is explicitly reported in the Physician’s Notes (see next).
163
CHAPTER 6. THE REFERENCE DOMAIN: DOCUMENTING THE HOSPITALWARD
Figure 6.2: A snapshot of the diagnostic/therapy plan sheet from the medical record.
164
6.3. COMPOSING THE COMPOSITE ARTEFACT
6.3.6 Physicians’ Notes
The Physicians’ Notes — PN is a collection of sheets that is also known by
similar expressions like ‘clinical diary’, ‘doctors notes’ or ‘progress notes’. All
these names suggest that this document is the central repository for any notes
physicians need to write down both to account for any decisions and inter-
ventions occurred so far and to make impressions, opinions, or just lines of
reasoning explicit either for themselves as memorandum or as written mes-
saging to other colleagues. Any sheet can contain a number of entries whose
basic elements are a progressive id, a date of compilation and a free-text box
of description. In this box, on a daily basis, physicians document any single
diagnostic and therapeutic decisions they take during the illness trajectory of
the patient at hand, as well as unexpected or anyway relevant consequences
of those decisions. In their notes, physicians are also supposed to record any
relevant event or condition variation occurred to the patient with respect to
either the preliminary examination (cf. the ‘R&A’ document) or previously doc-
umented portions of the stay, i.e., previous entries within the same document.
Also brief outlines about the significant outcomes of exams and treatment are
therein documented, since the Physicians Notes are intended to include any
piece of information should be known at a given point in the care process to
support next appropriate clinical decisions. Since even “no news” can be “good
news” on the way to recovery, a ward convention prescribes that at least one
entry per day is reported, even if in this note clinicians indicate that “all is
well”.
6.3.7 Single Sheets
The Single Sheets — S*S are a bunch of documents that can have different
names according to which aspect pertaining either to diagnosis or therapy they
cover. They are denoted as “single” (“unici”, in Italian) since they are sheets
conceived to integrate in one single sheet of paper sections that for their func-
tion should be parts of either the physicians’ or the nurses’ documentation.
These sheets are then the only documents within the medical record binder
that encompass specific sections to be compiled by either physicians or nurses
with a rigidly differentiated assignment of concerns and responsibilities. As
a general rule, such single sheets are used by physicians to order drugs, pre-
scribe treatments or referrals and establish particular therapeutic regimens:
165
CHAPTER 6. THE REFERENCE DOMAIN: DOCUMENTING THE HOSPITALWARD
in few words, to instruct nurses on the arc of intervention trajectory that the
on-duty physician deems at that time necessary to be accomplished about a
particular illness trajectory. Accordingly, for each of these task typology, al-
most any ward has a specific single sheet that has been purposely tailored to
fit the ward’s peculiar needs.
By means of these sheets physicians (a) refer patients to some external
facilities for some diagnostic or therapeutic procedure by compiling what is
called Single Diagnostic-Therapeutic Procedures Form (SDTF); (b) order
some laboratory examination on blood samples or biopsies by compiling the
Single Laboratory Examinations Form (SLEF); or (c) order drugs to be ad-
ministered to patients the next administering turn by compiling the Single
Pharmacological Therapy Form (SPTS). From the structural point of view
the above mentioned single sheets are quite similar: tabular sections encom-
passing one or more fields for the description of the order and the scheduled
and expected times for the order.
The Laboratory Examinations Form and the Diagnostic-Therapeutic
Procedures Form are structured check-box grids reporting a list of the most
common laboratory and diagnostic examinations (respectively) and represent-
ing the diagnostic and lab tests prescribed on a weekly basis.
The Pharmacological Therapy Form contains a large grid, divided in two
sections: drug prescriptions and drug administrations (the reader can refer to
Fig. 7.10). In the former physicians are supposed to fill in fields to indicate the
so called five rights of drug ordering: the right drug name (or active principle);
the right route, the right dose, the right time of administration8. In the latter
section, nurses are supposed to check scheduled administration turns and to
sign the corresponding boxes after completion.
Single sheets abound of places, fields and boxes where clinicians have to
affix their signature or initials. In fact, orders are officially issued (and wait-
ing to be executed by some nurse) only after the responsible physician affixes
her signature under the corresponding entry. Only then, these orders can (and
must) be addressed by nurses. They are supposed either to prepare and di-
rectly administer the prescribed drugs, or to take care of preparing the inpa-
tient for the prescribed treatments and examinations. In this latter case, al-
though nurses do not accomplish themselves the ordered treatments or tests,
they are responsible and accountable for such task “locally”, i.e., within the
8The fifth right, the right patient, is implied by the medical record at hand, since any patientis associated to one and only clinical record during all her stay at the hospital.
166
6.3. COMPOSING THE COMPOSITE ARTEFACT
ward, and they are supposed to collect the medical reports coming from the
referred facilities or services. After completion of the task, nurses are supposed
to provide an explicit feedback to physicians (not necessarily the person who
ordered, but her accountable representative in some next work shift) by prop-
erly compiling specific sections of the single sheets.
For their very nature, then, single sheets are those artifacts that have been
institutionally conceived so that physicians can “communicate” in a coordi-
native manner with nurses the orders which the latter ones are supposed to
accomplish. Nurses, in their turn, use the single sheets to give physicians a
feedback for the correct execution of their orders. Single sheets, notwithstand-
ing the differences due to their focus on a particular medical discipline, are all
documents used to mediate formal communication between physicians and
nurses, make them leave a clear-cut trace of this communication and make
coordination and awareness patterns on the progress of the therapy trajectory
explicit and accountable.
6.3.8 The Need Assessment Sheet
The The Need Assessment Sheet or just Need List — NL is for nurses what
the problem list is for physicians. Within the first twenty-four hours of stay, an
on-duty nurse is supposed to collect data about the patient in terms of degree
of autonomy along nine typologies of needs and report them in a so called
“need list at admission” (see box a in Fig. 6.4). The same assessment task
will be accomplished at the end of the care process, as compendium of the
overall conditions the patient exhibits when she is discharged from hospital
(see box b in Fig. 6.4). These typologies can be traced back to several models
of nursing activities classification (cf. [Wesley, 1995]9, which all stress some
particular aspect of caring. The model underpinning the NL artifact considers
nursing interventions along the dimension of all the possible needs that pa-
tients can express, ranging from the critical ones like breathing and feeding,
needs implying high workloads for nurses like those concerning hygiene and
movement, up to those needs that involve lower workloads and pertaining to a
9In the Italian medical and surgical settings, the most used model of nursing is byCantarelli [Cantarelli, 1996], which is centered on the patient’s needs and correlated nursingactivities that are necessary to have them satisfied. In other countries, other models of nursingpractice are adopted, e.g., the Roper model in the United Kingdom [Roper et al., 1980]. Manyof these models (among which those herein mentioned) are loosely based upon the activitiesof daily living (ADLs) model, developed from the work of Virginia Henderson in the sixties.
167
CHAPTER 6. THE REFERENCE DOMAIN: DOCUMENTING THE HOSPITALWARD
Figure 6.3: Routine information flows (thick arrows) and data correlations (dottedand thick arrows) among documents. The main documents of the medical record(above) and nursing record (below) have been encircled by a dotted line.
168
6.3. COMPOSING THE COMPOSITE ARTEFACT
Figure 6.4: A snapshot of the nursing need list.
wider acceptation of well-being, like making patients feeling safe, comfortable
and informed. Leveraging on this agreed and rational classification and on a
much more limited range of possibilities, the need list can be more structured
than the problem list (see Fig. 6.4)
After have collected such data, nurses then detect by assessment those
needs that the patient can satisfy without direct intervention of a nurse; those
needs that the patient is able to satisfy with the help of her family entourage
or other assistants; those needs that require the direct intervention of nurses
to be satisfied by the assisted inpatient. Then, nurses report such indications
on a dedicated section of the need list, where needs are ranked in terms of
these three general categories: autonomous patient (B, in Fig. 6.4); patient
to support (BA, in Fig. 6.4); patient to fully assist (BAI, in Fig. 6.4. The need
list, as the problem list, is not a static snapshot taken at admission time, but
changes accordingly with course of the illness.
6.3.9 Nursing Care Plan
In the Nursing Care Plan — NP, nurses formulate the caring objectives and
describe the outcome they aim at reaching for each caring need they previ-
ously identified and characterized in the NL document in terms of autonomy.
Each entry of plan is a scheduled activity that is explicitly referred to a need
169
CHAPTER 6. THE REFERENCE DOMAIN: DOCUMENTING THE HOSPITALWARD
Figure 6.5: A snapshot of the Activity Plan form for care assistants.
from the need list by means of a unique ID number.
Nurses are supposed to plan also the activities of their assistants. The Activ-
ity Plan sheet nurses compile for the daily job of assistants can be considered
part of the nursing care plan but its structure suggests us a marginal remark
(see Fig. 6.5). In such planning sheet, the free text areas are reduced to the
minimum and there is a number of check-boxes that assistants are supposed
to mark at task completion. This exemplifies as the extent information is struc-tured within the clinical record depends on the extent the phenomenon that
therein is described can vary or present margin of either decisional or interpre-
tational discretion. Assistants are supposed to accomplish a limited and quite
rigid number of activities, as a consequence of the limited responsibility they
can take upon themselves for legal reason. Accordingly, the corresponding
artifact can be more structured and reflect the coordinative and prescriptive
nature of communication between nurses and assistants.
As said before, also other artifacts than those stored within the clinical
record are used in the ward. Their main function is that of partial view that
join data represented elsewhere within the clinical record. One of these ar-
tifacts is the daily fasting list (see Section 7.2.5) that sometimes is added by
nurses to their official nursing documentation, according to the typology of
patient they attended.
6.3.10 Nursing Notes
The Nursing Notes — NN correspond to the Physicians’ Notes for the nursing
side of hospitalization. In fact, into these notes nurses record any observa-
tion regarding changes occurred in the patient’s state of health and any varia-
tions about the caring interventions planned within the NP artifact. Notes are
recorded in chronological order and each note is referred to a specific need as
it is expressed in the NL artifact. In each note entry nurses report an assess-
ment about the level of satisfaction of the nursing need and a comprehensive
170
6.4. THE OVERALL PICTURE OF THE WEB OF DOCUMENTS
description of those factors that eventually determine the necessity to refor-
mulate the nursing interventions.
6.4 The overall picture of the web of documents
In Fig. 6.3 the medical and nursing documents (smaller portions of the overall
web of documents at hand) have been distinguished by means of two dot-
ted ellipses. After have considered the documents compounding the clinical
record in terms of data contained, roles involved, functions, structure and cor-
related practices, we are interested in detecting and sketching the main flows
of information among the nodes of this web. In Fig. 6.3, the reader can detect
two main flows of information running in parallel, by following the counting
numbers on top of each arc. As a matter of fact, instead of flows, we should
rather speak of correlations, since we are not strictly interested in the “flow-
ing”, i.e., the physical moving and transmission of data between documents in
the IT-oriented common sense; we rather focus on the relationships between
data pertaining to similar or correlated pieces of information that belong to
different documents and thus contribute to the “holistic”, systemic nature of
the textual context (cf. Section 3.2 and 6.1.2 ).
Although it is possible to distinguish among several categories of mutual
relationships between data fields and data values, the actual existence of cor-
relations is not given a-priori, but they are rather dynamically established and
modified along with the content of documents within the web. Within this
web, data recording either follows or precedes tasks during the scheduled
routine of ward work. Although data can only follows unexpected events oc-
curred within the illness trajectories of inpatients, that notwithstanding they
do not usually appear in a totally arbitrary order. Data rather appear (i.e.,
are written) on documents according to some patterns that are influenced by
the care work models we mentioned above (see Sections 6.1.2 and 6.3.8 for
the medical and nursing practice respectively). It can be useful to represent
these chronological (although not necessarily sequential) patterns in order to
leverage on the tight relationship between data and correlated activities. This
temporal order heavily depends on the routine nature of events during the
admission and daily care of inpatients and is represented in Fig. 6.3 just as an
indication of sequentiality with cardinal numbers from zero on, as labels of
the flow arcs.
171
CHAPTER 6. THE REFERENCE DOMAIN: DOCUMENTING THE HOSPITALWARD
Drawing on evidences from our observational studies, we also make a
point that detecting, for designers, and being aware of, for practitioners, these
correlations and flows is of paramount importance within all the recovery tra-
jectory of each patient, since it is by making explicit these relationships be-
tween documents and their contents that users of a documental system can
really make sense of the latter and inform their actions accordingly.
6.5 Communication Patterns and Artifact Use
Once we got a general picture of the information flows and main cross-
references within the web of documents of the clinical record, our next aim
has been to understand what sources of patient information within that web
clinicians utilize in a typical ward of the Manzoni Hospital and which of these
sources they consider most reliable and supportive of their activities. To this
aim, we conducted a nonparticipatory and qualitative survey [Fitzpatrick and
Boulton, 1994,Mays and Pope, 1996] of clinicians’ self-report of their informa-
tion seeking behaviors in both the wards we studied at the Manzoni Hospital.
Our point was that by, even subjectively, assessing information-seeking be-
haviors, we could draw a picture of the typical communication patterns and
artifact use. We then designed a survey to assess the practitioners’ perception
of their utilization of written and verbal sources of patient information. In Au-
gust 2006, we administered to 56 clinicians from both the IM and NICU ward
a questionnaire of 41 questions (items). Respondents were asked to answer
each item of the questionnaire by using a five-point Likert scale, to rate both
frequency and dependability of the clinical record use within their ward, rang-
ing from ‘never’ to ‘always’ and ‘very low’ and ‘necessary’, respectively (see
Fig. 6.6).
This questionnaire (whose questions are reported in Appendix A) con-
tained five subscales: two subscales addressed the assessment of both the fre-
quency and relevancy of face-to-face, verbal communications (questions 1-
8); other two were conceived to assess frequency and relevancy of document-
mediated communication (questions 9-16); and a fifth one to assess how
frequently documents are actually compiled during care activities (in-care
compilation). This latter section of the questionnaire was also intended to
assess the extent clinicians indulge in the practice of updating and filling in
the legal documentation at once only at the end of the shift, rather than during
172
6.5. COMMUNICATION PATTERNS AND ARTIFACT USE
the actual caring activities (as they are supposed to). Indirectly, this was also
a way to assess how the coordinative role of documents could be jeopardized
by cumbersome or redundant documental practices.
The subscales addressing artifact-mediated communication were intended
to assess both the frequency and the extent clinicians rely on the consultation
of artifacts to retrieve the information they need on the go. The first two sub-
scales (questions 1-8) were conceived with the aim to assess how often and to
which extent clinicians think or — are aware of — to rely on communications
that, for either their very nature or some ward convention, are not mediated
by documents, and cannot either. In that, our research is not aimed at verifying
or confirming other previous studies that identify patterns of communication
behaviors in secondary healthcare [Coiera and Tombs, 1998], nor at measur-
ing communication loads on clinical staff [Coiera, 2002]. It also differ from
other studies proposed either to highlight how clinicians seem to prefer to
use verbal communication rather than documents [Alberdi et al., 2001,Brown
et al., 2004], or to collect evidences on the dynamics of communication be-
tween clinicians to improve the way information systems within health care
can be designed [Coiera, 2000]. But those works were taken as reference in
order to obtain results that could inform our following design activity (see
next Chapter).
The internal consistency and hence dependability of the survey was good,
since the alpha coefficient for the administration was 0.73 [Gliem and Gliem,
2003]. As regards artifact use and artifact usefulness, we outline the results
in Fig. 6.6: in that figure, the arrows pointing artifacts indicate compiling
(i.e., writing) practices and the arrows pointing the actors, i.e., physicians
and nurses respectively, indicate consultation (i.e., reading) practices. Median
values give a coarse and approximate indication of frequency and judgement
of use, while means (not to take too literally for the small number of respon-
dents, the 89% of administered questionnaires) give an idea of the opinion
tendencies among the surveyed clinicians. No significant difference were ob-
tained confronting peer roles and professional figures between the two wards.
Some differences were surveyed when confronting the nurses’ and physicians’
groups on some key questions, like those pertaining internal documents of the
medical and care records (P 0 0.05 using a Two-Sample Assuming Unequal
Variances t-Test).
The survey has helped us in identifying that single sheets and daily notes
173
CHAPTER 6. THE REFERENCE DOMAIN: DOCUMENTING THE HOSPITALWARD
Figure 6.6: The “use” and “usefulness” of documental artifacts in support of hospitalcare. In slanted figures: frequency of use, on a 5 values, symmetric Likert-scale. Inbold figures: effectiveness of use, on a 5 values, symmetric Likert-scale. Median valuesfirst, mean values between brackets.
174
6.5. COMMUNICATION PATTERNS AND ARTIFACT USE
are the main sources of information. An interesting finding regards the need
for clinicians (both physicians and nurses) to look information up in corre-
lated documents. The most evident example regards the nurses’ physicians’
notes: although these documents are concerned with the very same events and
conditions about the patient with the only difference they are recorded from
the nurses’ and physicians’ perspective, respectively10, usefulness for cross-
consultation is deemed useful both for nurses to consult the physician notes
(median 1, mean 0.8) and for physicians to consult the nursing notes (median
1, mean 0.9).
10In fact cross-compiling frequency scores the lowest values.
175
Chapter 7
Application of WOAD to thehospital domain
In this chapter, we will illustrate how to apply the WOAD model and language
to a real cooperative arrangement, basing on the experience we did within
two hospital ward settings that we reported in Chapter 6. We will treat the
topic from the perspective of the designer of a document-based cooperative
application layer (see Section 3.5) who needs to construct some mechanisms
by which to convey awareness information through a preexisting documental
application, in order to make it more supportive of document sense making,
task alignment, and clinical order committing. With reference to the three lev-
els mentioned in Section 3.3, in the next sections, we will decline the WOAD
framework both at domain level and at application level. First (in Section 7.1),
we will see how the WOAD model of document-based cooperative work can
be declined in a specific yet wide domain as the clinical one (see Section 7.1).
Then (in Section 7.2), we will see how the problems and informational re-
quirements raised by clinicians could be addressed at design and run-time by
means of a WOAD-compliant platform and a set of application-specific mech-
anisms conceived our observational studies (see Section 7.2).
7.1 Application of WOAD to the clinical domain
In order to evaluate the expressive power of the WOAD language and its abil-
ity to express relevant concepts and useful conventions in our reference do-
main, we first decided to refer it to existing and widespread standards used
177
CHAPTER 7. APPLICATION OF WOAD TO THE HOSPITAL DOMAIN
in the health care information management. In so doing, we could evaluate
the capability of the framework to facilitate the design and deployment of an
awareness-based application layer on top of some preexisting electronic docu-
ment management system in the architectural schema outlined in Section 3.5
so as to add to such third-party applications the capability to become more
context-aware and more supportive of the articulation dimension of coopera-
tive work.
The main models we have considered for the clinical domain are the so
called Reference Information Model (RIM) and the Clinical Document Archi-tecture (CDA) specification. Both models have been developed by the Health
Level Seven Inc. (HL7), a no-profit volunteer organization founded in 1987 to
develop feasible standards for the management and exchange of medical data
to support the delivery and evaluation of healthcare services. Since such or-
ganization includes international affiliates from several of the most populated
and industrialized countries1, HL7 is generally deemed as one of the most
authoritative institution for the development of healthcare standards aimed
at reaching both functional and semantic interoperability2 between different
facilities and organizations.
7.1.1 The clinical information reference model
The HL7 RIM is a consensus-based standard model by which to describe
and formalize the main concepts involved in health care, such as organiza-
tions, individuals, devices, places, but also documents, acts, their result and
their context. The underlying structure of the RIM (see Fig. 7.1) is based
on six “backbone” classes: Act, Participation, Entity, Role, ActRelationship, and
RoleLink [Dolin et al., 2006].
Act represents any intentional action that occurs — and is documented —
throughout the process of managing and providing health care services
(e.g., the patient encounter, an examination).
1The active affiliates include, among others, United States, Canada, Australia, Germany,United Kingdom, The Netherlands, India, China, Japan.
2Functional interoperability is the ability to exchange information, while semantic interop-erability regards the ability to use the exchanged information. Even assuming these prettystraightforward acceptations, it goes without saying that achieving interoperability betweenmachines is a completely different task than achieving it between their human users (cf.e.g. [Mark et al., 2002b]). But the former interoperability can be considered sort of a nec-essary condition for the latter or, at least, for the deployment of cooperative applications indistributed domains.
178
7.1. APPLICATION OF WOAD TO THE CLINICAL DOMAIN
Entity represents any physical thing or actor that can take part in or be con-
cerned with health care provision (e.g., a human actor, an organization,
an artifact).
Role expresses both the role that each entity can play as she participates in
health care acts and the competency of that entity irrespective of the act
in which she is involved (e.g., a patient, the physician, the nurse).
Participation defines how an entity, in a particular role, is involved in a par-
ticular act. It also expresses the context for an act such as who performed
it, for whom it was done, where it was done and the like.
Act Relationship represents a relationship between two Acts (e.g., causality,
indication).
Role Link represents a dependency between two Roles (e.g., one role has au-
thority over another role).
The RIM concepts can be easily mapped into corresponding concepts of
the WOAD model in virtue of the latter’s modularity and extensibility. RIM
entities and roles are equivalent to WOAD resources that are mapped into ex-
tensions of the corresponding entity-fact construct. The same holds for RIM
acts, that can be related to the WOAD construct of the work activity. For in-
stance, RIM Acts can exist in different ‘moods’, each. Moods can tell whether
the act refers to either a factual statement, a command, a possibility, or a goal,
i.e., whether the action actually occurred, was ordered or just serves as a crite-
rion for further acts, respectively. As regards the compatibility with the WOAD
constructs, the RIM moods can be either referred to a particular internal state
of a w-activity-fact (e.g., an ordered act corresponds to an enabled activity-
fact), they can be expressed in terms of relationships between entity-facts or,
as trivial but effective solution, they can be rendered as additional properties
of a corresponding RIM-compliant w-activity-fact.
7.1.2 The clinical record model
Based on the RIM, the CDA document markup standard defines how electronic
health care information can be consistently represented in structured docu-
ments for the purpose of exchanging information, both from the structural
and semantics point of view. CDA documents can consist of several sections,
which themselves consist of several information entries.
179
CHAPTER 7. APPLICATION OF WOAD TO THE HOSPITAL DOMAIN
Figure 7.1: The reference information model (RIM) as the core piece of HL7 mod-elling.
The driving force behind the development of the CDA specification has
been the need to standardize the narrative flow of clinical statements that are
recorded within almost any clinical report. This would allegedly enable com-
parison of content from different documents created on information systems
of widely varying characteristics and hence foster medical and epidemiological
research as well as a more efficient hospital management and quality control.
Our aim has been that of taking this specification, which has been man-
ifestly devised for other purposes than the direct management of illness tra-
jectories3, and see whether such a model could harmonize with a framework
which has been conversely devised to make the coordinative nature of records
explicit and to support it by means of the very same documental artifacts.
The case of the CDA has provided us with an interesting example of how a
domain-dependent model can enrich4 the WOAD model by providing a set of
concepts and attributes that specify some specific aspect of the setting at hand.
To give a highly significant example, the CDA specification permits any act
reported in a compliant document to be related to any other act by using any
of the enumerated relationship types. In this way, clinical record entries can
be cross-referenced by their compiler so that data can act either as descriptiveor perspective information, i.e., to inform readers about both the causes for the
execution of some task and the intentions expressed by the record compiler.
Figure 7.2 shows a subset of the allowed relationship types, along with source
and target acts that might be reasonably put in relationship through them.
The way domain-specific relationships are mapped into WOAD relation-
facts is often a mere matter of taste, but some application-centered choices can
3In the literature such other purposes of the clinical record are also called ‘secondary’ [Mannand Williams, 2003]. The primary purpose is to support direct patient care both by aidingmedical decision-making and by “ensuring continuity of care by all providers” (cf. the JCAHOdefinitions at http://www.jointcommission.org). Secondary purposes pertain to the sphere ofthe archival functions of records.
4In the sense of specializing.
180
7.1. APPLICATION OF WOAD TO THE CLINICAL DOMAIN
Figure 7.2: Some CDA relationships between act-related entries. From [Dolin et al.,2006].
also be affected by the description granularity and, above all, by the require-
ments that have been collected from the observational studies. In our case, for
instance, while some ActRelationship has been considered as WOAD relation-
ship between w-activity-facts (such as the SAS – starts after start, and
COMP – has component ones5), we preferred to represent some other CDA
relationships in terms of relation-facts between documental entries, i.e., be-
tween document-facts: namely, the CAUS – is etiology for, the MFST – is
manifestation of, the RSON – has reason) and the SPRT – has support
ones.
We have in fact questioned ward practitioners on the crucial point of data
correlations (see Section 3.3.3): we have asked them which kinds of relation-
ship they would more naturally employ to join two or more data that are not
explicitly correlated by the clinical record structure (or even implicitly, by dis-
playing them on the very same sheet). Then, we tried to understand which
CDA relationships semantics was more “easily” grasped by the average ward
practitioners, i.e., irrespectively of either their experience, profession or role.
The result was that practitioners found more natural to consider relationships
as occurring between data entries, either already recorded or still to record on
5Specifically the COMP relationship is natively supported by the belongs-to WOAD rela-tionship.
181
CHAPTER 7. APPLICATION OF WOAD TO THE HOSPITAL DOMAIN
the clinical record. In the former case, they pointed out the usefulness to re-
late data over distributed and different artifacts; while in the latter case, they
referred to the capability to draw relationships between data values (and the
corresponding documental and work activities) and fields yet to fill in, hencewith the corresponding work activities still to carry out.
In other words, clinicians seemed to understand and accept the general
tenets behind the CDA relationships, but seemed more prone to consider
them applicable to outputs of acts (still data), rather than thinking in a
strictly process-oriented manner. For instance, an examination can certainly
give sound motivation for a drug administration but yet — by a pretty obvious
metonymy — physicians preferred relating the very result of the examination
as it was reported in the referral sheet with the very sign that on the Single
Pharmacological Therapy Form (see Section 6.3.7) denoted the prescription
order.
In all these cases the WOAD language exhibits the important characteris-
tic to be “neutral” with respect to the semantics of other models that extend
(i.e., employ) its formal constructs. In fact, the source and target attributes of
WOAD relation-facts have been purposely conceived as not typed, in the sense
that their value domain and abstract type are not formally explicit. This means
that once the designer has defined domain-specific relationships as extensions
of the WOAD relation-fact, it depends on the mechanisms definition whether
a relationship applies only to a class type or not. Neutrality is an important
requirement to claim the portability of our framework also into other docu-
mental domains than the clinical one, that is leveraged by the malleability of
WOAD mechanisms. This property has allowed us to tune some awareness
providing mechanisms depending on the use we observed on the choice of the
most appropriate CDA relationship.
7.1.3 Downscaling the CDA model
At the end of some working shifts, immediately after the handing-over confer-
ence, we asked different practitioners to try to relate the most relevant notes
and entries they recorded during their work with other entries pertaining to
other sections of the same clinical record, both past and expected entries. This
task was proposed to actors that for their formal duties were already supposed
to be prepared for reporting any relevant data on current inpatients. We ob-
served that subtle yet important differences between CDA relationships tended
182
7.1. APPLICATION OF WOAD TO THE CLINICAL DOMAIN
to blur when they were applied into three main categories: causal, temporaland intentional correlations.
The generic semantics pertaining to the nature of relationship between
a source and a target information can be respectively rendered as (a) “the
source because of the target”, in the sense of strict causal relationship; (b) “the
source after the target”, not only in strict temporal sense, but also to hint a
very weak or just supposed causal relationship; (c) “the source for the target”,
in the sense of supporting evidence for a decision or making explicit an inten-
tion. We see those correlations as specifications (or, better yet, as extensions in
the sense so far considered) of what in Section 3.3.3 we called “correlations
between supplementary data”. In fact, each source and target information can
be seen as supplementing the other, i.e., as adding a semantic nuance that, in a
particular context, mutually completes or reinforces the meanings of the cor-
related data (cf. the concept of positive redundancy mentioned in Section 3.3.3
and in [Cabitza et al., 2005b]).
We collected several evidences that the intended use by doctors of such in-
dications on those supplementing correlations was to provide their colleagues
with accounts of occurred events as well to give them motivational and in-
tentional information, rather than strictly coordinative orders. The latter were
rather embedded in the rigid structure of forms and the prescriptive nature
of the conventions pertaining to their compilation. On the other hand, inten-
tional and motivational correlations regarded more descriptive conventions
by which clinicians used to commit colleagues on due next activities, and give
them rationales to adhere convinced to some clinical line of actions.
In that perspective, we provided the setting’s doctors with the domain-
specific relationships of the CDA specification as a “standard tool” that could
be used to make self-evident the interconnected nature of all clinical events
from the raw and isolated entries of the whole bunch of sheets pertaining to
the same inpatient’s stay. Since the CDA does not give a precise semantics of
their constructs and we could not rely on a formal reconciliation between the
ward jargon and the CDA lexicon, we often saw doctors to idiosyncratically as-
sign relationships a meaning according to the content which they applied the
relationships to. This situated practice could seriously hinder any application
that operationalizes relationship types according to their formal specification,
but yet, it is particularly well fit by the generality and parametric nature of
WOAD mechanisms. In fact, WOAD conventions — and their operationalized
183
CHAPTER 7. APPLICATION OF WOAD TO THE HOSPITAL DOMAIN
mechanisms — are content-driven, both as regards the time of occurrence
(i.e., when they have to be executed) and their effects (i.e., relating to what
they have to produce). For instance, let us consider the case of the SPRT re-
lationship, “it has support”. The CDA specifies that such relationship should
be used to show that the target entity provides “supporting evidence” of the
source entity. Yet, for either a poor translation or little knowledge of think-
ing in terms of support, doctors indistinctly used it to indicate a correlation
between diagnostic hypothesis (when they did it right) as well as between
acts (in the acceptation of “serving”, “being of use”). A mechanism of inter-
action that would rely just on the “label” SPRT would probably fail to convey
the right awareness information, while mechanisms that are sensitive to even
generic relationships between, e.g., the documental entries regarding “patient
sedation” and “biopsy performance” would be less sensitive to linking errors
or misunderstandings.
7.2 Application of WOAD to the case study
As said in Section 6.1.2, what is written on a document of the clinical record
does not inform just by itself, but in virtue both of the local rigidity of the
document, and of the document’s property to cross-refer readers from one of
its parts or sections to other documents and their parts. We also said that
this cross-referencing capability is fluid, to refer both to the Levy’s contribu-
tion mentioned in Section 2.3 and to its capability (and requirement) to have
cross-references reconfigured according to the informational needs of the con-
tingent situation. Here, we also make a point about the fact that such cross-
references can be either implicit or explicit, they are not fixed in any ad-hoc
structure and are only drawn if ever and whenever needed.
In the case such correlations are implicit, practitioners give them for
granted as conventionally acting between fields, sections or even modules of
different documents compounding the same clinical record, irrespective of the
inscriptions that those documental portions can host in practice. Conversely,
we speak of explicit correlations whenever practitioners someway drew and
made explicit them, to relate either fields across different documents or actual
values, depending on situated needs and clinical contingencies. We purposely
used the vague adverb ‘someway’ since, for the illustrative purpose of showing
the potentiality of the WOAD notation, it does not really matter how these cor-
184
7.2. APPLICATION OF WOAD TO THE CASE STUDY
relations among clinical data are made explicit but that they are represented
in some symbolic structure.
7.2.1 From practices to language constructs
In our observation of the ward paper-based practices, we have seen clinicians
making correlations across documents explicit in a number of ways, depending
on either personal idiosyncrasies or incidental conveniences. Some clinicians
used to jot down brief annotations, beside the fields or inscriptions to cross-
refer, mentioning what to refer to and where it was. Others used to either draw
a line, an arrow, connecting the related pieces of information, especially when
they were on the same sheet. Or to mark a couple of asterisks on the fields or
inscriptions to relate. In many cases, also, nurses and physicians explicitly put
data in some relationship by writing dedicated entries on their daily notes.
Flanking a documental prototype
These observations as well as the related comments we collected during the
scheduled interviews were very useful in shaping the prototypal mechanisms
by which to illustrate the WOAD-based support within a real technological
domain. For our “experimental” sessions with some key actors of the ward
personnel6, the Neonatology ward management put at our disposal a web-
based electronic patient record that the head physician commissioned approx-
imately one year earlier to a small local IT firm that had been providing the
ward with a number of smaller and task-specific applications during the last
ten years. By leveraging on the long-time acquaintance and acquired familiar-
ity between the designers of the small firm and some of the physicians work-
ing at the ward, a full-fledged prototype of clinical record was built to allow
for incremental improvements and further validation by the hospital manage-
ment. For interoperability issues and other red-tape hindrances at the whole
hospital level, such prototype was never amended and failed to be fully de-
ployed at the ward but nevertheless it constituted an ideal platform on top of
which we could conceive and illustrate the awareness-providing mechanisms
6Actually those meetings with some selected members of the ward staff were more an oc-casion to exchange comments, criticisms and proposals while tweaking with a provisional andyet-to-deploy computer-based documental platform (see next). They were neither experimentsin the strict sense of the word nor validations of WOAD implemented features, but rather justoccasions to exchange opinions with the pretext of having some computer-based application totrifle with.
185
CHAPTER 7. APPLICATION OF WOAD TO THE HOSPITAL DOMAIN
Figure 7.3: A screenshot of the prototypical Neonatology Electronic Patient Record
and data-structures to their intended beneficiaries in terms of “mocking up”
sessions.
In such computer-based practice sessions, we tried to evaluate how prop-
erly the conventions we observed in our field studies were rendered into
WOAD mechanisms that were calibrated on the prototype’s structured pages
and on the model of ward activities expressed in terms of L*WOAD constructs.
An interesting fact we observed during such sessions was exhibited by users
when they showed a clear interest in the capability of selecting fields and
inscriptions in any “screen” of the current patient record (see Fig. 7.3) and
of associating them with either some WOAD-predefined relationship or user-
defined ones. This informal and functional requirement led us in formalizing
the general and conceptual requirement of fluid cross-referencing mentioned
in Section 6.1.2 for the intended WOAD prototype.
When we enabled such functionality, actors found convenient to select the
most suitable predefined supplementary correlations from a cascading menu
(see Section 7.1.2 and 3.3.3). When they did not find any correlation precise
enough to denote the intended relationship that they wanted to draw between
record entries, they appreciated to be able to select a user-defined relationship,
that they were asked to characterize by filling a free text description field.
186
7.2. APPLICATION OF WOAD TO THE CASE STUDY
These observations led us to collect a number of interactional require-
ments that the full-fledged electronic documental platform should satisfy both
to make secretarial work by clinicians smoother (see Section 3.3.3), but also
and above all with respect to the WOAD requirements, to make the construc-
tion of conventional mechanisms on the clinicians’ cooperative needs easier
and more effective. These requirements are not to be intended as valid just
for the clinical application at hand or for the clinical ward we studied, but
they can also be made more general by correlating them to the main dimen-
sions of functionalities exerted by documents: archival and articulation (see
Section 2.3) and to the main WOAD awareness typologies that we have briefly
outlined in Section 5.2.
Such requirements can be summarized in the following enumeration:
• Function of alerting actors about data previously inserted by other ac-
tors, regarding either inconsitencies/errors or suggestions for their cor-
rection. This functionality can be harked back to the requirements per-
taining to the archival dimension of the record at hand (see Section 2.3)
and to the provision of either alerting, inconsistency or amending aware-
ness.
• Function of highlighting7 data values that could be useful for the users
to consider, so as to provide them with awareness information about
linkages with other data and well characterized relationships between
what they write (or are about to write) and other data written in the
past or by other people. This functionality pertains to the articulation
dimension of the record at hand. In fact, it is aimed at supporting the
task of making sense of what is recorded and is correlated by means
of the provision of explanatory, inquiring and provisionality awareness
information.
• Function of highlighting data fields that users must fill in during a given
documental activity (e.g. error-free form compilation); and the corre-
lated function of providing users with information about the reason and
way the form completion must be done. This functionality pertains both
to the archival and articulation dimension of the record: the former ben-
efits from a higher data quality (i.e., more complete records, more accu-7Highlighting seems an important requirement even in paper-based domains. As also Luff
et al. [Luff et al., 1992] report, doctors have been often observed underlining or marking textwith color pens in records to alert colleagues to irregularities in treatments.
187
fede
Note
forse anziché provisionality è "browsing"
CHAPTER 7. APPLICATION OF WOAD TO THE HOSPITAL DOMAIN
rate data), while the latter benefits of a support to documental activities
that have some priority over others. This functionality also regards the
inconsistency and amending awareness types, as well as the, explanatory,
browsing and inquiring awareness ones.
• Function of highlighting data fields so that the activities associated with
those fields are suggested as possible choices; in addition, in the case
none of the suggested activities is selected by actors, then occasion for
justification would be prompted to them. This functionality clearly re-
gards articulation of tasks: in fact, by the proper highlighting of fields a
corresponding flow of work is suggested to actors — even within a de-
scriptive rather than prescriptive dimension. Moreover, even when the
“flow suggestion” is disregarded by actors, a justification is requested in
order both to increase the accountability of the accomplished deeds and
to provide colleagues with the rationale of the deviation from conven-
tional or purely routinary work trajectories. This functionality regards
the enabling and inhibition awareness.
In the following, we will leverage on these interactional requirements as
regards the outputs of the cooperative layer of the documental application
we take as reference, as well as on the capability to define and characterize
correlations among data at run-time and on-the-fly, as an additional input
capability of actors within the field of work besides the obvious capability of
writing data on the forms compounding the clinical record.
Once the front-end has been realized as capable of fulfilling these minimal
requirements, we can revert to the back-end side of the cooperative applica-
tion enabling the above mentioned documental application with awareness-
provision and task-alignment capabilities.
The task of the designer at definition time is then that of conceiving and
composing conditional context and data-driven mechanisms by which to ren-
der in computational manner some of the conventions applying in the coop-
erative arrangement within and about documental activities, so as to provide
actors with relevant information while they gain access to and write docu-
ments in their daily tasks.
Such mechanisms apply to data as these are recorded into the documen-
tal system through pattern matching. Designers can conceive them to support
actors in both properly compiling the forms and in becoming aware of partic-
ular conditions and contextual correlations that their colleagues have tried to
188
7.2. APPLICATION OF WOAD TO THE CASE STUDY
“package” all together with the data written. This relates hence to the premises
that such mechanisms are sensitive to, i.e., to their antecedent side. In the an-
tecedent side, patterns are matched with the current content and state of the
fact space. On the other hand, awareness provision capabilities, as well as the
capabilities dedicated to update the documental content and the work context
are managed in the consequent side of such mechanisms.
7.2.2 Supporting clinical coordination
In this section and the following ones, we will see how designers of the co-
operative layer depicted in Fig.3.9 can properly (1) model a document-based
work arrangement by means of the WOAD model and language and then (2)
build mechanisms that express awareness-related conventions.
Such awareness-related conventions will regard, in order of exposition:
• The locally rigid structure of documents, i.e., their structural relation-
ships and their data schema8). In the following we call them structure-
related conventions (and corresponding mechanisms).
• The documental content those documents can refer to. We call them
content-related mechanisms.
• The relationships that users either implicitly or explicitly consider be-
tween different documents’ sections and their data. We call them mech-
anisms on web-spanning correlations.
Each of these three cases, even the structured-related and the content-
related ones, concern the whole representation of the context2 rendered
within the fact space, and hence also the contextual information regarding
the work setting at hand. Indeed, the antecedent part of any mechanism can
be seen as a way to make explicit a tie between any otherwise uncorrelated
contextual element, and hence as a way to relate textual context and work
context (the reader can still refer to Fig. 3.2).
8With ‘schema’ we naively refer to what in the Data Base literature (e.g., [Batini et al.,1992]) is usually associated with such term: properties that regard attributes of entities (in ourcase, documents and their fields), the data types such attributes can contain and the formalconstraints on those data types, without any reference to the semantics of data therein repre-sented. In other words, we refer to conventions regarding both how data are organized withindocuments (structure) and which instances of the defined structure are allowed (syntactic in-tegrity).
189
CHAPTER 7. APPLICATION OF WOAD TO THE HOSPITAL DOMAIN
For each of these cases, we will take our observations and field require-
ments as starting points for presenting the illustrative case in which a generic
designer has to apply the WOAD framework to a cooperative arrangement in
the light of the requirements she has previously collected from the intended
users of the documental application.
In order to illustrate how a generic designer could set up the process of im-
plementing a WOAD-compliant application, let us consider an aspect of clini-
cal work that both our observations and the spontaneous accounts we heard
from the interviewees have pointed out as the crucial aspect of document-
mediated ward coordination9: the so called “Physician Order Entry” (POE).
Order assignment and commitment
The POE denotes the general process in which doctors give orders about the
main interventions that a patient must undertake to recover and have her
health problems solved10. In the specialistic literature, many contributions are
investigating whether the introduction of Information Technology in the POE
brings more benefits than drawbacks, once that all stakeholders at hand have
been considered (e.g., [Ash et al., 2004,Aarts and Berg, 2004]). At the present
time, there is no general consensus on the best approaches to many of the
challenges that changing the traditional, paper-based order entry presents (cf.
e.g. [Kuperman and Gibson, 2003, Koppel et al., 2005, Beuscart-Zephir et al.,
2005]). Basically, computer-based POE (also acronymized to CPOE [Group,
2000]) supports physicians in preventing adverse drug events in hospitalized
patients by reducing errors related to handwriting or transcription and by au-
tomatically checking entries for duplicate, incorrect doses and incompatible
ways of administration. This picture can be even more complicated by verifi-
cation tools that match prescriptions with either clinical guidelines and proto-
cols or with the particular case that is represented within the rest of the clin-
ical record (e.g., by taking into account the current patient’s idiosyncrasies,
allergies and temporary impossibilities).
Generally, orders can be given about two main classes of interventions on
9The other main coordinative moment within ward work is represented by the handing-over conferences between shifts. As we have reported in [Cabitza et al., 2005b], clinicians thatare going off-duty do use the documentation to recollect relevant events and data to refer totheir colleagues going on duty but this task is not properly mediated by documents, since suchconferences are always vis-a-vis, co-located meetings where clinicians mainly rely on directconversation.
10Cf. the problem-oriented approach to clinical documentation mentioned in 6.1.2
190
7.2. APPLICATION OF WOAD TO THE CASE STUDY
patients: interventions directed either to (a) accomplishing diagnostic assess-
ments or (b) to steering therapeutic regimens (i.e., drug administration). For
the former class of interventions, orders usually regard a composite process in
which nurses or other clinicians have (1) to coordinate with an external ser-
vice (e.g., another hospital department or facility, the referred specialist) (2)
to prepare the patient both physiologically and psychologically (e.g., by having
her fast before the examination or by thoroughly informing her, respectively);
(3) to manage the return of the patient and the requested medical reports
so that the collected evidences can trigger further diagnostic and therapeutic
interventions.
For the class of therapeutic interventions the schema is pretty similar, com-
prising (a) the preparation of the drug and possibly of the patient (e.g., by giv-
ing her a gastroprotector) (b) the drug administration (c) the continuous mon-
itoring and management of any reaction to the administered therapy. From the
point of view of the supporting documents, ordering diagnostic interventions
is mediated by two specific sheets of the clinical record: the Single Laboratory
Examinations Form (SLEF) and the Single Diagnostic-Therapeutic Procedure
Form (SDTF); for the drug prescription, clinicians refer to the Single Pharma-
cological Therapy Form (SPTF) (see Section 6.3.7).
The POE, hence, encompasses two different “moments” within the official
interaction occurring between the two main roles acting in the ward, doc-
tors and nurses: namely a coordinative and an awareness time (cf. [Simone
and Bandini, 2002]). In the coordinative time, doctors commit and delegate
nurses to accomplish an intervention on the patient and nurses make them-
selves responsible for that intervention be executed as doctors expect to; in the
awareness time, nurses give doctors feedback on the completion of the related
task, thus enabling those activities that were waiting for the order execution.
In the following, we will outline how a designer could conceive proper
mechanisms to support both the above mentioned moments with the provi-
sion of context-driven awareness provision, basing our illustration on the con-
ventions we collected about the use of the single sheets, the problem list and
the physicians’ notes from the analyzed clinical record (see Section 6.3 for a
description of such artifacts).
191
CHAPTER 7. APPLICATION OF WOAD TO THE HOSPITAL DOMAIN
7.2.3 A small step methodology
The preliminary step for the definition of all kinds of WOAD mechanisms re-
ferring to the clinical record is to define a data structure for each document
compounding the clinical record at hand and then to likewise characterize the
main resources that have to do with those documents and the activities in
which they do.
To do so, the designer calls the define primitive on the data structures
that specify how the single sheets are rendered by the documental application
on screen11. In so doing, she creates a document-fact whose content property
contains a nested frame structure in which each entry of the form is rendered
as a terminal element of an arbitrary deep tree-like structure. The general
case of CDA documents encompasses a three-level nested structure in which
a documental body is composed of multiple sections, each section is composed
of either multiple paragraphs, lists or tables and each of these of multiple en-tries. Since mechanisms must be sensitive to the value of single fields — since
so do conventions — it is important that the chosen data structure could be
referenced with the proper degree of granularity.
For example, the define primitive called upon the Single Laboratory Ex-
amination Form (see Fig. 7.5) would generate a template that the designer
has just to fill in when she will have defined the other entities involved. In the
following example, we see the document-fact template defined in Fig. 5.6, and
recall that the web-name attribute indicates the web of documents that the de-
signer is modelling and that the parent-fact attribute reflects the hierarchical
structure of the model regarding the entity at hand.
(Document-fact
(name SLEF)
(description "Laboratory Examinations
Form")
(web-name "Manzoni-Ward")
(parent-facts [entity-fact], [woad-fact])
11The data structures defining this representational aspect of the web-based clinical recordwe considered were XML files. According to the CDA specification and other HL7 standardsfor clinical interoperability all parts of the electronic patient record should be specified bysome XML files and this recommendation is generally followed by the majority of the domainvendors. This would also allow designers of the higher-level layers of a cooperative applicationto abstract from the back-end technicalities and even from the data representation details of thedatabase level, and therefore to focus on the structure and content that actors would directlyinteract with.
192
7.2. APPLICATION OF WOAD TO THE CASE STUDY
(access-rights <roles-to-define>)
(content <tree-structure>)
(conventions <rules-to-define>)
)
According to the internal structure of the content frame, the L*WOAD in-
terpreter would also create a number of d-activity-facts that correspond to the
leaf elements of the tree-structure. For example (with respect to Fig. 7.5):
(D-Activity-fact
(name SLEF-orders-filling)
(description "Action of writing in an exam row of the SLEF")
Document-facts and corresponding d-activity-facts represent the structures
regarding the textual aspect of the WOAD context2 (see Section 3.2). The next
steps regard hence the characterization of the work context in terms of roles,
actors and work activities; the last step regards the definition of the relation-
facts that put in the belong-to relationship w-activity-facts and d-activity-facts
(see Section 5.1.2).
After have defined the documents on whose content the mechanisms will
apply, the designer has then to consider which actors can have something to
do with such forms during a typical hospital stay. Consequently, she creates an
entity-fact for each person that could sign and consult the forms at hand.
How to manage roles within the WOAD framework depends at greatest
extent on the peculiarities of the domain at hand. As a general rule, roles in
the acceptation of institutional functions and appointments — also, job titles,
i.e., what in the HL7 RIM is denoted by the Role construct — can be rendered
as entity-facts. For our illustrative purposes, just two roles could be factualizedinto the Doctor and Nurse entity-facts. By exploiting the extendibility of the
entity-fact construct, then, each employee working at the hospital ward could
be represented as an entity-fact that extends either the doctor entity-fact or
the nurse one.
193
CHAPTER 7. APPLICATION OF WOAD TO THE HOSPITAL DOMAIN
In the following examples, we see the pay slot as an exemplification of
some administrative information that regards the role level and that hence
will be inherited by the actors that are assigned to that role, e.g., the personal
fact of Dr. Gregory House. Other actor-level attributes characterize personal
For roles that people can dynamically play according to the situation within
a certain task — what in the HL7 RIM is expressed by the participation class,
the designer can employ particular relation-facts, e.g. denoted by a “plays-
in-as” label, that relate an actor entity-fact with some w-activity-fact at in-
stance level. For instance, in a handing-over conference — which for some
application-level requirement could be rendered as a specific w-activity-fact —
the going-on-duty nurse and the going-off-duty nurse would play two different
and corresponding temporary roles, while they both keep being “nurses”12.
Once that also institutional roles have been defined, the designer has to
consider which tasks and activities each role can be responsible for. For each
activity, she defines a corresponding w-activity-fact and binds it to the role
entity-fact by means of the responsibility attribute.
12This kind of roles cannot be rendered as specialization of institutional roles. In fact, it isnot always feasible to establish all these roles at definition time but that notwithstanding singleactors need to be defined as extensions of roles so that conventions that apply to roles can alsobe propagated to the actors that play them.
194
7.2. APPLICATION OF WOAD TO THE CASE STUDY
In the following example we see the exam prescription activity that is as-
signed to the doctor role.
(W-Activity-fact
(name exam-prescription)
(description "Task in which some orders are given")
If the application domain requires to formally describe the articulation of
work activities, i.e., how such activities can follow each other, also the pre-condition and effect attributes of each w-activity-fact would be filled in with
conditions on the execution and enabling of the other peer activities. In the
example above, the designer has defined that the exam-prescription is enabled
only after that the preliminary examination has been carried out (see the
precondition slot). Likewise, by means of an work-related convention, she
could express that the activity of exam preparation would be enabled when-
ever an exam-prescription has been carried out. See the slot conventions in
the following example:
(W-Activity-fact
(name exam-preparation)
(description "Task in which the patient is prepared for some exam")
CHAPTER 7. APPLICATION OF WOAD TO THE HOSPITAL DOMAIN
(name exam-preparation)
(internal-state enabled) ))))
)
Then, for each definite piece of work represented by a w-activity-fact, the
designer considers which documents are supposed to be consulted and likely
to be also edited during that activity. For each document or documental por-
tion that is thus considered, she creates a belongs-to relation-fact that binds the
w-activity-fact with the corresponding d-activity-facts having those portions as
either input or output.
(relation-fact
(name belongs-to)
(description "inter-activity relationship")
(relation-level class)
(source-entity SLEF-orders-filling)
(target-entity exam-prescription)
)
In Fig. 7.4 we see what the designer has so far modeled of the ward domain
to represent by means of the WOAD static constructs.
Figure 7.4: A graphical representation of the entities and relationships involved in theillustrative example.
7.2.4 Structure-related L*WOAD Mechanisms
As mentioned in Section 6.3.7, all single sheets mediate clinicians’ interactions
by means of conventions related to particular areas of the documents that only
196
7.2. APPLICATION OF WOAD TO THE CASE STUDY
doctors and nurses are supposed to compile for, respectively, order entry and
task confirmation. We call this kind of conventions structure-related and will
be the first we will give some examples in terms of mechanisms. For example,
boxes d and e in Fig. 7.10 represent the prescription and the administration
sections, with exclusive access by doctors and nurses, respectively; while box
d and n in Fig. 7.5 represent where doctors and nurses compile laboratory
prescription entries and confirmations, respectively.
For the sake of illustration, let us suppose that the designer wants to con-
struct some mechanisms that follow the well-established conventions regard-
ing which checkboxes are filled in and in which order they are on the Labora-
tory Examinations Form13 (SLEF — see Fig. 7.5). This spatial and temporal
order does not regard an aesthetic or qualitative requirement but conveys a
clear coordinative meaning in that the proper form compilation triggers mul-
tiple tasks, from having a blood sample be taken, having it sent to the hospi-
tal laboratory and having a referral be sent back by the laboratory staff with
the needed results. Consequently, these mechanisms will be conceived to ex-
press in a computational way which are the entangled conventions of proper
compilation and cooperative use of the form; as well as to render awareness
information on to-do tasks and priorities that can be triggered by that form.
The reader can refer to Section 3.4.2 to be recalled on which kinds of con-
ventional knowledge the WOAD framework focuses on. In terms of L*WOAD
constructs in which such conventional knowledge is conveyed we have now to
consider which mechanisms regarding the “proper filling in” will be included
within the conventions attribute of the SLEF document-fact that the designer
has defined in the previous section. That attribute pertains to the conventions
that directly refer to the document at hand. The awareness-related mecha-
nisms will be rendered as convention-facts that in their antecedent side will
refer both to the SLEF document and some awareness-fact management (def-
inition, assertion or deletion).
The case
Let us now refer to Fig. 7.5, representing the actual form on whose structure
coordinative conventions apply. Each prescription is represented as the inter-
13The very same thing holds also for the other two single sheets above mentioned. Indeed,the steps that we outline in the following can constitute a pretty schematic methodology for thedeployment of a WOAD-compliant system with respect to all the observed documental artifactsreported in Chapter 6.
197
CHAPTER 7. APPLICATION OF WOAD TO THE HOSPITAL DOMAIN
Figure 7.5: A snapshot of the Laboratory Examinations Form (SLEF). An area forprescribing only three typologies twice (e1 and e2) is brought into close-up, for room’ssake.
section between the rows denoting a particular examination and the couple of
columns (denoted with e1 and e2 in Fig. 7.5) indicating the main tasks regard-
ing examination according to the ward perspective: ordering and completing
them. The doctor that requires a laboratory examination for a patient is sup-
posed to put her initials on the corresponding field denoted as ‘RIC’ (request)
and to record date and time of the request (in the figure, ‘Data’ and ‘Ora’ fields,
respectively). Additionally, she is also supposed to indicate whether the exam-
ination is urgent (denoted with a capital U) or the blood sample can be taken
and sent to the laboratory with all the other routinary examinations, usually
the next day early in the morning. In this latter case the physician ought to
write a capital R (for ‘routine’) in the corresponding field. Obviously, the indi-
cation ‘routine’ is the conventional default value, and, accordingly, for routine
examinations the physician is usually exempted from marking the priority and
time fields (see box a in Fig. 7.5).
The coordinative convention here is that orders are officially committed as
soon as initials are signed in the field RIC of an exam row: in that moment,
nurses become in charge of preparing patients; take blood samples, book the
examinations to the laboratory facility; get from that facility an order ID; as-
sociate test tubes with correct stickers; have those material sent14 to the lab;
14Usually specific assistants are in charge of transporting blood samples to the laboratory at
198
7.2. APPLICATION OF WOAD TO THE CASE STUDY
and organize returned reports and results into a specific referral box at the ad-
mission desk of the ward. Nurses are supposed to give written confirmation of
order execution into the ESEG field (‘ESEG’ stands for ‘executed task’), as soon
as they know samples have been successfully received by the laboratory facil-
ity. In so doing, the on-duty doctor (not necessarily the same ordering doctor)
can15 consult the referral box, take the examination, consult it and afterward
file it in the correct patient record. The process is considered completed when
also the doctor acknowledges the test results putting his full signature in a
particular field; this is reproduced at the bottom of each RIC-ESEG pair of
columns of the SLEF with the function of encompassing the whole battery of
tests of a given day (N.B. that signature field is not represented in Fig. 7.5).
Mechanisms on proper compilation
From evidences collected in our field studies, we can exemplify the designing
of structure-related conventions by outlining three mechanisms for the proper
compilation of the SLEF: those regarding the conventions that (a) only doctors
can put their initials in the RIC field and only nurses can sign the ESEG field;
(b) the ESEG field can be compiled only after the corresponding RIC field has
been, and also after that the blood samples have been taken and sent to the
laboratory16; (c) when an examination is deemed urgent, the doctor should
also fill in the time field or, at least, warned to do so. Obviously, there are
no impediments to conceiving a single mechanism that encompasses all these
aspects, as well any other, regarding the proper compilation and coordinative
use of the form at hand but it is also good designing practice advocated by
the WOAD framework to separate work-related concerns and hence to design
smaller mechanisms addressing each a specific concern.
As regards the latter convention, making date and time mandatory fields
of the form in any single case would end up by nagging doctors, especially in
those cases that examinations are really urgent either to stabilize a patient or
begin as soon as possible a life-saving treatment. That notwithstanding, if an
examination is deemed as urgent, prescription time is a useful indication to
timely urge the laboratory in case of even slight delays on expected schedules.
predetermined hours in the morning.15Here again, we stress the different degree of prescriptiveness conveyed by the signs re-
ported on the SLEF: coordinative for nurses and awareness for doctors.16Provided that the dispatch information is made available in the hospital information system
and consequently factualized in a corresponding contextual information.
199
CHAPTER 7. APPLICATION OF WOAD TO THE HOSPITAL DOMAIN
For this reason, a proper mechanism must be capable of distinguish these two
cases of priority, not only on the basis of the mere syntactic indication U or
R but also depending on the priorities of current work activities in execution
— i.e., the so called work context — and reminding the ordering doctor at
need.
An important point about the applicability of WOAD mechanisms to forms
is that they are parametric as regards the contextual conditions they are sen-
sitive to and that they apply to contextual elements by pattern-matching. This
means that the designer does not have to write a mechanism for all possible
blood examinations that are currently included within the SLEF, once that a
general pattern has been conceived that can match with any of them; it also
means that she does not have to worry about possible additions or modifica-
tions to the form, if the latter ones do not regard the very structures referred
within the mechanisms by means of the conceived patterns.
On the proper role
The basic mechanism that checks that the proper role has gained access and
updated the SLEF according to her access rights would have in its antecedent
patterns that (a) match the content attribute of the SLEF document-fact; (b)
match a d-activity-fact that has in its input (or output)17 the same instance
of document-fact (or part of it); (c) match an actor entity-fact that is an ex-
tension of the role entity-fact that is represented in the access-rights attribute
of the document-fact18 and whose name attribute corresponds to the executorattribute of the above mentioned d-activity-fact.
In the exemplification depicted in Fig. 7.6, we represent the patterns that
express the above mentioned “logic” and point out the parametric nature of
WOAD mechanisms: the reader should not consider it a digression to some
language technicality or particular syntax, but yet see it as a convenient way
to illustrate the pattern-matching rationale of WOAD mechanisms. Each pat-
tern is a partial data structure with unbound variables, which we indicate with
a letter preceded by a question mark (?); by matching the facts within the fact
space, variables bind themselves with each value that makes the pattern true;
in Fig. 7.6, bindings between patterns’ variables are indicated with small geo-
17We mean input or output according to whether the role has gained accessed or updatedthe form, respectively.
18The match would be between the access-rights property and document-fact and the parent-facts property of the entity-fact.
200
7.2. APPLICATION OF WOAD TO THE CASE STUDY
metric figures for clarity’s sake. The convention template is further commented
by interlinear comments preceded by a semi-colon (;) and intended to make
the mechanism’ internal logic clearer.
Figure 7.6: WOAD mechanism for a convention on the proper role.
As mechanisms’s antecedents can reflect different application-level re-
quirements and conventions with additions to the basic mechanisms we have
above outlined, likewise also to decide which kind of awareness information
the designer should define and assert in the awareness section of those mech-
anisms’ consequent is a pretty arbitrary task. In the case a mechanism has
detected either an inconsistent state (e.g., a request date that is in the future,
or an ESEG field filled in before a RIC one) or a situation that is convention-
ally deemed as faulty (e.g., an urgent request that is not processed within a
certain lapse of time), awareness information could range between a grinding
halt (e.g., alerts that require some amendment before further processing) or
mild reminders that summon for further, but voluntary, verification. To make
an explicit reference to the options provided by L*WOAD and surveyed in Sec-
tion 5.2, we correlate the mechanism depicted in Fig. 7.6 with the provision
of inhibition awareness.
201
CHAPTER 7. APPLICATION OF WOAD TO THE HOSPITAL DOMAIN
On the proper order
The mechanism that checks whether fields are compiled in the correct order
(e.g., RIC first and then ESEG) is represented in Fig. 7.7: its antecedent part
contains a logic expression that evaluates that a RIC field has been previously
compiled (i.e., it is not empty) when the corresponding ESEG field is still to
be compiled. Obviously, even such a simple mechanism can contain further
conditional elements to represent conventions on the regular flow of tasks.
For instance, as we hinted above, some clinicians we interviewed drew our
attention on the necessity that all nurses follow the convention to compile the
ESEG field only after that they receive a dispatch receipt from the laboratory,
or at least, after having had really taken the blood sample from the patient.
Sometimes, conversely, nurses were used to fill in it at the time they prepared
the syringes for each patient, as a sort of to-do list. Unfortunately this practice
could eventually result in a number of misunderstanding and coordinative
breakdowns if for any reason the blood test could not be actually accomplished
(e.g., for indisposition of the patient). In this case, conventional mechanisms
can act as learning devices to instruct practitioner on the virtuous way to intend
the form structures and to grasp the intended meaning of the field ESEG (the
same argument was made at the beginning of Chapter 3).
In the following example, we see that this virtuous convention can be
represented by two w-activity-facts, expressing respectively the examination
booking and tube dispatch, triggering the corresponding mechanism when
their internal states are both completed. It is not necessary to explicitly express
the virtuous flow of work, in terms of preconditions and effects between those
activities and the work activity to which the compilation of the ESEG field be-
long. The mechanism triggering conditions emerge from the global state as it
is represented within the fact space so that next activities are enabled (their
facts being put in the enabled state) and proper awareness information pro-
vided to the involved actors accordingly19. The awareness information that the
consequent of such mechanism can provide actors with is a coordination one
since doctors rely on the ESEG marking to know when to access the referral
19In the example depicted in Fig. 7.7 and the following ones, we use a positional notationto indicate the elements of the documental content structure. The explicit, but yet conven-tional, reference is to the CDA specification, where the body of the document contain multiplesections, section can hold either rows in the case of tables, or fields and the latter a value. Ob-viously this way to express patterns is merely illustrative and purposely abstract: the very waycontent structure is represented in terms of processable data structure depends on the actualimplementation.
202
7.2. APPLICATION OF WOAD TO THE CASE STUDY
box and consult new arrivals.
Figure 7.7: WOAD mechanism for a convention on proper order.
On the proper timing
The same considerations can be made also for the virtuous convention of
proper compilation by the doctors, as in the case above mentioned in which
doctors are requested to indicate the precise time of prescription in the case
they deem the examination urgent. For this last case, we are not making the
syntax mechanisms explicit for its close similarity between this case and that
represented in Fig. 7.7. Rather we intend to show how different awareness
information could be provided according to the time spent since ordering. In
Fig. 7.8, we represent a mechanisms that after a hour reminds accountable
clinicians that an urgent examination is still to be processed20. The awareness
information provided in this case is of reminding type.
20As regards the temporal aspects, in the example depicted in Fig. 7.8 we have assumed somesimplifying assumptions. For example, time interval is calculated on actual time values as calcu-lated by the application, not on the basis of the value the doctor recorded in the artifact. Then,we do not check in which internal state subsequent related work activities are; we rather relyon other proper-compilation mechanisms to assume that the absence of signs in the ESEG fieldis significant and the related activity is actually not yet accomplished. Likewise, the mechanismdoes not provide a specific actor with awareness information just not to further complicate theexemplification of the case; we rather inform just a nurse role that is responsible for the orderexecution.
203
CHAPTER 7. APPLICATION OF WOAD TO THE HOSPITAL DOMAIN
Figure 7.8: WOAD mechanism for a convention on proper timing.
On the proper redundancy
Structure-related mechanisms can also regard static relationships between
fields, i.e., schema-level relationships that always hold, irrespective of the in-
serted values. To give a significant example taken from our field study, let us
consider the correlations for replicated and duplicated data we treated in Sec-
tion 3.3.3. These correlations regard fields that must contain the same value,
either within the same form or across different documents, respectively. Clini-
cians pointed out that from a technological support they would (also) expect
to be relieved of additional secretarial efforts they had to undertake to com-
plete their work: e.g., when clinicians — usually nurses — are supposed to
merely copy data from a document to another without any further fruitful
elaboration.
A pretty trivial but ubiquitous example of this kind of conventions is given
by documents headers where identifying data are replicated in each form that
204
7.2. APPLICATION OF WOAD TO THE CASE STUDY
can be pulled out from the record binder for the sake of reference (for ex-
ample, see box a in Fig. 7.10, where personal data and stay-period data are
reported in headnote). The corresponding conventions of replication would
hence regard when and which data should be replicated and in which field of
which document. The corresponding mechanisms would contain antecedents
that are similar to those of the mechanisms checking the internal consistency
of documents: their antecedents would have patterns that match the content
of the correlated fields and trigger the execution of the mechanism’s conse-
quent whenever their values are different (see Fig. 7.9). The trivial case would
be the initial case, in which one of the fields bound by a correlation for repli-
cated data is still empty and the mechanism reminds the executor of the cor-
responding d-activity-fact to replicate the data for the convenience of the col-
leagues that will refer to either fields. Also in this case the type of awareness
that the mechanism could provide is of reminding type.
Figure 7.9: WOAD mechanism for a convention on proper redundancy.
The careful reader would have noted that to conceive such mechanisms
could be overly burdensome in any digitized documental platform where iden-
tifying and administrative data are replicated just at presentation layer in
virtue of the schema-level associations between the clinical record structures.
That notwithstanding, less automatic and trivial conventions about which data
are to be replicated and which can be easily “interpolated” from the context
can exert the specific and useful function to modulate the degree of the so
205
CHAPTER 7. APPLICATION OF WOAD TO THE HOSPITAL DOMAIN
called “information overload”, i.e. the case of having too much information to
make a decision [Edmunds and Morris, 2000].
The fact that mechanisms operate upon the structure of the clinical record
“from the outside” and are not “hardcoded” in its schema could allow indi-
vidual wards to decide to deliberately create sections within their peculiar
version of the hospital-wide clinical records dedicated to conveying positive re-dundancy (see Section 3.3.3), by relying on specific mechanisms that in their
content section modify correlated documents so as to replicate information
where it needs.
Examples taken from our field studies and that we reported also in [Cab-
itza et al., 2005b] regard the single Pharmacological Therapy Form (SPTF)
(see Section 6.3.7), where according to the prescribing doctor and her neces-
sity to carry out simple calculations on the weight or age of the inpatient for
the dosing of a specific drug, she would appreciate that these values be re-
ported in any single SPTF (see the c box in Fig. 7.10) according to the very
drug/weight/age, while otherwise these data would be superfluous or even
misleading. Or, as another example clinicians considered important and still
pertaining to the conventional use of the documentation, the case of replicated
data regarding allergies and drug incompatibilities, in box b of Fig. 7.10: in
that case, data taken from the Anamnestic Data form — see Section 6.3.2 —
were reported into the single pharmacological therapy form for convenience’s
sake only in those cases that some amnestic data should be timely reminded to
the ordering physician with respect to the very prescription that she is filling
in the form.
Obviously the boundary between relevant data to replicate across the clin-
ical record and data that would constitute just a case of information overload
is very difficult to detect, especially by means of parametric and pattern-based
mechanisms. In many cases, whether a datum should be transcribed in parts
of the record where it is not supposed to be reported requires an interpreta-
tive intervention by the practitioner involved. This leads us to introduce the
two other classes of mechanisms, that involve either content characterization
or the direct human intervention in characterizing relationships between data
and structures.
206
7.2. APPLICATION OF WOAD TO THE CASE STUDY
Figure 7.10: A snapshot of the Single Pharmacological Therapy Form (SPTF). Dashedboxes indicate sections with a specific meaning within the clinical record.
7.2.5 Content-related L*WOAD Mechanisms
From the content perspective, WOAD mechanisms are a flexible way to cope
with the semantics of data stored within the clinical record, i.e., with what a
certain datum really means in cooperative and coordinative terms. Such mech-
anisms can act on single documents, or be applied to several distributed forms
so as to link information and practices together toward a more aligned un-
folding of clinical interventions. We denote this kind of mechanisms ‘content-
related’ since they do not depend on the structure of documents in which
content is conveyed but rather on the type of content, and on its intrinsic
properties.
Also in this case, we refer to the physician order entry, specifically per-
taining to drug prescription and administration as it is mediated by the Single
Pharmacological Therapy Form (SPTF — see Fig. 7.10).
For this kind of mechanism to properly work the assumption is that de-
tailed and reliable information on drug composition and drug features has
been represented in some digital document. Once this information has been
also “factualized” into the fact space, WOAD mechanisms can be easily config-
ured so that constraints and peculiarities of any single drug can be reflected
on proper and unambiguous prescriptions. In addition to these standardized
and worldwide instructions, WOAD mechanisms can also provide the single
ward application designer with a tool to configure local conventions on drug
207
CHAPTER 7. APPLICATION OF WOAD TO THE HOSPITAL DOMAIN
prescription and administration.
For instance, physicians have presented us the requirement that clinicians
from a certain ward could have their own idiosyncrasies in having a certain
drug be administered in a particular way or physical form, or within partic-
ular therapeutic regimens that are considered appropriate for a certain ty-
pology of patient. In these cases, the mechanisms would reflect not only a
domain knowledge whose rationalization and standardization is currently be-
ing greatly undergone in the field of pharmacological applications, but would
also integrate that knowledge base with local conventions on proper ways
to interpret it within a specific cooperative arrangement. Since this aspect is
close to supports that lead toward the integration of clinical record with med-
ical knowledge or best practices as they are represented into clinical pathways
and care programs [Berg et al., 2005] we do not go into it further, leaving it
for the Section on future work (Section 8.3).
The ‘DURATA’ field case
As said at the beginning of this section, content-related conventions can apply
to several fields within the same form as well as to a number of forms within
the same clinical record. As an example of the former case, let us consider
the f and g arrows reported in Fig. 7.10. These lines relate the drug form
(namely, the “Forma Farm.” field in the same figure) to the administration
duration (“Durata”) and the frequency indication (“Freq.”) to the number of
administration turns per day, respectively, as they are reported in the rows of
the administration section (box e in the same figure).
According to a ward-specific convention, only infusions can have a “du-
ration”, while the other kinds of administration are considered one-shot (i.e.,
either the “pill” has been administered or not) even if their intra-venous assim-
ilation can take a long while. In other words, only a convention that was prob-
ably established by who designed the form — but on which all its intended
users have definitely agreed upon later — indicates whether the Italian term
“durata”, which means both duration and length, refers either to the length of
the very administering process or to the duration of the overall regimen for
a given drug, i.e. for how long nurses do have to compile the corresponding
administration section of the form. Although this can seem a trivial matter at
a superficial glance it is right the kind of semantics that would be too rigid
to embed into the form structure and that must be managed with more flex-
208
7.2. APPLICATION OF WOAD TO THE CASE STUDY
ible and context-dependent mechanisms. Indeed, one of the most vague and
equivocal convention we collected from our field study within the neonatology
ward was right that regarding when an infusional therapy should be treated
either with a daily form or with a weekly form: clinicians “just knew” when
to employ a form instead of the other and the boundary for the choice of the
form was approximately set to one-hour long infusions although it depended
to a great extent on which kind of drug was to be infused and to which kind of
inpatient (i.e., her critical conditions). Right in those cases in which the type
of drug matters, actors could be provided with an alerting awareness that calls
their attention on a possible deviation from the conventional use of the SPTF,
whenever predefined conventional associations between drugs and patterns
of documental use are not met.
The patient preparation case
As an example of the case in which conventions span across different docu-
ments within the clinical record, let us step back to the Laboratory Examina-
tions Form (LEF — see Section 6.3.7 and Fig. 7.5). In that case, the designer
could render into a proper mechanism the ward convention by which requests
for a particular examination are usually associated with a particular prepa-
ration of the examined patient by the nurses in charge. This also is a typical
case in which either drug handbooks or nursing manuals can enumerate lots
of “best practices” in preparing patients for examinations and even suggest
particular preparations for particular examination; but that notwithstanding,
patient preparation is also an aspect of the patient need management in which
nurses operate with a high degree of autonomy and often according to local,
ward-wide conventions that have become established and consolidated for
their function of guaranteeing seamless task alignment and coordination21.
In order to mention a often recurring convention, a content-related mech-
anism for preparations for endoscopic examinations22 could have patterns to
refer to a Single Diagnostic-Therapeutic Form (SDTF — see Section 6.3.7), aswell as of the form that nurses use to indicate the daily diet of inpatients in
their nursing record (i.e, the Fasting plan, FP, see Section 6.3.9). This form is
21The conventional nature of routinary task can be also harked back to the need to rely onbehaviors that are easily recallable according to the contextual ward exigencies.
22We denote this kind of mechanism ‘content-related’ since it depends not on the structureof the form by which examinations are ordered but just on the type of ordered examination,i.e., on the form content.
209
CHAPTER 7. APPLICATION OF WOAD TO THE HOSPITAL DOMAIN
Figure 7.11: A snapshot of both the Single Diagnostic-Therapeutic Procedure Form(SDTF) and the Nurses’ Fasting plan. In the latter the four columns indicate, respec-tively, the bed-number, the name of the patient, the examination type, and the sched-uled time for the examination. For the SDTF the six columns indicate: the orderingdoctor, the ordered exam, date of request, date of booking, (scheduled) date of exe-cution and (scheduled) date of referral arrival.
used to indicate particular deviations from the regular meal that is daily served
by the ward catering service. In Fig. 7.11 a correlation for replicated data is
denoted with the letter a over the arrow relating the two ESAME fields (exam);
and with b a relationship between the scheduled time for the endoscopy (field
DATA ESECUZIONE on the SDTF, execution date) and the time the patient will
have to fast (field ORA on the FP).
In its consequent’ side, the mechanism would hence remind nurses that the
patient must follow a particular diet for the scheduled examination or, more
frequently, just fast until the next morning blood taking (reminding aware-
ness).
7.2.6 Applying L*WOAD to web-spanning correlations
The previous example leads us to consider the more frequent (and most in-
teresting) cases in which correlations are neither embedded in the inscribed
structure of documents, nor traceable back to the standardized content of doc-
uments — i.e., in our reference domain, drug and examination typologies. This
is the case in which the designer conceives mechanisms that are sensitive to
correlations that are explicitly drawn by clinicians during their daily activities.
We will outline three examples, taken from our observational study.
210
7.2. APPLICATION OF WOAD TO THE CASE STUDY
The Problem List case
The first two regard both the doctors’ Problem list23. As said in Section 6.3.4,
the problem list (PL) is more than a mere list of items, where the set of either
concomitant or sequential problems affecting the patient are reported. The PL
is also the document where the clinical case is objectified and separated into an
enumerable set of concerns and problems that must be solved for the complete
recovery of the inpatient. Moreover, problems can be also seen as diagnosis,and as such they do change over time. Changes that regard acuteness of a
previously stated problem are not represented explicitly into the PL; these are
rather represented in the Physicians’ Notes as evidence of the illness trajectory
unfolding (see Section 6.3.6). Rather, the PL only represents the main devi-
ations and swerves of such trajectory, and the results of the epicrises doctors
periodically accomplish in evolving and improving their diagnosis on a specific
case. Epicrises are critical summings up within a medical case history that usu-
ally are documented on the Physicians’ Notes; on the PL their outcomes can
result in previously unrelated symptoms that are crossed out with the stroke
of a pen and are substituted by a new comprehensive diagnostic item.
The physicians we interviewed called our attentions to the requirement of
having the possibility to relate past problems to new problems, as a way to
reconstruct or, better yet, make explicit the line of thought that has rational-
ized symptoms into problems and unrelated problems into precise diagnosis.
In this case, an awareness-provision mechanism could be designed just by
writing a couple of patterns: a pattern that is sensitive to problems that are
stricken out i.e., entries within the content attribute of the PL document-fact
that is “deleted”; and another pattern that is sensitive to the relation-fact that
puts the former problems in relationship with new problems (i.e., other en-
tries within the PL document-fact) and that would be asserted into the fact
space by the software platform whenever a doctor select the corresponding
relationship in the web-based application (see Section 7.2.1).
The prescription case
The same holds for a similar mechanism that the designer could conceive to
provide actors with awareness information about the relationship that doc-
tors draw between one or more problems reported in the PL and one or more
23The same argument can be symmetrically followed for the Need List of nurses.
211
CHAPTER 7. APPLICATION OF WOAD TO THE HOSPITAL DOMAIN
prescriptions ordered by means of the Pharmacological Therapy Form (SPTF).
That mechanism would have an even simpler antecedent (see Fig. 7.12), since
it would contain just a pattern that is sensitive to a relation-fact that relates
some item in a PL document-fact and some other item in a SPTF document-fact
(no particular condition must be verified on either). This mechanism would
help the system call the doctors’ attention to the causal correlation that a col-
league has previously drawn between a problem and a step in the process
of its resolution (an item among the physician orders); or, alternatively but
less frequently, to the correlation that relates the onset or recrudescence of a
problem with the course of a treatment that the patient has not tolerated.
Figure 7.12: WOAD mechanism for a convention on web-spanning correlations.
The Physicians’ Notes case
A similar mechanism covers the third main case in which doctors have re-
ported to feel the need for correlating data when they record events on the
clinical record: correlations between SPTF entries and entries in the Physician
Notes (PN — see Section 6.3.6). In this case correlations could convey one
from a wide range of different meanings and express the need for the order-
ing doctor to share with her colleagues of the next shifts her hypothesis on a
number of topics: e.g., how a patient is reacting to a certain course of treat-
212
7.2. APPLICATION OF WOAD TO THE CASE STUDY
ment; why a certain dosage had to be changed; or which result the doctor
hopes to reach in the following hours by the ordered treatment. In this last
case that we consider, the type of awareness information provided is close to
either what we have defined either inquiring or alerting awareness, according
to the very situation at hand and the very way the clinicians interpret it and
the consequent informational need for their coworkers.
Sharing these thoughts, making explicit correlations and giving them one
of the “flavors” that field observations have disclosed in any specific domain
(e.g., the causal, temporal and intentional correlations we mentioned in Sec-
tion 7.1.3) allow clinicians to put in common reflections and remarks that
otherwise would be difficult to reconstruct or even discover at hindsight. This
capability has been detected as a crucial requirement for both physicians and
nurses as regards the electronic clinical record they would welcome for their
daily work. This requirement can be traced back to the need for coopera-
tive workers to share pieces of information, all together with contextual items
that can help them in making sense of what is shared (i.e., unpacking their in-
tended meaning and their conventional interpretations [Schmidt and Bannon,
1992]).
The paper-based clinical record has always been a common and shared
repository for distributed and asynchronous communication: accordingly, the
designer that wants to deploy computational systems capable of preserving
and even augmenting the coordinative function of shared documental bases
like the clinical record should take care of the extent she can design data
structure with the explicit aim to fluidly bind data together, at run time, by
means of flexible and even underspecified means.
213
Chapter 8
Conclusive remarks
8.1 Summarizing the main achievements
In this thesis, we have concentrated on the role that documental systems com-
pound by a highly interconnected network of documents — what we call websof documental artifacts, WOAD — play in mediating and supporting distributed
cooperative settings, especially those in which practitioners need to rely on
asynchronous communication to articulate their decisions and interventions
on multiple and complex trajectories of work.
We have taken inspiration from previous researches addressing the use
of documents for information sharing and articulation work (e.g., [Bannon
and Bødker, 1997,Harper and Sellen, 1995,Star and Griesemer, 1989,Simone
and Divitini, 1999]) and we have corroborated their main findings after have
had conducted a short ethnographical study of how physicians and nurses
coordinate each other in two hospital wards of the same regional teaching
hospital by means of their official documentation, the patient-centered clinicalrecord (see Chapter 6).
In such studies, we have observed the practices by which hospital practi-
tioners make sense of records so as to be supported in articulating their ac-
tions across distributed locations and time shifts as well as along different
work trajectories (any single patient’s case [Strauss, 1985]). The evidences
we collected observing their practices, a number of semi-structured interviews
with several key actors of the settings at hand, and a thorough analysis of
their documental system, have then informed our task of detecting and speci-
fying collaborative issues and informational requirements and those practical
solutions that practitioners applied relying on local conventions and ad-hoc
215
CHAPTER 8. CONCLUSIVE REMARKS
agreements.
Grounding on such specific ward observations, the consequent analysis of
artifacts and the literature survey, we have then collected a proper set of re-
quirements that can be suitably adopted for the design of a computationally-
augmented documental system at support of cooperative work in documental
settings. As regards the high-level and general requirements we have high-
lighted the importance to preserve and enhance (1) the informational value
of documents, in terms of their ecological flexibility [Luff et al., 1992]; (2)
their evidential value, in terms of facilitating actors in conveying either add-onand by-product awareness [Simone and Bandini, 2002] to their colleagues to
conveniently coordinate with each other; (3) their capability to support ac-
tors in accessing and reconstructing the context of production of a recorded
item [Bannon and Bødker, 1997,Berg and Goorman, 1999].
Following a bottom-up approach, we have then tried to generalize our
findings into a more general framework for documental domains, i.e., for co-
operative work domains where documents play the twofold important role
of information holders and communication mediators. The main aim of such
framework is to focus on and characterize some relevant concepts that could
guide the design of a reference architecture for computer-based documental
systems in which the above mentioned requirements, taken from traditional
paper-based systems, are to be preserved and possibly enhanced.
The main components of this reference architecture are (a) the documents
that actors use in the execution of their own work, (b) a computational coun-
terpart of a common information space [Schmidt and Bannon, 1992], which
contains elements taken from the work and environmental context and which
we say “common” as regards both the documents’ content and the conven-
tional practices of making sense of it; and (c) the computational application
of conventions, i.e., setting-related mechanisms of interaction and information
provision, by which to make the state of documents and information space
change as a context-driven state-transition systems (see Chapter 3).
In our framework, the information space, termed fact space, is a shared
documental memory where each piece of information recorded within a web
of documents is made accessible to its human users1, it is made interconnected
1At this level of discussion, we purposely neglect the issue of privacy and authorization ofsuch data. The a-priori (and application-independent) underlying idea is anyway to reproduceinto the computational artifacts as much as restricted access and management as it is in theirtraditional paper-based counterparts and no more than that.
216
8.1. SUMMARIZING THE MAIN ACHIEVEMENTS
to all the other textual and contextual information it can be usefully referred
to and it is made associated with additional information that is intended to
represent some possible conventional interpretations to such data.
Our proposal tries to give concreteness to the above mentioned require-
ments in three main ways:
1. First by having users rely on a context-sensitive support to documental
practices — and related higher-level tasks — on the basis of symbolic
and computable representations of conventional patterns that regard
content production, content use and the content interpretation aimed
at task articulation and coordination.
2. Then, by providing users with the capability to indicate, at any point of
their work trajectories, even underspecified relationships between con-
tent items across the whole documental systems and between content
items and document structures in order to hint either coordinative or
just proper and timely use of them.
3. Lastly, by leveraging on user-defined relationships — as well as on those
indicated at design time by the setting’s analysts — to support the sense
making process of involved actors in order to provide them with aware-ness information [Dourish and Bellotti, 1992] whose type depends on the
informational needs and conventions detected in the setting at hand.
These summarized functionalities can also be harked back to the require-
ment regarding common information spaces [Schmidt and Bannon, 1992] of
facilitating the “active construction [of a] space where meanings of the shared
objects are debated and resolved” and where “both the producer and the re-
ceiver [of some documental content] consciously make an effort to understand
each other’ context”. In fact, the WOAD framework encompasses two specific
times and kinds of support to facilitate this “active construction”.
1. First, at design time, WOAD provides designers with a reference modeland a language (L*WOAD, see Chapter 5) by which to express locally-
constructed and shared agreements about the meaning of common data.
Designers are requested to represent such agreements and conventional
interpretations in terms of condition-driven mechanisms, that the sys-
tem executes to convey proper context-driven awareness information to
217
CHAPTER 8. CONCLUSIVE REMARKS
the involved actors. Yet, the WOAD framework does not impose design-
ers to master some particular programming language or to worry about
other implementation technicalities. In fact, they can express relevant
concepts and conventions of a specific work setting and have a WOAD
interpreter render their frame-like representations into the specific data
structures and the executable code of the platform currently implement-
ing the framework. At the present moment this platform is DJess, a
lightweight communication middleware that we specifically conceived
and implemented to enable the deployment of context-aware and mo-
bile applications in distributed settings (see Chapter 4 and also [Cabitza
and Dal Seno, 2005,Cabitza et al., 2005c].
2. Then at run time, WOAD enables the actual users of a documental sys-
tem to make explicit either user-defined or domain-dependent relation-
ships between document’ content and their context, once that the rele-
vant aspects of the work context and proper relationships between the
involved classes have been symbolically represented at the former step
by properly extending the WOAD constructs (see Chapter 7).
8.2 Confronting WOAD with similar approaches
So far, we have summarized the main tenets and characteristics of the WOAD
framework and outlined in Chapter 7 how we applied it to a real setting,
providing for the sake of clarity exemplifications whose simplifications do not
compromise its trustworthiness. In so doing, it is now easier for us to compare
our proposal with other contributions and approaches that have some points
in common on how to conceive computer-based technologies supportive of
cooperative documental domains.
The main common point between most computer applications is informa-
tion processing: information is gathered from the user and her environment,
is stored, organized, managed (e.g., by controlling access rights), processed,
and finally provided as output to some other agent, either some other soft-
ware component or, more often, the user herself. As reported in Section 2, al-
most the 90 percent of that information is unstructured, i.e., expressed within
documents and managed by human actors quite effortlessly and much more
difficultly by computational machines. Actors employ documental content to
inform their thoughts, decisions and actions: in short, to manage their own
218
8.2. CONFRONTING WOAD WITH SIMILAR APPROACHES
work trajectory with respect to all other trajectories they are mutually inter-
dependent with. For their part, machines are successfully used to process fast,
cheaply and accurately content, as long as practices, conventions and work
trajectories involved with content are mainly adjusted by actors. For this rea-
son, the relationship between content and coordination support is a funda-
mental issue in the design of CSCW systems [LaMarca et al., 1999].
In CSCW-informed deployed systems and, more generally, in groupware,
coordination-enabling and coordination-facilitating functionalities either are
embedded in new more comprehensive tools or old tools are someway
wrapped up by some cooperative component so that they can become more
supportive of information sharing and collaboration between their users. The
former approach has been often observed problematic (e.g., [Grudin, 1988,Ol-
son and Teasley, 1996], since users are usually reluctant in changing their ha-
bitual ways to have things done, especially about aspects of their work that
they think to accomplish very well (like articulating each other on a daily
basis). Also the latter approach can lead to unsatisfactory results: it is true
that users are not forced to get acquainted with new tools but the fact that
these tools can not be changed hinders the benefits of augmenting them with
a cooperation-oriented semantics that is tailored to the specific domain needs.
In the following, we mention two main works that to our knowledge
are the closest to our proposal for some points, especially for their focus
on the documental domain and we compare them to the WOAD framework
in terms of similarities and differences: one has been chosen as represen-
tative of the approach that proposes the use of new systems to get more
coordination-oriented features; the other as representative of the approach
that advocates the augmenting of existing systems with a collaborative logic
layer (e.g., [Greenberg, 1990]).
Context-aware computing for the healthcare
Context-aware applications in health and hospital care mostly focus on spe-
cific concerns other than the actual interaction of clinicians with the elec-
tronic clinical records, such as privacy and security issues [Bardram et al.,
2003] and bedside support2, such as patient monitoring and context-aware
drug administration (cf. e.g., the context-aware pill container in [Bardram,
2Bedside support regards the delivery of services “at the point of care” (POC) (cf., e.g., [Fis-cher et al., 2003]).
219
CHAPTER 8. CONCLUSIVE REMARKS
2004]). This attention for making computing embedded and almost disap-
pear within the hospital environment3 and in medical appliances risks yet to
neglect the most serious complaints that have been collected regarding why
most of all computer-based clinical records fail (e.g., [Heeks et al., 1999,Ben-
son, 2002,Jones, 2003]): in most of the cases, clinicians show manifest reluc-
tancy and resistance due to the significant alteration of their traditional work
patterns to accommodate the workflow imposed by the system [Anderson and
Aydin, 1997,Berg, 2003], i.e., by the clinical documentation itself.
As a contribution against these shortcomings, Jahnke et al. proposed
the Context Management System (CMS) [Jahnke et al., 2004b, Jahnke et al.,
2004a]. CMS is a framework for the provision of clinical information that is
also intended to be applied to other documental domains where information
is mainly in web format. At the core of the CMS there are a context fact base,
a context pattern base, and a context inference engine. The context fact base
is a graph-based database storing facts about “situational parameters of user
interactions” with the electronic documental system. The context pattern base
stores rules that associate certain pages (or screens) of the documental sys-
tem with some formal definitions of predefined usage patterns. The context
inference engine is the computational interpreter that composes convenient
vistas of the overall documentation according to the predefined patterns of
documental practices and the current data in the context fact base.
The main similarities with the WOAD framework are two (besides the
peculiar reference domain of hospital care): the centralized representation
and management of context and the context-aware provision of information
through the documentation. As regards the former point, there is a clear simi-
larity between the context fact base and the WOAD fact space, although CMS
employs a graph-based representation of context implemented by the GRAS
database [Kiesel and Schuerr, 1995] while WOAD decouples the data repos-
itory management from the data presentation at artifact level, and directly
manages the latter. Also the idea to provide information to clinicians throughthe documentation they have got access to, according to an easily modifiable
number of lean rules, can be likened to the WOAD tenet to provide actors
with awareness information, especially with that information we have termed
“enabling” and “inquiring” awareness (see Section 5.2).
That notwithstanding, the original points in WOAD are (1) to have these
3Cf. the concept of disappearing computing [Weiser and Brown, 2005], as well as of ubiq-uitous and pervasive computing [Weiser, 1993].
220
8.2. CONFRONTING WOAD WITH SIMILAR APPROACHES
lean rules (i.e., what we called conventions) associated with documents and
their content besides that with the general characterization of the setting at
hand (i.e., context2); (2) to have these rules become part of the common
context of a particular setting; and then (3) to make rules executable across
distributed and autonomous inference engines according to some domain-
dependent rationale or the very situation at hand (i.e., transitors). Moreover,
while the CMS is aimed at rationalizing the access to the on-line clinical docu-
mentation by presenting practitioners with the “right” pages and sections they
should be concerned with in according to the context, the WOAD framework
is aimed at providing users with context-related information while they are
using the documentation on their own initiative and because of their current
and partly unfathomable information needs; such needs are considered by
WOAD solely on the basis of context-sensitive conventions on the use of arti-
facts and cooperative work in a given work setting and not as enactment of
any work-based document-routing.
Document-centered collaboration
More evident are the similarities between the WOAD framework and Place-less Document [Dourish et al., 2000a, Dourish et al., 2000b], the infrastruc-
ture that we take as representative of the approach that focusses on exten-
sibility and smooth integration with existing document management tools to
augment them with cooperation-oriented functionalities. The Placeless Docu-
ments project, based in the Computer Science Lab at PARC, has explored a new
approach to document management that aims to give documents the resources
to achieve application integrity and autonomous coordination functionalities:
accordingly, the researchers involved in such project have called the underly-
ing conceptual approach “document-centered collaboration” [LaMarca et al.,
1999]. As in WOAD, their approach is to focus on collaboration as a feature
of the document rather than of the application that manages them. Within
the placeless approach this means that all operations on a document, such as
reading, writing, moving, and deleting, can be executed by some active codeassociated with the document, which is called property. Properties character-
ize intrinsic features and control logic of documents independent of the place
it is stored (hence, the attribute Placeless). As in WOAD, the active code is
executed by a middleware layer that sits between ordinary applications and
existing document repositories such as file systems. As in WOAD, active prop-
221
CHAPTER 8. CONCLUSIVE REMARKS
erties can take appropriate action on the basis of context since the platform
makes documents “situationally aware” and be responsive to changes in their
use and in the context. Properties can either notify actors on the actions to
perform, perform the operation itself, or prohibit the operation.
This marks two important differences with our proposal: first, properties
have a local scope, i.e., they are applied to the content of the document to
which they are attached. WOAD conventions and more generally, mechanisms,
instead, leverage on the pattern matching capabilities of distributed transitors
and can hence be associated with the content entries of any document ren-
dered within the fact space. Active properties are intended to bring “workflow
logic to applications that work on documents, [so as to avoid to create] stand-
alone and monolithic applications to do workflow” [LaMarca et al., 1999].
Also WOAD mechanisms can change documental content and even inhibit
it from being changed by actors depending on how it is implemented the bondthat the define primitive creates between actual data and factual representa-
tion of the artifact. Moreover, convention-facts and corresponding mechanisms
can be as much prescriptive and constraining as the work setting conventions
they refer to are. Often, in the clinical work domain, we have seen conventions
whose prescriptive nature did not derive from a fully reconciled and agreed
practices among clinicians, but rather from precise and very strict Italian laws
which prescribe how records ought to be compiled and when. The trespassers
of such laws are prosecuted with the expulsion from the medical register and
with other serious penalties that are also inflicted to whom has failed to report
any violation of the law. In this very case, the advocates of the deployment of
“constraining” technology propose to see it as a preventive measure against
legal problems and law infringements rather than a tight rein on practition-
ers’ autonomy. The final evaluation on this delicate balance can not obviously
leave out of consideration the very requirements and demands of the domain
at hand.
The point then is not to consider if this functionality can be either feasibly
applied or useful, but rather if there is the real risk of falling in the serious
drawbacks pointed out within the CSCW literature in a number of contribu-
tions that cannot be neglected (e.g., [Grinter, 2000,van der Aalst and Jablon-
ski, 2000,Hayes, 2000]).
For these reasons, our framework is mostly aimed at providing awareness:although it is possible to automatically change documental content, we rather
222
8.3. POSSIBLE DIRECTIONS FOR FUTURE WORKS
propose to use L*WOAD for the provision of notifications4, i.e., awareness
information that could “hint” actors what to do and even explain them why5.
The case of activity inhibition is the clearest (see Section 5.2): for the reflective
nature of the fact space when some conditions would prevent some activity
from being executed, actors are just notified of it, but they can proceed the
same (although some justification should be explicitly requested depending on
the application domain). When actors change the content of some document
within that particular activity, the internal representation of the activity followstheir actions, rather than constraining them, and commutes to a state that is
consistent with the new state of the documental content (e.g., in execution6).
To summarize, Placeless documents is perhaps the closest related approach
to the WOAD framework, sharing with it the focus on documental artifacts,
coordination and content decoupling, context-awareness and active behaviors
associated to single documents and their content. The differences lie in the
different stress on awareness provision rather than in ‘workflow management’
and in the global sharing of documental content, so that local conventions
(in the sense of intra-document) and setting conventions (in the sense of per-
taining to the whole setting in which the documental system is deployed) can
be applied to any piece of content from different documents and any other
contextual information and react accordingly.
8.3 Possible directions for future works
We can envision the articulation of the next activities regarding the WOAD
framework along three main dimensions, summarizable as follows: (1) inten-
sive verification of the framework in the field and its generalization to cope
other application domains’ peculiarities; (2) application of the framework to
explicitly support standard and structured procedures (3) application of the
framework to the inter-organizational coordination domain.
• First of all, we need to get more evidences from the field of work that
4A possible exception to this requirement could be conceived for those trivial cases whenusers explicitly require ways to automatically cope with negative-redundancy and low-valuesecretarial practices (e.g., replicating administrative data)
5This is the case, for instance, in which the provision of inhibition awareness is coupled withthe indication that doing otherwise is against the law.
6The same holds whenever reaching a “consistent state of the work activities with the doc-umental activities” requires that an executing activity commutes into, e.g., the idle state andanother work-activity goes into the execution state without even passing by its formal enabling.
223
CHAPTER 8. CONCLUSIVE REMARKS
the WOAD model and language can be conveniently used to curtail the
burden of modeling a generic document-based cooperative setting, irre-
spective of the specific domain.
Even within the general domain of healthcare, we would need to get
a longer and more thorough evaluation of how effectively and ade-
quately local conventions regarding both articulation work and docu-
mental content use can be rendered in terms of WOAD convention-facts
and whether the strictly reactive model of condition-action mechanism
can adequately represent and follow the changes occurring within such
hectic and dynamic field of work.
It goes without saying that no model can be claimed to be able to en-
compass and properly manage any possible situation. The point indeed
is to understand whether — and to what extent — computational mech-
anisms based on an arbitrary symbolic representation of context, as ac-
tors and designers are able to externalize and formalize it into WOAD
constructs (cf. [Bannon, 1995]), can hinder the activities of the field of
work and jeopardize the effectiveness of the actors’ interventions, espe-
cially when they have to handle those exceptions that could not even be
defined in terms of symbolic constructs.
To this aim, the WOAD framework should be applied to a full-fledged
electronic clinical record that is routinely used by different practitioners
on a daily basis. Yet, the first big challenge regarding the proper and fea-
sible deployment of innovative IT applications in the healthcare domain
is to first understand the rationale of current healthcare practices, the
work culture in which they are structured in some transferable knowl-
edge, and the political policies they are subject to [Kensing, 2004]. In
Italy, where we live and work, the full deployment of integrated and,
mostly important, extensible and customizable clinical applications is still
very rare; real experimentations toward their deployment is still episodic
and very limited in time (e.g., [Ancona et al., 2000, Quaglini et al.,
2005]), not only for the obvious delicacy and sensitivity of the hospi-
tal care domain, but also for investment policies and political reasons
that make it difficult to foresee relevant developments and the direction
they will be steered towards.
Also for these reasons, we are planning to apply WOAD to a different
and purely administrative domain, like the domain of the institutional
224
8.3. POSSIBLE DIRECTIONS FOR FUTURE WORKS
and public management of the Italian university and research. Specif-
ically, we could detect the same multivoicedness [Hertzum, 1999] (see
Section 2.3) whose support is explicitly addressed by the WOAD frame-
work, in the very set of forms, manuals, circulars, memorandums and
other official documents which are used within a civil service depart-
ment in its ordinary business. A thick fabric of cross-references, emen-
dations, different versions and notes also makes this web of documental
artifacts pretty integrated and difficult to make fully sense and use of
in any situation. We are aware that the typical rigidities and demands
for formality and strictness of modern bureaucracies can pose signifi-
cant challenges to the application of a cooperation-aware layer on top
of legacy applications used in the civil service offices; that notwithstand-
ing, it is also true that these very applications usually pertain to the
domain of office automation where the deployment of innovative tools
can find in the clerical practitioners less reluctant adopters than people
that might even have never had a computer mouse in their hands (as in
the hospital ward case).
• With “explicit support to standard7 and structured procedures” we re-
fer to those cases in which particular documents are explicitly intended
to steer actions: two simple but pervasive examples from the clinical
everyday work are to-do lists — whenever they are mainly intended in
sequential order — and flow-charts — when they are intended as pre-
scriptive and schematic representation of a process, like in the case of
the graphical companions to clinical pathways (we define them next).
Notwithstanding and apart from the concerns that we have above men-
tioned about the limitations of workflow technology, we could indeed
experience a strong interest for the provision of inhibition and enablingawareness (see Section 5.2) during our observational studies at the
Neonatology Intensive Care Unit. At the end of our studies, in fact, the
NICU head physician proposed us to reflect with him and some other
interested colleagues about possible ways to integrate clinical pathwaysinto the clinical record; the same interest was also shared by the develop-
ers of the clinical record prototype for some evidences they could collect
that this kind of feature would be a distinctive plus for their electronic
7We use such attribute in the acceptation used in [Cabitza et al., 2006d], pertaining to“anything considered by either an authority or general consent as a basis of comparison”.
225
CHAPTER 8. CONCLUSIVE REMARKS
clinical record with respect to other competing solutions.
A clinical pathway can be considered a purposely schematic represen-
tation of some part of the overall care process to apply to a certain
illness trajectory and that pertains to some specific problem requiring
routinary solutions. The general and declared purpose of clinical path-
ways is to improve medical outcomes and quality of care by providing a
mechanism to coordinate care, reduce fragmentation and unmotivated
variability of intervention, and last but not least, cost [Pearson et al.,
1995, Panella et al., 2003, Berg et al., 2005]. Many contributions in the
specialist literature (e.g. [Ireson, 1997,Campbell et al., 1998,Ellershaw,
2002,Browne et al., 2001] consider the integration of standardized pro-
tocols into the clinical records, where work is both recorded and com-
missioned, as the mere enactment of “virtuous workflows”, which most
of the times are that simple that even simple flow-charts can represent
their steps, branches and synchronization points. The allegedly virtuos-
ity of the application of such protocols to clinical records consists in the
evidences that the above mentioned literature has been collecting in the
last ten years: such contributions report that the application of clinical
pathways to medical practice could result into less indulging in superflu-
ous and useless differentiations from standard medical practice, in the
significant reduction of the number of possible deviations from best prac-
tices (and their correlated negative consequences) and in the enabling
of clinical and epidemiological research for the introduced capability of
comparing outcomes and methods. Accordingly, applying clinical path-
ways is assimilated to applying evidence-based and up-to-date medical
knowledge to the illness trajectory of a patient in the only allegedly “vir-
tuous” way in which caring activities should follow each other, according
to the very progress of the trajectory at hand.
A future application of the WOAD framework could then be to investi-
gate whether the inclusion of such standard and allegedly virtuous flows
of care is compatible with the frantic, almost unpredictable and highly
dynamic real unfolding of an illness trajectory within the broader con-
text of all the other trajectories that are treated in the same facility in
the same period. Far from rehashing considerations about the most man-
ifest pitfalls related with rigid workflow enactment in highly dynamic
work arrangements, we could rather investigate the role of the WOAD
226
8.3. POSSIBLE DIRECTIONS FOR FUTURE WORKS
framework as a “learning device”8 for the sharing of medical “best prac-
tices” either embedded or related with the clinical pathway at hand. We
think that the awareness provision approach could be a feasible way
to smoothly pass from the “scripting” nature of the strict application of
a pathway to its educational value, when a pathway is used as a map
“flanking beside” the clinical practice and supporting it through the af-
fordances conveyed through the records where actual practice is docu-
mented. The point that could be further investigated could also regard
which kind of awareness information should be conveyed to make ex-
plicit the possible differences between “the theory and the practice” as
they occur in the field of work, and how to convey such information to
make actors aware of the possible ways such differences can be recon-
ciliated with the expected outcomes and with respect to the regardable
demands of accountability of the medical discipline.
• A third line of development would be applying WOAD to those cases in
which two or more documental systems end up by interacting as well as
the communities of their users.
We have treated elsewhere [Cabitza et al., 2006c] the case in which
patient trajectories must unfold across multiple wards and departments
within the same hospital as it can happen whenever a patient must be
referred to some specialist or must undertake some diagnostic exami-
nation that is provided by an external service unit (e.g., the radiology
ward). To limit our scope to artifact sharing and the exchange of the
correlated flows of information, inter-networks collaboration (see Sec-
tion 6.1.1) is usually achieved by putting some interface artifact [Cabitza
et al., 2006c] in common: a document — typically a pretty well struc-
tured form — that is shared by the care-cluster that provides the service
with the care-cluster that requests that service. Members of the “request-
ing” cluster are supposed to express their request into the terms either
reified in or referred by the interface artifact since only doing so mem-
bers of the “providing” cluster can understand what they mean, have a
clear picture of the patient and her needs, and provide the requested
service as expected. The interface artifact can be seen as a sort of “bridg-
ing” document between two different webs of documents, which our
point would be to enable as “carrier of” and “facilitator of sharing” the8Cf. [Mark, 2002] and Chapter 3
227
CHAPTER 8. CONCLUSIVE REMARKS
proper conventions of documental use among members of different clus-
ters/communities of practice.
The future widening and intensification of such line of research would
place itself within an increasing interest in the organization of health-
care work along individual patient cases rather than along the demar-
cation lines of healthcare organizations. This increasing interest arises
as a consequence of the need to distribute care over larger networks of
services and care providers that are located in different settings and that
are no longer centralized within the same all-inclusive facility such as
the hospital. This need is caused by two important current trends: the
increasing aging of world population and, quite surprisingly, the vertigi-
nous advance of medical science. The fact that people tend to live longer
compared to earlier ages is the main affecting factor in the increasing of
the chronicity of health problems; and, in its turn, the ever-growing spe-
cialization of medical branches leads to a number of very specific treat-
ments or monitoring practices that require investments that few facilities
can easily concentrate in the same location.
In order to address from the CSCW perspective the matter of how
clinical records could support inter-organizational communication and
coordination as well as they do within the in-ward dimension, some
recent studies have, for instance, focussed on the discharge letter(e.g., [Dougherty, 1999, Winthereik and Vikkelso, 2005]). On the one
hand, this last part of the regular clinical record is seen as the docu-
ment that mediates communication — beyond the mere administrative
accounting — between the discharged patient and the professionals that
had her in charge. On the other hand, it is also seen as the tool that me-
diates coordination — in terms of handing over — between the hospital
— a secondary sector facility — with other primary or tertiary facilities,
i.e., the general practitioner and the specialist, respectively, in all those
cases in which a patient must be followed up. Yet in this case, usually cor-
respondent entities are simpler than hospital facilities in their internal
structure and hence can eventually not encompass complex and com-
posite documental systems that need to integrate with each other and
overlap into the discharge letter.
The need for achieving semantic interoperability and maintain a seam-
less articulation across multiple organizations is a precise requirement
228
8.3. POSSIBLE DIRECTIONS FOR FUTURE WORKS
of the so-called domain of integrated care or shared care [Hampson et al.,
1996]. The expression “shared care” refers to the sharing of responsibil-
ities that is related to the provision of healthcare services by profession-
als or teams from different organizations, “or where substantial orga-nizational boundaries exist” [Pritchard and Hughes, 1995], and that is
aimed at reaching significant improvements in the quality of care and
life of all the stakeholders involved (especially, the care beneficiaries).
Since shared care necessarily involves information sharing about illness
trajectories that unfold over time and across organizational and pro-
fessional boundaries, the most crucial aspect to successful shared care
programs relies on achieving and maintaining a good functional and
semantic interoperability between all the care-clusters involved: an ob-
jective that recent research is showing as a long-term and non-linear
process [Mur-Veeman et al., 2001] and that the CSCW community has
always assimilated to overcoming the “knowledge boundaries” [Carlile,
2002].
Our research on the externalization and exploitation of conventions per-
taining to documental use can hence contribute in shedding some light
on which requirements to collect and how to substantialize them into
a feasible and adequate software platform aimed at maintaining and
enhancing the coordinative and informational values of documental re-
sources that end up by being shared between heterogeneous and dis-
tributed organizations. The work agenda would then concentrate on
having these sets of “bridging” documental artifacts (cf. [Rolland et al.,
2006]) better mediate such “boundary crossing” and actively limit the
related “ontological drift” (cf. [Robinson and Bannon, 1991]) occurring
when artifacts move or are used between semantic communities.
229
Appendix A
The NICU survey questions
• Score Key
– Frequency of use
-2 Never (occasionally, almost exceptionally)
-1 Sometimes (one or twice each work shift)
0 No opinion / No comment
+1 Often (one or twice each hour)
+2 Always (quite frequently each hour)
– Usefulness / efficaciousness
-2 Poor
-1 Quite low
0 No opinion / No comment
+1 Useful
+2 Fundamental
• Questions
1. What is your institutional role/job at the NICU?
– Senior Doctor
– Doctor
– Senior Nurse
– Nurse
– Assistant
– Student/Trainee
– Other
231
APPENDIX A. THE NICU SURVEY QUESTIONS
2. As regards the caring process within the NICU, would you please characterizethe following modalities by which you get useful information with respect tocare, in terms of frequency of use and usefulness/efficaciousness.
(a) Conversations with nurses (either senior or not) during the morninground.
(b) Conversations with senior nurses during the work shift (exceptround).
(c) Conversations with junior nurse during the work shift (except theround).
(d) Conversations with the doctors on-duty during the morning round.
(e) Conversations with the doctors on-duty (except the round)
(f) Conversations with the senior doctors on-duty (except the round)
(g) Conversations with the doctors (either senior or not) that are goingoff-duty (handing over time)
(h) Conversations with specialist consultants.
(a) Consultation of the Single Infusional Therapy Sheet
(b) Consultation of the Single Pharmacological Therapy Form
(c) Consultation of the Single Working Sheet
(d) Consultation of the Summary Sheet
(e) Consultation of the Physicians’ Notes (and Problem List)
(f) Consultation of the Preliminary Objective Examination and First CarePlanning sheets
(g) Consultation of the Nursing Notes
(h) Consultation of the medical reports
3. As regards the caring process within the NICU, would you please characterizehow often you compile (or just sign) the following documents, with respectto direct support to caring.
(a) Single Infusional Therapy Sheet
(b) Single Caring Procedures Sheet
(c) Single Laboratory Examinations Form
(d) Single Diagnostic-Therapeutic Procedures Form
(e) Single Pharmacological Therapy Form
(f) Single Working Sheet
(g) Summary Sheet
(h) Physicians’ Notes (including Problem List)
(i) Nursing Notes (including Need List)
232
Bibliography
[Aalst et al., 2003] Aalst, W. M. P. V. D., Hofstede, A. H. M. T., Kiepuszewski,
B., and Barros, A. P. (2003). Workflow patterns. Distrib. Parallel Databases,14(1):5–51.
[Aarts et al., 2002] Aarts, E., Harwig, R., and Schuurmans, M. (2002). Ambi-
ent intelligence. The invisible future: the seamless integration of technologyinto everyday life, pages 235–250.
[Aarts and Berg, 2004] Aarts, J. and Berg, M. (2004). Understanding imple-
mentation: The case of a computerized physician order entry system in a
large dutch university medical center. Journal of the American Medical In-formatics Association, 11:207–216.
[Acharya, 1996] Acharya, A. (1996). Eliminating redundant barrier synchro-
nizations in rule-based programs. In Proceedings of the 10th internationalconference on Supercomputing, pages 325–332. ACM Press.
[Akkiraju et al., 2005] Akkiraju, R., Farrell, J., J.Miller, Nagarajan, M.,
Schmidt, M., Sheth, A., and Verma, K. (2005). Web service semantics -
wsdl-s. Technical report, A joint UGA-IBM Technical Note.
[Alberdi et al., 2001] Alberdi, E., Becher, J., Gilhooly, K., and Hunter, J.
(2001). Expertise and the interpretation of computerized physiological
data: implications for the design of computerized monitoring in neonatal
intensive care. International Journal of Human-Computer Studies, 55:191–
216.
[Allen, 1984] Allen, J. F. (1984). Towards a general theory of action and time.
Artificial Intelligence, 23:123–154.
[Amigoni and Somalvico, 1998] Amigoni, F. and Somalvico, M. (1998). Dy-
namic agencies and multi-robot systems. In Lueth, T., Dillmann, R., Dario,
233
BIBLIOGRAPHY
P., and Worn, H., editors, Proceedings of the 4th International Symposium onDistributed Autonomous Robotic Systems, pages 215–224, Karlsruhe, Ger-
many. Springer-Verlag.
[Amigoni et al., 1999] Amigoni, F., Somalvico, M., and Zanisi, D. (1999). A
theoretical framework for the conception of agency. International Journalof Intelligent Systems, 14(5):449–474.
[Ancona et al., 2000] Ancona, M., Dodero, G., Gianuzzi, V., Minuto, F., and
Guida, M. (2000). Mobile computing in a hospital: the WARD-IN-HAND
project. In ACM SAC 2000, Como, Italy. ACM Press.
[Andersen et al., 1990] Andersen, N. E., Kensing, F., Lundin, J., Mathiassen,
L., Munk-Madsen, A., Rasbech, M., and Sørgaard, P. (1990). ProfessionalSystems Development — Experience, Ideas, and Action. Prentice-Hall, Engle-
wood Cliffs, New Jersey, USA.
[Anderson and Aydin, 1997] Anderson, J. and Aydin, C. (1997). Evaluating
the impact of health care information systems. Intern. J. Tech. ssess. inHealth Care, 13(2):380–393.
[Apt and Bol, 1994] Apt, K. and Bol, R. (1994). Logic programming and
negation: a survey. Technical report, Centrum voor Wiskunde en Infor-
matica (SMC) Netherlands.
[Ark and Selker, 1999] Ark, W. and Selker, T. (1999). A look at human in-
teraction with pervasive computers. IBM Systems Journal special HCI issuewith a focus on Pervasive Computing, 38(4):504–507.
[Ash et al., 2004] Ash, J. S., Berg, M., and Coiera, E. (2004). Some unin-
tended consequences of information technology in health care: The nature
of patient care information system-related errors. Journal of the AmericanMedical Informatics Association, 11:104–112.
[Atkinson, 1995] Atkinson, P. (1995). Medical talk and medical work. Sage
Publications.
[Avgerou et al., 2004] Avgerou, C., Ciborra, C., and Land, F., editors (2004).
The Social Study of Information and Communication Study. Oxford Univer-
sity Press.
234
BIBLIOGRAPHY
[Axelrod, 1997] Axelrod, R. (1997). The Complexity of Cooperation, chapter
Evolving New Strategies. Princeton University Press.
[Bandini et al., 2003] Bandini, S., Colombo, E., Colombo, G., Sartori, F., and
Simone, C. (2003). The role of knowledge artifacts in innovation manage-
ment: the case of a chemical compound designer cop. Communities andtechnologies, pages 327–345.
[Bandini et al., 2002] Bandini, S., Manzoni, S., and Simone, C. (2002). Deal-
ing with space in multi–agent systems: a model for situated mas. In AAMAS’02: Proceedings of the first international joint conference on Autonomousagents and multiagent systems, pages 1183–1190. ACM Press.
[Bang et al., 2003] Bang, M., Larsson, A., and Eriksson, H. (2003). NOSTOS:
A Paper-Based Ubiquitous Computing Healthcare Environment to Support
Data Capture and Collaboration. In 2003 AMIA Annual Symposium, pages
46–50, Washington DC.
[Bannon, 2000] Bannon, L. (2000). Understanding common information
spaces in CSCW. paper presented at the workshop on cooperative organisa-
tion of common information spaces. Technical report, Technical University
of Denmark. Available at http://dmm.cti.dtu.dk/position/bannon.pdf.
[Bannon and Bødker, 1997] Bannon, L. and Bødker, S. (1997). Constructing
Common Information Space. In Proceedings of the Fifth European Coop-erative Supported Cooperative Work, pages 81–96, Lancaster (UK). Kluwer
Academic Publishers, Netherlands.
[Bannon, 1993] Bannon, L. J. (1993). CSCW: An initial exploration. Scandi-navian Journal of Information Systems, 5:3–24.
[Bannon, 1995] Bannon, L. J. (1995). The politics of design – representing
work. Communications of the ACM, 38(9).
[Bannon and Schmidt, 1991] Bannon, L. J. and Schmidt, K. (1991). CSCW:
four characters in search of a context. Studies in computer supported coop-erative work: theory, practice and design, pages 3–16.
[Bardram and Bossen, 2005a] Bardram, J. and Bossen, C. (2005a). Mobil-
ity work: The spatial dimension of collaboration at a hospital. ComputerSupported Cooperative Work, 14(2):131–160.
235
BIBLIOGRAPHY
[Bardram, 2000] Bardram, J. E. (2000). Temporal coordination: On time
and coordination of collaborative activities at a surgical department. Com-puter Supported Cooperative Work, The Journal of Collaborative Computing,
9(2):157–187.
[Bardram, 2004] Bardram, J. E. (2004). Applications of context-aware com-
puting in hospital work: examples and design principles. In SAC ’04: Pro-ceedings of the 2004 ACM symposium on Applied computing, pages 1574–
1579, New York, NY, USA. ACM Press.
[Bardram and Bossen, 2004] Bardram, J. E. and Bossen, C. (2004). Inter-
woven Artifacts – Coordinating Distributed Collaboration in Medical Care.
Technical report, Centre for Pervasive Computing, Arhus, DENMARK.
[Bardram and Bossen, 2005b] Bardram, J. E. and Bossen, C. (2005b). A web
of coordinative artifacts: collaborative work at a hospital ward. In GROUP’05: Proceedings of the 2005 international ACM SIGGROUP conference onSupporting group work, pages 168–176, New York, NY, USA. ACM Press.
[Bardram et al., 2003] Bardram, J. E., Kjaer, K., and Nielsen, C. (2003).
Context-Aware User Authentication - Supporting Proximity-Based Login in
Pervasive Computing. In Ubicomp 2003: Proceedings of the InternationalConference on Ubiquitous Computing, pages 107–123, Seattle, WA. Springer
Verlag.
[Batini et al., 1992] Batini, C., Ceri, S., and Navathe, S. B. (1992). Concep-tual database design: an Entity-relationship approach. Benjamin-Cummings
Publishing Co., Inc., Redwood City, CA, USA.
[Benerecetti et al., 2001] Benerecetti, M., Bouquet, P., and Bonifacio, M.
[Benford et al., 1994] Benford, S. D., Bowers, J. M., Fahlen, L. E., and Green-
halgh, C. (1994). Managing mutual awareness in collaborative virtual en-
vironments. In Singh, G., Feiner, S., and Thalmann, D., editors, VRST’94:Proceedings of the ACM SIGCHI Conference on Virtual Reality and Technology,
pages 223–236, Singapore. ACM Press, NY, USA.
[Beniger, 1986] Beniger, J. R. (1986). The Control Revolution: Technologicaland Economic Origins of the Information Society. Harvard University Press.
236
BIBLIOGRAPHY
[Benson, 2002] Benson, T. (2002). Why general practitioners use computers
and hospital doctors do not—part 1: Incentives. British Medical Journal,9(325):1086–1089.
[Berg, 1998] Berg, M. (1998). Medical work and the computer-based pa-
tient record: A sociological perspective. Methods of Information in Medicine,
37(294-301).
[Berg, 1999] Berg, M. (1999). Accumulating and Coordinating: Occasions for
Information Technologies in Medical Work. Computer Supported Coopera-tive Work, The Journal of Collaborative Computing, 8(4):373–401.
[Berg, 2003] Berg, M. (2003). Health Information Management. Routledge.
[Berg and Goorman, 1999] Berg, M. and Goorman, E. (1999). The contextual
nature of medical information. International Journal of Medical Informatics,56:51–60.
[Berg et al., 2005] Berg, M., Schellekens, W., and Bergen, C. (2005). Bridging
the quality chasm: integrating professional and organizational approaches
to quality. International Journal for Quality in Health Care, 17(1):75–82.
[Berry and Goulde, 1994] Berry, M. and Goulde, M. (1994). A new view of
documents. integrated information management in the ´90s. WorkgroupComputing Report, 17(8).
[Bertelsen and Bødker, 2001] Bertelsen, O. and Bødker, S. (2001). Coopera-
tion in massively distributed information space. In ECSCW´2001: Proceed-ings of the Seventh European Conference on Computer Supported CooperativeWork, pages 1–17. Kluwer.
[Beuscart-Zephir et al., 2005] Beuscart-Zephir, M. C., Pelayo, S., Anceaux, F.,
Meaux, J.-J., Degroisse, M., and Degoulet, P. (2005). Impact of cpoe on
doctor-nurse cooperation for the medication ordering and administration
process. International Journal of Medical Informatics, 74:629–641.
[Biegel and Cahill, 2004] Biegel, G. and Cahill, V. (2004). A framework for
developing mobile, context-aware applications. In Percom 2004: Proceed-ings of the 2nd IEEE Conference on Pervasive Computing and Communica-tions.
237
BIBLIOGRAPHY
[Bikson and Frinking, 1993] Bikson, T. K. and Frinking, E. J. (1993). Preserv-ing the present: toward viable electronic records. den Haag: Sdu Publishers.
[Blumberg and Atre, 2003] Blumberg, R. and Atre, S. (2003). The problem
with unstructured data. DM Review Magazine.
[Bang and Timpka, 2003] Bang, M. and Timpka, T. (2003). Cognitive tools in
medical teamwork: The spatial arrangement of patient records. Methods ofInformation in Medicine, 42:331–336.
[Bock and Gruninger, 2004] Bock, C. and Gruninger, M. (2004). Psl: A se-
mantic domain for flow models. Software and Systems Modeling Journal.
[Boland et al., 1992] Boland, R., Schwartz, D., and Tenkasi, R. (1992). Shar-
ing perspectives in distributed decision making. In CSCW ‘92: Proceedingsof the International Conference on Computer Supported Cooperative Work,
pages 306–313, Toronto, Canada. ACM Press.
[Boselli et al., 2005] Boselli, R., Cabitza, F., Paoli, F. D., and Loregian, M.
(2005). An adaptive middleware to support context-aware knowledge
sharing. In ICDCS Workshops, pages 352–358.
[Bossen, 2002] Bossen, C. (2002). The parameters of common information
spaces: the heterogeneity of cooperative work at a hospital ward. In
CSCW’02: Proceedings of the International Conference on Computer Sup-ported Cooperative Work,, New Orleans Louisiana USA. ACM Press.
[Bourdieu, 1977] Bourdieu, P. (1977). Outline of a Theory of Practice. Cam-
bridge University Press, Cambridge, MA, USA.
[Bowers et al., 1995] Bowers, J., Button, G., and Sharrock, W. (1995). Work-
flow from within and without: Technology and cooperative work on the
print industry shopfloor. In ECSCW’95: Proceedings of the Fourth EuropeanConference on Computer-Supported Cooperative Work, pages 51–66. Kluwer
Academic Publishers.
[Bowker et al., 1997] Bowker, G., Star, S. L., Turner, W., and Gasser, L. (1997).
Social Science, Technical Systems and Cooperative Work-Beyond the GreatDivide. Lawrence Erlbaum Associates, Publishers.
238
BIBLIOGRAPHY
[Braa and Sandahl, 2000] Braa, K. and Sandahl, T. (2000). Introducing dig-
ital documents in work practices - challenges and perspectives. Group De-cision And Negotiation, 9(3):189–203. Publisher Kluwer Academic Nether-
lands Isbn Issn 0926-2644.
[Braa and Sandahl, 1998] Braa, K. and Sandahl, T. I. (1998). Informationand Process Integration in Enterprises. Rethinking Documents, chapter Ap-
proaches to Standardization of Documents. Kluwer Academic Publishers.
[Brehmer, 1991] Brehmer, B. (1991). Distributed Decision Making: CognitiveModels in Cooperative Work, chapter Distributed Decision Making: Some
Notes on the Literature. Blackwell, NY: John Wiley.
[Brooks, 1991] Brooks, R. A. (1991). Intelligence without representation. Ar-tificial Intelligence, 47:139–159.
[Brown and Duguid, 1991] Brown, J. and Duguid, P. (1991). Organizational
learning and communities of practice: Towards a unifiedview of working,
learning, and innovation. Organization Science, 2:40–57.
[Brown and Duguid, 1994] Brown, J. S. and Duguid, P. (1994). Borderline
issues: Social and material aspects of design. Human-Computer Interaction,
9:3–36.
[Brown et al., 2004] Brown, P., Borowitz, S., and Novicoff, W. (2004). Infor-
mation exchange in the nicu: what sources of patient data do physicians
prefer to use? International Journal of Medical Informatics, 73(4):349–55.
[Browne et al., 2001] Browne, G. J., Giles, H., Mccaskill, M. E., Fasher, B. J.,
and Lam, L. T. (2001). The benefits of using clinical pathways for managing
acute paediatric illness in an emergency department. Journal of Quality inClinical Practice, 21(3):50.
[Buckland, 1991a] Buckland, M. (1991a). Information as thing. Journal ofthe American Society of Information Science, 42(5):351–360.
[Buckland, 1991b] Buckland, M. (1991b). Information retrieval of more than
text. Journal of the American Society for Information Science, 42:586–588.
[Buckland, 1997] Buckland, M. (1997). What is a “document”? Journal ofthe American Society of Information Science, 48(9):804–809.
239
BIBLIOGRAPHY
[Buneman and Steedman, 2002] Buneman, P. and Steedman, M. (2002). An-
notation – the new medium of communication. In UKCRC Grand Challengeworkshop, Edinburgh, UK.
[Cabitza and Dal Seno, 2005] Cabitza, F. and Dal Seno, B. (2005). Djess — a
knowledge-sharing middleware to deploy distributed inference systems. In
Proceedings of ENFORMATIKA’05 Joint Conferences, Istanbul, Turkey.
[Cabitza et al., 2005a] Cabitza, F., Dal Seno, B., Sarini, M., and Simone, C.
(2005a). Being at one with things: The interconnection metaphor for in-
telligent environments. In Proceedings of the IEE International Workshop onIntelligent Environments, Colchester, UK.
[Cabitza et al., 2006a] Cabitza, F., Locatelli, M., Sarini, M., and Simone, C.
(2006a). CASMAS: Supporting collaboration in pervasive environments.
In PerCom2006: Proceedings of the Fourth Annual IEEE International Confer-ence on Pervasive Computing and Communications, Pisa, Italy. IEEE.
[Cabitza et al., 2006b] Cabitza, F., Locatelli, M. P., and Simone, C. (2006b).
Cooperation and ubiquitous computing: an architecture towards their inte-
gration. In Hassanaly, P., Herrmann, T., Kunau, G., and Zacklad, M., editors,
Cooperative Systems Design - Seamless Integration of Artifacts and Conversa-tions – Enhanced Concepts of Infrastructure for Communication, pages 86–
101. IOS Press. ISBN 1-58603-604-1.
[Cabitza et al., 2004] Cabitza, F., Loregian, M., and Sarini, M. (2004). Sup-
porting wards with interactive resources and logic-based systems. In Ubi-health2004: Proceedings of the 3rd international workshop on ubiquitouscomputing for pervasive healthcare applications, Nottingham, UK.
[Cabitza et al., 2005b] Cabitza, F., Sarini, M., Simone, C., and Telaro, M.
(2005b). When once is not enough: The role of redundancy in a hospi-
tal ward setting. In Group’05: Proceedings of the International Conference,Sanibel Island, Florida, U.S.A. ACM.
[Cabitza et al., 2006c] Cabitza, F., Sarini, M., Simone, C., and Telaro, M.
(2006c). Torres, a conceptual framework for articulation work across
boundaries. In COOP’06: Proceedings of the 7th International Conferenceon the Design of Cooperative Systems, France, Provence.
240
BIBLIOGRAPHY
[Cabitza et al., 2006d] Cabitza, F., Sarini, M., and Viscusi, G. (2006d). Let a
standard be standard: reminding people of deviations from standards. In
COOP’06: Proceedings of the 7th International Conference on the Design ofCooperative systems (short paper session), Provence, F.
[Cabitza et al., 2005c] Cabitza, F., Seno, B. D., and Sarini, M. (2005c). Djess
– a context-sharing middleware to deploy distributed inference systems in
pervasive computing domains. In ICPS’05: Proceedings of the IEEE Interna-tional Conference on Pervasive Services 2005, Santorini, Greece.
[Cabitza and Simone, 2006] Cabitza, F. and Simone, C. (2006). “You Taste
Its Quality”: Making sense of quality standards on situated artifacts. In
MCIS’06: Proceedings of the First Mediterranean Conference on InformationSystems, Venice, Italy, EU.
[Cabral et al., 2004] Cabral, L., Domingue, J., Motta, E., Payne, T., and
Hakimpour, F. (2004). Approaches to semantic web services: An overview
and comparisons. In ESWS2004: Proceedings of the First European SemanticWeb Symposium, Heraklion, Greece, EU.
[Campbell et al., 1999] Campbell, A. T., Coulson, G., and Kounavis, M. E.
(1999). Managing complexity: Middleware explained. IT Professional,1(5):22–28.
[Campbell et al., 1998] Campbell, H., Hotchkiss, R., Bradshaw, N., and Por-
teous, M. (1998). Integrated care pathways. British Medical Journal,316(10):133–137.
[Cantarelli, 1996] Cantarelli, M. (1996). Il modello delle prestazioni infer-mieristiche. Masson.
[Carlile, 2002] Carlile, P. (2002). A pragmatic view of knowledge and bound-
aries: boundary objects in new product development. Organization Science,
13(4):442–455.
[Carriero and Gelernter, 1989] Carriero, N. and Gelernter, D. (1989). Linda
in context. Communications of the ACM, 32(4):444–458.
[Carstensen and Schmidt, 1999] Carstensen, P. and Schmidt, K. (1999).
Handbook of human factors, chapter Computer supported cooperative
241
BIBLIOGRAPHY
work: New challenges to systems design, pages 619–636. Asakura Pub-
lishing, Tokyo, JP. (English version).
[Cengeloglu et al., 1994] Cengeloglu, Y., Khajenoori, S., and Linton, D.
(1994). DynaCLIPS: A dynamic knowledge exchange tool for intelligent
agents. In Proceedings of the Third CLIPS Conference at NASA Johnson SpaceCenter, Houston, TX, USA, September.
[Charalambos et al., 1995] Charalambos, I., Benbasat, I., and Dexter, A. S.
(1995). Electronic data interchange and small organizations: Adoption
and impact of technology. MIS Quarterly, 19(4):465–485.
[Chen and Rada, 1996] Chen, C. and Rada, R. (1996). Modelling situated
actions in collaborative hypertext databases. Journal of Computer Mediated-Communication, 2(3).
[Chen and Kotz, 2000] Chen, G. and Kotz, D. (2000). A survey of context-
aware mobile computing research. Technical Report TR2000-381, Dept. of
Computer Science, Dartmouth College.
[Ciborra, 1985] Ciborra, C. (1985). Reframing the role of computers in orga-
nizations: The transaction costs approach. In Proceedings of Sixth Interna-tional Conference on Information Systems, pages 16–18, Indianapolis, USA.
[Clement and Wagner, 1995] Clement, A. and Wagner, I. (1995). Fragmented
exchange: Disarticulation and the need for regionalized communication
spaces. In ECSCW’05: Fourth European Conference on Computer SupportedCooperative Work, pages 33–49, Stockholm, Sweden.
[Coiera, 2000] Coiera, E. (2000). When Conversation is better than computa-
tion. Journal of American Medical Informatics Association (JAMIA), 7:277–
286.
[Coiera, 2002] Coiera, E. (2002). Communication loads on clinical staff. TheMedical Journal of Australia, 176(9):415–418.
[Coiera and Tombs, 1998] Coiera, E. and Tombs, V. (1998). Communication
behaviours in a hospital setting - an observational study. British MedicalJournal, 316:673–677.
[Corkill, 1991] Corkill, D. D. (1991). Blackboard systems. AI Expert, 6(9):40–
47.
242
BIBLIOGRAPHY
[Crowston, 1994] Crowston, K. (1994). A taxonomy of organizational de-
pendencies and coordination mechanisms (working paper no. 3718-94).
Technical report, Massachusetts Institute of Technology, Sloan School of
Management.
[Crowston, 2003] Crowston, K. (2003). The Process Handbook, chapter A
taxonomy of organizational dependencies and coordination mechanisms,
pages 85–108. MIT Press, Cambridge, USA.
[Dan R. Olsen et al., 1998] Dan R. Olsen, J., Hudson, S. E., Phelps, M.,
Heiner, J., and Verratti, T. (1998). Ubiquitous collaboration via surface
representations. In CSCW ’98: Proceedings of the 1998 ACM conference onComputer supported cooperative work, pages 129–138, New York, NY, USA.
ACM Press.
[de Farias et al., 2000] de Farias, G., Ferreira, C., and van Sinderen, P. (2000).
A conceptual model for the development of cscw systems. In COOP2000:Proceedings of the Fourth International Conference on the Design of Coopera-tive Systems.
[Dey, 2001] Dey, A. K. (2001). Understanding and using context. PersonalUbiquitous Comput., 5(1):4–7.
[Dey et al., 2001] Dey, A. K., Salber, D., and Abowd, G. D. (2001). A con-
ceptual framework and a toolkit for supporting the rapid prototyping of
[Dick et al., 1997] Dick, R. S., Steen, E. B., and Detmer, D. E., editors (1997).
The Computer-Based Patient Record: An Essential Technology for Health Care,Revised Edition. National Academy Press.
[Divitini and Simone, 2000] Divitini, M. and Simone, C. (2000). Supporting
different dimensions of workflow adaptability. Computer Supported Coop-erative Work, The Journal of Collaborative Computing, 9(3):365–397.
[Divitini et al., 1996] Divitini, M., Simone, C., and Schmidt, K. (1996).
ABACO: Coordination mechanisms in a multi-agent perspective. In
COOP’96: Proceedings of the 2nd International Conference on the Design ofCooperative Systems, pages 103–122, Juan-les-Pins, France. INRIA Press.
243
BIBLIOGRAPHY
[Dix, 1997] Dix, A. (1997). Challenges for cooperative work on the web: An
analytical approach. Computer-Supported Cooperative Work: The Journal ofCollaborative Computing, 6:135–156.
[Dix et al., 1993] Dix, A., Finlay, J., Abowd, G., and Bealle, R. (1993).
Human-Computer Interaction. Prentice Hall.
[Dobres, 2000] Dobres, M. A. (2000). Technology and social agency : outlininga practice framework for archaeology. Blackwell Publishers, Oxford, UK.
[Dolin et al., 2006] Dolin, R. H., Alschuler, L., Boyer, S., Beebe, C., Behlen,
F. M., Biron, P. V., and Shabo, A. (2006). Hl7 clinical document architecture,
release 2. Journal of the American Medical Informatics Association, 13:30–
39.
[Dougherty, 1999] Dougherty, G. (1999). Conventional, dictated versus
database-generated discharge summaries: Timeliness, quality and com-
pleteness. Canadian Medical Association, 160(3):345–346.
[Dourish and Bellotti, 1992] Dourish, P. and Bellotti, V. (1992). Awareness
and coordination in shared workspaces. In CSCW’92: Proceedings of the1992 ACM conference on Computer-supported cooperative work, pages 107–
114, New York, NY, USA. ACM Press.
[Dourish and Bly, 1992] Dourish, P. and Bly, S. (1992). Portholes: support-
ing awareness in a distributed work group. In CHI ’92: Proceedings of theSIGCHI conference on Human factors in computing systems, pages 541–547,
New York, NY, USA. ACM Press.
[Dourish et al., 2000a] Dourish, P., Edwards, W. K., Howell, J., LaMarca, A.,
Lamping, J., Petersen, K., Salisbury, M., Terry, D., and Thornton, J. (2000a).
A programming model for active documents. In UIST2000: Proceedings ofthe ACM Symposium on User Interface Software and Technology, San Diego,
USA.
[Dourish et al., 2000b] Dourish, P., Edwards, W. K., LaMarca, A., Lamping, J.,
Petersen, K., Salisbury, M., Terry, D. B., and Thornton, J. (2000b). Ex-
tending document management systems with user-specific active proper-
ties. ACM Transactions on Information Systems, 18(2):140–170.
244
BIBLIOGRAPHY
[Dreyfus, 1978] Dreyfus, H. L. (1978). What Computers Can’t Do: The Limitsof Artificial Intelligence. Harpercollins.
[Edmunds and Morris, 2000] Edmunds, A. and Morris, A. (2000). The prob-
lem of information overload in business organisations: a review of the lit-
erature. International Journal of Information Management, 20(1):17–28.
[Eiter et al., 2004] Eiter, T., Faber, W., Leone, N., Pfeifer, G., and Polleres,
A. (2004). A logic programming approach to knowledge-state planning:
Semantics and complexity. ACM Transactions on Computational Logic,5(2):206–263.
[Ellershaw, 2002] Ellershaw, J. (2002). Clinical pathways for care of the dy-
ing: An innovation to disseminate clinical excellence. Journal of PalliativeMedicine, 5(4):617 –621.
[Ellingsen and Monteiro, 2003] Ellingsen, G. and Monteiro, E. (2003). A
patchwork planet integration and cooperation in hospitals. ComputerSupported Cooperative Work, The Journal of Collaborative Computing,
12(1):71–95.
[Elliott and King, 2005] Elliott, M. S. and King, J. L. (2005). A common in-
formation space in criminal courts: Computer-supported cooperative work
(cscw) case management systems. In HICSS ’05: Proceedings of the Proceed-ings of the 38th Annual Hawaii International Conference on System Sciences(HICSS’05) - Track 8, page 272.1, Washington, DC, USA. IEEE Computer
Society.
[Engesmo and Tjora, 2006] Engesmo, J. and Tjora, A. (2006). Documenting
for whom? a symbolic interactionist analysis of technologically induced
changes of nursing handovers. New Technology, Work and Employment,21(2):176–189.
[Ferber, 1999] Ferber, J. (1999). Multi-Agent Systems: An Introduction to Dis-tributed Artificial Intelligence. Addison-Wesley Longman Publishing Co.,
Inc., Boston, MA, USA.
[Ferber and Mueller, 1996] Ferber, J. and Mueller, J.-P. (1996). Influences and
reaction: a model of situated multiagent systems. In ICMAS’96: Proceedingsof International Conference on Multi-Agent Systems.
245
BIBLIOGRAPHY
[Fikes and N.J.Nilsson, 1971] Fikes, R. and N.J.Nilsson (1971). Strips: A new
approach to the application of theorem proving to problem solving. Artifi-cial Intelligence, 3-4(2):189–208.
[Fischer et al., 2003] Fischer, S., Stewart, T. E., Mehta, S., Wax, R., and Lapin-
sky, S. E. (2003). Handheld computing in medicine. Journal of the AmericanMedical Informatics Association, 10:139–149.
[Fitzpatrick, 2004] Fitzpatrick, G. (2004). Integrated care and the working
record. Health Informatics Journal, 10(4):291–302.
[Fitzpatrick et al., 1995] Fitzpatrick, G., Tolone, W., and Kaplan, S. (1995).
Work, locales and distributed social worlds. In ECSCW ’95: Proceedings ofthe 1995 European Conference on Computer Supported Cooperative Work,
pages 1–16.
[Fitzpatrick and Boulton, 1994] Fitzpatrick, R. and Boulton, M. (1994).
Qualitative methods for assessing health care. Quality in Health Care,
3(2):107–113.
[Fjeld et al., 2002] Fjeld, M., Lauche, K., Bichsel, M., Voorhorst, F., Krueger,
H., and Rauterberg, M. (2002). Physical and virtual tools: Activitytheory
applied to the design of groupware. Computer Supported Cooperative Work,The Journal of Collaborative Computing, 11(1-2):153–180.
[Frank M. Shipman and Marshall, 1999] Frank M. Shipman, I. and Marshall,
C. C. (1999). Formality considered harmful: Experiences, emergingthemes,
and directions on the use of formal representations ininteractive systems.
Computer Supported Cooperative Work, The Journal of Collaborative Com-puting, 8(4):333–352.
[Friedman-Hill, 2003] Friedman-Hill, E. (2003). Jess in Action – Java Rule-based Systems. Manning Publications Co.
[Fuentes et al., 2004] Fuentes, L., Jimenez, D., and Pinto, M. (2004). To-
wards the development of ambient intelligence environments using aspect-
oriented techniques. In Workshop at AOSD’04, The International Conferenceon Aspect-Oriented Software Development, Lancaster UK.
[Fuggetta et al., 1998] Fuggetta, A., Picco, G. P., and Vigna, G. (1998). Un-
derstanding code mobility. IEEE Transactions on Software Engineering,
24(5):342–361.
246
BIBLIOGRAPHY
[Fussell et al., 1998] Fussell, S. R., Kraut, R. E., Lerch, F. J., Scherlis, W. L.,
McNally, M. M., and Cadiz, J. J. (1998). Coordination, overload and team
performance: effects of team communication strategies. In CSCW ’98: Pro-ceedings of the 1998 ACM conference on Computer supported cooperativework, pages 275–284, New York, NY, USA. ACM Press.
[Galegher and Kraut, 1990] Galegher, J. and Kraut, R. E. (1990). Computer-
mediated communication for intellectual teamwork: a field experiment in
group writing. In CSCW ’90: Proceedings of the 1990 ACM conference onComputer-supported cooperative work, pages 65–78, New York, NY, USA.
ACM Press.
[Garfinkel, 1967] Garfinkel, H. (1967). Studies in Ethnomethodology, chapter
“Good” organizational reasons for “bad” clinic records, pages 186–2006.
Prentice-Hall, New Jersey, USA.
[Gelernter, 1985] Gelernter, D. (1985). Generative communication in Linda.
ACM Trans. Program. Lang. Syst., 7(1):80–112.
[Giarratano, 1991] Giarratano, J. (1991). CLIPS User’s Guide. Software Tech-
nology Branch, Lyndon B. Johnson Space Center, Houston, TX, USA, ver-
sion 5.0 edition.
[Gibson, 1979] Gibson, J. J. (1979). The Ecological Approach to Visual Percep-tion. Lawrence Erlbaum Associates, New Jersey, USA.
[Gliem and Gliem, 2003] Gliem, J. and Gliem, R. (2003). Calculating, inter-
preting, and reporting cronbach’s alpha reliability coefficient for likert-type
scales. In Proceedings of the Midwest Research to Practice Conference in Adult,Continuing, and Community Education,.
[Gordon, 1997] Gordon, M. D. (1997). ‘It’s 10 a.m. Do you know where your
documents are? the nature and scope of information retrieval problems in
business. Information Processing and Management, 33(1):107–121.
[Gorman et al., 2000] Gorman, P., Ash, J., Lavelle, M., Lyman, J., Delcambre,
L., Maier, D., Weaver, M., and Bowers, S. (2000). Bundles in the Wild:
Managing Information to Solve Problems and Maintain Situation Aware-
ness. Library Trends, 49(2).
247
BIBLIOGRAPHY
[Gray and Reuter, 1994] Gray, J. and Reuter, A. (1994). Transactions Process-ing: Techniques and Concepts. Morgan Kaufmann Publishers Inc., San Fran-
cisco, CA, USA.
[Greenberg, 1990] Greenberg, S. (1990). Sharing views and interactions with
single-user applications. In Proceedings of the ACM Conference on OfficeInformation Systems, pages 227–237.
[Gregory et al., 1995] Gregory, J., Mattison, J., and Linde, C. (1995). Naming
notes: transitions from free text to structured entry. Methods of Informationin Medicine, 34(1-2):57–67.
[Grinter, 2000] Grinter, R. E. (2000). Workflow systems: Occasions for suc-
cess and failure. Computer Supported Cooperative Work, The Journal ofCollaborative Computing, 9(2):189–214.
[Group, 2000] Group, F. C. (2000). A primer on physician order entry. Tech-
nical report, California HealthCare Foundation’s Quality Initiative.
[Gruber, 1993] Gruber, T. R. (1993). A translation approach to portable on-
tologies. Knowledge Acquisition, 5(2):199–220.
[Grudin, 1988] Grudin, J. (1988). Why CSCW Applications Fail: Problems In
The Design And Evalutation Of Organizational Interfaces. In CSCW ’88:Proceedings of the International Conference on Computer Supported Cooper-ative Work, pages 85–93, Portland, Oregon, USA. ACMPress.
[Guimbretiere, 2003] Guimbretiere, F. (2003). Paper augmented digital doc-
uments. In UIST ’03: Proceedings of the 16th annual ACM symposium onUser interface software and technology, pages 51–60, New York, NY, USA.
ACM Press.
[Gutwin and Greenberg, 1997] Gutwin, C. and Greenberg, S. (1997).
Workspace awarness. Position paper for the ACM CHI’97 Workshop on
Awareness in Collaborative Systems, organized by Susan E. McDaniel and
Tom Brinck, Atlanta, USA.
[Gutwin and Greenberg, 2002] Gutwin, C. and Greenberg, S. (2002). A de-
scriptive framework of workspace awareness for real-time groupware.
Computer Supported Cooperative Work, The Journal of Collaborative Com-puting, 11(3-4):411–446.
248
BIBLIOGRAPHY
[Gutwin et al., 1996] Gutwin, C., Roseman, M., and Greenberg, S. A. (1996).
A usability study of awareness widgets in a shared workspace groupware
system. In CSCW ‘96: Proceedings of the International Conference on Com-puter Supported Cooperative Work, pages 258–267, Cambridge MA, USA.
ACM Press.
[Haas, 1996] Haas, C. (1996). Writing Technology: Studies on the Materialityof Literacy. Lawrence Erlbaum.
[Habing et al., 2001] Habing, N., Dietz, J., and Zwetsloot-Schonk, B. (2001).
Activity patterns in health care: identifying building blocks for the CPR.
SIGGROUP Bulletin, 22(2):9–15.
[Halverson, 2002] Halverson, C. A. (2002). Activity theory and distributed
cognition: Or what does CSCW need to do with theories? Computer Sup-ported Cooperative Work, The Journal of Collaborative Computing, 11(1-
2):243–267.
[Hampson et al., 1996] Hampson, J., Roberts, R., and Morgan, D. (1996).
Shared care: A review of the literature. Family Practice, 13(3):264–279.
[Hardstone et al., 2004] Hardstone, G., Hartswood, M., Procter, R., Slack, R.,
Voss, A., and Rees, G. (2004). Supporting informality: team working and
integrated care records. In CSCW ’04: Proceedings of the 2004 ACM confer-ence on Computer supported cooperative work, pages 142–151, New York,
NY, USA. ACM Press.
[Harper and Sellen, 1995] Harper, R. and Sellen, A. (1995). Collaborative
tools and the practicalities of professional work at the international mon-
etary fund. In CHI ’95: Proceedings of the SIGCHI conference on Humanfactors in computing systems, pages 122–129, New York, NY, USA. ACM
Press/Addison-Wesley Publishing Co.
[Harper et al., 1989] Harper, R. H. R., Hughes, J. A., and Shapiro, D. Z.
(1989). Working in harmony: An examination of computer technology in
air traffic control. In ECSCW’89: Proceedings of the First European Confer-ence on Computer Supported Cooperative Work, pages 73–86, London, UK.
[Hartswood et al., 2003] Hartswood, M., Procter, R., Rouncefield, M., and
Slack, R. (2003). Making a case in medical work: Implications for the elec-
249
BIBLIOGRAPHY
tronic medical record. Computer Supported Cooperative Work, The Journalof Collaborative Computing, 12:241–266.
[Hayes, 2000] Hayes, N. (2000). Work-arounds and boundary crossing in a
high tech optronics company: The role of co-operative workflow technolo-
gies. Computer Supported Cooperative Work, The Journal of CollaborativeComputing, 9(3/4):435–455.
[Hayes-Roth, 1985] Hayes-Roth, B. (1985). A blackboard architecture for
control. Artificial Intelligence, 26:251–321.
[Hayles, 1999] Hayles, K. (1999). How We Became Posthuman: Virtual Bodiesin Cybernetics, Literature, and Informatics. The University of Chicago Press,
Chicago, USA.
[Headrick, 2000] Headrick, D. R. (2000). When information came of age :technologies of knowledge in the age of reason and revolution, 1700-1850.
Oxford University Press.
[Heath et al., 2000] Heath, C., Knoblauch, H., and Luff, P. (2000). Technology
and social interaction: the emergence of ’workplace studies’. British Journalof Sociology, 51(2):299–320.
[Heath and Luff, 1992] Heath, C. and Luff, P. (1992). Collaboration and con-
trol. crisis management and multimedia technology in london underground
control rooms. Computer Supported Cooperative Work, The Journal of Col-laborative Computing, 1(2):69–94.
[Heath and Luff, 1996a] Heath, C. and Luff, P. (1996a). Cognition and Com-munication at Work, chapter Convergent Activities: Line Control and Pas-
senger Information in the London Underground, pages 96–129. Cambridge
University Press.
[Heath and Luff, 1996b] Heath, C. and Luff, P. (1996b). Documents and Pro-
fessional Practice: ‘bad’ organisational reasons for ‘good’ clinical records. In
CSCW’96: Proceedings of the international conference on computer-supportedcooperative work, pages 354–363, Cambridge MA. ACM Press.
[Heath et al., 2002] Heath, C., Svensson, M. S., Hindmarsh, J., Luff, P., and
vom Lehn, D. (2002). Configuring awareness. Computer Supported Coop-erative Work, The Journal of Collaborative Computing, 11(3-4):317–347.
250
BIBLIOGRAPHY
[Heath and Luff, 80] Heath, C. C. and Luff, P. (65–80). Collaborative activ-
ity and technological design: Task coordination in london underground
control rooms. In Bannon, L. J., Robinson, M., and Schmidt, K., editors,
ECSCW’91: Proceedings of the Second European Conference on Computer-Supported Cooperative Work, pages 65–80, Amsterdam, NL. Kluwer Aca-
demic Publishers.
[Heath et al., 2001] Heath, C. C., Luff, P., Kuzuoka, H., and Yamazaki, K.
(2001). Creating coherent environments for collaboration. In ECSCW’01:Proceedings of the Seventh European Conference on Computer Supported Co-operative Work, Bonn, Germany. Kluwer Academic.
[Heeks et al., 1999] Heeks, R., Mundy, D., and Salazar, A. (1999). Why health
care information systems succeed or fail. Technical report, Institute for
Development Policy and Management (IDPM), Manchester, UK.
[Henry et al., 1998] Henry, S., Douglas, K., Galzagorry, G., Lahey, A., and
Holzemer, W. (1998). A template -based approach to support utilization
of clinical practice guidelines within an electronic health record. Journal ofthe American Medical Informatics Association, 5(3):237–244.
[Hertzum, 1993] Hertzum, M. (1993). ‘information retrieval in a work set-
ting: A case study of the documentation part of chemists’ work’. In Bansler,
J. P., Bødker, K., Kensing, F., Nørbjerg, J., and PriesHeje, J., editors, Proceed-ings of the 16th IRIS. Information Systems Research Seminar in Scandinavia,DIKU report 93/16, pages 786–798. University of Copenhagen,.
[Hertzum, 1999] Hertzum, M. (1999). Six roles of documents in profession-
als’ work. In ECSCW’99: Proceedings of the Sixth European conference onComputer supported cooperative work, pages 41–60, Norwell, MA, USA.
Kluwer Academic Publishers.
[Hill and Gutwin, 2003] Hill, J. and Gutwin, C. (2003). Awareness support
in a groupware widget toolkit. In GROUP ’03: Proceedings of the 2003 inter-national ACM SIGGROUP conference on Supporting group work, pages 258–
267, New York, NY, USA. ACM Press.
[Hoare, 1969] Hoare, C. A. R. (1969). An axiomatic basis for computer pro-
gramming. Communication of the ACM, 12(10):576–580.
251
BIBLIOGRAPHY
[Howie et al., 1996] Howie, C. T., Kunz, J. C., and Law, K. H. (1996). Soft-
ware interoperability. Technical report, Center for Integrated Facility Engi-
neering, Stanford University.
[Hughes and King, 1993] Hughes, J. and King, V. (1993). Requirements andMetaphors of Shared Interaction Part II: Shared Artifacts. COMIC Deliverable4.1, chapter Paperwork, pages 153–325. Lancaster, UK.
[Hughes et al., 1995] Hughes, J., King, V., Rodden, T., and Andersen, H.
(1995). The role of ethnography in interactive systems design. Interac-tions, 2(2):56–65.
[Hutchins, 1995] Hutchins, E. (1995). How a cockpit remembers its speed.
Cognitive Science, 19:265–288.
[Hutchins, 1996] Hutchins, E. (1996). Cognition in the Wild. The MIT Press,
Cambridge, MA.
[Ireson, 1997] Ireson, C. (1997). Critical pathways: Effectiveness in achiev-
ing patient outcomes. Journal of Nursing Administration, 27(6):16–23.
[Ishida, 1995] Ishida, T. (1995). Parallel, distributed and multi-agent pro-
duction systems – A research foundation for distributed artificial intelli-
gence. In Lesser, V., editor, Proceedings of the First International Conferenceon Multi-Agent Systems, pages 416–422, San Francisco, CA. MIT Press.
[Jahnke et al., 2004a] Jahnke, J. H., Bychkov, Y., Dahlem, D., and Kawasme,
L. (2004a). Context-aware information services for health care. In KI2004Workshop - Modeling and Retrieval of Context.
[Jahnke et al., 2004b] Jahnke, J. H., Bychkov, Y., Dahlem, D., and Kawasme,
L. (2004b). Implicit, context-aware computing for health care. In OOP-SLA’04 Workshop on Building Software for Pervasive Computing.
[Jang et al., 2000] Jang, C. Y., Steinfield, C., and Pfaff, B. (2000). Supporting
awareness among virtual teams in a web-based collaborative system: the
teamSCOPE system. SIGGROUP Bulletin, 21(3):28–34.
[Jang et al., 2002] Jang, C.-Y., Steinfield, C., and Pfaff, B. (2002). Virtual
team awareness and groupware support: an evaluation of the TeamSCOPE
system. Internation Journal of Human-Computer Studies, 56(1):109–126.
252
BIBLIOGRAPHY
[Jones, 2003] Jones, M. (2003). “Computers can land people on Mars, why
can’t they get them to work in a hospital?” Implementation of an Electronic
Patient Record system in a UK Hospital. Methods of Information in Medicine,
42:410–415.
[Josefsson, 1999] Josefsson, U. (1999). Aspects of awareness in constructing
a common information space. In IRIS 22: Proceedings of the 22nd Informa-tion Systems Research Seminar in Scandinavia “Enterprise Architectures forVirtual Organizations”, Keuruu, Finland.
[Kahan et al., 2001] Kahan, J., Koivunen, M.-R., Prud’Hommeaux, E., and
Swick, R. R. (2001). Annotea: An open rdf infrastructure for shared web
annotations. In Proceedings International WWW Conference, volume 10,
Hong-Kong.
[Kaptelinin, 1996] Kaptelinin, V. (1996). Context and Consciousness: ActivityTheory and Human-Computer Interaction, chapter Activity Theory: Implica-
tions for Human-Computer Interaction. MIT Press, Cambridge, MA (USA).
[Keen, 1980] Keen, P. (1980). MIS research: Reference traditions and a cu-
mulative tradition. In Proceedings of the first International Conference onInformation Systems, pages 9–18, Philadelphia, USA.
[Kensing, 2004] Kensing, F. (2004). It-augmented shared care. In CSCW’04:Proceedings of the Distributed Collective Practices Workshop at the ACM Con-ference on Computer Supported Cooperative Work, Chicago, USA. ACM Press.
[Kiesel and Schuerr, 1995] Kiesel, N. and Schuerr, A. (1995). GRAS, a graph-
oriented (software) engineering database system. Information Systems,20(1):21–52.
[Kirsh, 1995] Kirsh, D. (1995). The intelligent use of space. Artificial Intelli-gence, 73(1-2):31–68.
[Koppel et al., 2005] Koppel, R., Metlay, J. P., Cohen, A., Abaluck, B., Localio,
A. R., Kimmel, S. E., and Strom, B. L. (2005). Role of computerized physi-
cian order entry systems in facilitating medication errors. Journal of theAmerican Medical Association, 293:1197–1203.
[Kuperman and Gibson, 2003] Kuperman, G. J. and Gibson, R. F. (2003).
Computer physician order entry: Benefits, costs, and issues. Annals of In-ternal Medicine, 139:31–39.
253
BIBLIOGRAPHY
[Kuutti, 1991] Kuutti, K. (1991). The concept of activity as a basic unit of
analysis for cscw research. In CSCW’91: Proceedings of the Second Euro-pean Conference on Computer-Supported Cooperative Work, pages 249–264.
Kluwer Academic Publisher.
[LaMarca et al., 1999] LaMarca, A., Edwards, W. K., Dourish, P., Lamping, J.,
Smith, I., and Thornton, J. (1999). Taking the work out of workflow: Mech-
anisms for document-centered collaboration. In ECSCW’99: Proceedings ofthe Sixth European Conference on Computer-Supported Cooperative Work,
Copenhagen, Denmark.
[Latour, 1999] Latour, B. (1999). Pandora’s Hope: Essays on the Reality ofScience Studies. Harvard University Press, Cambridge, MA, USA.
[Lauwers and Lantz, 1990] Lauwers, C. J. and Lantz, K. A. (1990). Collabora-
tion awareness in support of collaboration transparency: Requirements for
the next generation of shared window systems. In CHI’90: Proceedings ofthe ACM SIGCHI Conference on Human Factors in Computing Systems, pages
303–311, Seattle, Washington, USA. ACM Press.
[Lave, 1988] Lave, J. (1988). Cognition in Practice. Cambridge University
Press.
[Levy, 1994] Levy, D. (1994). “fixed or fluid? document stability and new me-
dia”. In Proceedings of the European Conference on Hypermedia Technology,
New York, USA. ACM Press.
[Lindwer et al., 2003] Lindwer, M., Marculescu, D., Basten, T., Zimmermann,
R., Marculescu, R., Jung, S., and Cantatore, E. (2003). Ambient intelligence
visions and achievements: Linking abstract ideas to real-world concepts.
In Proceedings of the conference on Design, Automation and Test in Europe(DATE ’03), pages 10–15.
[Lortal et al., 2005] Lortal, G., Lewkowicz, M., and Todirascu, A. (2005).
Ant&cow, a tool supporting collective interpretation of documents through
annotation and indexation. In Proceedings of DIENG, MATTA, IJCAI - KMOMWorkshop, Edinburgh.
[Luff and Heath, 1998] Luff, P. and Heath, C. (1998). Mobility in collabora-
tion. In CSCW’98: Proceedings of the 1998 ACM conference on Computersupported cooperative work, pages 305–314. ACM Press.
254
BIBLIOGRAPHY
[Luff et al., 1992] Luff, P., Heath, C., and Greatbatch, D. (1992). Tasks-in-
interaction: paper and screen based documentation in collaborative activ-
ity. In CSCW ’92: Proceedings of the 1992 ACM conference on Computer-supported cooperative work, pages 163–170, New York, NY, USA. ACM
Press.
[Luff et al., 2000] Luff, P., Hindmarsh, J., and Heath, C., editors (2000).
Workplace Studies: Recovering Work Practices and Informing System Design.
Cambridge University Press, Cambridge, UK.
[MacKay, 1999] MacKay, W. E. (1999). Is paper safer? the role of paper flight
strips in air traffic control. ACM Trans. Comput.-Hum. Interact., 6(4):311–
340.
[Malone and Crowston, 1994] Malone, T. and Crowston, K. (1994). The in-
terdisciplinary study of coordination. Computing Surveys, 26(1):87–119.
[Malone, 1983] Malone, T. W. (1983). How do people organize their desks?:
Implications for the design of office information systems. ACM Transactionson Information Systems, 1(1):99–112.
[Malone and Crowston, 1990] Malone, T. W. and Crowston, K. (1990). What
is coordination theory and how can it help design cooperative work sys-
tems? In Computer Supported Cooperative Work, The Journal of Collabora-tive Computing, pages 357–370.
[Mamei et al., 2003] Mamei, M., Zambonelli, F., and Leonardi, L. (2003). Tu-
ples On The Air: A middleware for context-aware computing in dynamic
networks. In ICDCSW ’03: Proceedings of the 23rd International Conferenceon Distributed Computing Systems, page 342. IEEE Computer Society.
[Mani and Maybury, 1999] Mani, I. and Maybury, M. T., editors (1999). Ad-vances in Automatic Text Summarization. The MIT Press.
[Mann and Williams, 2003] Mann, R. and Williams, J. (2003). Standards in
medical record keeping. Clinical Medicine, Journal of the Royal College ofPhysicians, 3(4):329–332.
[Mark, 2002] Mark, G. (2002). Conventions and Commitments in Distributed
CSCW Groups. Computer Supported Cooperative Work, The Journal of Col-laborative Computing, 11(3-4):349–387.
255
BIBLIOGRAPHY
[Mark et al., 1997] Mark, G., Fuchs, L., and Sohlenkamp, M. (1997). Sup-
porting groupware conventions through contextual awareness. In Prinz,
W., Rodden, T., Hughes, J., and Schmidt, K., editors, ECSCW’97: Proceed-ings of The Fifth European Conference on Computer Supported Cooperative,pages 253–268, Lancaster, UK. Kluwer Academic Publisher.
[Mark et al., 2002a] Mark, G., Gonzalez, V., Sarini, M., and Simone, C.
(2002a). Supporting articulation with the reconciler. In CHI Extended Ab-stracts, pages 814–815.
[Mark et al., 2002b] Mark, G., Gonzalez, V. M., Sarini, M., and Simone, C.
(2002b). Reconciling different perspectives: An experiment on technology
support for articulation. In COOP’02: Proceedings of the International Con-ference on the Design of Cooperative systems, pages 23–37.
[Martin et al., 2005] Martin, D., Paolucci, M., McIlraith, S., Burstein, M., Mc-
Dermott, D., McGuinness, D., Parsia, B., Payne, T., Sabou, M., Solanki, M.,
Srinivasan, N., and Sycara, K. (2005). Bringing semantics to web services:
The owl-s approach. Lecture Notes in Computer Science, 3387:26–42.
[Mays and Pope, 1996] Mays, N. and Pope, C. (1996). Qualitative research inhealth care. British Medical Journal Books, London, UK.
[Miller, 2004] Miller, T. (2004). Researching work processes at the micro-
scale level. In Proceedings of the 9th Great Lakes Information Studies Con-ference, Toronto, CA.
[Milner, 1980] Milner, R. (1980). A calculus of Communicating systems, vol-
ume 92. Springer-Verlag, Berlin Heidelberg.
[Moran and Dourish, 2001] Moran, T. P. and Dourish, P. (2001). Introduction
to the special issue on context-aware computing. Human-Computer Inter-action, 16:2–4.
M., and Bernardi, A. (2002). A methodological approach to supporting
organizational learning. International Journal of Human-Computer Studies,56(3):337–367.
[Mur-Veeman et al., 2001] Mur-Veeman, I., Eijkelberg, I., and Spreeuwen-
berg, C. (2001). How to manage the implementation of shared care. Jour-nal of Management in Medicine, 15(2):142–155.
256
BIBLIOGRAPHY
[Murphy et al., 2001] Murphy, A. L., Picco, G. P., and Roman, G.-C. (2001).
Lime: A middleware for physical and logical mobility. In ICDCS-21: Proceed-ings of the 21st International Conference on Distributed Computing Systems,pages 524–533, Phoenix ( AZ, USA).
[Nardi, 1995] Nardi, B. A. (1995). Studying context: a comparison of activ-ity theory, situated action models, and distributed cognition, pages 69–102.
Massachusetts Institute of Technology, Cambridge, MA, USA.
[Nielsen et al., 1992] Nielsen, M., Rozenberg, G., and Thiagarajan, P. S.
[Nii, 1986] Nii, P. (1986). Blackboard systems: The blackboard model of prob-
lem solving and the evolution of blackboard architectures. AI Magazine,
7(2):38–53,82–106.
[Nilsson, 1980] Nilsson, N. (1980). Principles of Artificial Intelligence. Tioga
Publishing Co., Palo Alto, CA, USA.
[Nonaka and Takeuchi, 1995] Nonaka, I. and Takeuchi, H. (1995). TheKnowledge Creating Company. Oxford University Press, Oxford, UK.
[Norman, 1988] Norman, D. A. (1988). The Design of Everyday Things. Dou-
bleday, New York, USA.
[Norman, 1991] Norman, D. A. (1991). Designing interaction: psychology atthe human-computer interface, chapter Cognitive artifacts, pages 17–38.
Cambridge University Press.
[Nurminen et al., 1997] Nurminen, M. I., Fjuk, A., and Smordal, O. (1997).
Taking articulation work seriously - an activity theoretical approach. Tech-
nical report, Turku Centre for Computer Science.
[Olson and Teasley, 1996] Olson, J. and Teasley, S. (1996). Groupware in the
wild: Lessons learned from a year of virtual collocation. In CSCW’96: Pro-ceedings of the ACM Conference on Computer-Supported Cooperative Work,
Boston, USA. ACM Press.
[Omicini et al., 2004] Omicini, A., Ricci, A., Viroli, M., Castelfranchi, C., and
Tummolini, L. (2004). Coordination artifacts: Environment-based coordi-
nation for intelligent agents. In Jennings, N. R., Sierra, C., Sonenberg, L.,
257
BIBLIOGRAPHY
and Tambe, M., editors, Third International Joint Conference on AutonomousAgents and Multiagent Systems – AAMAS’04, volume 1, page 286–293, New
York, USA. ACM.
[Panella et al., 2003] Panella, M., Marchisio, S., and Stanislao, F. D. (2003).
Reducing clinical variations with clinical pathways: do pathways work? In-ternational Journal for Quality in Health Care, 15:509–521.
[Parunak, 2003] Parunak, H. D. (2003). Making swarming happen. In Pro-ceedings of the Conference on Swarming and Network Enabled Command,Control, Communications, Computers, Intelligence, Surveillance and Recon-naissance (C4ISR), McLean, Virginia, USA.
[Parunak et al., 2003] Parunak, H. V. D., Brueckner, S., Fleischer, M., and
Odell, J. (2003). A preliminary taxonomy of multi-agent interactions. In
Proceedings of the 2nd International Joint conference on Autonomous Agentsand Multiagent Systems (AAMAS 2002), pages 1090–1091. ACM Press.
[Pearson et al., 1995] Pearson, S., Goulart-Fisher, D., and Lee, T. (1995). Crit-
ical pathways as a strategy for improving care: problems and potential.
Annals of Internal Medicine, 12:941–948.
[Pollock, 2005] Pollock, N. (2005). When is a work-around? conflict and ne-
gotiation in computer systems development. Science, Technology & HumanValues, 30(4):496–514.
[Prinz, 1994] Prinz, W. (1994). Object-oriented organization modeling for
the support of cscw. System Sciences, Information Systems: Collabora-tion Technology Organizational Systems and Technology, Proceedings of theTwenty-Seventh Hawaii International Conference on, 4:797–806.
[Pritchard and Hughes, 1995] Pritchard, P. and Hughes, J. (1995). SharedCare. The Future Imperative. Royal Society of Medicine Press, London.
[Quaglini et al., 2005] Quaglini, S., Panzarasa, S., Cavallini, A., Micieli, G.,
Pernice, C., and Stefanelli, M. (2005). Smooth integration of decision sup-
port into an existing electronic patient record. In AIME, pages 89–93.
[Randall, 2000] Randall, S. (2000). What’s common about common informa-
tion spaces? paper presented at the workshop on cooperative organisation
258
BIBLIOGRAPHY
of common information spaces. Technical report, Technical University of
Denmark. Available at http://dmm.cti.dtu.dk/position/randall.pdf.
[Randell, 2004] Randell, R. (2004). Accountability in an alarming environ-
ment. In CSCW ’04: Proceedings of the 2004 ACM conference on Com-puter supported cooperative work, pages 125–131, New York, NY, USA. ACM
Press.
[Raposo and Fuks, 2002] Raposo, A. and Fuks, H. (2002). Cooperative Sys-tems Design. Frontiers in Artificial Intelligence and Applications, volume 74,
chapter Defining Task Interdependencies and Coordination Mechanisms for
[Raposo et al., 2000] Raposo, A. B., Magalhaes, L. P., and Ricarte, I. L. M.
(2000). Petri nets based coordination mechanisms for multi-workflow en-
vironments. Computer Systems Science and Engineering, 15(5):315–326.
[Reddy and Dourish, 2002] Reddy, M. and Dourish, P. (2002). A Finger on
the Pulse: Temporal Rhythms and Information Seeking in Medical Work. In
CSCW’02: Proceedings of the international Conference of Computer SupportedCooperative Work. ACM Press.
[Reddy et al., 2001] Reddy, M., Dourish, P., and Pratt, W. (2001). Coordi-
nating Heterogeneous Work: Information and Representation in Medical
Care. In ECSCW’01; Proceedings of the European Conference on Computer-Supported Cooperative Work, Bonn.
[Reiser, 1984] Reiser, S. J. (1984). Transformation and tradition in the sci-ences: Essays in honor of I. Bernard Cohen, chapter Creating form out of
mass: The development of the medical record, pages 303–316. Cambridge
University Press, New York, USA.
[Ricci et al., 2004] Ricci, A., Viroli, M., and Omicini, A. (2004). Agent coor-
dination context: From theory to practice. In in Proc. of the Cybernetics andSystems 2004, 17th European Meeting on Cybernetics and Systems Research(EMCSR 2004), volume 2, Vienna, Austria. Austrian Society for Cybernetic
Studies.
[Robinson and Bannon, 1991] Robinson, M. and Bannon, L. (1991). Ques-
tioning representations. In ECSCW’91: Proceedings of the Second Euro-
259
BIBLIOGRAPHY
pean Conference on Computer-Supported Cooperative Work, Amsterdam, The
Netherlands.
[Rolland et al., 2006] Rolland, K., V.Hepsø, and Monteiro, E. (2006). Con-
ceptualizing common information spaces across heterogeneous contexts:
mutable mobiles and side-effects of integration. In CSCW ’06: Proceedingsof International conference on computer-supported cooperative work. ACM
Press.
[Roper et al., 1980] Roper, N., Logan, W., and Tierney, A. (1980). The Ele-ments of Nursing. Churchill Livingstone.
[Roscoe et al., 1997] Roscoe, A. W., Hoare, C. A. R., and Bird, R. (1997). TheTheory and Practice of Concurrency. Prentice Hall PTR, Upper Saddle River,
NJ, USA.
[Russell and Norvig, 1995] Russell, S. and Norvig, P. (1995). Artificial Intelli-gence: A Modern Approach. Prentice Hall.
[Sarini and Simone, 2002] Sarini, M. and Simone, C. (2002). Recursive Ar-
ticulation work in Ariadne: the alignment of meanings. In COOP’02: Pro-ceedings of International Conference on the Design of Cooperative Systems,pages 191–206, Saint Raphael, France.
[Schmidt, 1991] Schmidt, K. (1991). Riding a Tiger, or Computer Supported
Cooperative Work. In ECSCW ‘91: Proceedings of the Second European Con-ference on Computer-Supported Cooperative Work, pages 1–16, Amsterdam,
NL. Kluwer.
[Schmidt, 1994a] Schmidt, K. (1994a). Cooperative work and its articula-
tion: Requirements for computer support. Le Travail Collectif - Travail Hu-main, 57(4):345–366.
[Schmidt, 1994b] Schmidt, K. (1994b). Social Mechanisms of Interaction.COMIC Deliverable 3.2, chapter Mechanisms of interaction reconsidered,
pages 15–122. Lancaster University.
[Schmidt, 1997] Schmidt, K. (1997). Of maps and scripts: the status of formal
constructs in cooperative work. In GROUP’97: Proceedings of the GROUPConference, pages 138–147, Phoenix Arizona USA. ACM Press.
260
BIBLIOGRAPHY
[Schmidt, 1998] Schmidt, K. (1998). Some notes on mutual awareness -
cotcos-report. Technical report, Technical University of Denmark.
[Schmidt, 2000] Schmidt, K. (2000). Distributed collective practices: A cscw
perspective, invited talk. In Proceedings of the Conference on DistributedCollective Practices.
[Schmidt, 2002] Schmidt, K. (2002). The problem with ‘Awareness’: Intro-
ductory remarks on ‘Awareness in CSCW’. Computer Supported CooperativeWork, The Journal of Collaborative Computing, 11(3):285–298.
[Schmidt and Bannon, 1992] Schmidt, K. and Bannon, L. (1992). Taking
CSCW Seriously: supporting Articulation Work. Computer Supported Co-operative Work, The Journal of Collaborative Computing, 1(1):7–40.
[Schmidt and Simone, 1995] Schmidt, K. and Simone, C. (1995). Demonstra-tor prototypes of Computational Mechanisms of Interaction. COMIC Deliver-able 3.3, chapter Coordination mechanisms: An approach to CSCW systems
design, pages 15–122. Lancaster University.
[Schmidt and Simone, 1996] Schmidt, K. and Simone, C. (1996). Coordina-
tion Mechanisms: Towards a conceptual foundation for CSCW systems de-
sign. Computer Supported Cooperative Work, The Journal of CollaborativeComputing, 5(2-3):155–200.
[Schmidt and Wagner, 2002a] Schmidt, K. and Wagner, I. (2002a). Coordina-
tive artifacts in architectural practice. In at al., M. B.-F., editor, COOP 2002:Proceedings of the Fifth International Conference on the Design of CooperativeSystems, pages 257–274, Saint Raphal, France. IOS Press, Amsterdam.
[Schmidt and Wagner, 2002b] Schmidt, K. and Wagner, I. (2002b). Coordi-
native artifacts in architectural practise. In COOP’02: Proceedings of theInternational Conference on the Design of Cooperative Systems, pages 257–
274.
[Schmidt and Wagner, 2004] Schmidt, K. and Wagner, I. (2004). Ordering
Systems: Coordinative practices and artifacts in architectural design and
planning. Computer Supported Cooperative Work, The Journal of Collabora-tive Computing, 13(5-6):349–408.
261
BIBLIOGRAPHY
[Seiner, 2001] Seiner, R. (2001). Metadata as a knowledge management en-
abler. TDAN.com & KIK Consulting Services The Data Administration Newslet-ter (TDAN.com) ., 15. Available at www.tdan.com.
[Sellen and Harper, 2003] Sellen, A. J. and Harper, R. H. R. (2003). The Mythof the Paperless Office. MIT Press, Cambridge MA.
[Sengupta and Zhao, 1998] Sengupta, K. and Zhao, J. (1998). Improving the
communicationai effectiveness of virtual organizations through workflow
automation. International Journal of Electronic Commerce, 3(1):49–69.
[Serres and Latour., 1995] Serres, M. and Latour., B. (1995). Conversationson Science, Culture and Time. University of Michigan Press.
[Shannon and Weaver, 1949] Shannon, C. and Weaver, W. (1949). The Math-ematical Theory of Communication. University of Illinois Press, Urbana, Ill,
USA.
[Simone and Bandini, 2002] Simone, C. and Bandini, S. (2002). Integrat-
ing awareness in cooperative applications through the reaction-diffusion
metaphor. Computer Supported Cooperative Work, The Journal of Collabora-tive Computing, 11((3-4)):495–530.
[Simone and Divitini, 1999] Simone, C. and Divitini, M. (1999). Integrat-
ing Contexts to Supporting Coordination: The CHAOS Project. Com-puter Supported Cooperative Work, The Journal of Collaborative Computing,
8(3):239–283.
[Simone and Sarini, 2001] Simone, C. and Sarini, M. (2001). Adaptabil-
ity of classification schemes in cooperation: What does it mean? In EC-SCW’01: Proceedings of European Conference on Computer-Supported Coop-erative Work, pages 19–38. Kluwer Academic Publishers.
[Simone and Schmidt, 1998] Simone, C. and Schmidt, K. (1998). Taking the
distributed nature of cooperative work seriously. In Proceedings of the 6thEuromicro Workshop on Parallel and Distributed Processing, pages 295–301,
Madrid, Spain. IEEE Computer Society.
[Simone and Schmidt, 2000] Simone, C. and Schmidt, K. (2000). Mind the
gap! Towards a unified view of CSCW. In COOP2000: Proceedings of the
262
BIBLIOGRAPHY
fourth international conference on the design of cooperative systems, Sophia-
Antipolis (Fr).
[Sorbya et al., 2002] Sorbya, I. D., Melbyb, L., and Nytroa, O. (2002). Char-
acterising Cooperation In The Ward: A Framework for Producing Require-
ments to Mobile Electronic Healthcare Records. In Computer Science Grad-uate Student Conference 2002 - (CSGSC-2002).
[Star and Griesemer, 1989] Star, S. L. and Griesemer, J. R. (1989). Institu-
tional Ecology, ’Translations’ and Boundary Objects: Amateurs and Profes-
sionals in Berkeley’s Museum of Vertebrate Zoology, 1907-39. Social Studiesof Science, 19:387–420.
[Steels, 1994] Steels, L. (1994). The artificial life roots of artificial intelli-
gence. Artificial Life Journal, 1(1):89–125.
[Strauss, 1985] Strauss, A. (1985). Work and the division of labor. The Soci-ological Quarterly, 26(1):1–19.
[Strauss, 1988] Strauss, A. (1988). The articulation of project work: An or-
ganizational process. The Sociological Quarterly, 29(2):163–178.
[Strauss et al., 1982] Strauss, A., Fagerhaugh, S., Suczek, B., and Wiener, C.
(1982). Sentimental work in the technologized hospital. Sociology of Healthand Illness, 4(3):254–278.
[Strauss et al., 1985] Strauss, A., Fagerhaugh, S., Suczek, B., and Wiener, C.
(1985). The Social Organization of Medical Work. University of Chicago
Press.
[Strohbach et al., 2004] Strohbach, M., Gellersen, H.-W., Kortuem, G., and
Kray, C. (2004). Cooperative artefacts: Assessing real world situations with
embedded technology. In Ubicomp’04: Proceedings of the 6th InternationalConference on Ubiquitous Computing, pages 250–267.
[Suchman, 1993] Suchman, L. (1993). Technology in Working Order. Studiesof Work, Interaction, and Technology, chapter Technologies of Accountabil-
ity: On Lizards and Airplanes, pages 113–126. Routledge, London, UK.
[Suchman, 1987] Suchman, L. A. (1987). Plans and situated actions: Theproblem of human-machine communication. Cambridge University Press.
263
BIBLIOGRAPHY
[Suchman, 1996] Suchman, L. A. (1996). Cognition and Communication atWork, chapter Constituting shared workspaces, pages 35–60. Cambridge
University Press, Cambridge, UK.
[Susi and Ziemke, 2001] Susi, T. and Ziemke, T. (2001). Social cognition,
artefacts, and stigmergy: A comparative analysis of theoretical frameworks
for the understanding of artefact-mediated collaborative activity. CognitiveSystems Research, 2:273–290.
[Tanenbaum and van Steen, 2002] Tanenbaum, A. S. and van Steen, M.
(2002). Distributed Systems: Principles and Paradigms. Prentice Hall.
[Tang and McDonald, 2000] Tang, P. C. and McDonald, C. J. (2000). MedicalInformatics: Computer Applications in Health Care and Biometrics, chapter
[Tata et al., 1999] Tata, S., Canals, G., and Godart, C. (1999). Specifying in-
teractions in cooperative applications. In Proceedings of the Eleventh In-ternational Conference on Software Engineering and Knowledge Engineering,
Kaiserslautern, Germany.
[Tellioglu, 2003] Tellioglu, H. (2003). Modeling coordinated work: Definition
and application of the model “coordinated work environment”. Journal ofSupercomputing, 24(2):161–171.
[Theraulaz and Bonabeau, 1999] Theraulaz, G. and Bonabeau, E. (1999). A
brief history of stigmergy. Artificial Life, 5:97–116.
[Timmermans and Berg, 2003] Timmermans, S. and Berg, M. (2003). The
practice of medical technology. Sociology of health and illness, 25:97–114.
[Tollmar et al., 1996] Tollmar, K., Sandor, O., and Schemer, A. (1996). Sup-
porting social awareness @work: Design and experience. In CSCW ‘96:Proceedings of the International Conference on Computer Supported Cooper-ative Work, pages 298–307, Cambridge MA, USA. ACM Press.
[van der Aalst et al., 2000a] van der Aalst, W., Desel, J., and Oberweis, A.
(2000a). Business Process Management - Models, Techniques and EmpiricalStudies. Lecture Notes in Computer Science 1806. Springer Verlag, Berlin.
264
BIBLIOGRAPHY
[van der Aalst and Jablonski, 2000] van der Aalst, W. and Jablonski, S.
(2000). Dealing with workflow change: Identification of issues and solu-
tions. International Journal of Computer Systems, Science, and Engineering,
15(5):267–276.
[van der Aalst et al., 2000b] van der Aalst, W. M. P., Barros, A. P., ter Hofstede,
A. H. M., and Kiepuszewski, B. (2000b). Advanced workflow patterns. In
CooplS ’02: Proceedings of the 7th International Conference on CooperativeInformation Systems, pages 18–29, London, UK. Springer-Verlag.
[van Ginneken and Moorman, 1997] van Ginneken, A. and Moorman, P.
(1997). Handbook of Medical Informatics, chapter The patient record. Bohn
Stafleu Van Loghum.
[Weed, 1971] Weed, L. (1971). The problem oriented record as a basic tool in
medical education, patient care,and research. Annals of Clinical Research,
3(3).
[Weiser, 1991] Weiser, M. (1991). The computer for the twenty-first century.
Scientific American, pages 94–10.
[Weiser, 1993] Weiser, M. (1993). Some computer science issues in ubiqui-
tous computing. Communications of the ACM, 36(7):75–84.
[Weiser and Brown, 2005] Weiser, M. and Brown, J. S. (2005). The coming
age of calm technology. Technical report, The Institute for End User Com-
puting, Inc. as edited on Thursday, June 23, 2005.
[Wenger, 1998] Wenger, E. (1998). Communities of Practice: Learning, Mean-ing, and Identity. Cambridge University Press.
[Wesley, 1995] Wesley, R. L. (1995). Nursing theories and models. Spring-
house, PA: Springhouse Corporation.
[Wilson, 1975] Wilson, E. O. (1975). Sociobiology: The New Synthesis. Har-
vard.
[Winograd and Flores, 1986] Winograd, T. and Flores, F. (1986). Understand-ing Computers and Cognition: a new foundation for design. Addison Wesley,
Reading MA.
265
BIBLIOGRAPHY
[Winthereik and Vikkelso, 2005] Winthereik, B. R. and Vikkelso, S. (2005).
Ict and integrated care: Some dilemmas of standardising inter-