Page tree
Skip to end of metadata
Go to start of metadata
Title (Goal)Giving submitters a safe and easy to use interface to perform edits on existing items
Primary ActorHuman
ScopeItem page
Level 
Story (A paragraph or two describing what happens)

The repository administrator, John, has configured the repository's configuration file, so that permissions are delegated to an item's original submitter, to change his submission's metadata after archival.

Two weeks after Sally has finalised the submission of her thesis to DSpace, she realizes that she forgot to fill out the sponsorship field where she was supposed to add grant or funder information. Sally is able to login and edit the metadata of the original item, in order to put this additional information in place. However, she is not able to remove, replace or add any bitstreams to the existing item.

When Sally saved the modifications to her thesis, the item returned to the workflow. As such, the item could no longer be viewed our found through the repository's user interface.

3 Comments

  1. This usecase was discussed during the August 2014 DCAT call on end user use cases.

    Jim Ottaviani mentioned that this was implemented at the University of Michigan, allowing submitters to use the admin item edit interface for editing their own items. They can also add bitstreams but can't remove any.

    Another participant on the call mentioned that theses probably present a use case where the original submitter shouldn't (at least not automatically) get any rights to modify the metadata or files after after it has gone through the workflow.

    This usecase is related to End User - Crowdsourcing metadata for archived items but is of course more restrictive, as we are only considering the original submitter, or maybe to some extent co-authors or other contributors mentioned on the item.

  2. My opinion is that providing administrative functions  (edit metadata&add/reingest bitstreams) to end users becames more a problem than a solution.  Some problems (most of them are more philosophical than practical):

    • Dspace is "compatible" with OAIS.. And OAIS separates "ingest" functions from administrative ones.  There is no usecase on OAIS for that scenario
    • I do not feel comfortable with the idea of persistent URL tied to a "non-persistent" object  (un-controlled by the administrator)
    • We would need to maintain a track log of changes to metadata, in order to solve conflicts of "who has made what".... We need to resolve usecase:  Structure - Automated Retention of All changes to Items
    • What do we do with curation tasks that perodically changes or evolve or curate the data?  How this feature conflicts with existing administrative functionality?   It seem to me that to solve this usecase, we will have to solve some dozens of additional usecases..
    • How do we rewrite the license of deposit?   What kind of agreement between the author and the repository  can exist in that situation, if the author can change his/her deposit? does she/he need to upload another license?
    • ....

     

    Having said that, we inherited two years ago, for maintanance and evolution, a Dspace repository with that buit-in feature. In order to take charge of the contract, we instantly remove it, and nobody complains (200 hundreds registered users) 

     

  3. Regarding this use case, we know that this is important, also for the submitter/author, to have the capacity to edit/correct or improve metadata.

    From the repository manager perspective, this shouldn't be done in this, by just editing. We would prefer that the submitter/author (or any other user) submit changes that are then validated by the administrator. 

    Based on the ISO 16363 (Audit and certification of trustworthy digital repositories) and an audit we develop to repositories, one item is evaluated, the capacity of the end-user to provide feedback on each item of the repository. This can by achieved by sending an email with the page of the item or by using a more sophisticated functionality. This new functionality can be something integrated in the workflow and use the "Versioning functionality" (and also the OAIS state on another comment) to identify versions of the same item after he is validated by the administrator (the general administrator or the administrator of the community/collection).

    In this context, the OAI-PMH interface for example should also be "notified" by updating the date of the item.