Page History
...
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.
The main page list the topics found in the events loaded in the system
By default the system sort the events within a topic by trust descending (most accurate correction first)
but it is also possible to revert the direction
getting the less accurate correction first
In the detail view of events in a specific topic links always open in a new tab so that the repository manager can quickly check the details without loosing the overview
Below a screen of possible missing abstract events, where the repository manager will be able to check the current local publication record clicking on the title and scroll the abstract reported by OpenAIRE. Accepting the suggestion, the local record will be enriched with this extra information. The Ignore suggestions button is instead intent to be used to discard a notification without flagging it as wrong. This is important because the OpenAIRE Graph process the data from the repository not in real-time so it can happen that a local record has been updated recently with information not yet known to OpenAIRE. In such scenarios it could be possible that the repository manager prefers to keep the local version but this should be not reported to OpenAIRE a wrong suggestion as this feedback can be used to improve the OpenAIRE guessing capabilities. In contrast a wrong suggestion should be rejected so that OpenAIRE can learn from that.
For PROJECT related events, alternative additional actions are needed. This is usually the case for information that is related to linked entities that can be tracked on the local repository as flat metadata (in such case the “abstract approach UI” will be used) or as individual entity. In this later case the below screen applies:
The system will attempt to identify a local record for the information reported by OpenAIRE (the project) and will offer to the repository manager the option to manually lookup the record or fix the automatic match
if the related project is found in the system the repository manager can proceed to accept the correction linking the publication to the local copy of the project otherwise it is possible to import and connect the project in one click as shown in the first project related screen above
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
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.
...
{ eventId: "<the notification broker event id>", status: “<STATUS-ENUM>” }
where the status ENUM could have the following values:
- DISCARDED: the event was not processable by the system. OpenAIRE should not interpret such status in a negative or positive sense with regard to the accuracy of the notification
- REJECTED: a human takes the decision to reject the suggestion as it was wrong
- ACCEPTED: a human takes the decision to apply the suggested enrichment to the local record
On the Repository side what is performed is encapsulated in a JAVA class specialized to deal with a specific TOPIC. The /config/spring/api/qaevents.xml spring configuration file map each TOPIC to a specific implementation
<bean id="org.dspace.qaevent.service.QAEventActionService" class="org.dspace.qaevent.service.impl.QAEventActionServiceImpl">
<property name="topicsToActions">
<map>
<!--The key are the TOPIC, the value must be a valid implementation of the
org.dspace.qaevent.QAEventAction interface -->
<entry value-ref="ProjectLinkedEntityAction">
<key><util:constant static-field="org.dspace.qaevent.QANotifyPatterns.TOPIC_ENRICH_MORE_PROJECT"/></key>
</entry>
<entry value-ref="ProjectLinkedEntityAction">
<key><util:constant static-field="org.dspace.qaevent.QANotifyPatterns.TOPIC_ENRICH_MISSING_PROJECT"/></key>
</entry>
<entry value-ref="AbstractMetadataAction">
<key><util:constant static-field="org.dspace.qaevent.QANotifyPatterns.TOPIC_ENRICH_MISSING_ABSTRACT"/></key>
</entry>
<entry value-ref="AddReviewMetadataAction">
<key><util:constant static-field="org.dspace.qaevent.QANotifyPatterns.TOPIC_ENRICH_MORE_REVIEW"/></key>
</entry>
<entry value-ref="AddEndorsedMetadataAction">
<key><util:constant static-field="org.dspace.qaevent.QANotifyPatterns.TOPIC_ENRICH_MORE_ENDORSEMENT"/></key>
</entry>
<entry value-ref="PIDMetadataAction">
<key><util:constant static-field="org.dspace.qaevent.QANotifyPatterns.TOPIC_ENRICH_MORE_PID"/></key>
</entry>
<entry value-ref="PIDMetadataAction">
<key><util:constant static-field="org.dspace.qaevent.QANotifyPatterns.TOPIC_ENRICH_MISSING_PID"/></key>
</entry>
<entry value-ref="AddLinkMetadataAction">
<key><util:constant static-field="org.dspace.qaevent.QANotifyPatterns.TOPIC_ENRICH_MORE_LINK"/></key>
</entry>
</map>
</property>
</bean>
Please consider org.dspace.qaevent.QANotifyPatterns is a java class introduced with coar-notify-7 branch.
Each implementation allows to configure additional parameters to deal with the event as needed, ranging from the simple definition of the metadata to use to save the information as in the case of the Abstract related events
<bean id="AbstractMetadataAction" class="org.dspace.qaevent.action.QAOpenaireSimpleMetadataAction">
<property name="metadata" value="dc.description.abstract" />
</bean>
to a dynamic mapping used for SUBJECT and PID related events
<!-- Add a new identifier to the given item, using the defined types mapping -->
<bean id="PIDMetadataAction" class="org.dspace.qaevent.action.QAOpenaireMetadataMapAction">
<property name="types">
<map>
<!--The key are the type of identifier (or subject) reported in the message, the value is the metadata in
the linked entity where the information should be stored -->
<entry key="default" value="dc.identifier.other" />
<!-- <entry key="doi" value="dc.identifier.doi" />
<entry key="pmid" value="dc.identifier.pmid" /> -->
</map>
</property>
</bean>
to the definition of the metadata used in linked entity for Project related events
<!-- This action bind the publication to the project, otherwise if the project has not been specified,
create a new project with the available data and then bind it to the publication -->
<bean id="ProjectLinkedEntityAction" class="org.dspace.qaevent.action.QAEntityOpenaireMetadataAction">
<!-- which metadata will hold the relation between the publication and the project -->
<property name="relation" value="isPublicationOfProject" />
<!-- the type of local entity used to store the project details -->
<property name="entityType" value="Project" />
<property name="entityMetadata">
<map>
<!--The key are the json path of qa message, the value is the metadata in
the linked entity where the information should be stored -->
<!-- <entry key="acronym" value="" /> -->
<entry key="code" value="dc.identifier" />
<!-- <entry key="funder" value="oairecerif.funder" /> -->
<entry key="title" value="dc.title" />
<!-- <entry key="fundingProgram" value="oairecerif.fundingProgram" /> -->
<!-- <entry key="openaireId" value="oairecerif.funding.identifier" /> -->
</map>
</property>
</bean>
...
Overview
Content Tools