Authority controlled metadata in archived items

[euler]

Dear  Colleagues,

I am testing my local installation of DSpace 7.6, specifically the authority control of metadata values. I have ported some of my authority classes from version 6 to version 7.6. The authority control works during submission, as it looks up values from an external web service. However, for archived items, there seems to be no 'lookup' button for authority-controlled metadata just like in the previous versions of DSpace. Even the language and types which I enabled to be authority controlled have no way of editing which by the way in the previous versions, these metadata fields contains a dropdown in which the user could only select those included in the list.

Edit Item metadata from version 6x

Edit Item metadata from 7.6 (no lookup and authority values, just plain textarea)

I even enabled Sherpa so that the metadata for Publishers and Journal titles were authority controlled but still, no lookup button.

The behavior is the same even if I used the included 'srsc' controlled vocabulary.

Am I missing a configuration? Or is this feature for authority control for archived items not yet ported to version 7?

Thanks in advance!

euler

[DSpace Technical Support]

Hi euler,

Unfortunately, this feature does not exist in DSpace 7.  There's a ticket for it available here: https://github.com/DSpace/dspace-angular/issues/1758   However, it's still waiting on a volunteer to help us implement it.

You are welcome to add your feedback to that ticket, but we'll need to find a volunteer before it can be implemented.

Tim

[Marijka Azzopardi]

Thanks for informing on the existence of this ticket Tim. I've added a comment to inform that we are keen to see authority control look-up functionality implemented for archived items in DSpace 7.

I certainly welcome Euler to comment on this ticket also to inform on the number of Dspace 7 clients heavily impacted by this issue.

Kind regards,

Marijka

[euler]

Hi Marijka,

This is one of the reasons why I hold off upgrading to version 7x. In our organization with different departments, we have 6 repositories running version 6.x version in addition to other repositories (4) that I am supporting outside of our institution. Unfortunately for us, this issue was tagged medium-priority, so we may have to wait for somebody to take a look and issue a pull request for this. I am not a developer and angular is very new to me, that's why I'm hoping somebody could investigate this issue.

This issue is a deal breaker for us since we rely on the lookup feature a lot for maintaining quality metadata in the fields (mostly authors, subjects, geographical names) that use authority control.

Best regards,

euler

[Marijka Azzopardi]

Hi Euler,

Thanks for informing, as an existing DSpace 7 user this issue is a high priority for us also. We use authority control persons and grants in our institutional Dspace 7 repository and have been unable to add or remove them for our archived items.

Tim, Github doesn't have a "vote" feature to allow the community to vote or request the review of priorities for reported issues (unless we add 'likes' or apply something like https://github.com/cncf/gitvote). I'm happy to add continue to add comments to issues impacting us if this is the best way to vote at present. In the interim, is there any chance we may be able to request your review of this ticket's priority (https://github.com/DSpace/dspace-angular/issues/1758) based on our comments?

Regards,

Marijka

[DSpace Technical Support]

Hi Marijka,

Currently, that ticket is at a "medium priority" simply because of how it was prioritized by our Steering/Leadership groups during the 7.x development process: https://github.com/DSpace/dspace-angular/issues/1758   

That said, those priority labels are more "general guidelines" at this point.  Now that 7.x feature development has completed, most of our development effort for 8.0 is *volunteer based*.  We do not have a centralized DSpace development team. Rather, we are able to organize development of new features via active volunteers worldwide.  While I can make recommendations for features to build next, the feature still won't be built until I'm able to find a volunteer.

There are three main ways to try to ensure a specific feature is built more rapidly:

• Build it yourself and give it back.  This obviously can be very hard if you don't have developers with the expertise to do so.
• Hire a service provider to build it and give it back.  This will require paying that service provider, or collaborating with others to pay that service provider.
• Add comments or thumbs up on the ticket in GitHub or bring this up in discussion in DCAT meetings to get more support.  Keep in mind, this has a minimal impact until we notice a larger number of institutions all needing the same feature (Currently, while I understand a handful of institutions are very negatively impacted, it still looks to be <5 institutions impacted out of thousands worldwide). If we notice a larger number of institutions impacted, then sometimes Steering may be able to help organize those institutions into funding the work or perhaps find funding in the DSpace budget (usually again via a service provider).

I hope this helps explain ways that this can be built more rapidly.  Overall, I'd love to see this feature get built, but it's priority is based on the number of impacted institutions at this time.  If you have funding to hire a service provider to build this feature, that may be the quickest fix.  Otherwise, I'd recommend looking around for others impacted (perhaps via DCAT and other groups) and encourage them to also make their voices heard.  It's also possible that others would have funding to help hire a service provider or would have someone on staff willing to help build this feature.

Tim