5Extended example: emulating DSpace

To
demonstrate the versatility of the design, a submission workflow in Greenstone
was developed that closely emulates DSpace’s [1].
Since both are open source systems, much of the HTML was transferred directly.
The functionality is very similar, the difference being in how a submission
involving multiple files is handled—as when submitting a web page including
external resources such as images. In DSpace each file must be individually
specified from within the form-based submission process. Since Greenstone can
already handle archive formats such as Zip and Tar, we decided to ask the user
to submit multiple-file works in this form. All files that make up the work
must still be identified, but this happens outside the form-based submission,
and is usually easier since the files can be multiply selected in one go.

In DSpace,
runtime functionality for the submission process is handled by the server. If
Title metadata is compulsory this is checked when the user proceeds to the next
step of the submission process. In Greenstone the analogous functionality was
embedded into each web page using JavaScript. This offers more flexibility to
customize the workflow and more immediate feedback to the user.

Figure 4
shows snapshots of a faculty member working their way through the Greenstone
adaptation of the DSpace submission procedure. To submit an item of work the
user starts by logging in, and then selects the DSpace repository clone
collection. Using Greenstone’s collection macro override facility, this
repository provides its own tailored workflow—eight steps in all, visible at
the top of the snapshots. In the simple example of Figure 1 the progress
bar was located at the bottom of the page, but it is easy to move the position
of the macro _depositorbar_
within the structured HTML to move it to at the top. In DSpace the progress bar
is implemented as a series of images, and although we could have emulated this
we chose not to because there is an existing Greenstone facility with the same
function—furthermore it makes it easier to change the color scheme, fonts and
wording used. (We tend to avoid textual images in Greenstone to facilitate
multilingual operation.)

The
scenario here is a university that uses DSpace-style submission to manage its
staff’s digital outputs. In Figure 4a the instructor for a Machine
Learning course is at the first page of submitting a lecture on Bayesian
networks. He has entered his and a colleague’s name, the title of the talk and
its type (a presentation). Other fields such as series, report number, and ISBN
are not relevant and so he leaves them blank.

In
Figure 4b the instructor has moved to the second step, which prompts for
descriptive metadata: keywords, abstract, sponsors, and description. Again not every
field is relevant. For each part of the form contextual help is available that
describes the purpose of the field. In Figure 4c he has moved to the point
where the file (in this case PowerPoint) is requested. Next (Figure 4d)
information is displayed about the file transfer from submitter’s computer to
the server. The checksum is shown so he can check that no transmission errors
occurred. This is accomplished using AJAX
technology [7] to retrieve the information from the server in an extensible
manner.

The fifth
step (Figure 4e) provides an opportunity to review and edit all
information entered so far. It is also possible to return to any previous stage
by clicking the progress bar. Making the system remember existing fields—even
when they support an arbitrary number of values, as with authors—is tricky in
JavaScript but possible. Figure 4f shows the final user input page, where
the user decides whether to grant the distribution license. If he does, the
PowerPoint presentation, along with its metadata, is time-stamped and deposited
into the collection area. The collection’s editor will be notified by email,
and/or the collection will be incrementally rebuilt, depending on the settings
in the collection’s configuration file.