DSpace 7.6.1 How to suppress automatic DOI generation and registration for imported items?

[Matthias Letsch]

Hi there,

I have activated automatic DOI generation and registration for new items on Datacite. Above all, items that are newly submitted manually via the submission form should receive a DOI.

I am also currently testing a mass import of an old external repository via batch import (SAF). This involves a quantity of around 8k items.

For a subset of about 150 items imported yesterday as a test, all items have now been automatically provided with new DOIs and these have been sent to Datacite fabrica test. However, these items (old journal articles) should not receive a DOI at all, as some of them already have one. Furthermore, registering all these items in the productive system would be incredibly expensive. It is therefore absolutely necessary to suspend the DOI registration for these items.

I have also noticed that a new DOI is always generated automatically when importing e.g. articles from external sources such as CrossRef, which a user can also initiate. However, most imported articles already have a DOI.

Is there a way to prevent DOI registration for imports without deactivating it completely? Or can it be set somewhere so that only items received via the input screen actually receive a new DOI?

Thank you and kind regards,
Matthias

[Matthias Letsch]

Hi there,

I'd like to repeat my question, because I still really need support with this.

Brief summary:
- Items that are entered by users via the input mask should generally receive their own DOIs (with the exception of secondary publications that already have a different DOI).
- Imports via SAF or from other external sources, however, shall not (expensive and/or redundand). A SAF mass import with over 8000 items is being planned.
- The DOI service in DSpace apparently works in such a way that either ALL items whit no exceptions get an in-house DOI (activated) or alternatively NO item at all (deactivated).

--> I currently know that I can comment out the DOIIdentifierprovider.xml in identifier-service.xml and restart the server in order to completely interrupt the DOI generation for the period of my SAF import (which can take a very long time). However, this cannot be the desired approach, as it means that no other user should enter any other new item during this time, for which item an in-house DOI may be necessary after all.

I have read through the documentation at https://wiki.lyrasis.org/display/DSDOC7x/DOI+Digital+Object+Identifier, but it does not cover the case of exceptions.

Is there really no other possibility to make items exceptions to the automatic doi generation while activated? Maybe I'm missing something obvious, but as of now I haven't found a place where I could set anything regarding for which items DOIs should be provided and which not.

It's hard for me to imagine that no other institution has similar requirements to those mentioned above. (As far as I can tell all repository providers with both open access second publications and in-house first publications need to ensure that a new DOI may only be generated in certain cases). I would really appreciate any advice or other experiences on this matter!

Thank you and kind regards,

Matthias

[Agustina Martinez-Garcia]

Hi Matthias,

I believe what you are after is achieved via configuring DOI filters in spring/api/item-filtering.xml. Have a look at the example filter named "doi-filter".

This is the approach we take to avoid DOIs being registered in specific cases, e.g. the item we are importing already has an external DOI. Once the filter that meets your criteria is added, you can then configure the doi provider bean in identifiers.xml to use that filter. Via the DSpace configuration you can also set whether you want the filter to apply at submission stage (pre-registering DOIs) or only when installing items.

I hope this helps.

Agustina

[Matthias Letsch]

Hi Agustina,

thank you, that is exactly what I was looking for!

To be honest, I actually managed to somehow overlook the section "Configure filters and behavior" in the documentation (https://wiki.lyrasis.org/display/DSDOC7x/DOI+Digital+Object+Identifier)... So thank you for that.

I have adapted the filter so that it excludes all items that already contain a value dc.identifier.uri with the value "doi" or a doi pattern (regex 10\.\d{5}). In addition, the imports are excluded by a specific value in the dc.relations field, which only these imports contain. This covers my cases so far.

After archiving the items, the DOI has the status "(Minted (not registered))", so it is not passed on to DataCite. This may already be sufficient for my case, but it would be even more practical if it were completely discarded (status DELETED) so that all the numbers are not wasted. According to the documentation, it should be possible to configure a filter accordingly:

Users often want to see what DOI they will  get so they can alter their PDF, coverpage, other metadata, and so on.

This feature should ensure that users can see their future DOI, and if necessary, a warning that if certain conditions are not met, the DOI will not be registered after approval.

(https://wiki.lyrasis.org/display/DSDOC7x/DOI+Digital+Object+Identifier)

However, it is not explained in detail how exactly this can be set up. Can you possibly help here, too?

Thank you again
Matthias

[Agustina Martinez-Garcia]

Hi Matthias,

 

Great that I was able to help. We have configured the pre-registration of DOIs as per your question:

 

Users often want to see what DOI they will  get so they can alter their PDF, coverpage, other metadata, and so on.

This feature should ensure that users can see their future DOI, and if necessary, a warning that if certain conditions are not met, the DOI will not be registered after approval.

(https://wiki.lyrasis.org/display/DSDOC7x/DOI+Digital+Object+Identifier)

This is how we configure it (happy to share our config values below):

 

########################################################################

######################IDENTIFIER CONFIGURATIONS#########################

########################################################################

# These configs are used for additional identifier configuration such  #

# as the Show Identifiers step which can "pre-mint" DOIs and Handles   #

########################################################################

 

# Should configured  identifiers (eg handle and DOI) be minted for (future) registration at workspace item creation?

# A handle created at this stage will act just like a regular handle created at archive time.

# A DOI created at this stage will be in a 'PENDING' status while in workspace and workflow.

# At the time of item install, the DOI filter (if any) will be applied and if the item matches the filter, the DOI

# status will be updated to TO_BE_REGISTERED. An administrator can also manually progress the DOI status, overriding

# any filters, in the item status page.

# This option doesn't require the Show Identifiers submission step to be visible.

# Default: false

identifiers.submission.register = true

 

# This configuration property can be set to a filter name to determine if a PENDING DOI for an item

# should be queued for registration. If the filter doesn't match, the DOI will stay in PENDING or MINTED status

# so that the identifier itself persists in case it is considered for registration in the future.

# See doi-filter and other example filters in item-filters.xml.

# Default (always_true_filter)

# identifiers.submission.filter.install = doi-exclusions-filter-register

identifiers.submission.filter.install = doi-exclusions-filter-register

 

# This optional configuration property can be set to a filter name, in case there are some initial rules to apply

# when first deciding whether a DOI should be created for a new workspace item with a PENDING status.

# This filter is only applied if identifiers.submission.register is true.

# This filter is updated as submission data is saved.

# Default: (always_true_filter)

identifiers.submission.filter.workspace = doi-exclusions-filter-workflow

 

# This configuration property can be set to a filter name to determine if an item processed by RegisterDOI curation

# task should be eligible for a DOI

identifiers.submission.filter.curation = doi-exclusions-filter-register

 

# Show Register DOI button in item status page?

# Default: false

# This configuration property is exposed over rest. For dspace-angular to work,

# this property must always have a true or false value. Do not comment it out!

identifiers.item-status.register-doi = true

 

# Which identifier types to show in submission step?

# Default: handle, doi (currently the only supported identifier 'types')

identifiers.submission.display = handle

identifiers.submission.display = doi

 

Re not wasting the DOI numbers, for new items, we are actually seeing in our repository that a DOI is not minted at all by default, so it would be great to hear from someone else that has this also working to see if they have some hints on the configuration.

 

I think that this option, should also help not wasting DOI numbers if the pre-registration is enabled, and you can then apply the filter then:

 

identifiers.submission.filter.curation = your-filter-for-workspace-items

 

Best,

Agustina

--
All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
---
You received this message because you are subscribed to a topic in the Google Groups "DSpace Technical Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dspace-tech/qF9Yb3NnV50/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dspace-tech...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/75c89ff9-4a6f-4112-912f-73274d4e1e80n%40googlegroups.com.