Recommendation demo to be displayed in HAL
based on reviews by Denis Reviewer 2 and 1 anonymous reviewer
Notification of the recommendation done by PCI
Abstract
Recommendation: posted 20 October 2022, validated 06 September 2023
Reçommènder, D. (2022) Recommendation demo to be displayed in HAL. Peer Community in Computational Statistics, 100144. https://doi.org/10.24072/pci.evolbiol.100144
Recommendation
This documentation has been developed by COAR as part of the COAR Notify Initiative.
Log of changes to the technical specifications
Funding
COAR has been awarded a US$4 million grant from Arcadia, which will go towards the COAR Notify Project. The funded project began on July 1, 2022 and will last for four years.
Editorial Board
Paul Walk, Antleaf
Martin Klein, Los Alamos National Laboratory
Herbert Van de Sompel, Data Archiving & Networked Services (DANS)
Patrick Hochstenbach (Ghent University)
Website Development
Paul Walk, Antleaf
More information
Editorial Process
Feedback
The recommender in charge of the evaluation of the article and the reviewers declared that they have no conflict of interest (as defined in the code of conduct of PCI) with the authors or with the content of the article. The authors declared that they comply with the PCI rule of having no financial conflicts of interest in relation to the content of the article.
[no funding]
Reviewed by anonymous reviewer 1, 20 Oct 2022
Notify notifications are designed to be sent and received using the W3C Linked Data Notifications (LDN) standard. Payloads have a predictable structure, based primarily on Activity Streams 2.0, with some additional vocabularies included for particular properties.
Notify notification patterns are more domain-specific implementations of the generic patterns described by Event Notifications in Value-Adding Networks.
Core Payload
All Notify payloads define an Activity Streams 2.0 activity, and include other properties from the Notify context. They may also, optionally, include other properties from other contexts. The following properties from Activity Streams 2.0 are used consistently in all the notification patterns:
The activity must contain the following properties:@context: This is the JSON-LD 'context' for the activity.
id: This must be a URI, and the use of URN:UUID is recommended. An HTTP URI may be used, but in such cases the URI should resolve to a resource which represents the activity.
type: This should include one of the Activity Stream 2.0 Activity Types. It may (depending on the activity) also include a type from the Notify Activity Types vocabulary
origin: The originator of the activity, typically the service responsible for sending the notification.
object: This should be the focus of the activity. Other object properties may appear in notifications, as properties of other properties.
target: The intended destination of the activity, typically the service which consumes the notification.
The activity property may (and often will) contain the following properties:actor: This identifies the party or process that initiated the activity.
inReplyTo: This property is used when the notification is a direct response to a previous notification (usually a request) and references the Activity Streams 2.0 activity id of the previous notification.
context: This identifies another resource which is relevant to understanding the notification.
Reviewed by Denis Reviewer 2, 20 Oct 2022
This website documents the COAR Notify Protocol, which consists of documented community conventions for the use of W3C Linked Data Notifications (LDN) to integrate repository systems with relevant services in a distributed, resilient and web-native architecture.
Notify notification patterns are more specific implementations of the generic patterns described by Event Notifications in Value-Adding Networks.
The COAR Notify Protocol specifies:
Notification Patterns (templates) which describe the payload for re-usable notifications. These notifications describe the individual linked data notifications sent between repositories and services, one or more of which may be used in a scenario. A given notification is defined in the context of a scenario, and uses a pattern.
A vocabulary which are used to provide values for certain properties in the notification payloads.
Scenarios which describe an example operation (from one or more of the identified use-cases), typically involving a repository system and one other service. These operations are enabled by the exchange of notifications.
