PubMan Workflows

Standard Workflows

For the publication process two core workflows are identified, the “Standard Publication Workflow” and the “Standard Modification Workflow”.

Standard Publication Workflow

https://subversion.mpdl.mpg.de/repos/smc/tags/public/PubMan/WF_Publication_Standard.jpg

Standard Modification Workflow

https://subversion.mpdl.mpg.de/repos/smc/tags/public/PubMan/WF_Modification_Standard.jpg

Currently, workflow engines are under evaluation for implementing the envisioned workflows. see Workflow engine evaluation

Other Workflows (currently implemented)

In order to demonstrate the flexibility of the workflows, possible alternative workflows named “Simple Publication Workflow” and the “Simple Modification Workflow” are also defined. They are the default workflows for now. Besides that we have implemented two further workflows, which are extended for the step "submit", in order to enable a quality assurance for metadata. These two workflows are listed after the two simple workflows.

Additional publication workflows can be defined between the steps “UC_PM_SM_03 submit item” and “UC_PM_QA_08 release item”.

Additional modification workflows can be defined between the steps “UC_PM_QA_11 modify item” and “UC_PM_QA_08 release item”.

Simple Publication Workflow

https://subversion.mpdl.mpg.de/repos/smc/tags/public/PubMan/WF_Publication_Simple.jpg

Simple Modification Workflow

https://subversion.mpdl.mpg.de/repos/smc/tags/public/PubMan/WF_Modification_Simple.jpg

Extended Publication workflow

Depositor can only submit an item. Only if the moderator checked the item and released it, it is visible to the public. https://subversion.mpdl.mpg.de/repos/smc/tags/public/PubMan/WF_Publication_MPIPL.jpg

Extended Modification workflow

The depositor can correct/change the released entries s/he has created. If s/he finished the change, the item goes back to the submitted state and only the moderator can release it again after s/he checked it. https://zim01.gwdg.de/repos/smc/tags/public/PubMan/WF_Modification_MPIPL.jpg

Status of an item

• Pending

Pending items can be edited and deleted by the owner. They can not be searched but are visible to the owner (my items).

• Submitted

Submitted items can be viewed and edited by the users assigned to workflow tasks. They can not be searched but are visible to the owner and the users assigned to workflow tasks. In the currently implemented standard workflow submitted items can be viewed by the owner of the item (depositor) and by the moderator of the collection. Submitted items can be edited by the moderator or sent back for rework (by the moderator) to the depositor.

• In rework

Items in rework have been sent back to the owner during the publication workflow. They can be edited and deleted by the owner. They can not be searched but are visible to the owner and the respective moderator.

• Released

After the publication workflow has been finalized the item is released. It is now visible and searchable by all users.

• Withdrawn

Withdrawn items are not searchable. They can be retrieved by their owners or directly by PID. The attached file is no longer retrievable.

Locking

In a web application it often happens that a user starts editing a record and then leaves without using a "Cancel" or "Logout" action. If a pessimistic locking method is used, other users who want to edit the same record have to wait until the lock of the first user expires. To avoid this unnecessary waiting but still assure that records are not silently overwritten an optimistic locking method is used. The used optimistic locking method is based on timestamps. Whenever an item is read a timestamp is retrieved. During an update the timestamp is compared with the actual persistent timestamp. If the timestamps are equal the updated can be performed and the item timestamp is updated too. If not the item has been changed since the read of the item and the update is refused. The user gets the message that the item has been modified in the meantime. To minimize the occurrences of the situation that two users modify one item concurrently and the first who saves wins, a user is informed when an item is already in modification by another user. So whenever a user u1 starts an action which modifies the item this information is stored as a kind of lock. If another user u2 starts a modification action on the same item, he is informed that the item is already in modification by the user u1. Then user u2 can decide whether he wants to start the modification action anyway or cancel the modification action. Locking is only necessary for modification action that be done by more than one user at the same time. An item in the state pending can only be edited by the owner of the item, so locking is not necessary.

Use Case

Quality Assurance

Persistent Identifer or Identification