Self-submission in ReDBox

Showing 1-6 of 6 messages
Self-submission in ReDBox Duncan Dickinson 9/6/12 5:45 PM
Hi All,

A number of ReDBox community members have had discussions with me regarding modifications to ReDBox to allow for researcher self-submission and I thought I'd take the opportunity to start looking at how we could achieve this - from a business end rather than a technical end.

Firstly, the model for self-submission is (potentially) based on a model of researcher submissions from a range of workflows, including:
  • Self-submission: Researchers submitting their own metadata
  • Data management planning (DMP): Researchers defining a data management plan that may, eventually, provide metadata to a collection record
  • Provisioning: Researchers requesting resources (such as HPC or storage) that may, eventually, provide metadata to a collection record
In all of these models, the (ReDBox-biased) workflow might appear as:
  1. Researcher logs into ReDBox and creates a new record (in their inbox), using a form focussed on their goal (self-sub, DMP or provisioning)
    1. The researcher may keep a draft to get back to later
  2. Once ready, the researcher will submit the form. The submitted form might:
    1. For self-sub, enter the reviewing workflow
    2. For DMP, store the plan and send notifications to the relative groups that a plan has been created
    3. For provisioning, store the request and send notifications for the resource to be prepared
So, there are some (many) decisions that need to be made, including:
  1. Should the researcher be able to drag a record back from the review workflow for editing?
    1. I think that this could be quite confusing
  2. When in the inbox (draft) should others (such as a group) be able to share the record?
  3. Can the DMP and provisioning metadata be somehow reused in a collection description?
  4. Should there be linking between collections, DMP and provisions?
    1. This isn't really covered in RIF-CS but could be useful
I don't want to go too far at this point but thought I'd lay a basis for feedback so please send through your thoughts.



Duncan Dickinson 

QCIF Project Manager 

Central Queensland University 

My contact details:

ph: 07 3138 2084

m: 0432 402 511

skype: de.dickinson

website calendar | LinkedIn

Project involvement

ReDBox (Research Data Box)

TERN Central Portal

Tropical Data Hub

Developer? Check out dev8D-AU at

Re: [ReDBox] Self-submission in ReDBox Peter Sefton 9/6/12 5:56 PM
I'd add that some of these submission models might actually take place elsewhere, eg Researcher fills out a form in the help-desk system to request storage, and the HelpDesk system or staff deposit part of the form as a DMP. So what I'd suggest for all of these would be to think about a submission API.

-- Website:
You received this message because you are subscribed to the Google Groups ReDBox group. To post to this group, send email to To unsubscribe from this group, send email to For more options, visit this group at


Peter Sefton +61410326955
Gmail, Twitter & Skype name: ptsefton

Re: [ReDBox] Self-submission in ReDBox Duncan Dickinson 9/6/12 7:47 PM
Hi Peter,

Agreed - and this can work through the Alerts system in ReDBox (e.g. In a nutshell, the system can pick up a file (XML but other formats could be made available) and map it into the ReDBox metadata.


Re: [ReDBox] Self-submission in ReDBox Peter Sefton 9/6/12 8:03 PM
Ok, but I think we should be looking at an HTTP based API as well - probably not too hard as it can leverage the forms interface already there - it's all http posts, right?
Re: Self-submission in ReDBox 9/10/12 10:03 PM
Hi Duncan,
Deakin is particularly interested in researcher self-submission. We had noted that ReDBox is very focussed on the administrator. Feedback from our researchers has indicated that expecting them to enter metadata for their collections into ReDBox is likely to deter the researcher from completing a metadata record. It seems very seperate from other activities that they undertake in the research lifecylce therefore is likely to be seen as an additional overhead. We have been considering how we could provide a front end to our researchers that is integrated with their current research practices so that for instance, a metadata record is created automatically when a project is created in ResearchMaster, metadata fields are prefilled with information from ResearchMaster where possible and the record is displayed to the researcher to confirm the information that we already have for their data collection metadata record and provide additional information where they are able to. One of our researchers had suggested that we take a look at as an example of a tool that researchers are familiar with using, is focussed and built around the persona of the researcher and that provides questioning functionality (questions them to agree or disagree with publications that may or may not belong to them).
The questions that you pose around the workflow are interesting:
1. It is a very real possibility that the researcher may want to edit the record once it has been submitted for review. Even once the record has been published it may potentially need to be updated. So this is something that will need to be accommodated with researcher self-submission.
2. Not too sure about this one. I think we'd need to ask our researchers if they would want others (who they are able to specify) to be able to edit the metadata record when in the creation stage.
3. We have also been considering how we might implement a data management planning tool to support the researcher to manage their data more effectively. I am interested in your statement about possibly feeding info from the data management plan in to the metadata record. This could be a great way of collecting the required info for the record while also providing valuable input to the data management plan.
4. This idea of linking the collections to the Data Management Plan is one that we would have to investigate further. The researcher may not want to widely share the information in the data management plan but if a link could be made that was only accessible by the creator of the record for instance this may be useful.
If QCIF are seriously considering building a self-submission interface for researchers to submit their own metadata that is focussed on the researcher rather than the administrator, Deakin would be very interested in providing further input to this.
Thanks Duncan!
See you at the Virtual infrastructure conference if you're there!
Re: [ReDBox] Self-submission in ReDBox Marianne 9/10/12 11:57 PM
JCU has been doing self submission for a while with our prototype system and are now hoping to move to ReDBox and do the same. We couldn't manage to do everything we wanted in the prototype but here is how we want it to work:

  • Researchers enter metadata. Where possible we try and harvest existing data from university systems but most collection metadata is unique to the collection. 
  • Workflow in current system:
    • new record initially in a "private" state. Only visible to the user who created and anyone they nominate as being able to view and/or edit.
    • one user is happy with the record they submit it for review. At this point it enters the "Pending review" state.
    • In the pending state, only the reviewer can edit the record but anyone who had edit rights in the private state can retract the record from pending and return it to private.
    • The reviewer can either publish the record (if its ready for publication) or send it back to private with notes to the researcher on what they need to fix.
    • Once the record is published only the site administrator can edit it or return it to a private state.
  • What we would have liked to do is add the ability to "check out" a copy of the published record in order to allow editing by the original owners of the record. The edited version would then go back through the same workflow and replace the original published version only if it made it through the review process. This way researchers could fix typos or add additional information to the metadata when it became apparent it was needed at a later date.
So for Duncan's list of points, JCU's wishlist would be
  1. Yes, would like retract abilities
  2. Yes, would like to be able to share the edit and/or view privileges with a group of users
  3. Yes - or even another collection record (something that has been requested by researchers). Some of our datasets are from the same research project using the same methodology but for a different geospatial location or some other slight change. Creating a new record by pre-filling it with an existing record or data from the DMP or provisioning form would be handy.
  4. Not sure - I kind of think of the DMP and provisioning request as things that exist in order to get to the data collection point and that once the data collection exists with a metadata record then they are superfluous - but I'm happy to be mistaken :D

Marianne Brown
Project Manager - TDH Project, eResearch Centre
Division of Research and Innovation
James Cook University, Townsville QLD 4811 AUSTRALIA
P (07) 4781 6904; I +61 7 4781 6904; M 0403 889 478
Location: Faculty of Science & Engineering Room 143 (Building 17.143)
JCU CRICOS Provider Code: 00117J

Note: The contents of this email transmission, including any attachments, are intended solely for the named addressee and are confidential; any unauthorised use, reproduction or storage of the contents and any attachments is expressly prohibited. If you have received this transmission in error please delete it and any attachments from your system immediately and advise the sender by return email or telephone. James Cook University does not warrant that this email and any attachments are error or virus free.