Notification Patterns

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.

The following notification patterns are defined to be widely reusable.

Categorised Notification Patterns

Requests

This category of pattern is used to request a service (by making an Activity Streams 2.0 Offer)

Examples:

Process

This category of pattern is a general category for notifications related to processing other notifications.

Examples:

Un-processable Notification Draft
Undo Offer

Acknowledgements

This category of pattern is used to acknowledge receipt of a notification (most often an Offer), normally providing an Accept or Reject type

Examples:

Announcements

This category of pattern is used to Announce the existence of something - normally a web-resource

Examples:

All Notification Patterns
Name	Description	Category
Accept	This pattern is used to acknowledge and accept a request (`Offer`). This should be interpreted to mean that the `target` intends to act on the request in some way. It does not imply any kind of outcome beyond this.	acknowledgements
Announce Endorsement	This pattern is used to announce the existence of an endorsement, referencing (in `context`) the resource that has been endorsed	announcements
Announce Ingest	This pattern is used to announce a resource has been ingested	announcements
Announce Relationship	This pattern is used to announce a relationship between two resources	announcements
Announce Review	This pattern is used to announce the existence of a review, referencing (in `context`) the resource that has been reviewed	announcements
Announce Service Result	This pattern is used to announce the existence of a "service result", referencing (in `context`) the resource to which the service result pertains	announcements
Reject	This pattern is used to acknowledge and reject a request (`Offer`). This should be interpreted to mean that the `target` will take no further action with regard to this `Offer`. It does not imply any kind of outcome beyond this.	acknowledgements
Request Endorsement	This pattern is used to request endorsement of a resource owned by the `origin` system.	requests
Request Ingest	This pattern is used to request that the target system ingest a resource	requests
Request Review	This pattern is used to request a review of a resource owned by the `origin` system.	requests
Tentatively Accept	This pattern is used to acknowledge and tentatively accept a request (`Offer`). This should be interpreted to mean that the `target` currently intends to act on the request in some way, but that this might change. It does not imply any kind of outcome beyond this.	acknowledgements
Un-processable Notification Draft	This pattern is used to indicate that a previously received Notify notification was un-processable for some reason. The reason is given in the `summary` property.	process
Undo Offer	This pattern is used to `Undo` (retract) an `Offer` previously made.	process