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 schrieb am Mittwoch, 21. Februar 2024 um 16:11:48 
UTC+1:

> 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/75c89ff9-4a6f-4112-912f-73274d4e1e80n%40googlegroups.com.

Reply via email to