Research Contribution Claim Network: A Blueprint

Living Document,

Latest published version:
https://claimnetwork.info
Feedback:
Codeberg
Editors:
(Ghent University Library)
(SURF)
(SURF)
(DANS)

CC0 To the extent possible under law, the editors have waived all copyright and related or neighboring rights to this work. In addition, as of 29 May 2026, the editors have made this specification available under the Open Web Foundation Agreement Version 1.0, which is available at https://www.openwebfoundation.org/the-agreements/the-owf-1-0-agreements-granted-claims/owfa-1-0. Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.

Abstract

1. Introduction

This blueprint details an approach that allows a researcher to claim a research contribution that is available on the web. In order to do so, the researcher posts about the contribution on a social network, thereby including its URL. A posted claim triggers an automated claim logging process that results in adding information about the research contribution to the researcher’s profile in a Research Information Management System (RIMS), e.g. a Current Research Information System or an Institutional Repository) that keeps track of contributions over time.

The described approach - the research contribution claim network - can be used to claim traditional contributions such as journal articles that tend to be published in well-know scholarly venues but is especially appealing for new types of open science contributions, such as blog posts, radio interviews, newspaper articles, teaching activities, software releases, etc. that are scattered across the web at large and lack distinguishing characteristics, such as persistent identifiers, that facilitate discovery of traditional contributions.

The blueprint is informed by lessons learned from a 2024/2025 experiment in which SURF (the IT cooperative of Dutch education and research institutions) and IMEC-IDLab (the Flemish Internet Technology and Data Science Lab) collaborated to explore whether and how decentralized social networks could be leveraged to claim research contributions as a means to remove the burden of researchers having to manually enter claims into the RIMS of their institutions. Given its origins, this blueprint presents certain implementation details in terms of the distributed, standards-based Mastodon social network. But it is assumed that core ingredients of the approach can also be implemented on the basis of other social networks.

The blueprint’s focus is on:

research contribution claim network overview
High-Level Overview of the Research Contribution Claim Network.

A high-level overview of a research contribution claim network is depicted in Figure 1. It shows the main actors/components, i.e. Carol, Carol’s institutional RIMS, Claimbot, and a claim logging process associated with Claimbot:

Figure 1 also shows that Carol has a new research contribution, available at URL-F, which she wants to add to her profile in her institutional RIMS:

The remainder of this document covers details regarding several aspects of the research contribution claim network in the sections:

2. Terminology

The following terms are used throughout this blueprint:

RIMS

A RIMS, abbreviation for Research Information Management System, is a system that keeps an authoritative overview of contributions made by researchers/academics to the scholarly endaevor. A RIMS typically provides such an overview for all researchers/academics affiliated with a specific institution but RIMS that provide such overviews at different levels of aggregation, such as regional or national, also exist.

research contribution claim network

A research contribution claim network is a social network that is extended with a capability that allows researchers to update the authoritative overview of their research contributions provided by a RIMS by posting about those contributions on the social network.

claim logging process

A claim logging process is a process that handles researchers' claims for research contributions. The process is triggered by a researcher posting about a new research contribution on a social network and, if successful, results in writing a claim record pertaining to the contribution in the claim network community log.

claim network community log

A claim network community log is a repository of claim records pertaining to research contributions claimed by researchers that are affiliated with the group of institutions for which a claim logging process operates.

claim network community profile document

A claim network community profile document is a document associated with a claim logging process that enumerates the group of institutions for which it operates, essentially listing the URL of their respective RIMS.

claim record

A claim record is information gathered by the claim logging process that pertains to a research contribution claimed by a researcher and that is written to the claim network community log.

summarization

The summarization task is part of the claim logging process and consists of accessing the URL of a research contribution claimed by a researcher and gathering information about it that is necessary for the creation of a claim record pertaining to the claim in the claim network community log.

verified link

A verified link in a credential-protected document at URL-A is a link that points at a credential-protected document at URL-B, whereby the latter document contains a link with a rel=me relationship that points back at URL-A.

Inbox

An inbox is a Web location exposed by network nodes in a research contribution claim network to receive JSON-LD notifications that comply with the Event Notifications in Value-Adding Networks specification.

Notification

A notification is a JSON-LD message exchanged in a research contribution claim network that complies with the Event Notifications in Value-Adding Networks specification.

3. Identity, Trust, Verification in the Social Network

The trust mechanism provided here does not pertain to the veracity of Carol claiming URL-F as a research contribution. With that regard, a research contribution claim network relies on trust by reputation, i.e. the reliability of a person is based on their past behavior in the network.

Furthermore, it is assumed that no one but Carol can be active in the claim network using the account @carol@social and no one but Claimbot can be active using the account @claimbot@social. This necessitates adequate security measures that safeguard the social network accounts against unauthorized posting. Achieving this may require robust security measures by the server(s) on which Carol and Claimbot have their respective social network accounts, including a strong password policy, multi-factor authentication, up-to-date SSL certificates, thorough security audits, regular software updates, and a proven reputation for delivering secure, ethical, and privacy-preserving services.

A research contribution claim network requires the capability to provide the following information in a verifiable and trustworthy manner:

The trust mechanism used throughout the Mastodon social network leverages verified links implemented by means of the microformat rel="me" mechanism. A verified link can be recognized in a social network profile by means of a special-purpose indicator such as a check mark, a color, ... Social networks other than Mastodon could potentially support this verified links mechanism or may use different approaches to meet the above requirements in a verifiable and trustworthy manner.

The above requirements can be met as follows using the verified link trust mechanism:

verified links in a research contribution claim network
Trust in a Research Contribution Claim Network via Verified Links.

Figure 2 illustrates the use of verified links in a research contribution claim network:

In order for the verified links trust mechanism to adequately serve the aforementioned purposes:

4. Vocabulary for Posting

To allow straightforward parsing of the content of Carol’s post in which she claims contribution URL-F and to be able to provide information that is essentially required by Carol’s institutional RIMS and that may not be obtainable by the claim logging process, it may prove beneficial to establish minimal vocabulary rules for posting claims. Such rules can be published in Claimbot’s social network profile and in the claim network community profile document. For example:

5. Claim Network Community Profile Document

The claim network community profile document:

The claim network community profile document should be accessible to members of the community served by the claim logging process but must also be easy for machines to process. This can easily be achieved by:

Example: publishing a rel=me link to Claimbot’s social profile (URL-Social/Claimbot) and a rel=http://purl.org/dc/terms/hasPart link to a RIMS (URL-RIMS). 
<link rel="me" 
      href="URL-Social/Claimbot"/>
<link rel="http://purl.org/dc/terms/hasPart" 
      typeof="https://schema.org/ResearchOrganization" 
      href="URL-RIMS"/>

6. Claimbot

As shown in Figure 3, Claimbot is a machine actor that stands with one foot in a social network, ready to receive a post from Carol in which she claims a research contribution, and keen to respond to Carol once her claim has been processed. Claimbot stands with the other foot outside of the social network to ensure that the claim logging process handles Carol’s claim.

Claimbot's position a research contribution claim network
Claimbot as a bridge between the Social Network and the Claim Logging Process.

In order to decide whether to relay Carol’s claim to the claim logging process, Claimbot performs verifications, including:

There are two possible outcomes of these verifications:

7. Claim Logging Process

Figure 4 provides an insight into the claim logging process that starts when Claimbot relays the posting it obtained ([3] in Figure 1 ; [2] in Figure 3 ; [1] in Figure 4) in which Carol claims URL-F. We can safely assume that the following information is available in such message:

The claim logging process consists of two tasks that are discussed in the remainder of this section, i.e. summarization and logging of a claim in the claim network community log. This section describes a scenario in which Claimbot and the claim logging process:

However, although a close association between Claimbot and the claim logging process is assumed, other scenarios are possible and are described in the Interoperability section Distributed Claim Logging Process.

the claim logging process in a research contribution claim network
The Claim Logging Process in a Research Contribution Claim Network.

7.1. Summarization

The summarization task consists of accessing URL-F and gathering information about it that is necessary for the creation of a claim record in the claim network community log that pertains to Carol’s claim.

In the experiment that led to this blueprint, information was gathered by means of a Zotero Translation Server that extracted structured metadata from URL-F and did a quite acceptable job at it. But other approaches can be envisaged, including summarizing the content at URL-F using AI techniques or creating an archival copy of it in a web archive. But using different approaches to gather information for different kinds of contributions can also be envisaged. For example, structured metadata can readily be discovered for traditional contributions identified by a persistent identifier but is harder to extract for non-traditional contributions such as a radio interview.

It is up by the community served by the claim logging process to determine the requirements regarding the information that is necessary for the creation of a claim record.

There are two possible outcomes of the summarization task:

7.2. Claim Logging

The claim logging task consists of creating a claim record pertaining to Carol’s claim in the claim network community log. The claim record that contains the information gathered by the summarization task must be made accessible at a URL that is specific to Carol’s claim of URL-F, i.e. at URL-Claim ([5] in Figure 1). With this regard:

With the claim record created:

7.3. Claim Network Community Log

It is up to the community served by the claim logging process to determine:

Furthermore, there are no expectations regarding the long-term persistence of the claim network community log nor of the URLs of any of the claim records it stores. Implementing the claim network community log as a sliding-window cache is especially conceivable when downstream systems, such as the RIMS that are served by the claim logging process, provide adequate guarantees regarding long-term information persistence. These considerations must be taken into account in case long-term persistence of the claim network community log is not pursued:

8. Retrieving Claim Records

In order for Carol’s institutional RIMS to remain up-to-date regarding the contributions she claims, it must be able to obtain the claim records that are created for those claims in the claim network community log. Also, depending on the policy of the community served by a claim logging process, downstream systems other than Carol’s institutional RIMS may be entitled to aggregate information about research contributions.

Depending on the technical capabilities of downstream systems two approaches can be considered:

9. Interoperability Considerations

This section focuses on aspects of a research contribution claim network that may benefit from introducing interoperability across various instantiations, e.g. to increase ease of use, optimize chances for adoption, enable the reuse of tools, etc.

9.1. Distributed Claim Logging Process

The communication between Carol and Claimbot adheres to the protocol used by the social network on which they have an account. For Mastodon, that is a combination of the ActivityPub W3C Recommendation and the Mastodon API.

But, Claimbot asking the claim logging process to handle Carol’s claim of URL-F and the claim logging process responding to Claimbot when that process has concluded, requires communicating beyond the social network. With this regard, the section Claim Logging Process assumes that Claimbot and the claim logging process operate under the umbrella of the same organization/domain as a single overarching task. As such, the communication between both can be handled as a mere internal matter. But other scenarios are possible and would benefit from an agreement regarding the communication protocol to be used in order to allow for the re-use of tools across research contribution claim networks:

Claimbot and the claim logging process operated by different organizations
Claimbot and the Claim Logging Process Operated by Different Organizations.

The experiment that provided the inspiration for this blueprint successfully used the Event Notifications in Value-Adding Networks for these communications. In this case, a party communicates by sending Notifications to the Inbox of the other party. The approach is attractive for a variety of reasons including:

In order to allow gaining a better insight in the use of Event Notifications in Value-Adding Networks for the communication between Claimbot and the claim logging process, Appendix 1 provides sample Notifications for requests/responses between Claimbot and a claim logging process operated by a different organization that handles both summarization and claim logging under a single umbrella (Figure 5).

Claimbot, summarization, and claim logging operated by different organizations
Claimbot, Summarization, and Claim Logging Operated by Different Organizations.

The experiment that is the basis for this blueprint implemented an approach in which Claimbot and both tasks of the claim logging process were handled as autonomous distributed modules (Figure 6). It successfully used Event Notifications to establish interoperable communication. This is described in a detailed technical document about the experimental set-up.

When Claimbot and the claim logging process act under the umbrella of different organizations/domains, a mechanism to authorize incoming requests is helpful. This can be achieved by means of verification mechanisms that are appropriate for the communication protocol used between Claimbot and the claim logging process. When using the Event Notifications approach, both Claimbot and the claim logging process need a mechanism to restrict the parties that can send Notifications to their respective Inboxes. With this regard, the use of a Content-Digest or Signature HTTP header when sending Notifications can be considered.

9.2. Retrieving Claim Records - Realtime Push by the Claim Logging Process

Downstream systems that support a push-interface can be kept informed about new claim records as they are being added to the claim network community log:

In order to make such information push realistically possible in an environment with many research contribution claim networks and many downstream systems, including RIMS, establishing interoperability is advisable. The Event Notifications in Value-Adding Networks approach presents itself as an attractive candidate for the same reasons that were brought forward in Distributed Claim Logging Process. Moreover, use of the same interoperability substrate to support communication between the claim logging process and both Claimbot and downstream systems is attractive and efficient.

When using the the Event Notifications approach, downstream systems need a mechanism to restrict the parties that can send Notifications to their respective Inboxes. With this regard, the use of a Content-Digest or Signature HTTP header when sending Notifications can be considered.

In order to allow gaining a better insight in the use of Event Notifications in Value-Adding Networks for the communication between the claim logging process and downstream systems, including the institutional RIMS for which the process operates, Appendix 2 provides detailed notification information.

Appendix 1: Notifications between Claimbot and the Claim Logging Process

The Event Notifications in Value-Adding Networks (EN) protocol is a lightweight, asynchronous messaging approach for direct communication between participants in a network that does not require any centralized infrastructure. The protocol draws from the Decentralized Web movement and builds on W3C standards including Linked Data Notifications (LDN) and Activity Streams 2.0 (AS2). As a way to indicate its core building blocks, LDN+AS2 is used to denote event notifications sent using the LDN protocol that carry AS2 payloads.

The EN protocol specifies which communication patterns and AS2 payloads are valid. It is a specialized implementation of the LDN protocol designed for scholarly communication, but it has also been applied in archival settings. COAR Notify is the primary implementation of EN, using it to support peer review and open access publishing workflows.

Event notifications between Claimbot and the claim logging process are sent to their respective LDN Inboxes in a manner that is compliant with the Linked Data Notifications protocol. Depending on their nature, incoming notifications may or may not require the recipient to respond. Each notification carries a JSON-LD payload that uses the AS2 vocabulary.

The below sections describe communication patterns between Claimbot and the claim logging process in a scenario with a distributed distributed claim logging process as illustrated by Figure 5. The following example URLS are used to illustrate notifications pertaining to a claim by Carol, which is processed by the claim logging process and, if successful, subsequently recorded in the claim network community log (Appendix 1) and pushed as an update to Carol’s institutional RIMS (Appendix 2):

Table 1: Example URLs in the claim workflow
Description URL
Carol
Carol’s social network profile https://social.edu.nl/@carol
Carol’s social media handle @carol@social
Carol’s institutional RIMS profile https://my.institute.nl/person/23189-231
Carol’s social network post claiming URL-F https://social.edu.nl/@carol/112891078566219289
The URL-F claimed in Carol’s social network post https://parliament.nl/questions/2025-21-121291
Claimbot
Claimbot’s social network profile https://social.edu.nl/@claimbot
Claimbot’s social media handle @claimbot@social
Claimbot’s LDN Inbox https://claimbot.nl/inbox/
Claim logging process
Claim Network Community Profile Document https://summary.surf.nl/profile.html
Claim logging process LDN Inbox https://summary.surf.nl/inbox/
Claim record for Carol’s URL-F claim https://summary.surf.nl/claim/12712-128219

Notification from Claimbot to the claim logging process

This communication pattern is used by Claimbot to relay Carol’s social network posting in which she claims URL-F to the claim logging process, thereby requesting processing of the claim.

Offer

To request handling Carol’s claim of URL-F, Claimbot sends an LDN+AS2 notification to the Inbox of the claim logging process that has the following properties:

An LDN+AS2 notification pertaining to Carol’s claim of research contribution https://parlaiment.nl/questions/2025-21-121291 sent from Claimbot to the claim logging process. 
{
    "@context": "https://www.w3.org/ns/activitystreams",
    "id": "urn:uuid:urn:uuid:75806b42-41f5-46fb-8519-6e964c93c19e",
    "type": "Offer",
    "published": "2025-02-02T06:46:01.000Z",
    "actor": {
      "id": "https://social.edu.nl/@claimbot",
      "name": "Claimbot",
      "inbox": "https://claimbot.nl/inbox/",
      "type": "Service"
    },
    "object": {
      "id": "https://social.edu.nl/@carol/112891078566219289",
      "content": "I just submitted my first question to the Dutch 
      parliament! https://parliament.nl/questions/2025-21-121291 
      s /cc @claimbot@social",
      "url": [
        {
          "type": "Link",
          "href": "https://parliament.nl/questions/2025-21-121291"
        }
      ],
      "type": "Note"
    }
}

Notification(s) from the claim logging process to Claimbot

Upon receipt of an LDN+AS2 notification in its Inbox, the claim logging process can respond to Claimbot with one of the following notification types: Accept, Reject, Announce. They are described in the below sections.

Accept

Optionally, the claim logging process may respond to Claimbot with a notification that indicates receipt of the request to process Carol’s claim of URL-F and the intention to process it. To that end, the claim logging process sends an Accept LDN+AS2 notification to Claimbot’s Inbox that has the following properties:

Example 3 illustrates an LDN+AS2 notification that the claim logging process may send to Claimbot to indicate its intent to process Carol’s claim for URL-F. It is an optional response to the request to process the claim, which the claim logging process received as an Offer notification from Claimbot in Example 2.

An Accept LDN+AS2 notification sent by the claim logging process to Claimbot in response to the Offer sent in Example 2.

{
    "@context": "https://www.w3.org/ns/activitystreams",
    "id": "urn:uuid:dea5fba6-fcf3-4fb3-a7c5-4052490a79b4",
    "type": "Accept",
    "published": "2025-02-02T06:47:13.000Z",
    "actor": {
      "id": "https://summary.surf.nl/profile.html",
      "name": "SURF Claim Logger",
      "inbox": "https://summary.surf.nl/inbox/",
      "type": "Service"
    },
    "context": "https://parliament.nl/questions/2025-21-121291",
    "inReplyTo": "urn:uuid:75806b42-41f5-46fb-8519-6e964c93c19e",
    "object": {
      "id": "urn:uuid:urn:uuid:75806b42-41f5-46fb-8519-6e964c93c19e",
      "type": "Offer",
      "published": "2025-02-02T06:46:01.000Z",
      "actor": {
        "id": "https://social.edu.nl/@claimbot",
        "name": "Claimbot",
        "inbox": "https://claimbot.nl/inbox/",
        "type": "Service"
      },
      "object": {
        "id": "https://social.edu.nl/@carol/112891078566219289",
        "content": "I just submitted my first question to the Dutch 
        parliament! https://parliament.nl/questions/2025-21-121291 
        s /cc @claimbot@social",
        "url": [
          {
            "type": "Link",
            "href": "https://parliament.nl/questions/2025-21-121291"
          }
        ],
        "type": "Note"
      }
    }  
}

Reject

It is possible that the claim logging process can not successfully handle the request to process Carol’s claim for URL-F, for example because it runs into technical, privacy, security, or summarization problems. In this case, the claim logging service must send a Reject LDN+AS2 notification to Claimbot’s Inbox that has the following properties:

Example 4 illustrates an LDN+AS2 notification that the claim logging process must send to Claimbot to indicate its failure to process Carol’s claim for URL-F. It is a response to the request to process the claim, which the claim logging process received as an Offer notification from Claimbot in Example 2.

A Reject LDN+AS2 notification sent by the claim logging process to Claimbot in response to the Offer sent in Example 2.

{
    "@context": "https://www.w3.org/ns/activitystreams",
    "id": "urn:uuid:dea5fba6-fcf3-4fb3-a7c5-4052490a79b4",
    "type": "Reject",
    "published": "2025-02-02T06:47:13.000Z",
    "actor": {
        "id": "https://summary.surf.nl/profile.html",
        "name": "SURF Claim Logger",
        "inbox": "https://summary.surf.nl/inbox/",
        "type": "Service"
    },
    "context": "https://parliament.nl/questions/2025-21-121291",
    "inReplyTo": "urn:uuid:75806b42-41f5-46fb-8519-6e964c93c19e",
    "object": {
      "id": "urn:uuid:urn:uuid:75806b42-41f5-46fb-8519-6e964c93c19e",
      "type": "Offer",
      "published": "2025-02-02T06:46:01.000Z",
      "actor": {
        "id": "https://social.edu.nl/@claimbot",
        "name": "Claimbot",
        "inbox": "https://claimbot.nl/inbox/",
        "type": "Service"
      },
      "object": {
        "id": "https://social.edu.nl/@carol/112891078566219289",
        "content": "I just submitted my first question to the Dutch 
        parliament! https://parliament.nl/questions/2025-21-121291 
        s /cc @claimbot@social",
        "url": [
          {
            "type": "Link",
            "href": "https://parliament.nl/questions/2025-21-121291"
          }
        ],
        "type": "Note"
      }
    },
    "summary": "Page does not exist"
}

Announce

When the claim logging process has successfully processed Carol’s claim for URL-F and, as a result, has written a claim record into the claim network community log, it must send an Announce LDN+AS2 notification to Claimbot’s Inbox that has the following properties:

Example 5 illustrates an LDN+AS2 notification that the claim logging process must send to Claimbot to indicate it successfully processed Carol’s claim for URL-F. It is a response to the request to process the claim, which the claim logging process received as an Offer notification from Claimbot in Example 2.

An Announce LDN+AS2 notification sent by the claim logging process to Claimbot in response to the Offer sent in Example 2.

{
    "@context": "https://www.w3.org/ns/activitystreams",
    "id": "urn:uuid:ef99b36a-5896-46ee-b164-2da1467f6a35",
    "type": "Announce",
    "published": "2025-02-02T06:49:29.000Z",
    "actor": {
        "id": "https://summary.surf.nl/profile.html",
        "name": "SURF Claim Logger",
        "inbox": "https://summary.surf.nl/inbox/",
        "type": "Service"
    },
    "context": "https://parliament.nl/questions/2025-21-121291",
    "inReplyTo": "urn:uuid:75806b42-41f5-46fb-8519-6e964c93c19e",
    "object": {
        "id": "https://summary.surf.nl/claim/12712-128219",
        "type": "Document"
    }
}

The claim record, URL-Claim, for Carol’s claim of URL-F can be serialized in various formats. It is up to the community served by a claim logging process to agree on such formats keeping in mind that a claim record must be readable by both humans and machines. For humans, an HTML page can display the information collected during the claim logging process, whereas for machines, providing this information in JSON-LD is recommended. The same URL-Claim can serve both HTML and JSON-LD representations by supporting content negotiation.

Example 6 provides an example of a machine readable JSON-LD claim record that results of processing Carol’s claim for URL-F from Example 2.

The claim record, published at URL-Claim (https://summary.surf.nl/claim/12712-128219), provides the derived metadata and a generated summary of the research contribution that Carol claimed. It also contains information about Carol’s social profile at URL-Social/Carol (https://social.edu.nl/@carol) and her institutional profile URL-RIMS/Carol (https://my.institute.nl/person/23189-231). The claim record further includes a link to Carol’s social media post (https://social.edu.nl/@carol/112891078566219289) and the extracted URL-F of the claimed resource (https://parliament.nl/questions/2025-21-121291). 
{
    "@context" : "https://mycontributions.info/contexts/claim.jsonld",
    "id" : "urn:uuid:80965c07-59b4-429c-bdf9-50932284425c",
    "type" : "Claim",
    "about" : {
       "https://summary.surf.nl/claim/12712-128219" : {
          "id" : "https://parliament.nl/questions/2025-21-121291",
          "type" : "https://schema.org/WebPage",
          "author" : "House of Representatives",
          "datePublished" : "2025-01-30",
          "language" : "en-US",
          "title" : "Violating the ban on killing eels with a salt bath."
       }
    },
    "creator" : {
       "id" : "https://social.edu.nl/@carol",
       "type" : "Person",
       "name" : "Carol Hayes",
       "institutionalProfile": "https://my.institute.nl/person/23189-231",
    },
    "isBasedOn" : "https://social.edu.nl/@carol/112891078566219289",
    "mainEntity" : "https://parliament.nl/questions/2025-21-121291",
    "sdDatePublished" : "2025-02-02T06:45:54.000Z",
    "sdPublisher" : {
       "id" : "https://summary.surf.nl/profile.html",
       "type" : "Service",
       "name" : "SURF Claim Logger"
    }
 }

Appendix 2: Notification from the Claim Logging Process to Downstream RIMS

For a brief description of Event Notifications as well as an overview of the example URLs used in this Appendix, see the introductory paragraphs of Appendix 1.

The claim logging process can use an Event Notification to notify downstream systems, including Carol’s institutional RIMS, about the availability of the new claim record, URL-Claim, which results from its processing of Carol’s claim for URL-F.

Claim logging process to RIMS

In this EN communication pattern, the claim logging process sends a single Announce notification to the RIMS to deliver claim record information. The RIMS does not respond.

Announce

To announce the creation of a claim record that results from processing Carol’s claim for URL-F, the claim logging process sends an Announce LDN+AS2 notification to the Inbox of Carol’s institutional RIMS that has the following properties:

Example 7 illustrates an LDN+AS2 notification that the claim logging process sends to Carol’s institutional RIMS to announce the availability of a new claim record, URL-Claim.

The claim logging process sends an Announce LDN+AS2 notification to a RIMS to notify it about a newly processed claim by one of its affiliated researchers. The RIMS can asynchronously retrieve a machine-readable version of the claim record by content negotiating for JSON-LD with URL-Claim.

{
    "@context": "https://www.w3.org/ns/activitystreams",
    "id": "urn:uuid:ef99b36a-5896-46ee-b164-2da1467f6a35",
    "type": "Announce",
    "published": "2025-02-02T06:49:29.000Z",
    "actor": {
        "id": "https://summary.surf.nl/profile.html",
        "name": "SURF Claim Logger",
        "inbox": "https://summary.surf.nl/inbox/",
        "type": "Service"
    },
    "object": {
        "id": "https://summary.surf.nl/claim/12712-128219",
        "type": "Document"
    }
}