Specification - adammoore/corda GitHub Wiki

Introduction

Jisc ORCID support team gets a lot of requests (probably the first or second most common from new members especially) for information on how many researchers are signed up to ORCID at a particular institution.

Institutional managers with responsibility for monitoring and promoting take up of ORCID would like to answer questions such as:

  • How many of my researchers have an ORCID ID?
  • How many of those researchers have connected to my institutional system, and how many have not, and who are they?

As ORCID iD is personal to the researcher and the email field is by default set to private arriving at an accurate answer can be a tricky thing to do

The current methods for obtaining some parts of the answer comprise:

  1. Reports generated by ORCID: these can return the number of researchers with an email address associated with the institutional email domains. If there’s an active integration with the registry, numbers of ORCID iD that are accessing that integration

However the report does NOT include which iD accessed or is associated with that affiliation (Affiliation can be retrieved separately via a search - see 2)

  1. Searching Using the ORCID API (for members)
  • Based on email address

if the individuals email address is set to public, the API can be used to search against email address

If the email address is set to trusted (and your institution has requested and been granted trusted organisation status), the member API can be searched

  • Based on organisational affiliation This does not distinguish between current and previous affiliations

  1. Using your integration You can get information from the integration you have with the ORCID registry via your repository (e.g. the ORCID advance plugin for eprints) or the Pure / Elements links. This information is typically accessed via reports, API or querying the underlying database.

  2. The ORCID annual data file is another option

So, we’re looking at building a layer that has a common set of classes / abstractions that you can use to bring the above methods together. The abstraction layer will supplement information from the ORCID API with information from CRIS / repositories / HR systems etc so that the results can be presented within another level which manages reporting and visualisation and other end user interaction.

In the run-up to the hackday, iterative cycles will be used to firm up the specification for the abstract layer, based on known requirements (synthesised from previous input). During the hackday rapid sprints and codesign will be used to prototype /wireframe and hopefully deliver a demonstrator platform to further inform the next iterations.

System

Abstract Layer Diagram shows internal infrastructure and open sources along with ORCID data connected to layer which in turn feeds dashboard Abstract Layer Diagram shows internal infrastructure and open sources along with ORCID data connected to layer which in turn feeds dashboard

The Jisc Common Abstraction Layer is a set a classes / methods for accessing a variety of institutional infrastructure and information in a standard way, without worrying what the specific piece of infrastructure is underneath, It allows the platforms built on top of it to express their information requirements and interactions without having to then customise their installation based on instances in each institution.

Overall Specification

The abstraction layer needs to serve 3 purposes:

  1. To provide convenience/facilitation classes for information where there is no existing method - for example:
  • Get all results from the ORCID registry where the existing API returns paged results
  • Get range where the existing API doesn’t support ranged queries
  1. To provide an abstracted call to a specific infrastructure without worrying what the API/method underlying it is - for example
  • Get cris.all_works
  • Get hr.staffid
  1. To provide a common method of accessing information that may be available across a variety of different infrastructure - for example
  • Get linked surname
  • Get department

Jisc Common Interface Specification

The Jisc Common Abstraction Layer will provide a defined interface that external systems, such as the Jisc Hub / Dashboard will use in order obtain required information and otherwise interact with underlying systems.

This section defines the particular endpoints that will be needed.

Connector Interfaces Specification

The Jisc Common Abstraction Layer needs to define specific connector interfaces for interacting with the underlying systems. Specific connectors for these underlying systems will then need to be developed that expose information via these defined interfaces.

Imported from the google doc