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!
  • No labels

10 Comments

  1. Jim Ottaviani

    +1

  2. Iryna Kuchma

    +1

  3. 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.

  4. 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.

    1. 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.

      1. 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.

  5. 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 

    1. Of what value are the input-forms in their current design?  We repeatedly find our team using inputforms as a form of pseudo schema for validation of user input. I would recommend that we need to separate the concepts of visualization of input forms from the validation of the assigned metadata, so that validation can be applied at the time of review and archiving (possibly a curation task) rather than as a Submission Activity
    2. Of what value are the Controlled Vocabularies in their current form, again we in @mire tend to repurpose these files during import/export to validate and transform fields from other systems into expected CV values in DSpace.  In recent projects, we have actually replaced the CV and InputForms with Authority Controls and more specifically, should we work to deprecate CV's and Value Lists in favor of the AUthority control abstraction? TBH, we all know these UI that utilize popup windows are rather antiquated.   

    DSpace Needs a Validation "Engine" for Items that meets the following Criteria

    • Associates Validation Rules with DSpace Item "Content Types" independent of Submission
    • Can be used by InputForms and Submission to define appropriate forms.
    • Can be called after Packager and ItemImport tool processing to flag Items that are in an invalid state.
    • We can then associate those Content Types with Collections rather than InputForms.
    • Ideally this is considered part of the DSpace Domain Model and is persisted into either DB and/or Assetstore as a formal attribute of the Collection and/Community.
    • Ideally this is architected using the DSpace II Services Approach to allow its implementation to be an independent addon to the dspace core.
    • Ideally, this validation engine is content centric rather than collection centric, and this also pertains to the allowed metadata fields being associated with the Item Content Model, it would be best to consider it as an extension of the MetadataRegistry such that the Registry can be customized and made specific to different Item Types. And that it captures the validation ruleset for that Item type. 
    • Finally, these above requirements are similar in nature to the MetadataSchemaStorage service design requirements that did not get off the ground for DSpace II.

  6. 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 :)

  7. 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:

    • This is a complex task, and we may need to break this up into several steps.
    • May be possible to split up into: (1) better metadata validation and (2) improved form management (currently both of these are lumped together into input-forms.xml config file, which is really not ideal)
    • As you may be able to tell from full IRC discussion, the developers themselves are unsure of the best way to approach this. We may need to find a few volunteers to investigate options, especially investigate if there are any third-party, open source tools/form builders which may make this easier (rather than building something new ourselves, which is a much larger task)
    • There is a definite interest amongst the developers to see this happen. But, it may take an institution/developer (or two) volunteering some time for investigation of options and better determining requirements, etc.

    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.

  8. 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.

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.