JIRA Reference: https://jira.duraspace.org/browse/DS-164
Proposed: "[A] web interface for altering input-forms.xml, being able to select an input form "on the fly" based on the type of item being deposited, a web interface to the Configurable Submission System, eliminating the need to restart the server after changes to input-forms.xml and the Configurable Submission System, allowing more configuration (e.g. input-forms.xml, Configurable Submission) and command-line actions (e.g. batch imports) to be pushed down to community and collection administrators, allowing metadata specific to an eperson (e.g. name, metadata fields to exclude) to be stored in that eperson's profile. It was noted that the lack of a web interface to many DSpace configuration files means that repository managers who are not also systems administrators may not be able to configure their installations fully."
DGOC/DCAT review: A small group did an initial review of this on 2 Nov 2010, and while its status was not 100% clear to us, it doesn't appear to have progressed substantially since 2009's Google Summer of Code <https://wiki.duraspace.org/display/DSPACE/Google+Summer+of+Code+2009+Submission+Enhancements>.
Regardless, this would be a welcome change to the current functionality, which requires DSpace collection managers to have XML skills to deal with what can quickly become a very large and unwieldy input-forms.xml document. As a result, this is a barrier to new DSpace users who often can't/don't customize as desired for fear of breaking this file with a single syntax error or a missing bit of punctuation...and as a result bringing down submission capability for their entire installation! We recommend this receive a boost in priority, and if possible build on the GSoC work to implement it in a near-future release, since it would have a high impact on usability.
DCAT initial assessment: Relevant; Medium-High or High priority
Next steps: We would like to hear the community's opinions and thoughts on this, and we'd like to try using the DSpace code committers' method for indicating your level of support, since that will help make it easy for them to understand where we're coming from on these:
- If you agree with the above assessment and have no additional comments, you can simply respond with a +1.
- If you disagree but have no comments, a -1 works, and if you have no opinion at all, 0 is fine. (And encouraged, since that means we know you've had a chance to weigh in.)
- If you do have comments or other ideas, you're not limited to the numbers, of course. So please do share your thoughts!
10 Comments
Jim Ottaviani
+1
Iryna Kuchma
+1
Sarah Shreeves
+1
I do think this will be a major upgrade, but I think this kind of general functionality - allowing a gui interface to administrative functions that have generally only been accessible to changes by either programming staff or very competent and technically inclined repo managers - is really, really important. I could see this particular enhancement being developed in stages - first allowing repo managers to make these changes on a collection or community basis and then looking at tying changes to a file/genre type or a eperson.
Elin Stangeland
+1
I agree with Sarah, this is a big change, would be very useful though. It links in with work already taking place, please see under the heading "Postponed for a future release" in the 1.7 release notes: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+1.7.0+Notes
Extract: "Context Guided Ingest – define an interface, where any submission code can write "attributes" and can retrieve those again later on. Can add any new attributes/values that you want for your submission code. Could be serialized to XML (using input-forms.xml) OR have an implementation of that service that stores in DB (recommended). JPA2?"
This seems to be related and may be worth coordinating? I think it came from Richard Rodgers and Robin Taylor, although I notice that their names are not associated with this any more.
Jim Ottaviani
I agree with Sarah and Elin...I didn't mention it in my summary, but when the group discussed this live we acknowledged that even if the GSoC work was substantial this upgrade is still likely to require plenty of work.
I'll reserve judgment as to whether this is something that should get coordinated with or rolled into the "Context Guided Ingest" idea, since I don't know enough about that. What I will say is that I always hesitate to endorse rolling too many features into one big proposed change...and a change with no defined date attached. "Context Guided Ingest" sounds great, but even more complicated than DS-164, and the danger of bundling them together is that the perfect becomes the enemy of the good, so to speak, and nothing gets decided or done.
Elin Stangeland
Agreed - avoiding scope creep on ideas is not good and I am happy to keep these separated. To provide a little more detail on this, there is a JIRA ticket on this: https://jira.duraspace.org/browse/DS-464, which I'm thinking of picking up on for this week. It is a little unclear to me what status is for this, it looks like it fell through for 1.7 although at OR10 we talked of this as an obvious candidate to be included. I'll see if I manage to join the committers meeting today and ask for clarificiations.
Mark Diggory
Having participated in GSOC as a mentor for this project. I can comment that what the student created for inputforms was a functional solution that enabled support only for the forms. I challenge what we need here though, is an overall reconsideration of Item Content Modeling and Validation for DSpace
DSpace Needs a Validation "Engine" for Items that meets the following Criteria
Robin Taylor
First a bit of background info - At Edinburgh Uni we did implement the GSOC Configurable Submission Forms solution (not sure it was actually called that). I later submitted a tidied up version for consideration as a contribution for DSpace. Worth noting that I left out the bit that is most relevant to this discussion, namely the ability to edit the forms via the UI. This bit of code was less well designed and developed than the rest. This left just the functionality to create XML based input forms for different form types and select from that list during submission. It so happened Richard Rogers had simultaneously been considering enhancements to the submission process and his CGI proposal surfaced shortly thereafter. As far as I know Richard is still interested in this area and our next stop should be to seek his views on this subject.
Reading the proposal above it touches on more than just the submission process although there is a common theme, namely allowing more configuration via the UI. Some of the issues are already being discussed as JIRA issues eg https://jira.duraspace.org/browse/DS-655.
With regards to Mark's comments - absolutely agree we should separate the presentation from the validation, in order that the validation can be used for other forms of ingest. Not sure if I understand "We can then associate those Content Types with Collections rather than InputForms". Collections needn't be organised around Content Type. Maybe I have misunderstood.
I think we need to tease out what are the priorities here, stop us developers going off at our own tangent :)
Tim Donohue
Hi All,
As you can tell from some of the recent activity above, we discussed this issue & DCAT's comments in our DSpace Developers Meeting yesterday. I've added the full discussion thread to https://jira.duraspace.org/browse/DS-164
Here's the basic, high-level summary of our discussion.
The general consensus seems to be the following:
I've encouraged developers to add comments to this Forum and/or DS-164 itself. But, I think Robin's point above is a good one – currently, we are "swimming" in various ideas/tangents. It may help if we can tease out priorities/requirements. As it is, as a group the Developers don't seem to have found a good way forward. Sometimes it can also be helpful to have a few individuals bring back a "proposal" which we can then respond to (preferably with some basic requirements or even potential ideas/resources for how to implement). So, the next step may be to find interested persons/institutions.
Andrea Schweer
The repositories I'm looking after may be interested in something like this (with Tim's item (2) having a much higher priority than (1)); the alternative is focusing even more strongly on Sword forms. I am likely to have some time in the not too distant future to help investigate options. I'd also be happy to participate in discussions to figure out requirements.