Child pages
  • Ability to add reason for withdrawal (DS-587 - add the capability to indicate a withdraw reason to an item ( tombstone ))
Skip to end of metadata
Go to start of metadata

JIRA Issue:

Note that DCAT agreed that after we have a working set of requirements/functionality we will start a new JIRA issue for this request.

Workflow for withdrawal of items

Here are the requirements as I understand them:

When an item is withdrawn from DSpace, the administrator can select a pre-defined reason why the item was withdrawn. These might include:

  1. Removed from view by legal order
  2. Removed from view by the University
  3. Removed from view at request of the author
  4. Removed from view because of duplicate entry
  5. Removed from view for other reason [Note – is this necessary? Option b may cover this.]

In addition, an administrator should be able to add free text about why an item was removed or to reference the request. For example, when I currently remove items from DSpace, I notate the dc.provenance field with information about why the item was withdrawn, but also note the requestor’s name and the date of the email or letter.

There should be an option to allow both the reason for withdrawal and a subset (or full set) of the metadata to be displayed on the item page. The set of metadata that might be displayed upon withdrawal may be set at a system level rather than determined item by item. The free text does not need to be displayed. However, the page should return a 404 status code so that search engines no longer index it.

  • No labels


  1. This looks well thought out Sarah. I agree that we can probably leave out the "other" reason if we have a free text field to include additional information.

    Am I understanding it correctly that the reason for withdrawal will only be available to the administrators and not users?

  2. The above would be very welcome and I think the default reasons listed above would work, as long as the option for the free text is provided..Yes, it shouldn't be indexed if it is withdrawn, but I think that the error message on the 404 will have to be changed to state the reasons that the item cannot be found and a link provided to the Admin for discussion if needed.

  3. +1 on not needing option 5 if we have a free-form text field and I like Claire's suggestion that the 404 message be changed.  I had a discussion yesterday with our catalogers (who are responsible for our repository metadata) and there was some general concern about people being stymied by links that no longer work or reaching a generic 404.  Claire's suggestion takes care of that issue. 

    On the metadata--are you envisioning a choice between displaying the full metadata or a subset, or do we need to pick one or the other as part of the definition of the functionality?

    There was also a question about whether this functionality would be set for expunged items as well.  It's my understanding that we're only talking about withdrawn items--is that correct?

  4. +1 as well on no need for option 5 if we have a text field option.

    Sue: I think the reasons for withdrawal should, by default at least, be made available to all users who find themselves at the item's page. Doing so may preempt some plaintive emails asking for special dispensation to view it anyway. (I'm an optimist.) From the email discussion, I agree with (and also use) Sarah's current practice of recording additional information in a provenance field. These are not viewable by end users anyway, so they're great places to add as much additional information as an administrator (or depositor/author) desires. And, no new functionality is required to do this.

    Claire: I think the 404 error message only affects (and is only seen by) search engines. To my mind the point of the tombstone is to provide humans who have a citation to something in DSpace with a way to confirm that they didn't merely get a bogus URL...that the thing they wanted was indeed there, and accessible, at one point but that it is not there now.

    Amy: I prefer to show full metadata for an item, even when it's withdrawn. However, I could be talked into displaying a subset. My minimal metadata to display would be title, author, and date, which is usually enough to positively i.d. an item. And yes, an expunged item is completely gone -- nothing at all is shown or accessible, including metadata, so no tombstone is needed.

    From email, Sue and Amy briefly talked about whether depositors could withdraw items. I agree with Sue that they shouldn't. I don't (strongly) object to that being a possibility, but IMO -- based on many requests by depositors to withdraw things that I've been able to talk people out of -- at the very least the default behavior should be that only administrators can withdraw something.

  5. Thanks, Jim--I'd forgotten to respond to Sue's response on the question of who can withdraw.  I'm in agreement with the two of you and think the ability to withdraw should be very tightly restricted; I just didn't know if there was a use case out there for expanding that privilege that we would need to take into account. 

    On the metadata, we wouldn't go any leaner than author, title and date, but there's some resistance to the idea of leaving all the metadata in (we're adding LCSH to everything as well as some additional information), but if that's what the community would prefer, then I don't think we'd have serious objections.