Page History

...

The goal of the curation system ('CS') is to provide a simple, extensible, way to manage
routine content operations on a repository. These operations are known to CS as 'tasks', and they
can operate on any DSpaceObject (i.e. subclasses of DSpaceObject) - although
the first incarnation will only understand Communities, Collections, and Items - viz. core
data model objects. Tasks may essentially work on only one type of DSpace object - typically
an item - and in this case they may simply ignore other data types (tasks have the ability to
'skip' objects for any reason). The DSpace core distribution ought to provide a number of useful
tasks, but the system is designed to encourage local extension - tasks can be written
for any purpose, and placed in any java package. What sorts of things are appropriate tasks?

Some examples:

• apply a virus scan to item bitstreams (this will be our example below)
• profile a collection based on format types - good for identifying format migrations
• ensure a given set of metadata fields are present in every item, or even that they have particular values
• call a network service to enhance/replace/normalize an items's metadata or content
• ensure all item bitstreams are readable and their checksums agree with the ingest values

...

If a task extends the AbstractCurationTask class, that is the only method it needs to define.

Task Invocation

Tasks are invoked using CS framework classes that manage a few details (to be described below), and this invocation can occur wherever needed, but CS offers great versatility 'out of the box':

1. On the command line

A simple tool 'CurationCli' provides access to CS via command line. For example, to perform a virus check on collection '4':

./dsrun org.dspace.curateCurationCli -t vscan -i 123456789/4

As with other command-line tools, these invocations could be placed in a cron table and run on a fixed schedule, or
run on demand by an administrator.

1. In the admin UI

In the XMLUI, there is a 'Curate' tab (appearing within the 'Edit Community/Collection/Item') that exposes a drop-down list
of configured tasks, with a button to 'perform' the task, or queue it for later operation (see section III below). You may
filter out some of the defined tasks (not appropriate for UI use), by means of a configuration property.

1. In workflow

CS provides the ability to attach any number of tasks to standard DSpace workflows. Using a configuration file
(workflow-curation.xml), you can declaratively (without coding) wire tasks to any step in a workflow. An example:

<taskset name="cautious">
<flowstep name="step1">
<task name="vscan">
<workflow>reject</workflow>
<notify on="fail">$flowgroup</notify>
<notify on="fail">$colladmin</notify>
<notify on="error">$siteadmin</notify>
</task>
</flowstep>
</taskset>

This markup would cause the virus scan to occur during step one of workflow, and automatically reject any
submissions with infected files. It would further notify (via email) both the reviewers (step 1 group), and the
collection administrators, if either of these are defined. If it could not perform the scan, the site administrator
would be notified.

Like configurable submission, you can assign these task rules per collection, as well as having a default for
any collection.

1. In arbitrary user code

If these pre-defined ways are not sufficient, you can of course manage curation directly in your code. You would use the CS helper classes. For example:

Collection coll = (Collection)HandleManager.resolveToObject(context, "123456789/4");
Curator curator = new Curator();
curator.addTask("vscan").curate(coll);
System.out.println("Result: " + curator.getResult("vscan"));

would do approximately what the command line invocation did. the method 'curate' just performs all the tasks configured
(you can add multiple tasks to a curator).