dc.identifier.uri for new communities/collections

[tant...@umn.edu]

In DSpace 7.6.2, newly created collections and communities are not being assigned a persistent identifier (dc.identifier.uri) in the metadatavalue table.  I have handle.canonical.prefix and handle.prefix set in dspace.cfg, and the correct metadata is generated for new items.  There are no errors in any of the log files (apache, tomcat, dspace), nor in the javascript console.  Setting the log level to DEBUG exposes other "org.hibernate.SQL @ insert into public.metadatavalue()" statements for community title, text, news, etc, but nothing for dc.identifier.uri

As I said, this metadata is generated for all new items.

Is anybody else seeing this issue or is this behavior configurable and 'off' by default or do I have some other isolated problem?

Regards,

Bill

[DSpace Technical Support]

Hi Bill,

I just tried this out on a DSpace 7.6.2 instance locally that I started using the Docker scripts (documented at https://wiki.lyrasis.org/display/DSPACE/Try+out+DSpace+7)

I had no issues creating a new Community and Collection and both received a new "dc.identifier.uri" which is displayed on the Community / Collection Homepage next to the text saying "Permanent URI for this [community]/[collection]".   So, I don't believe this is a bug in out-of-the-box DSpace 7.6.2.   (That said, if others can confirm this same behavior, then we can dig further to see if there are specific scenarios where this might be happening)

It's very odd to me that you'd see no errors when following the Troubleshooting Guide steps https://wiki.lyrasis.org/display/DSPACE/Troubleshoot+an+error#Troubleshootanerror-DSpace7.x(orabove).  You could verify that no errors appear in any of the tabs in your Browser's DevTools (especially also the "Network" tab).

Hopefully, if someone else runs into this they will mention it here as well.

Tim

[Bill Tantzen]

I haven't dug into the code any deeper, but I have discovered that if I enable

  org.dspace.identifier.VersionedHandleIdentifierProvider

instead of

  org.dspace.identifier.VersionedHandleIdentifierProviderWithCanonicalHandles

in dspace/config/spring/api/identifier-service.xml

The metadata is created and added to the metadatavalue table as expected.

Is this the intended behavior?  Off the top of my head, I would think that since versioning only applies to items, these classes should treat communities and collections the same regardless of which one is enabled.

~~Bill

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/74514521-fac0-4e5a-a0d4-d6461c4236a8n%40googlegroups.com.

--

______________________________________
Bill Tantzen    University of Minnesota Libraries
612-626-9949 (U of M)  612-325-1777 (mobile)

[DSpace Technical Support]

Hi Bill,

I don't understand how the versioning feature could impact this...as you said, it's not used by Communities & Collections.  It's also odd to me that this odd behavior would *only* impact Communities & Collections, as it should also impact Items if the versioning configuration was to blame.  Something isn't adding up here.

I can verify the I tested on my end with the default settings of "org.dspace.identifier.VersionedHandleIdentifierProvider" and everything is working.   The Demo Site also has this default setting in place and it's working fine as well: https://demo.dspace.org/  (Demo is running 8.0, but this area of the codebase shouldn't be significantly different between 7.6.2 and 8.0)

I'm really at a loss as to what the cause could be.  My only thought is to try to reinstall 7.6.2 (maybe some old config or cached JAR is causing issues?), or you could try out a 100% vanilla installation (of 7.6.2) on your local machine just to verify for yourself whether that works or not.   My suspicion is that is likely either a configuration issue, a conflicting JAR or a customization causing issues.  

Possibly the only way to determine if that suspicion is correct is to try out a completely vanilla installation (with no existing data) and see if it works.  If that works, you could then trying your local codebase (again with no existing data) to see if that works.  If it doesn't, it's something in your local codebase or configs (and you may want to diff them with defaults to see what's different).  If it still does work, then maybe there's some sort of issue at the data level (I think that's less likely here, but I could be wrong).

Tim

[Bill Tantzen]

Just out of curiosity, did *you* try toggling to org.dspace.identifier.VersionedHandleIdentifierProviderWithCanonicalHandles on your server or did you just go with the default?  Or are there any other installs out there that use this older, pre-version 6x strategy?

~~Bill

To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/675180f2-e92b-4635-9ce4-a332d789e472n%40googlegroups.com.

[Bill Tantzen]

Taking a closer look at the source code for the two choices for identifier provider classes, I see that VersionedHandleIdentifierProvider.java will persist an identifier for Community, Collection, or Item DSpaceObjects (it calls dsoService.addMetadata()).

VersionedHandleIdentifierProviderWithCanonicalHandles.java on the other hand, will only persist an identifier for Items -- Communities and Collections are ignored (it calls itemService.addMetadata()).  This class supports the legacy method of versioning that was used in DSpace 4/5 which happens to be the method we prefer to use going forward.  I believe that handles were not persisted as metadata for Communities or Collections prior to version 6.

This looks like a bug to me -- VersionedHandleIdentifierProviderWithCanonicalHandles is ignoring Communities and Collections when creating dc.identifier.uri metadata.  It works similar to the class it replaced in version 5x with regard to anything that is not an Item.

Thoughts?