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 On Wednesday 21 February 2024 at 09:24:03 UTC Matthias Letsch wrote: > 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 > > Matthias Letsch schrieb am Freitag, 2. Februar 2024 um 17:20:42 UTC+1: > >> 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 >> > -- 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 the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/5201e0f5-8a61-4da8-a36e-0bc21fe9870fn%40googlegroups.com.
