...

The LDN system, as a message exchanging i/o system, has an inbox and an outbox. Every LDN message refers to a Notify Service: all the Notify Services are configured manually from the admin application form. A Notify Service is just like an authority labelled on LDN messages.

The Quality Assurance system is the implementation of item metadata updates operations. A Quality Assurance Event contains informations for item metadata updates: QAEvent are stored into QAEvent solr collection. All of the QAEvent are shown on an administration form. Every QAEvent can be accepted, ignored or removed: if accepted some metadata of the referred item are modified, if ignored or removed nothing about the item is modified. Every QAEvent has a property named source : qa events created by processing an LDNMessage has source="coar-notify".

...

The following page is used to submit a new LDN Service:

LDN Inbox queueing

LDN incoming messages are stored into the ldn_message database table. As far as the property ldn.enabled  is true and the incoming json is valid, the LDN Message is stored on the table. Together with the storage of the record, the queue status of the message is initialized. The queue_status column of the table contains the status of the LDN message inside the queue. All the possible queue_status values are described into the java class org.dspace.app.ldn.LDNMessageEntity as integer constants.

If all validations are run successfully the LDN Notification status is set as QUEUE_STATUS_QUEUED and the notification will be processed as soon as the extractor retrieves it from the queue. 

...

In the example below it is shown the submission of an Item with a new section for COAR-Notify.
In this section we can manually choose ldn-services (which were not marked as automatic) in order to ask for Review, Endorsement and Ingest to external services.
If No (non-automatic) pattern has been configured for the LDN Service this service will not be displayed in any of the dropdown. 

Automatic Inbound pattern triggering

...

This consumer is responsible for the handling of both automatic a non-automatic patterns

Understanding the structure of the LDN Notification

...

The context section is the same for any LDN Notification 

  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://purl.org/coar/notify"
  ]

actor

This section describes the actor which performs the request
This is a descriptive section and doesn't include important information

  "actor": {
    "id": "https://review-service.com",
    "name": "Review Service",
    "type": "Service"
  }

context

This is one of the most important section.
In this section we have a description of the Item being involved in the LDN Notification

...

other fields are descriptive fields for the item

  "context": {
    "id": "https://research-organisation.org/repository/preprint/201203/421/",
    "ietf:cite-as": "https://doi.org/10.5555/12345680",
    "type": "sorg:AboutPage",
    "url": {
      "id": "https://research-organisation.org/repository/preprint/201203/421/content.pdf",
      "mediaType": "application/pdf",
      "type": [
        "Article",
        "sorg:ScholarlyArticle"
      ]
    }
  }

id

The identifier of the LDN notification (Each notification has a different id)

inReplyTo

This field is used to reply to other LDN notification so that the system knows if the current notification is a response

object

This is a descriptive section of the received Review, Endorsement etc..

• id → is the URL of the review/endorsement etc.

  "object": {
    "id": "https://review-service.com/review/geo/202103/0021",
    "ietf:cite-as": "https://doi.org/10.3214/987654",
    "type": [
      "Document",
      "sorg:Review"
    ]
  }

origin

This is an important section since it is used (for incoming notifications) to determine the service among the registered ones.
If the service is not recognized as registered the notification is untrusted

The field being used for this check is inbox

  "origin": {
    "id": "https://review-service.com/system",
    "inbox": "https://review-service.com/inbox/",
    "type": "Service"
  }

target

This section is used to describe the target system involved in the notification workflow 

  "target": {
    "id": "https://generic-service.com/system",
    "inbox": "https://generic-service.com/system/inbox/",
    "type": "Service"
  }

type

This type section is important since it's determining how to process/evaluate any received notification

  "type": [
    "Announce",
    "coar-notify:ReviewAction"
  ]