Progress Report Towards CERIF-ORCID API Adapter

Towards a CERIF-ORCID API Adapter A progress report Tom Demeranville, Josh Brown, Jan Dvo k, Dimitrios Karaiskos

The quick ORCID introduction Provides identifiers for people An international enabling infrastructure Links people with things and places using identifiers A EuroCRIS strategic partner A lead partner in the EC funded THOR project

The status quo CRIS systems interact with ORCID using the ORCID Public or Member API CRIS systems have to map the ORCID data model and exchange formats to their own internal representations

The questions raised (the last time we met) Could ORCID and CRIS systems speak to each other using the same language and protocols? Should they? Would it aid interoperability? How might it work?

Project aims 1) Let s make it easier for ORCID and CRIS systems to interact 2) See (1) above.

As developers our first though was... Let build a prototype and see!

The requirements As a client I would like to be able to retrieve CERIF XML from the ORCID registry for a person so that I can easily ingest and map it into my own systems.

Introducing the CERIF API Publisher: euroCRIS, 2015 Goal: to facilitate the interoperability of CRIS systems and their integration with other systems/services Functionality (v1.0): read-only access to information in CRIS systems

More on the CERIF API Technologies: HTTP REST, CERIF-XML Details: http://eurocris.org/cerif-api-v10 http://hdl.handle.net/11366/420

The approach We developed the adapter as a read only service in the first instance Its far, far simpler

The approach We implemented the APIs in parallel There s no clear way to overlay CERIF API entities onto the existing ORCID API There were content negotiation conflicts (two types of xml on one endpoint? No thanks!) Prototype code was, by definition, not ready for production Versioning is difficult when supporting two specifications

The approach We developed the library from the ground up: The reference implementation is good, but the team use different sets of libraries; adding more creates maintenance issues. We used the OpenAIRE semantics with a couple of additions Why reinvent the wheel? Standards aid interoperability

Mappings Mapping is interesting: multiple ORCID entities can map to a single CERIF entity and vice versa ORCID people Person ORCID works ResultPublication, ResultProduct ORCID employment, education OrganisationUnit ORCID funding Funding

Security The ORCID API is secured using Oauth and the CERIF API is authentication agnostic This means that using the adapter requires clients to understand the security layer on top of the CERIF API specification. This is a barrier to simple integration, but not a major issue

Privacy ORCID is a user-centric system and supports three privacy levels ORCID visibility attributes do not map well to CERIF XML although there are some possible solutions using classifications and linking entities

Preliminary outcome Once development was completed and reviewed, it was apparent that while it would meet the goals set out by the requirements, the prototype would not be suitable for production use

Lessons learnt 1.Input from CRIS system vendors is required to ensure that the service fulfils their requirements. 2.Testing against real world systems wasn t possible. This is partly due to the early adoption nature of the CERIF API, but also because the end users of the ORCID CERIF API adapter are not defined.

Lessons learnt 3. There are concerns about expressing ORCID privacy levels within CERIF XML that need to be addressed. 4. We encountered problems with title languages when mapping works to publications and products. Language is a required attribute within CERIF XML, but generally unpopulated within the metadata received by ORCID.

Lessons learnt 5. Mapping from ORCID alternative names to separate cfFirstNames and cfFamilyNames proved tricky. Although ORCID stores primary names as two components, additional names on a record are stored as literal strings. This was resolved using cfOtherNames.

Lessons learnt 6. CERIF API is authentication agnostic and does not specify an authentication layer. Our use case demonstrates that the CERIF API will need to tackle this, possibly by making its users aware that although authentication neutral, in real world deployments, authentication service layers (e.g. OAuth) could be seen and should be taken into account by client implementations.

Lessons learnt 7. The integration approach taken, while mitigating issues around diverging API design now and in the future, does not wholly remove the maintenance burden on the core ORCID registry. As a service owned by its members, ORCID needs to be able justify the required commitment at this time.

Recommendations A translation layer, separate from ORCID and any specific CRIS would be a better solution - Reduces versioning and maintenance issues for ORCID and CERIF More amenable to change Could be a local service, remote service or a library - -

Towards an open-source adapter tool Talks are underway with the goal of developing a shared open-source, CERIF-ORCID API adapter tool. Ideally this will be developed, governed and maintained by the community - including ORCID and EuroCRIS We need CRIS system vendors on board for requirements, use cases, validation and development effort.

Thanks for listening Tom Demeranville and Josh Brown (ORCID EU; Project THOR) Jan Dvo k (euroCRIS; Charles University in Prague) Dimitrios Karaiskos (euroCRIS; National Hellenic Research Foundation/National Documentation Center, Athens, Greece)