...
Co-Mentors: Bram Luyten, Richard Rodgers, ???
Abstract
| Excerpt |
|---|
In the current DSpace implementation, a workflow system is present that allows content submitters to ingest an item in the repository, that can be reviewed by simply accepting the submitted content, changing some of the submitted metadata or rejecting the item so it can be altered by the submitter. The current collection workflow system contains up to three steps for the submission of files. Except for the metadata changes, there are no possibilities for changing any of the submission content during the different steps of the workflow system. |
In more demanding situations these few steps and editing functionalities can be insufficient to suit the requirements of the repository managers. Therefor the workflow system should be transformed into a series of different steps which can be individually defined, and can be configured on a per collection basis. It should be possible to configure the workflow system as a modular system. This way, the repository managers can choose the number and order of different workflow steps for each collection and configure each of these steps for its specified function. Also, it should be possible to change more and different content in each step of the submission. This means that it is possible to define steps in which it is possible to change not only the metadata but also for example the submitted files. This way the repository manager can maintain some interaction with the submitter during the submission process. Changes to the submitted files or info by the submitter can be requested between different steps of the process. This approach gives a lot more freedom and can result in better submissions that are optimally suited for the repository.
...
In the current DSpace implementation, a workflow system is present that allows content submitters to ingest an item in the repository, that can be reviewed by simply accepting the submitted content, changing some of the submitted metadata or rejecting the item so it can be altered by the submitter. The current collection workflow system contains up to three steps for the submission of files. Except for the metadata changes, there are no possibilities for changing any of the submission content during the different steps of the workflow system.
Workflow Step | Possible actions |
|---|---|
1) | Can accept submission for inclusion, or reject submission. |
2) | Can edit metadata provided by the user with the submission, but cannot change the submitted files. Can accept submission for inclusion, or reject submission. |
3) | Can edit metadata provided by the user with the submission, but cannot change the submitted files. Must then commit to archive; may not reject submission. |
...
An example of a more elaborate workflow is a peer reviewing workflow in which reviewers are invited who each have to review the given item, so that afterwards the appropriate manager can either approve or decline an item based on the individual reviews.
Differences in the editing possibilities could be that a submission initially just contains a short description and some metadata.
After the approval of these contents, extra files and information can be added to the submission and the reviewing process can continue.
Of course the existing functionalities of the workflow system will be preserved.
These contain the notification of the groups assigned to a step in the system, editing control and many more.
The new system will be completely backwards compatible with the current.
Goal Breakdown
...
Configuration for a simple collection workflow (submit/accept-reject/accept-reject-edit metadata):
| Code Block |
|---|
<actions>
	<action id="editMetadata" name="Edit Metadata" />
	<action id="acceptRejectAbstract" type="acceptReject" />
	<action id="uploadFullAbstract" type="uploadDocument" />
	<action id="uploadFullText" type="uploadDocument" />
	<action id="..." type="..." />
</actions>
<roles>
	<role id="submitter" name="Author" />
	<role id="convener" name="Convener" />
	<role id="editorInChief" name="Editor-in-chief" />
</roles>
<workflow>
	<step id="StartSubmission" name="Submit paper">
		<action id="editMetadata" />
		<action id="uploadAbstract" />
	</step>
	<step id="acceptRejectAbstractStep" name="Awaiting abstract approval">
		<>
	</step>
</workflow>
|
Example configuration for an elaborate (peer-reviewing) collection workflow:
| Code Block |
|---|
<actions>
	<action id="editMetadata" type="EditMetadata">
		<inputforms value="default" />
		<continuationaction id="uploadAbstract" />
	</action>
	<action id="uploadAbstract" type="uploadDocument">
		<uploadrequired value="true" />
		<continuationaction id="acceptLicense" />
	</action>
	<action id="acceptLicense" type="acceptLicense">
		<nextstep id="acceptRejectAbstractStep" />
	</action>
	<action id="uploadFullText" type="uploadDocument" />
	<action id="assignReviewersForItem" type="assignRoleMembers">
		<selectFromRole value="reviewer" />
		<addToRole value="assignedReviewer" />
		<assignmentMethod value="manual" />
		<assignmentMethod value="SomeClass.biddingAlgorithm()" />
	</action>
	<action id="acceptAbstract" type="accept" />
	<action id="returnAbstract" type="return" />
	<action id="commitToArchive" type="archive" />
</actions>
<roles>
	<role id="submitter" name="Author" />
	<role id="metadataeditor1" name="Metadata Editor (1)" />
	<role id="metadataeditor2" name="Metadata Editor (2)" />
	<role id="metadataeditor3" name="Metadata Editor (3)" />
	<role id="reviewer" name="Reviewer" />
	<role id="assignedReviewer" name="Assigned Reviewer" />
	<role id="convener" name="Convener" />
	<role id="editorInChief" name="Editor-in-chief" />
</roles>
<workflow id="default">
	<step id="StartSubmission" name="Submit paper" role="submitter">
		<action id="editMetadata" nextStep="acceptRejectAbstractStep"/> <!-- list of actions to be chosen from -->
	</step>
	<step id="acceptRejectAbstractStep" name="Awaiting abstract approval" role="metadataeditor1" defaultNextStep="editMetadataStep">
		<action id="acceptAbstract" nextstep="EditMetadataStep" /> <!-- list of actions to be chosen from -->
		<action id="returnAbstract" nextstep="StartSubmission" />
	</step>
	<step id="editMetadataStep" name="Awaiting abstract approval" role="metadataeditor2">
		<action id="editMetadata" /> <!-- list of actions to be chosen from -->
		<action id="acceptAbstract" nextStep="..." />
	</step>
...
	<step id="assignReviewers" name="..." role="convener">
		<action id="assignReviewersForItem" nextstep="reviewFullText" /> <!-- list of actions to be chosen from -->
	</step>
	<step id="reviewFullText" name="Awaiting abstract approval" role="assignedReviewer">
		<action id="editMetadata" /> <!-- list of actions to be chosen from -->
		<action id="uploadDocument" />
		<action id="acceptFullText" waitForAll="assignedReviwer" nextStep="..." />
	</step>
	<step id="commitArchive" name="Add to archive" role="convener">
		<action id="commitToArchive" />
	</step>
</workflow>
<workflow id="123456789/6546">
</workflow>
|
...
Design
Domain model analysis
Action
- These are the basic building blocks of the new workflow system
- Different types of actions
- Can be performed in a step
- Can be linked to a next action for the same user to create a sequence of actions
- Can be linked to a next step
...
- Part of the workflow system
- Can be looped
- Step combinations are restricted by certain constraints
- Example: it makes no sense to combine a reviewingstep and an acceptance step with the reviewstep as the last one in the sequence
- Different categories of steps as described in the domain model analysis
- Each step defines a role or number of roles
- Can contain a sequence of actions
Detailed Design
WorkflowPart
- Generalization of Actions and Steps
- Interface used for common parts in the workflow system
- Selection of the next step/action (depending on the current action and eventually a choice for an action)
...
- The execution of actions will be implemented using the Command design pattern
- Action types
- Actions to choose which action to perform next
- Have different next actions or steps
- Actions to perform a single operation
- Make it possible to perform an operation
- Has a pointer to a next action or a next step
- Actions to choose which action to perform next
...
- More action types could be added
- The interface for the exisiting existing actions could be improved