Workflow in Hydra, Curation concerns & Hydra in a Box with Jeremy & Justin


Jeremy - Princeton has a workflow with curation concerns. There is a move to put Sipity into Curation Concerns.
Asks: Questions about what people need in a workflow.


Someplace is using bags used for ingesting.
Differing workflows for ETD ingest. some from Proquest some via student self deposit.
UVA has a custom Admin interface to their repository. Separate Rails App that talks to Sufia. Dartmouth has something similar.
Copenhagen has a requirement for ETD ingest.
Some places have ETD workflows that track the student's progress on their Thesis like "in progress", "defended but not yet approved", "approved"
Tufts has Mira which is a separate hydra head for ingesting objects.
Mention of someplace that uses a PHP based application.
Show of hands needing a separate application that provides workflow.
The Sipity based work has not yet been folded into Curation concerns.
# diagramming possible workflows
The goal is to support any kind of workflow.
transition from outside the system to 'published'
media deposit workflows may have just 1 or 2 steps or many.
Need to be able to support flagging content and/or removing.
Challenge of associating roles with changing the state of an object or batch. Who can push something from 'pending' to 'published'.
Need recognized for a user interface for management of users, groups and their privelege.
Sipity associates workflows with object states.
Jeremy explains the workflow proxy concept in Sipity.
Dspace has some UI for group and roles workflow but the workflow in Dspace is not flexible and very linear. Someone points out that Dspace has configurable workflows but the UI in an XML documents.
Actions:
Notifications: to whom, by what mechanism.
DOI assignment
Sipity has a single controller that updates workflow state.
Discussion of sequential actions that have to occur as objects transition along a workflow path.
There needs to be protections enforced at certain points of the workflow. example: an approved ETD can not be updated by the dissertator.
A depositor may not be able to edit an object after deposit or after approval. The system needs to accommodate various institutions needs.
Requirement: Curation concerns should have a function to strip permission from an object.
Ownership of an object may need to change during the workflow.
It would be good if workflows can be shared accross institutions.
Jeremy talks about workflow callback functions.
Include some sample workflows with Curation concerns / Hydra in a Box.
Jeremy recommends iteratively diagramming ETD workflows with your Grad School.
A workflow may need to accomodate auto assignment of objects to a curator or cataloger based on the area of study (History, Biology, ). Or a deposited work may need to enter an "assign to cataloger" state.
Currently the "type of work", "person", "attributes of the work (form fields values)" determines what workflow a work is assigned to.
A lot of use cases were expressed in this session and the goal of this development effort is to provide an 80% solution. A solution that helps 80% of the audience.
Project Goal: ecapsulation of the software for re-use.
indylib/Sipity is where to find Sipity code.
The workflow in Curation Concerns project is inspired by Sipity and has some of its functionality but it is stripped down version.