Hello together,
we have a DataCite membership and doi registration to our fabrica test environment just worked fine with the configurations set like described in https://wiki.lyrasis.org/display/DSDOC7x/DOI+Digital+Object+Identifier. We use the DataCite API directly. some weeks ago we updated up to version 7.6.1-SNAPSHOT (because of the "browse by subject group" bugfix). I also updated all necessary configuration files regarding the doi registration process: - config/dspace.cfg (everything in "DOI registration agency credential" as well as "crosswalk.dissemination.DataCite.publisher") - config/spring/api/identifier-service.xml (see attachment) - config/item-submission.xml (only for showing pending dois in the submission form) - config/modules/identifiers.cfg (see attachment) By submission a doi is created in the following syntax: 10.87220/x (x = serial number, e.g. 10.87220/7 etc.) Now our doi registration has some strange behaviors and I don’t understand where they come from: 1. The status of the doi doesn't switch automatically from "pending" to "Queued for registration" when a new submission is accepted by admin. (Before the update to 7.6.1, this was the case). 2. So I enabled „registering doi from admin“ to manually set the status "Queued for registration" in the status tab of the item via "identifiers.item-status.register-doi = true" in config/modules/identifiers.cfg. 3. Now, with some items with doi status "queued for registration" (database: 1), I used the typical dspace commands „./dspace doi-organiser -u/-s/-r/-d“, but in command –r (register) an error occured: It wasn't possible to register this identifier: doi:10.82770/7 Exception: Database table DOI contains a DOI that is not valid: doi:10.82770/7! java.lang.IllegalStateException: Database table DOI contains a DOI that is not valid: doi:10.82770/7! at (...) How is 10.82770/7 not valid? DSpace did register all dois with that syntax just fine before the dspace version update. 4. So I concluded that the registration didn’t work. Yet here the funny thing is: I looked up our datacite fabrica test environment at https://doi.test.datacite.org/ and there a new item with doi 10.82770/7 actually found its way to the registered dois. So DSpace did send the doi to DataCite. BUT in our dspace database at table doi, the doi 10.82770/7 STILL has status 1 instead of 3 (1 = queued for registration, 3 = registered) and no doi was written into the metadata (dc.identifier). Does anyone know how this can happen and which configuration file I need to change? Thank you very much! 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/9bc03cb4-0167-4891-9283-8d1f0a23585cn%40googlegroups.com.
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd";> <!-- Identifier Service Application Interface. Will be autowired with any Identifier Providers present in Spring context. --> <bean id="org.dspace.identifier.service.IdentifierService" class="org.dspace.identifier.IdentifierServiceImpl" autowire="byType" scope="singleton"/> <!-- If you enabled versioning, you should use one of the versioned handle identifier provider instead of the default one. The VersionedHandleIdentifierProvider creates a new versioned handle for every new version. --> <!-- <bean id="org.dspace.identifier.HandleIdentifierProvider" class="org.dspace.identifier.VersionedHandleIdentifierProvider" scope="singleton"> <property name="configurationService" ref="org.dspace.services.ConfigurationService"/> </bean> --> <!-- The VersionedHandleIdentifierProviderWithCanonicalHandles preserves the first handle for every new version. Whenever a new version is created the previous version gets a new handle. This leads to a handle that points always to the newest version, but there is no permanent handle, that will always keep pointing to the acutal newest one. --> <!-- <bean id="org.dspace.identifier.HandleIdentifierProvider" class="org.dspace.identifier.VersionedHandleIdentifierProviderWithCanonicalHandles" scope="singleton"> <property name="configurationService" ref="org.dspace.services.ConfigurationService"/> </bean> --> <!-- provider to mint and register DOIs with DSpace. To mint DOIs you need a registration agency. The DOIIdentifierProvider maintains the doi database table and handling of DSpaceObject. It uses a DOIConnector that handles all API calls to your DOI registration agency. Please configure a DOIConnector as well! --> <!-- In order to mint DOIs with DSpace, get an agreement with a DOI registration agency, take a look into dspace.cfg, and activate either the DOIIdentifierProvider or the VersionedDOIIdentifierProvider, depending on whether you have Item Level Versioning activated or not. --> <bean id="org.dspace.identifier.DOIIdentifierProvider" class="org.dspace.identifier.DOIIdentifierProvider" scope="singleton"> <property name="configurationService" ref="org.dspace.services.ConfigurationService" /> <property name="DOIConnector" ref="org.dspace.identifier.doi.DOIConnector" /> </bean> <!-- <bean id="org.dspace.identifier.DOIIdentifierProvider" class="org.dspace.identifier.VersionedDOIIdentifierProvider" scope="singleton"> <property name="configurationService" ref="org.dspace.services.ConfigurationService" /> <property name="DOIConnector" ref="org.dspace.identifier.doi.DOIConnector" /> </bean> --> <!-- An optional logical item filter can be included in provider configuration based on the filters defined in item-filters.xml, eg. --> <!-- <bean id="org.dspace.identifier.DOIIdentifierProvider" class="org.dspace.identifier.DOIIdentifierProvider" scope="singleton"> <property name="configurationService" ref="org.dspace.services.ConfigurationService" /> <property name="DOIConnector" ref="org.dspace.identifier.doi.DOIConnector" /> <property name="filter" ref="doi-filter" /> </bean> --> <!-- The DOIConnector will handle the API calls to your DOI registration agency for the DOIIdentifierProvider. If your registration agency tells you to use the DataCite API directly, you can use the DataCiteConnector. If your registration agency is not part of DataCite or provides their own API, you have to implement a DOIConnector. e.g. EZID is part of DataCite but provides their own APIs. The following DataCiteConnector won't work if EZID is your registration agency. --> <bean id="org.dspace.identifier.doi.DOIConnector" class="org.dspace.identifier.doi.DataCiteConnector" scope="singleton"> <property name='DATACITE_SCHEME' value='https'/> <property name='DATACITE_HOST' value='mds.test.datacite.org'/> <property name='DATACITE_DOI_PATH' value='/doi/' /> <property name='DATACITE_METADATA_PATH' value='/metadata/' /> <property name='disseminationCrosswalkName' value="DataCite" /> </bean> <!-- Provider to mint and register DOIs using EZID as the registrar. --> <!-- Set generateDataciteXML to true to send metadata in DataCite xml schema for EZID DOI mint requests. When generateDataciteXML is enabled, EZIDIdentifierProvider uses dspace.cfg:crosswalk.dissemination.DataCite.stylesheet XSL configuration for metadata mapping --> <!-- Uncomment to enable DOI using EZID <bean id="org.dspace.identifier.EZIDIdentifierProvider" class="org.dspace.identifier.EZIDIdentifierProvider" scope='singleton'> <description>Uses the EZID service to provide DOI identifiers from DataCite</description> <property name="configurationService" ref="org.dspace.services.ConfigurationService"/> <property name='requestFactory'> <bean class='org.dspace.identifier.ezid.EZIDRequestFactory'> <property name='EZID_SCHEME' value='https'/> <property name='EZID_HOST' value='ezid.cdlib.org'/> <property name='EZID_PATH' value=''/> </bean> </property> <property name='crosswalk'> <map> <entry key='datacite.creator' value='dc.contributor.author'/> <entry key='datacite.title' value='dc.title'/> <entry key='datacite.publisher' value='dc.publisher'/> <entry key='datacite.publicationyear' value='dc.date.issued'/> </map> </property> <property name='crosswalkTransform'> <description>How to compute the crosswalked value from the original. Default is plain copy.</description> <map> <entry key='datacite.publicationyear'> <bean class='org.dspace.identifier.ezid.DateToYear'/> </entry> </map> </property> <property name='generateDataciteXML' value='false'/> <property name='disseminationCrosswalkName' value='DataCite'/> </bean> --> </beans>
#----------------------------------------------------------------------# #---------------------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-filter # 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 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 = always_true_filter # If true, the workspace filter will be applied as submission data is saved. If the filter no longer # matches the item, the DOI will be shifted into a MINTED status and not displayed in the submission section. # If false, then once a DOI has been created with PENDING status it will remain that way until final item install # Default: true identifiers.submission.strip_pending_during_submission = true # 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 = always_true_filter # 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
