Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

This page describes features that Dryad may implement using ORCID. We expect that many of these features will be of value to the larger DSpace community. If you have feedback, please comment on this page, or send a note to ryan@datadryad.org.

The descriptions below encompass features that should be of interest to a large DSpace community. See Dryad's wiki for ORCID-based features that are more specific to Dryad.

Basic authentication

Authentication to allow submitters to use their ORCID login as a login for DSpace.

Requirements:

  • Users can login to DSpace using the ORCID login system.
  • Users can create a new DSpace account using an ORCID login.
  • If the user is logged in, their ORCID user account will "own" any submissions created by the user.
  • The user's profile page should encourage them to link their account to ORCID.
  • There should be a button on the profile page that allows the user to login to ORCID (they may need to create an ORID account in the process). After logging in, their DSpace account is linked to the associated ORCID account.
  • When an ORCID is linked to a user's account, all relevant metadata associated with the ORCID account is stored in the user's DSpace profile.
    • The use of the metadata will honor the privacy settings in ORCID. Information that is marked as "Public" may be displayed alongside the user's name in DSpace, for disambiguation purposes. Information marked as "limited" may be retrieved on-the-fly for internal use by curators/catalogers.

Expected changes to DSpace:

  • Add basic support for OAUTH.
  • Add an XMLUI aspect that includes all ORCID-specific authentication.
    • Login page must include an option to use ORCID for authentication.
  • EPerson object should include a copy of the ORCID.
  • User profile page should include:
    • button to link an account to ORCID
    • if the account is linked, display summary of ORCID metadata (either looked up on-the-fly, or included in the EPerson).

Technical notes:

Adding ORCIDs to items at submission

As described in the comments below, this portion of the integration is being addressed by Atmire, in the DSpace 5 ORCID Integration.

When users submit new DSpace items, the authors listed in the items should be associated with ORCIDs.

Requirements:

  • There must be buttons that allow the submitter to lookup ORCIDs of all authors on the item.
    • Pressing one of these buttons launches a new window which searches the ORCID system for the given author's name.
    • If the search locates the correct author, the submitter selects the author, and the associated ORCID is transmitted back to Dryad.
    • If the target author does not already have an ORCID, they should be invited to create one.

Expected changes to DSpace:

  • Submission system should allow buttons that link out to the ORCID search process.
  • Once submitter has selected an ORCID, the submission system page should reload and display the selected ORCID information.
  • No labels

6 Comments

  1. Bram Luyten (Atmire)

    Ryan, great work and thanks for opening this dialogue. A few ideas about this which probably need to be more fine tuned in the future:

    The academic usecase

    Here are a few properties shared among academic institutional repositories I've come across:

    • The repository and the department or team operating the repository are not often the systems and people who control the institutional staff ids. 
    • At best, the repository has some kind of API access or integration with staff IDs and has been using that as an authority control on author names for staff. Example: http://dukespace.lib.duke.edu/dspace/browse?type=dukeAuthor

    ORCID specific vs broader concept of "external identifier for authors"

    Especially because you suggest to store the ORCID ID on the ePerson level (assuming that's what was meant with the user's DSpace profile), I was wondering if there shouldn't be a broader need to store any, or a number of external identifiers for a person. I think two distinct assumptions can be followed:

    • There's an external service that already bundles all of the identifiers for a person. In this case it could be logic to store only the identfier in that particular system, because it can reference the other identifiers. I've seen that ORCID allows you to store Scopus ID as well, but would it be able to keep a linkedin ID, twitter accountname or any other identifier that a researcher wants to link to his/her scientific persona?
    • If we believe there will always be a number of different services offering different identifiers for the same person, there may be a case for keeping all of them in the DSpace user account/Eperson. I'm especially thinking about internal university staff IDs + external ORCID ideas. But while considering this, wouldn't it be the people who control the institutional staff registries & ID attribution to build a service that does exactly that, keeping track of the internal & external staff ids.

    Potential duplication: storing IDs in Eperson vs Item metadata

    I'm not articulating it very well here, but I'm just wondering about the potential benefits and drawbacks on storing ORCIDS (or any external ID) in both Eperson and item metadata.

    ORCID in Eperson but not in Item Metadata

    Usecase: person that has signed in/registered in DSpace with his ORCID but hasn't attached him or herself as a contributor to a particular item.

    ORCID in Eperson and in Item Metadata

    Usecase: person that has signed in/registered in DSpace with his ORCID and has a few items archived where he or she is identified as an author. This would mean that the ORCID resides both in the Eperson, as well as on the level of the individual item metadata, right?

    ORCID not in Eperson but in Item Metadata

    Usecase: adding a person as a co-author through the ORCID lookup, even though this person isn't individually registered in DSpace. In this case I think the ORCID will only be an authority key in the item metadata and doesn't need to create an Eperson/DSpace user account for this co-author, right?

     

  2. Hilton Gibson

    Implement CRIS open standards for interoperability, see: http://wiki.lib.sun.ac.za/index.php/OpenScholar

     

  3. Andrea Bollini (4Science)

    We should thing separately to the two aspects of an ORCID:

    • identity
    • authentication

    The EPerson class actually in DSpace is mainly related to the authentication and authorization world, it map the concept of account in a moder IR or a CRIS system we need to identify all the authors and people related to the publications and digital objects stored in the system. This mean that we have a separated entity "People" that need to be identified (ORCID is a very good candidate for that). People and account entities have some relationship but it is not necessary a one-to-one.

    So IMHO the eperson class should continue to manage the authentication aspects and store the ORCID only to be able to perform the OAUTH. We need a separate entity for people, in DSpace-CRIS we have called that Researcher Page, where you are able to store one or more identifier like ORCID, ResearcherID, RePEcID, etc.

    Below some integration scenario that with the help of the DSpace-CRIS addon we could implement as described on the mailing list

    http://www.mail-archive.com/dspace-tech@lists.sourceforge.net/msg23023.html

    ORCID Integration Scenarios:

    -          Authentication: We propose to develop an authentication plugin for DSpace to allow researchers to login in their IR using their ORCID credentials.

    -          ORCID creation and/or association: We propose to develop an integration between the DSpace-CRIS open source addon used to managed the researchers profile inside the IR and the ORCID authority. The researcher will be able to request a new ORCID sending the information already available in her IR profile or associate an existent ORCID to her profile. In the case of new researchers or researchers that have not yet created a personal profile in the IR, supplying an existent ORCID the profile information will be prefilled with the data coming from ORCID.

    -          Keeping profiles synchronized: We propose to develop an integration between the DSpace-CRIS addon and ORCID to allow the researcher to easily keep synchronized profiles in IR and ORCID. The system will suggest to retrieve data from ORCID in case any update on the ORCID side is detected or send update to ORCID after editing of the IR profile.

    -          Update publication list on ORCID: the researcher will be able to send some of her publication records from the IR to her ORCID profile Import publication records in the IR from ORCID: the researcher will be able to select one or more publications to import in the IR from the bibliographic records available in ORCID.

    1. Andrea Bollini (4Science)

      A very good starting point to revise the EPerson DSpace implementation to enable oauth is the Spring Social Library

      http://www.springsource.org/spring-social

      http://static.springsource.org/spring-social/docs/1.0.x/reference/html/implementing.html

  4. stuart yeates

    It's worth remembering that people can have multiple ORCIDs. The ISNI standard (on which ORCID is based) makes it very clear that these identifiers are issued for names not entities. A researcher who changes their name (through marriage, gender reassignment, etc, etc) mid career may validly have two ORCIDs for their professional output.

  5. Bram Luyten (Atmire)

    We have started filling the Documentation template for our DSpace 5 ORCID contribution.

    ORCID Integration

    The pull request, finalization of this work still needs to follow but we wanted to share early.

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.