Web-based Learning Solutions for Communities of Practice

are often manually encoded on a case-by-case
basis using specific transformation languages such
as XSLT (World Wide Web Consortium, 1999).
The process of transformation and thus of reuse is
generally divided in three main phases (Kuikka,
1996). The first one aims at understanding the
source and target schemas’ structures. The goal
of the second phase is to discover schemas’ mappings
by means of inter-schema correspondences,
capturing input and output constraints imposed on
the documents. In the third phase discovered mappings
are translated into an appropriate sequence
of operations in a given transformation language
over the input document, to produce the required
output document (which requires non-trivial programming
skills). The transformation process has
long been known to be extremely laborious and
error-prone at several levels.
The aim of the structured document reuse
tool “DocReuse” is to allow existing documents
initially structured for a given purpose to be
restructured for use in a different context, thus
improving reusability and information sharing between
communities of practice. DocReuse tool is
composed of two services: (1) Automatic matching
and transformation: takes as input two templates
(source and target), a set of source instances and
produces automatically structured target instances.
The goal is to enable CoP members to transform
structured documents in a transparent and automatic
manner. The automatic transformation is
based on a mapping file produced automatically
by the system. (2) Template-driven evolution:
ensures the automatic adaptation and validity of
instances when templates evolve. Moreover, it
enables CoP members to modify the template
without knowing XTiger syntax.
Motivating Examples
Here we present motivating examples that show
how the manual reuse process is difficult. Figure
2 depicts two examples of templates (used by
two different CoP groups) that describe the bib-
18
A Document Reuse Tool for Communities of Practice
liography used by CoP groups in order to support
their activities.
Example 1: One CoP group (using template
1) wants to use data produced by another CoP
group (using template 2) in order to enrich his
already produced bibliographic references. Since
the two groups are structuring their data in a different
manner (publications are either classified
by author or by category), the first group needs
first to identify the correspondences between the
two templates then to restructure each instance
of template 2 which is a time consuming process.
Moreover, this kind of restructuring requires the
mastery of the XSLT transformation language.
Using the automatic matching and transformation
service, a CoP user needs just to upload the two
templates and instances he wants to transform, the
system identifies the similarities between the two
templates and automatically generates transformation
script as well as transformed instances.
Example 2: Let us now consider the CoP group
working with the template 1. Let’s imagine that
after a certain time; they want to make the template
evolve by splitting the author name into two subelements
First Name and Last Name. Performing
the suggested change leads to the invalidity of
the related instances. To remain valid according
to the new change, each author name instance (in
each article and each book) should be removed
and two sub-elements First Name and Last Name
should be created, paying attention to keeping their
content corresponding to the original author name.
Manually modifying the instances will be time
consuming. Moreover, if the user is not familiar
with the XTiger language (which is the case of
the majority of CoP members) the task will be
infeasible. Using the template driven evolution
service, a CoP member has just to select the author
name, to choose an operation “Split” and to select
the instances he want to make evolve, the system
will automatically generate a new template and
new valid instances.