CRIS Requirements

Requirements for CRIS services

(Which services should use PTCRISync)

Communication with ORCID

A CRIS service interested in using PTCRISync to synchronize it research outputs should register for the ORCID Member API, which allows clients to modify information of an ORCID's user's profile (rather than only reading). The client secret provided to the CRIS should then be used to request to the user an authorization code. For the purpose of PTCRISync, the scope of this request must be at least /activities/update, otherwise the procedures will not be able to update the user's ORCID profile. Moreover, /read-limited privileges are also recommended, otherwise activities with limited visibility may affect the correctness of the synchronization procedures. For an overview of ORCID concepts and procedures relevant to PTCRISync, see here.

PTCRISync acts on the profile level, and thus the ORCID iD of the user whose profiles are to be synchronized must be known. It is assumed that the interested CRIS service has external mechanisms to retrieve and persists the ORCID iD of their users.

Data Model

To unify the communication of the CRIS services with PTCRISync, the synchronization procedures require the local profiles to encoded according to ORCID data schema. In PTCRISync 0.2, this consists essential on encoding research productions as ORCID works. In this context, the putcode field of each work is assumed to represent an internal identifier that uniquely identifies it within a CRIS user profile.

PTCRISync is built around a persistent notion of synchronized productions: once a production is set to be synchronized, the PTCRISync procedures will keep those records up-to-date in the user's ORCID profile. A production may only be synchronized if it contains at least one external identifier (in order to follow the ORCID guidelines to avoid works without external identifiers), and if two productions share external identifiers, only one of them may be selected (due to the restriction on unique external identifiers from the same source). Maintaining these constraints may not be a trivial affair: for example, when adding a external identifier to a production two productions that previously shared no external identifiers may now share some. There are several valid alternatives for enforcing this constraint: for example, ask the user which of the productions should no longer be exported, or simply deselect all conflicting productions from being exported. A production will typically also contain varied additional meta-data such as its title, publication year, publication type, authors, etc.

PTCRISync is semi-automatic and notification based. Thus, each CRIS service will be required to support two kinds of notifications in a user profile: creation notifications, to alert the user that a new production has been found in ORCID; and modification notifications, to alert the user that new external identifiers for an existing production have been found. This can be distinguished by the putcode assigned to the works returned by the procedures: empty putcodes denote creation notifications, assigned putcodes point to the local productions that needs be updated.

Modification notifications currently focus on keeping external identifiers up-to-date (see here here for details).

Notifications have also a set of external identifiers, which must not be empty for modification notifications, since their goal is precisely to propagate newly found external identifiers. Additionally, a creation notification contains the meta-data associated with the new production. The shape of the meta-data supported by the PTCRIS service may not be the same as the one supported by ORCID and it may not be trivial to convert one format to the other. However, as will be shown below, the synchronization procedure is oblivious to the meta-data information and relies only on external identifiers to match research outputs. Thus, no specific conversion procedure from one format to the other will be imposed, leaving to each PTCRIS service the decision of how to do so, which should be clarified as precisely as possible. In this report, this is abstracted by assuming that the constructor of creation notifications takes into consideration an ORCID work from which the meta-data is extracted. If the notification system is to be used for other purposes in the PTCRIS service, this data model must be adapted accordingly.