Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Data Correction

Scenario 1: A repository manager of a repository indexed in OpenAIRE can subscribe the event for Missed/More PIDs and Project links in the Content Provider Dashboard using “a repository callback” as notification mechanism instead of the current email alert. They login in the repository and see the list of events received, among others one publication that has a PMID that was unknown to the repository and a link to a project. They click on the “accept the suggestion” button and the new information is stored in the local record. OpenAIRE could “flag” the data as confirmed.

...

As the OpenAIRE Content Provider Dashboard doesn't allow yet to create a subscription setting up a callback mechanism, we agree with the OpenAIRE team to read the data generated by openAIRE's Notification Broker Service from a JSON file postponing to the last phase of the project the discussion and the implementation about the delivery mechanism (polling new versions from a stable URL, receive it as payload of a repository URL, etc.).

Data source

The JSON file contains an array of JSON Events, where each event has the following structure

...

The detailed REST contract for such endpoints are available on the 4Science Rest7Contract repository and embedded at the bottom of the page for easy reference.

Repository Manager UI

The resulting UI is accessible from the administrative menu - if the configuration key is true: qaevents.enabled (it can be found onto qaevents.cfg file and is defaulted as false). As entry point for the features a “Notifications” menu entry has been added to the DSpace administrative menu, from where the repository manager will be able to manage the OpenAIRE subscription and access the details of received events.

...

For PID related events, the system offers where available (doi, handle, pmid, pmc, arXiv, NCID, urn/url) the resolution of the identifier to a details page

notification broker linked doi

notification broker linked doi

Processing the decisions

The backend is responsible to process the repository manager decisions taken over the received events. As noted in the REST Contract the decision is recorded PATCHing the DSpace qaevents REST resource updating its status.

...

the above configuration is the default for DSpace-CRIS, for a plain DSpace the QAEntityOpenaireMetadataAction bean must define the attribute relation instead than metadata. The relation must match the rightward name of the relation used to link a publication with a project that is isPublicationOfProject in the openaire4-relatioship.xml proposal.

Rest Contract

Two REST endpoints have been developed to interact with the notification broker events

  • /api/integration/qualityassurancetopic to provide access to summary information about the available topic and number of events to deal with
  • /api/integration/qualityassuranceevent to provide access to the detailed events so that they can be reviewed and managed by the repository manager

/api/integration/nbtopics

nbtopics endpoint

/api/integration/qaevents

qaevents endpoint