Page tree
Skip to end of metadata
Go to start of metadata
Title (Goal)

Generate Handle / Allow access before committing Item

Primary ActorSubmitter
Scope 
Level 
Story (A paragraph or two describing what happens)

Grace Hoppers paper has been accepted. The journal requires her to provide accompanying data at a permanent url.  So she uploads the relevant data to her universities DSPACE instance and provides the generated handle to the publisher. The item becomes accessible under the given handle url, so that the journal reviewers can access it. None of the DSPACE pages link to the item though, since it is not fully committed yet. It is essentially hidden and only accessible via direct url.

During the journals review process she is asked to change some of her data files:

  • change the format of one bitstream,    
  • replace the results of a computation with the results of a slightly changed data analysis
  • add additional data

After the article is published she adds the DOI and finally marks the item as ready to be committed to the DSPACE instance so it enters the regular DSPACE review process. The collection review makes sure all local conventions have been fulfilled and approves the submission. The item along with its handle becomes fully visible at this point.

In the unlikely case that Hopper withdraws her article from publication, she lets the collection  reviewer know, who rejects the item. At that point the generated handle needs to be dealt with, it could be redirected to the tombstone  

3 Comments

  1. I have a few (minor) clarification questions regarding this use case:

    1. I'm not sure I fully understand what is meant by an item being "committed". It sounds like the implication is just that this Item is in DSpace, but it's "hidden" by default from browse/search (only findable by sharing the direct URL).  So, does the statement "marks the item as ready to be committed" just simply mean that the user is "un-hiding" the item (i.e. it then becomes visible in search/browse)?
    2. I'm assuming the "review process" mentioned here is some sort of external review (i.e. not in DSpace) from the Journal publisher/reviewer themselves?  I'm just trying to clarify which steps DSpace is expected to perform (as DSpace is obviously not a full journal publishing system), and which parts are external to DSpace.

    Overall, the Use Case does sound interesting. It seems like it also might have some basic commonalities with this other use case, which asks for the ability to allow original submitters to be able to edit the existing document:  End User - Item editing by original submitters

  2. I edited the use case to clarify

    • yes sharing is done via direct url only
    • yes the committing means 'unhiding'
    • and yes there is an outside journal review process but there may also be a DSPACE specific review process

    This idea is indeed related to the 'End User - Item editing by original submitters' use case. But this approach should be easier to realize, since it circumvents the need for keeping track of changes, because the generated handle becomes 'official' after the item has settled into its final state. 

  3.   DS-1705 - Getting issue details... STATUS relates to this