Agenda

ORCID: Experiences - Ambitions - Challenges

The initial integration between DSpace and ORCID is a feature that was added in DSpace 5:

Documentation: ORCID Integration

Bram Luyten (Atmire) will give a 5 minute introduction on how the feature works with following slides:

http://www.slideshare.net/bramluyten/orcid-identifiers-for-dspace

During the call, participants are invited to share experiences with this feature. We will discuss the challenges of adopting ORCID in DSpace and hope to collect use cases or feature requests for further development.

The issues that are already logged in JIRA will be discussed as well:

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

This one is already added in DSpace 5.2, but there is no general awareness about this, so we'll discuss it as well:

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Other topics

Meeting notes

ORCID

Introduction

An often occurring problem was is the lack of authority control on metadata in DSpace. An author's name, for example, often occurs as multiple variants in the same repository.

The solution was to create an authority cache in DSpace. This is an XML file in the solr core which logs values used for a certain metadata field after submission. These values can be retrieved later on using the submission form's lookup functionality.

Although using the Authority cache already decreases metadata value ambiguity, it is still limited to one repository. It is also not capable of dealing with homonyms. For example, when two different authors have the same name, it can not distinguish between them. These are issues which can be dealt with by ORCID.

ORCiD is a cross-platform persistent author identifier. As an ORCiD ID is unique, it enhances trust in the author's metadata field more than the authority cache. ORCID also handles homonyms well and deals with author name ambiguity.

Since DSpace 5.x XMLUI there is an integration with ORCID in DSpace. Similar to the authority cache, ORCiD lookups can be done in the submission form's author field.

Q & A

Is there an ORCID integration for JSPUI?

Up to now the ORCID integration was only developed for XMLUI. There is no JSPUI integration available out of the box.

In case Symplectic Elements is integrated in your DSpace, how does ORCID identifiers get matched to names entered in Elements?

For being able to do this, Symplectic Elements should not only push the author string name but also the ORCID Identifier to DSpace.

Is there support for other metadata fields than author names as well?

Currently there is only support for the author metadata fields. There is, however, ongoing development to support project and funder identifiers.

Integrating ORCID means adding ORCID links to existing files. How could we do this in a time effective way?

By exporting the metadata in a CSV file you are able to batch-edit items and re-import the metadata to DSpace. This way you can add an author's ORCID identifier to all their items at once.

Suggestions

  • It would be convenient if only identifiers of your own institutions are shown by default. Alternatively it might be an option to display an authors affiliation with their ORCID identifier.
  • There is a need for a web interface to manipulate the authority cache so it can be extended or corrected. Currently their is only a script to here is a script to add new information (update) to the authority cache. This script can also remove id's which are not used in the repository, so the cache does not become polluted.

Results from the meeting

Unable to locate Jira server for this macro. It may be due to Application Link configuration.  

Included in the scope of the use case at Integrations - Support external authorities (ORCID) in Authority Cache

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Included in the scope of the use case at Integrations - Support for external identifiers (ORCID) in the CSV Batch edit

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Included in the scope of the use case at Integrations - Support external authorities (ORCID) in Authority Cache

XMLUI Test plan for DSpace 6 Testathon

Although we already have many test, the test plan is far from complete. Anyone interested in creating new tests or defining expected results is welcome. The goal is to have a solid test plan in place prior to the start of the testathon on January 4th 2016.

UI prototype challenge

Currently there is a UI prototyping challenge going on to replace both XMLUI and JSPUI. An overview of the competing prototypes can be found on https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Prototype+Challenge. The goal is to develop a uniform UI and bring the community back together for DSpace 7. This challenge will be used to decide which technologies should be used.

Date & Time

  • December 08 16:00 UTC/GMT - 11:00 EST

Call Attendees

  • No labels

21 Comments

  1. I'm in a timezone that doesn't let me join the call, but challenges I'm seeing for clients supported by the University of Waikato ITS:

    • How do we show ORCID iDs associated with an item on the item page? (XMLUI; I believe the mets.xml file contains only the local authority key, not the ORCID iD)
    • How do we add ORCID iDs to new submissions that come in via XSLT-based crosswalks, such as the ones used by SWORD and by the Symplectic Elements DSpace integration? (the documentation talks about bulk metadata editing as the only non-interactive form of submission)
    • How do we add ORCID iDs to OAI-PMH feeds? (I believe the xoai XML representation that custom oai crosswalks work on includes only the local authority key, not the ORCID iD)

    Some or all of the above may already be possible, in which case it would be great to have documentation for these features.

    1. How to show the ORCID iDs on a page

      @mire has done this very recently for CGSpace and the code is open source. example item: https://cgspace.cgiar.org/handle/10568/69013

      Relevant code: https://github.com/ilri/DSpace/commit/0e8886f120bde5250493b7ad1b0a6eae81ff9989 (check later commits as well, but this should give away which files to look into).

      In a nutshell, the approach we took: we wrote an itemadapter plugin to put the orcid id's as temporary metadata fields in the METS:

      https://cgspace.cgiar.org/metadata/handle/10568/69013/mets.xml (scroll all the way to the bottom). Once it's present in the mets, you can pick up the IDs in the XSL, as they have the same authority key associated with them as the respective author fields.

      Adding ORCID iDS to OAI-PMH feeds

      This is part of the RIOXX work. Relevant code snippets:

      https://github.com/atmire/RIOXX53/blob/master/dspace/modules/additions/src/main/java/org/dspace/xoai/util/ItemUtils.java#L152

      https://github.com/atmire/RIOXX53/blob/master/dspace/config/crosswalks/oai/metadataFormats/rioxx.xsl#L146

      Adding ORCID iDs to new submissions that come in via XSLT based crosswalks

      I don't immediately have an example for this. 

  2. My understanding is that there is currently no ORCID integration for JSPUI, and the only option available is to use Cineca's DSpace-CRIS add-on. Is that correct? If anyone has experience with DSpace-CRIS add-on, I would love to hear about it.

  3. I should be on the call for the first c45 minutes.

    We advocate for self-registration but don't mandate it right now; I am in the early stages of investigating various integrations that would be possible/desirable and therefore on a fact finding mission to see how things have been developed for DSpace (and decide whether to add this to my future development list).

     

     

  4. We at Cornell University are not using ORCID, currently, but there is a discussion happening on incorporating it.  So, I will be interested to learn what I can about its implementation.

  5. We recently upgraded our repository—CGSpace, hosted by the International Livestock Research Institute (ILRI) in East Africa—to DSpace 5 and are now mapping ORCiDs (for authors who have them) manually during item submission. We're wondering how to map ORCiDs to existing items in the repository.

    Edit: the answer is to add ORCiDs in the CSV metadata and re-import it, but this introduces some side effects, for example you can no longer arbitrarily order the author names in the authors field, so you have to pay much more attention to this. These and other issues should be documented on the wiki, mailing list, etc... it will surely be a pain point for people!

  6. Bram, do you think we can enter 'dummy' orcid ID's for people without them? in batch editing eg?

     

    https://cgspace.cgiar.org/handle/10568/69013

    lin

  7. Does the lookup tool for ORCiD search across the entire database? Is there a way to only search across your institution. otherwise, it seems difficult to find the correct "John Smith" just using a name search. 

    1. Capturing the suggestion I offered on the phone here: I think displaying the author affiliation as well as the name in the lookup results would both meet this need, and help correctly populate fields for items where authors come from multiple institutions.

      1. This would be tricky because, for example, many of our authors have ORCiDs but have no institutional information in their profile. Check a few of these authors:

        https://cgspace.cgiar.org/handle/10568/69013

        On the other hand, if a particular ORCiD has more than one affiliation in their profile, which one do we show? I'm not sure if it's really DSpace's responsibility to show this.

        1. I agree, we definitely don't want to restrict ORCiD lookups to institution as it will not be uncommon to want to represent external collaborators in metadata. 

          What might help though is to somehow prioritise or categorise results e.g. showing institution associated ID's first (where the info is available i.e. the researcher has not made it private) then everyone who either has, multiple institutions, no institutions or private details second.

          I like Jim's idea of having the institution displayed next to the name regardless, but note that this will be tricky if there is more than one of them.

          1. Ideally, we'd display all institutions associated with a name+ORCID. Tricky, but worth the effort, since that would provide more certainty with regards to choosing the right author.

            Regarding the situation where there's no institution information at all, I don't think it's a show-stopper. Absent that information we're no worse off than we were before...and arguably better off: If you know the "John Smith" you want is from "University X" and none of the John Smith's that do show affiliation information show University X, then you can eliminate those from consideration with high probability of being correct.

            None of this will work perfectly, and the option for a researcher to keep his/her ORCID private (ORCID's default, unfortunately, and one that limits the ID's utility in just about every use case) makes our job even harder. But the old saying about not letting the perfect be the enemy of the good applies, and I'm optimistic that ORCIDs will be used more frequently in the future, and cautiously optimistic that displaying affiliation will become the norm.

  8. the trouble is that most of these authors have private ORCIDs

    1. what's a private ORCID? Do they somehow lock access to it? Or is it just that they have an orcid, but haven't shared what it is (and that they have one) with you as the repository managers?

      1. I think it's like this:

        https://orcid.org/0000-0001-8444-0940

        Where there is no public affiliation listed in the author's ORCiD profile.

      2.  

        When you log in the option is top right. You pick one of the icons.

        For repository editors, it does make it hard to determine who is who for a given orchid ID if they are private - there may be several people with the same name

  9. Does dspace auto-generate authority file/cache with all existing authors, that we could edit manually?

  10. Very useful again thanks Bram.  Shame I missed the very beginning

  11. I have added three new JIRA tickets as outcome of this meeting, see the meeting notes under "Results from the meeting". 

  12. new report:

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.