Child pages
  • DSpace 587 - Add the capability to indicate a withdraw reason to an item ( tombstone )
Skip to end of metadata
Go to start of metadata

JIRA Reference: (see also

Proposed: (from original issue DS-429) "The current implementation of tombstoning does not appear to show any item information in the tombstone. To extend the metaphor, it would be good to provide something along the lines of "Here lies item [title of item]", rather than a blank/generic tombstone -- or at least have the option to do so. We implemented a local customization that does two things. First, it continues to display metadata for the item, while preventing access to the downloadable bitstreams. This alerts the requestor that they have indeed arrived at the right place. Second, it allows the administrator to choose from a menu of withdrawal messages -- stored in dc.description.withdrawalreason so it's customizable after the fact -- that displays in the "Files in This Item" block. 

Here are some examples in our system:

Our standard phrases are "Removed from view by legal order." (haven't had to use that one yet!), "Removed from view by the University of Michigan," and "Removed from view at request of the author."

DCAT review:  While we rarely withdraw content, when we do, it's always been a problem that there is not a way to notify the public why an item was withdrawn. I believe that adding a reason would allow better trust of the repository (i.e. the item hasn't just been withdrawn for a random reason). Also, we sometimes have duplicate items deposited and tend to withdraw a duplicate item. It would be useful to be able to include a link to the remaining item. This would also be true for items that are withdrawn because a final copy has been made available.

The ticket is already assigned to Jose Blanco (University of Michigan) who developed a patch for this for the jspui at Michigan. I don't know though if that is still a current assignment.

DCAT initial assessment: Relevant; High priority 

Next steps: I think that we need to restart the discussion with the committers about this change. There are some added complications that were added by the committers (see the JIRA ticket) so I think it's worth a conversation about where this sits.

  • 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


  1. +1 (with an obvious bias; I agree that additional discussion with committers is a good idea)

  2. I had a conversation with Tim Donohue about this on Friday. He suggested that it would be helpful to pull together the comments from JIRA and develop a better set of requirements.

  3. +1 -- this has obvious good karma.  This would be great to implement.

  4. +1  We definitely have a need for this at Dryad.