...

Name: a label for the Notify Service used on the UI

Description: the description of the Notify Service - add details here

Service URL: the url of the remote Notify Service used when DSpace sends out LDN Messages

Level of Trust: floating point number value accepted between 0 and 1. This value is passed into every QA Event created by every LDN Message

associated with this Notify Service: it goes to evaluate the "score" attribute of the QA Event. Score attribute is used for rejection/acceptance

qa event automation. See the project file dspace/config/spring/api/qaevents.xml on the bean qaAutomaticProcessingMap/qaScoreEvaluation

Service IP Range: two IP numbers expected as minimum and maximum. This range can be used to add a filter to entrust the identified Notify Service of

every incoming LDN Messages. If IP Range is enabled, the sender Notify Service is identified but the current LDN Message is coming from an IP

out of this range - the LDN Message is set as untrusted.

LDN Inbox URL: every incoming LDN Message must have an identifiable Notify Service. We match this field to the origin.inbox attribute of the

LDN Message. Despite the ip range - this field is mandatory. Every incoming LDN Message with a non-identifiable Notify Service associated is set

as untrusted and won't be enrouted to the Ldn Router.

Inbound Pattern: stored into the database table notifyservice_inbound_pattern - we can add at least 1 of them for each Notify Service. Every inbound

pattern is the triple of [ pattern, item filter, automatic flag ] :

pattern: see https://notify.coar-repositories.org/patterns/ for all possible combinations, currently are hardcoded on the angular frontend project;
item filter: known on DSpace and declared onto dspace\config\spring\api\item-filters.xml
automatic flag: when activated the ldn message exchange starts automatically at the item submission time. Automatic triggers an Outbox Outgoing LDN
message targeting the Notify service and targeting the item in submission. The automatic flag involves only the submission phase of an item.
If no item filter is set - the flag is applied on all submissions.

...

When the Offer message has been followed by a related incoming Acknowledgement message: if the ack is an accept/tentative accept the box shown is blue, if the ack is a tentative rejct the box shown is red.

When Offer message has been followed by a related Announce incoming message, there are no boxes of this kind shown, because it’s expected for the boxes about qa to be shown!

Level of Trust

the box shown is blue! It is blue because receiving an Announce means - then the message is extracted - we produce a new QA Event. As every QA Event it is shown on Item Page and myDSpace page.

Level of Trust

It’s a number 0 < # < 1. Triggers an automatic It’s a number 0 < # < 1. Triggers an automatic approval of QAEvent once the LDN message is extracted. On qaevents.xml spring configuration files the bean qaScoreEvaluation describes three different boundaries defaults to manage the level of trust:

...

score <= rejection deletes the QAEvent; score <= ignore discards the QAEvent; score >= approval accepts the QAEvent automatically, so nobody will see it from the Quality Assurance Page because it’s created and right after approved.

...

Again about automatic Inbound Patterns flag

In the example below it is shown the submission of an Item with a new section named COAR-Notify. In this section we can choose manually specific ldn-services which cover the request on Review, Endorsement and Review. If No LDN-Services have been configured with these Inbound Patterns, combos on the COAR-Notify section are going to be empty! Example: by flagging automatic to the Inbound Pattern Request Review of LDN Service named "X" , it means that the LDN Service X will not be visible on the Request Review combo of the COAR-Notify submission section. This is the meaning of automatic: a Request Review is going to be sent out to X every time an Item is submitted. All items? No, the items filtered by the Item Filter configured on that Inbound Pattern.

Image Added

Test calls: Request Endorsement (LDN Message on item submission)

Let's configure a new Notify Service such as:

...

For this specific example we can set just the first Inbound Pattern as Request Review and leave the item filter blank. This test is not about item submission.
Pick the following POST call from the Postman project (see below to download it and import it to your installed PostMan instance): let's emulate the Notify Service external system sending us an LDN Message!

{
"@context":[
"https://www.w3.org/ns/activitystreams",
"https://purl.org/coar/notify"
],
"actor":{
"id":"https://orcid.org/0000-0002-1825-0097",
"name":"Josiah Carberry",
"type":"Person"
},
"id":"urn:uuid:0370c0fb-bb78-4a9b-87f5-bed307a50dff", //// IMPORTANT!! this must be a unique value because it's going to be stored as uuid into the ldn_message table.
"object":{
"id":"http://localhost:4000/handle/123456789/1122", ////IMPORTANT!! this is the handle link to the item from the referred local repository
"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"
]
}
},
"origin":{
"id":"url.ServiceURL?score=0.8",
"inbox":"http://ldn.ServiceURL?score=0.8", ///IMPORTANT through this field we reach the configured Notify Service entity by matching this field to the one named LDN Inbox URL
"type":"Service"
},
"target":{
"id":"https://review-service.com/system",
"inbox":"https://notify-inbox.info/inbox",
"type":"Service"
},
"type":[
"Offer",
"coar-notify:ReviewAction"
]
}

See below the successful response:

...

This means the LDN Message has been enqueued. Please remember the enqueued ldn messages must be evaluated by the Extractor for a QA Event (with source=coar-notify) to be produced. As soon as it is, a blue popup is shown on Item and myDSpace pages:

Image Modified