An Example
Nishadi De Silva
School of Electronics and Computer Science, University of Southampton, SO17 1BJ, UK
Keywords: Collaborative writing, Coherence, Narrative-based writing, Document narratives, Rhetorical Structure
Theory (RST).
Abstract: Document coherence is often harder to achieve in collaborative writing owing to a lack of group consensus
and misaligned contributions by the co-authors. By ‘coherence’ we refer to the feature of a text that makes it
easy to read and understand. This can be linked to the implicit story that a document conveys to its reader.
Despite being an integral aspect of a successful document, software support for coherence is minimal.
Collaborative writing tools do ensure syntactic consistency but this still does not guarantee coherence. Other
approaches such as agreeing on an outline at the start can improve the document but outlines too have their
shortcomings. Previously, we introduced a technique called narrative-based writing to fill these gaps and
built a prototype of a tool that allows co-authors to engage in this method. The purpose of this paper is to
present an example of how a team of authors can make use of this narrative-based technique and tool, and
show how the corresponding document evolves.
Collaborative writing (CW) is a necessity in today’s
academic and industrial settings. It is the process in
which multiple authors work together to produce a
single document. It is not just the sharing of
opinions but also the contribution of the various
sections which are collated to form the final
CW has several advantages over single-author
writing. In a survey by Noël and Robert (2004), the
participants agreed that CW resulted in richer
documents owing to diverse ideas and input from
co-authors with different expertise. In theory, CW
should also take less time since the authors produce
the text simultaneously. Also, if each section is
written by the relevant expert in the team, it is likely
that the text will be better and more accurate.
Participants of the same survey, however, had
also pointed out the disadvantages of CW including
difficult group management and coordination (Noël
and Robert, 2004), and documents that are poorly
structured. Extra coordination is needed in CW,
especially when the authors are geographically
dispersed. The team leader may need to edit the
sections contributed by the authors so that they fit
into the document. All this could lead to an increase
in the time spent, in comparison to the time required
for a single author to write the same document. The
overall coherence of the final document may also
suffer. There are several reasons why this would be
the case. For instance, some co-authors lower down
in the hierarchy may not be aware of the whole
purpose and structure of the document (e.g. a PhD
student delegated some writing by his supervisor).
The authors may just have different opinions about
how the document should be structured. The
sections thus created may not fit together properly
leading to documents that have, in the past, been
described as ‘arbitrary’ (Lowry et al., 2004). This is
the focus of our research.
Coherence is a subjective phenomenon that is
difficult to formally define. By the word
‘coherence’, we refer to the feature of a text that
makes it easy to read and understand (in addition to
the use of right grammar and language). This is
largely dependent on the sequence of the sentences
(or sections) because readers tend to draw
conclusions about the logical relationships between
adjacent sentences. When these relationships are not
obvious, the text becomes difficult to decipher.
Determining the most natural sequence in which to
present the information is not trivial. If a set of
perfectly-formed sentences are placed in various
De Silva N. (2007).
In Proceedings of the Ninth International Conference on Enterprise Information Systems, pages 351-358
combinations, only a few (if not, just one) of them
will make sense. While this is easy to detect and
repair in a short text like a paragraph, it is much
harder in large documents, particularly when
multiple authors are involved.
While software tools assist many aspects of
collaboration excellently, support for this attribute of
writing is almost non-existent. The best effort is
made by tools that merge concurrent changes
accurately to ensure syntactic consistency (e.g.
CVS). However, syntactic consistency alone does
not guarantee coherence (De-Silva and Skaf-Molli,
There is evidence to suggest that a period of
planning can significantly enhance the quality and
coherence of a document (Torrance and Bouayad-
Agha, 2001). Such a plan would make the authors
aware of the goals and structure of the document. A
popular technique used for this purpose is outlining.
An outline is “an orderly plan…showing the division
of ideas and their arrangement in relation to one
another” (Roth, 1999). When done at the start, it
gives the authors an overall view of the structure of
the document and they can write their text
Figure 1: An outline for this paper.
Relationships between the ideas in an outline are
shown by indentation (main topic and sub-topic) and
the use of the same type of symbol for concepts of
equal importance (e.g. A, B, C). However, an outline
lacks explicit information as to why a certain section
was placed where it is and its relationships with the
rest of the document. In our opinion, such
information can assist authors to improve coherence.
Narrative-based writing (De-Silva and Henderson,
2005, Henderson and De-Silva, 2006) was
developed to fill this gap.
The next section briefly describes narrative-
based writing and the corresponding tool. In Section
3, we present an example that shows a team of
writers making use of narratives to plan a research
paper. Finally, the conclusions and discussions are
Narrative-based writing makes use of some of the
concepts from narratives in technical documents. It
is based on the idea that coherence can be linked to
the inherent ‘story’ conveyed by a document to its
readers. The more consistent the story is, the better
the document. Thereby, the method requires the
authors to begin the writing process by ruminating
on the story that their document will contain. An
explicit précis of this story is called a Document
Narrative or a DN, for short. Parts of this DN will
correspond to sections in the document.
The DN can then be analysed using Rhetorical
Structure Theory (RST) (Mann and Thompson,
1988). RST is a discourse theory developed by
linguists to analyse and improve the coherence of
texts. It asserts a hierarchical structure on the text,
based on relationships between the segments in the
text such as Motivation and Justify. It is not possible
to explain RST in detail in this paper but a short
description of it is given in section 2.2.
Finally, once the authors are satisfied with the
DN, they can get to work on the document. These
three steps are summarised below.
1. Ruminate on the story and create the DN.
2. Analyse the DN using RST in order to evaluate
and improve its coherence. The authors may
decide to repeat steps 1 and 2 until they are
convinced that the DN is the optimal for their
3. Use the DN as a guide to writing the actual
document, checking that the expanded text maps
on to the DN so as to implement the story and its
RST analysis.
The rest of this section explains these three steps.
2.1 Creating the DN
A narrative, by definition, is a representation of
events (Onega and Landa, 1996, Abbott, 2002) and
has been used to refer to a wide variety of texts and
dialogues. Even though there is some debate about
the difference between a narrative and a story, they
are taken to mean the same thing in our research.
A DN is a short text, no more than half a page
long, that captures the story of a document.
Articulating a coherent DN is not always
straightforward and may require some time and
thought. However, the process of thinking about this
story first will, in our opinion, help converge
different opinions from the authors and create a
deeper understanding before writing. For larger
1.0 Introduction
2.0 Narrative-based writing
A) Creating the DN
B) Analysing the DN with RST
C) Producing the document
D) Tool
3.0 Example
4.0 Discussions and conclusions
ICEIS 2007 - International Conference on Enterprise Information Systems
documents like books and theses, a DN can be
created for the whole document and then for the
subsequent chapters or sections too.
DNs for some types of documents such as a
research proposal can be found in (De-Silva and
Henderson, 2005, Henderson and De-Silva, 2006).
2.2 Analysing the DN with RST
It is now possible to analyse the DN using RST.
There are several formal theories to analyse texts
(Lehnert, 1981, Hobbs, 1985). RST was chosen for
this research because it is relatively simple, makes
use of tree structures (easier to visualise) and
provides a means of evaluating coherence. Using
RST in this way, to analyse the DN ahead of
embarking on writing the actual document, amounts
to a pragmatic method of using RST in document
synthesis, as opposed to the document analysis for
which it is popularly used.
The first step in the RST analysis is to break the
text into segments. Segments can be of arbitrary
size, but are typically clauses. Some segments are
crucial to the understanding of the text and they are
called nuclei (N). Others provide information to
support the nuclei and are called satellites (S).
Once the segments have been identified,
relationships are defined between them.
Relationships can be illustrated using diagrams as
shown below. Most relationships link a satellite to a
nucleus (so-called hypotactic relationships, e.g.
Motivation). A few relationships link multiple nuclei
(so-called paratactic relationships, e.g. Sequence).
Text coherence in RST arises due to a set of
constraints and an overall effect that is defined for
each relationship (Mann and Thompson, 1988) (see
Figure 3).
Figure 2: An example of a hypotactic relationship
(Motivation) and a paratactic relationship (Sequence).
Note that the arrows in a hypotactic relationship point
towards its nucleus.
There are 23 relationships defined in the original
paper (Mann and Thompson, 1988). However, only
nine of them have been consistently used in our
analysis of technical documents so far. They are
Background, Contrast, Elaboration, Enablement,
Evidence, Justify, Motivation and Sequence. It is
still too early to predict if this subset of relationships
is sufficient for analyses of all technical documents.
More research is required.
These relationships can be applied recursively to
form a tree called a rhetorical structure tree (RS-
tree). For instance, the DN in Figure 5 ahead has two
segments. In the RST analysis, these two segments
are linked by a SOLUTIONHOOD relationship
(segment 1 is the problem – satellite - and segment 2
is the solution - nucleus). Had the DN been larger
with more segments, the span created by this
relationship (i.e. the joining of segments 1 and 2)
could have, in turn, become involved in another RST
relationship. This continues until all the segments
are part of the RS-tree. Depending on the analyst,
there can be several valid RS-trees for a given DN.
Benefits of doing the RST analysis are:
It is conjectured that if a text can be placed in a
well-formed RS-tree, the text is likely to be
more coherent (Marcu, 2000, Mann and
Thompson, 1988). This feature is used in this
research as a guideline for coherence in the
DNs. If the author struggles to fit the segments
into a RS-tree, it is recommended that he or she
re-think the DN.
An RST analysis forces the authors to question
the existence and positioning of each section in
the DN. This helps to identify sections that play
no role in strengthening the document or
segments that are currently missing. This leads
to a better document.
The tree diagrams also provide a useful
graphical representation of the narrative
structure of the document.
Constraints on N Presents an unrealised action
Constraints on N+S Comprehending S increases the
reader’s desire to perform the action
in N
The effect The reader’s desire to perform the
action in N is increased
Figure 3: The definition for the Motivation relationship
(Source: Mann and Thompson, 1988).
2.3 Producing the Document
After a successful analysis, the authors can be
reasonably confident that the DN is coherent and
begin constructing the document. As a general rule,
the sequence of sections in the document should
correspond to the sequence of segments in the DN.
The content of each of the sections will depend on
the RST relationships that the associated segment in
the DN is involved with. For instance, in a document
introducing a new software tool, descriptions of
successful applications of the software or positive
comments from the users may help satisfy a
Motivation relationship in the RST analysis.
2.4 Prototype of the Tool
We recognised that one way to introduce narrative-
based writing to teams of geographically-dispersed
authors would be to make it available via an easily
accessible tool. Therefore, a prototype of a tool was
built to enable co-authors to create and analyse a DN
at the start of their writing process. The rest of this
section outlines the features of this tool.
The tool was implemented as a Java Web Service
and a JSP client because this was a simple way to
create an easily accessible, shared document. The
web-based interface makes it easy for authors to
access the tool and requires no software installation
prior to use (assuming most users today will have a
Web Browser). The DN and RST relationship data
are stored in a relational database. Currently we use
Microsoft Access but are investigating alternative
Java methods were written for the following
major functions: read, edit, review and merge DNs.
It is important to note that the authors can use these
functions asynchronously without interference (more
experiments are being conducted regarding this). An
initial Business Process model for this tool can be
found in (Henderson and De-Silva, 2006). This
model has since changed to accommodate more
The tool contains a list of predefined DNs for
some popular types of documents (e.g. research
proposal, an abstract, a conference presentation
and so on). At the start, authors can either select
and modify a DN from this list, or create a new
Once a DN has been created, the users are
presented with a list of tasks (e.g. edit the DN,
edit the RST analysis, review or merge DNs).
Users can select the version they wish to work on
from a drop-down list of all the versions for this
In the tool, we have introduced the concept of the
status of a RST relationship. A relationship is said
to be “satisfied” if its nucleus and satellite fulfil
the definitions that Mann and Thompson
described for them. This is determined by the
authors. Until explicitly stated otherwise, a
relationship will remain “unsatisfied”. Similarly,
changes to parts of a RS-tree can change the status
of affected relationships to “unsatisfied”. When
the DN is displayed, all satisfied RST
relationships are shown in blue and unsatisfied
relationships in red, thus drawing the authors’
attention to sections in the DN that may need
changing. This is particularly useful since changes
made by other authors may render some parts of
the RST analysis untrue.
Once the analysis is complete, the DN can be
reviewed. Authors can verify that all the RST
relationships are satisfied.
When a change is made to the RS-tree, a new
version of it is created. However, only the
affected parts of the tree are copied. The
remaining parts of the tree are linked to from the
parent version. This is similar to the technique of
storing deltas (changes) in tools such as CVS
(Cederqvist, 2002) and RCS (Tichy, 1982).
Two versions of the DN can also be merged,
particularly those derived from the same parent
version. At the moment, the merge algorithm is
very simple. In the future, a better algorithm will
be devised.
The HTML user interface of the tool is simple
(see screenshot in Figure 4). The left frame
contains the menus, a link to the Help document
and a table showing the history of the versions of
this DN. The DN is displayed in the upper frame
on the right. A second version of the DN can be
viewed at the same time in a separate window.
This is useful for comparisons.
The DN thus produced can be used by the
authors to create the eventual document. Several
areas of the tool, especially the user interface, are
still under construction. We anticipate that this
narrative-based functionality can, in the future, be
added onto existing CW tools that already have
advanced version management and merging
algorithms (and other properties necessary for
ICEIS 2007 - International Conference on Enterprise Information Systems
This section presents an example that shows how the
narrative-based technique and tool can be used by a
team of authors to structure their document. The
example is a rational reconstruction of the process
by which the paper by De Silva and Skaf-Molli
(2006) was written. The authors were in two
different countries and did not meet face-to-face to
plan it. A lot of the structure was determined by
exchanging DNs and drafts by e-mail. A fictional
third author has, however, been introduced here to
make the writing task more complex. Apart from
that, the example has been kept deliberately small so
that the necessary aspects of collaboration can be
demonstrated within the space limitations in this
The CW task involves three authors (A, B and C)
writing a joint research paper about merging
algorithms and narrative-based writing. Authors A
and B are authorities on merging algorithms while
Author C is researching on narrative-based writing.
They hope to divide the sections of the document
according to their expertise.
To start the process, Author A comes up with a
basic DN for the paper. He inputs the DN into the
tool and does a simple RST analysis of it. Both the
DN and RS-tree now become available to the other
authors (version 1). These are shown in Figure 5.
Version 1 (created by Author A)
1: Merging techniques guarantee syntactic
convergence but not the coherence of the
2: Integrating merging algorithms with
narrative-based writing can fill this gap.
Figure 4: Screen shot of the tool showing version 1 of a DN for an abstract of a paper.
I. Introduction
II. The problem
III. Our solution
IV. Conclusion
Possible outline for the
paper that corresponds to
the DN above
Figure 5: Version 1 of the DN and RS-tree (created by
Author A), and a possible outline for the paper.
The sections that need to be in the document
according to the DN are listed in the outline. Note
that the ‘Introduction’ and ‘Conclusion’ are
mandatory for most papers and are not governed by
the DN in this case (hence, they are in grey).
Sections II and III in the outline correspond to the
two segments in the DN and implement the
SOLUTIONHOOD relationship between them.
In theory, a paper with this structure should be
sufficient. However, the structure is flat and lacking
in detail. The general norm is to introduce some
background material before talking about the
research problem. However, what should this
background material be and where should it be
placed (seeing as several areas of research need to be
introduced)? In our opinion, this is where a DN can
play a major role. Trying to say the story, naturally,
will help answer some of these questions.
So, Author B responds by e-mail:
“It’s likely that many people at this
conference will be from a collaborative
writing background. While being aware
of merging techniques, narrative-based
writing will be new to them. We should
definitely include some background
material on merging techniques,
collaborative writing and, in particular,
narrative-based writing. What do you
Author B goes on to make multiple changes to
the RS-tree. She adds two new segments to the DN
and changes the RST analysis. In the tool, this
would have to be done in several stages because the
tool tracks and records every change by creating a
new version. These intermediate stages have been
omitted for simplicity and the version by Author B
has been labelled as version 2 in Figure 6. (Note
that the segments in the DNs have all been uniquely
labelled for clarity, even though some segments
appear in all the DNs.)
Note that Author B has linked two pieces of
background information into the DN. Segment 3
about collaborative writing is the background to the
problem and segment 5 about narrative-based
writing is the background to the solution. This, in
her opinion, is the most natural way to narrate this
story. These changes are accepted by the other
The SOLUTIONHOOD relationship is marked
by the tool as being unsatisfied due to the changes
made to the DN. Despite not doing a formal review
of the relationships to change its state to “satisfied”,
the authors agree that it is still valid and get started
with the writing. Authors A and B agree to do
sections I, II, III and VI. Author C gets assigned
sections IV and V. They are aware of how these
sections should be linked (dictated by the RST
Version 2 (derived from version 1 by Author B)
Figure 6: Version 2 of the DN and RS-tree (created by
Author B), and possible outline for the paper.
Meanwhile, Author C recognises the lack of a
MOTIVATION or JUSTIFY relationship in the DN
to address the ‘So what? How is this useful?’
question that may arise in the reader’s mind. To
rectify this, Author C adds a new node and a
MOTIVATION relationship to version 1 of the DN.
She believes this will improve the document.
3: Coherence is harder to achieve in
collaborative writing when authors work on
replicas of a document.
4: Merging techniques guarantee syntactic
convergence but not the coherence of the
5: Narrative-based writing is a technique to plan
coherent documents.
6: Integrating merging algorithms with
narrative-based writing can fill this gap.
I. Introduction
II. Background
III. The problem
IV. Narrative-based writing
V. Our solution
VI. Conclusion
ICEIS 2007 - International Conference on Enterprise Information Systems
Version 3 (derived from version 1 by Author C)
Figure 7: Version 3 of the DN and RS-tree (created by
Author C).
In Figure 7, note that segments 8 and 9 are
involved in a MOTIVATION relationship. Segment
9 provides the motivation to carry out the research
outlined in segment 8. Section IV in the outline
corresponds to segment 9 in the DN.
The other authors realise the usefulness of a
MOTIVATION relationship in the DN and agree that
it is an essential component of a winning paper.
However, they still think the background material in
Version 2 is important too. Seeing that both version 2
and version 3 were derived from version 1, they use
the tool to merge the two DNs to produce the results
below (version 4 in Figure 8).
The authors are confident with this merged
version. The RST relationships are all still valid
(even though the tool has marked SOLUTIONHOOD
as “unsatisfied” according to the implemented
protocol). The scene for the paper is set by sections II
and III which will explain why coherence is harder in
CW, give an overview of the shortcomings of current
merging techniques and describe how this affects
documents. Next, the solution is introduced together
with a short tutorial on narrative-based writing which
is necessary to fully comprehend the nature of the
proposed work.
Version 4 (merged from versions 2 and 3
by Author A)
Figure 8: Version 4 of the DN and RS-tree (created by
Author A).
The Benefits section can contain applications or
examples of where the solution will help the
existing situation. This will be the motivation that
led to the development of these ideas.
For the actual paper, the DN was changed again
so that the satellite of the MOTIVATION
relationship preceded the solution and so on.
However, we stop the example here because the
essential attributes of how the DN and the tool can
assist in planning a document have been shown.
7: Merging techniques guarantee syntactic
convergence but not the coherence of the
8: Integrating merging algorithms with narrative-
based writing can fill this gap.
9: This is a unique solution that helps writers
produce better documents.
I. Introduction
II. The problem
III. Our solution
IV. Benefits
IV. Conclusion
10: Coherence is harder to achieve in
collaborative writing when authors work on
replicas of a document.
11: Merging techniques guarantee syntactic
convergence but not the coherence of the
12: Narrative-based writing is a technique to plan
coherent documents.
13: Integrating merging algorithms with
narrative-based writing can fill this gap.
14: This is a unique solution that helps writers
produce better documents.
I. Introduction
II. Background
III. The problem
IV. Narrative-based writing
V. Our solution
VI. Benefits
VII. Conclusion
Coherence is the attribute of a document that makes
it easy to understand, and is often harder to achieve
in CW because multiple authors are responsible for
the content. Coherence can be linked to the implicit
story conveyed by the document to the readers.
However, software support for this aspect of writing
is almost non-existent. Even planning techniques
such as outlining do not seem to adequately address
the problem. Narrative-based writing is a planning
technique that was introduced to address this
problem. It involves creating a DN and analysing it
using RST to evaluate and improve its coherence.
The segments in the DN correspond to sections in
the document. We claim that a better DN will lead
to a better document.
The DN provides a way of quickly discovering
the natural progression of concepts in a document.
The authors need to think of the best possible story
that their ideas can be fitted into. The corresponding
RST analysis gives some evaluation of the story’s
coherence and also helps point out ill-fitting story
segments and better alternatives. When several
authors have opinions on the content of the paper,
forcing themselves to create a DN helps combine
these ideas into a coherent whole.
A tool has been built to help authors engage in
narrative-based writing. The tool helps manage the
versions, store the RS-trees and draw the authors
attention to unsatisfied relationships (particularly
beneficial in large analyses). This paper has
presented an example that shows how this tool and
technique can be used by a team of authors. The
changes in the DN made by each author are reflected
in the plan for their document. The DN is updated
until all the co-authors are confident that it is the
most effective for the purpose of their document.
Existing CW tools like CVS already have
advanced features to manage and merge versions,
making it unnecessary for us to re-visit these areas in
our implementation. What existing tools appear to
lack is support for coherence. We anticipate that the
inclusion of DNs and support for RS-trees in these
tools will bridge this gap, and assist co-authors even
Abbott, H. P. (2002) The cambridge introduction to
narrative, Cambridge, UK, Cambridge University
Cederqvist, P. (2002) Version Management with CVS,
Network Theory Ltd.
De-Silva, N. & Henderson, P. (2005) Narrative Support
for Technical Documents: Formalising Rhetorical
Structure Theory. 7th International Conference on
Enterprise Information Systems (ICEIS). Miami, FL,
De-Silva, N. & Skaf-Molli, H. (2006) Narratives to
preserve coherence in collaborative writing. The
Eighth International Workshop on Collaborative
Editing Systems. Banff, Canada.
Henderson, P. & De-Silva, N. (2006) A narrative approach
to collaborative writing: A business process model.
8th International Conference on Enterprise
Information Systems (ICEIS). Cyprus.
Hobbs, J. R. (1985) On the coherence and structure of
discourse. Center for the study of language and
information, Stanford University.
Lehnert, W. (1981) Plot Units: A Narrative
Summarization Strategy. IN LEHNERT, W. &
RINGLE, M. (Eds.) Strategies for Natural Language
Processing. New Jersey, Lawrence Erlbaum
Lowry, P. B., Curtis, A. & Lowry, M. R. (2004) Building
a taxonomy and nomenclature of collaborative writing
to improve interdisciplinary research and practice.
Journal of Business Communication, 41, 66-99.
Mann, W. & Thompson, S. (1988) Rhetorical Structure
Theory: Toward a functional theory of text
organisation. Text, 8, 243-281.
Marcu, D. (2000) The Theory and Practice of Discourse
Parsing and Summarization, The MIT Press.
Noël, S. & Robert, J.-M. (2004) Empirical Study on
Collaborative Writing: What do co-authors do, use,
and like? Computer Supported Cooperative Work, 13.
Onega, S. & Landa, J. (1996) Introduction. IN ONEGA, S.
& LANDA, J. (Eds.) Narratology. New York and
London, Longman Group Ltd.
Roth, A. J. (1999) The research paper: process, form and
content, USA, Thomas Learning Inc.
Tichy, W. F. (1982) Design, implementation, and
evaluation of a Revision Control System. 6th
international conference on Software engineering.
Tokyo, Japan, IEEE Computer Society Press.
Torrance, M. & Bouayad-Agha, N. (2001) Rhetorical
Structure Analysis as a method for understanding
writing processes. IN DEGAN, L., BESTGEN, Y.,
SPOOREN, W. & WAES, L. V. (Eds.)
Multidisciplinary Approaches to Discourse.
Amsterdam, Nodus.
ICEIS 2007 - International Conference on Enterprise Information Systems