Claims Network

1. Introduction

Research assessment is an integral part of academic life and measures the quality of the research output and, by cumulative evaluations, contributes to the assessment of each researcher. There is a global activity to take a broad range of activities and contributions into account in researcher assessments. Examples are the [COARA] (Coalition for Advancing Research Assessment) initiative and OpenAIRE [Graspos] researcher profile. A recurring question in these initiatives is: "How to capture information beyond traditional research outputs?" Current Research Information Systems (CRIS) seldom capture activities such as interviews, news reports about a researcher or research project, teaching activities, and contributions to open-source development.

In 2024, SURF (the ICR cooperative of Dutch education and research institutions) and IMEC-IDLab (the Flemish Internet Technology and Data Science Lab) created an experimental, decentralized claim network that collects and distributes claims about researcher activities and contributions. The claims network is depicted in Figure 1 below.

Figure 1: Overview of the claims network

The processing flow in the claims network is listed below:

• [1] Alice, a Dutch researcher, wants to claim a new contribution at URL-F for her scholarly record.

• [2] Alice, as an account on a national academic social networking service which provides researchers a safe communication medium to support informal researcher interactions with a focus on science, popularization of science, and education. In the Figure 1, the national academic social service social.edu.nl is implemented using Mastodon. With a 'toot' message including the URL-F , Alice claims her contribution. In her toot message she sends a carbon-copy (cc) of this message to a claim bot at the Mastodon handle @logbot@bots.surf.nl .

• [3] Using the Mastodon API, the claim bot receives push message for every toot address to the bot account @logbot@bots.surf.nl .

• [4] The claim bot reads the claimed URL-F from the incoming toot message and uses one or more summarizer services in the network to collect descriptive metadata for this URL.

• [5] The summarizer service, on request, generates a metadata summary for URL-F .

• [6] When a summary is available, the summarizer service updates the claim bot about the metadata summary.

• [7] The [=claim bot]= uses the summary to update a public activity log with Carol’s contributions. This activity log can be used by a national claims service (e.g. a CRIS system) to update the scholarly record for Alice.

2. Functional and non-functional requirements

A claims network should have the following functional requirements:

• Distributed architecture : The network should operate across multiple social networking services, claim bots, summarizer and claims services to prevent a reliance on a central authority for each of these services.

• Broad scope : The network should allow for the processing of a broad scope of Web resource about which researcher can make claims. The claims are not confined to traditional research outputs but can include various forms of content such as newspaper clips, media appearances, lectures recordings, and contributions to software development projects, among others.

• Automated content summarization : The network should automate content summarization for researcher claims. Providing a URL of a claimed Web resource to a claim bot should be sufficient to update the claim service with metadata about that claim.

• Automated updated of claims service pages : The network should provide automated updated claims service page that aligns with preferences of a researcher. Researchers can provide in their Mastodon profile the URL of a personal claims service page that should be updated by the network.

• Verification of ownership : The network should provide the verification of ownership of Mastodon account and claims service pages by supporting backlink verification.

• Verification of actors : The network should provide the verification of actors participating in the network. It should be possible to proof an actor is a researcher and part of some (national) research community.

• Selection and filtering : The network should provide a selection and filtering mechanism for claims by actors that are part of a particular research community. Research is a global enterprise, a claim bot may only provide services for researchers belonging to a national research community, or withing a discipline from that community.

• Version history : The network should provide a version history of all claims that are added to the claims service.

3. Terminology

The following terms are used in this specification:

Academic social networking service

A social network platform such as Mastodon that is used in an academic setting that is used by researchers to publish claims about a contribution to the scholarly record of the researcher.

Activity Log

A public machine-readable Web resource that contains descriptive metadata about claims created by a researcher combined with provenance information about the claim itself.

Artifact

An artifact is a Web resource identified by a URL that serves at the main focus of interaction between the participants in the network. Examples of artifacts are traditional scholarly contributions but also interviews, news reports about a researcher or research project, teaching activities, and contributions to open-source development.

Claim

An artifact that is a proof of a researcher activity that needs to become part of the scholarly record of a researcher.

Claim bot

An automated process that works on behalf of the researcher to collect claims, descriptive metadata about such claims and updates the activity Log of a researcher.

Claims network

A decentralized network of evolving claim assertions.

Claims service

A service node that collects claims made by a researcher and provides an public accessible overview activities and contributions of a researcher.

Data Node

A data node is a network node that hosts artifacts. Examples of data nodes are news agencies, institutional repositories, blogs, and governmental websites.

Inbox

An inbox is a Web location conform with the Event Notifications in Value-Adding Networks specification. Inboxes are setup by data nodes and service nodes to receive LDN+AS2 JSON-LD messages that are exchanged in the claims network.

Notification

A notification is are JSON-LD messages exchanged in the claim network using the Event Notifications in Value-Adding Networks specification.

Service Node

A service node provides value-added services for artifacts hosted by data nodes. An example of a service node is a summarizer service that generates descriptive metadata for a given Web resource.

Service Result

A service result is any outcome of providing a value-added service for an artifact. An example of a service result is a JSON document that contains the descriptive metadata generated by a summarizer service.

Summarizer Service

A summarizer service is a service node that, given claim, generates descriptive metadata about the claim.

Verification Service

A verification service is a node in the network that provides that verifies the identities of used by researchers in the claims network.

4. Network communication patterns

In a claims network automated agents, such as the claims bot, operate on behalf of a researcher to update an activity log and claims service with descriptive metadata about claims made by the researcher on a (national) academic social networking service. The network nodes operate by sending LDN+AS2 between each other that follow the Event Notifications in Value-Adding Networks specification.

Depending on the type of sender an receiver different types of messages that are specified below.

4.1. Academic social network service to claimbot

The academic social network service to claimbot pattern is used by the academic social networking service to forward claims to a claims bot. Example 1 provides an example of such a claim made by the researcher Alice on a Mastodon instance hosted at https://social.edu.nl .

I just submitted by first question to the Dutch parliament! 
https://parlaiment.nl/questions/2025-21-121291 /cc @logbot@bots.surf.nl 

We assume that the claims network includes the capability to transform (toot) messages that are forwarded to the claims bot into a LDN+AS2 message. An example implementation could involve a process operating on behalf of the claim bot, which monitors the @logbot@bots.surf.nl account on bots.surf.nl using the Mastodon API and generates LDN+AS2 messages for each incoming toot directed at the claim bot.

4.1.1. Announce

An academic social networking service should trigger a claim bot by sending an LDN+AS2 message to the Inbox of the claim bot with the following properties:

• The id property should contain a new minted identifier for every toot message.

• The type property is the fixed string Announce .

• The actor property should contain:

  • As value of the id property the social networking profile URL of the researcher who created the original post.

  • As value of the name property, the name of the researcher.

  • As value of the type property, the fixed string Person .

• The origin property should contain information about the LDN+AS2 generator software:

  • As value of the id property, a public WebID profile URL.

  • As value of the name property, the name of the generator software.

  • As value of the type property, the fixed string Service .

• The object property should contain information about the forwarded social networking post:

  • As value of the id property, the URL of the social networking post.

  • As value of the content property, the post message.

  • The url property is a collection of zero or more URL-s that are mentioned in the post message. Each url item has the following properties:

    • As value of the href property, the URL that is mentioned in the post message.

    • As value of the type property, the fixed string Link .

  • As value of the type property, the fixed string Note .

• The published property should contain in ISO 8601 format the datetime of the original post message.

In Example 2, we illustrate the structure of an LDN+AS2 message corresponding to the toot message presented in Example 1.

{
    "@context": "https://www.w3.org/ns/activitystreams",
    "id": "urn:uuid:6d21a2ae-df59-40d9-999c-18e19277d21a",
    "type": "Announce",
    "published": "2025-02-02T06:45:54.000Z",
    "actor": {
      "id": "https://social.edu.nl/@alice",
      "name": "Alice",
      "type": "Person"
    },
    "origin": {
      "id": "https://mycontributions.info/service/m/profile/card#me",
      "name": "Mastodon Bot",
      "type": "Service"
    },
    "object": {
      "id": "https://social.edu.nl/@alice/112891078566219289",
      "content": "<p>I just submitted by first question to the Dutch parliament! https://parlaiment.nl/questions/2025-21-121291 /cc @logbot@bots.surf.nl",
      "url": [
        {
          "type": "Link",
          "href": "https://parlaiment.nl/questions/2025-21-121291"
        }
      ],
      "type": "Note"
    }
}

4.2. Claimbot to summarizer service

The claimbot to summarizer service pattern is used by a claim bot to request the generation of descriptive metadata for a claim at one or more summarizer services. Example 1, contains an example of such a claim: https://parlaiment.nl/questions/2025-21-121291 . A summarizer service can have many types of implementations such as Zotero Translation Server, web archives, Crossref clients, web crawlers, AI-driven text analyzers to name a few. What all implementation have in common is that they employ the LDN+AS2 messages using the Event Notifications protocol to communicate asynchronously with the claims bot. Asynchronous messaging enables the summarizer service to scale efficiently by executing data extraction algorithms through batch jobs, as opposed to real-time processing.

4.2.1. Offer

To request a summary for a claim an LDN2+AS2 message should be send to the Inbox of a summarizer service with the following properties:

• The id property should contain a new minted identifier for every toot message.

• The type property is the fixed string Offer .

• The actor property should contain information about the LDN+AS2 generator software:

  • As value of the id property, a public WebID profile URL.

  • As value of the name property, the name of the generator software.

  • As value of the inbox property, the Inbox of the claim bot.

  • As value of the type property, the fixed string Service .

• The object property should contain information about the claim:

  • As value of the id property, the URL of the claim.

  • As value of the type property, the fixed string Document .

• The published property should contain in ISO 8601 format the datetime of the original post message.

In Example 3, we illustrate the structure of an LDN+AS2 message that the claim bot sends to the summarizer service pertaining to the claim of Example 1.

{
    "id": "urn:uuid:urn:uuid:75806b42-41f5-46fb-8519-6e964c93c19e",
    "type": "Offer",
    "published": "2025-02-02T06:46:01.000Z",
    "actor": {
      "id": "http://mycontributions.info/service/m/profile/card#me",
      "name": "Mastodon Bot",
      "inbox": "http://mycontributions.info/service/m/inbox/",
      "type": "Service"
    },
    "object": {
      "id": "https://parlaiment.nl/questions/2025-21-121291",
      "type": "Document"
    }
}

4.3. Summarizer to claimbot service

The summarizer service has the four possible responses to respond to an LDN+AS2 message received in the Inbox of the service:

• [1] Ignore the LDN+AS2 message if it is not well-formatted.

• [2] Tentatively accept the LDN+AS2 message as a new request for metadata extraction. Optionally the summarizer service can send an Accept LDN+AS2 message to the Inbox of the claim bot as confirmation.

• [3] Reject the LDN+AS2 message for one of two reasons. In both of these cases the summarizer service should send a Reject LDN+AS2 message to the Inbox of the claim bot:

  • [a] No attempt was made to summarize the claim due to technical, privacy or security reasons.

  • [b] An attempt was made to summarize the claim, but it lead a processing failure.

• [4] If summarization of claim has a (possible empty) result, then an Announce LDN+AS2 message should be send to the Inbox of the claim bot.

For each of the four scenarios we will present below the requirements for the LDN+AS2 messages.

4.3.1. Accept

To (tentatively) accept an offer for the summarization of a claim, the summarizer service can optionally send an Accept LDN+AS2 message to the Inbox of the claim bot with the following properties:

• The id property should contain a new minted identifier for every toot message.

• The type property is the fixed string Accept .

• The actor property should contain information about the summarizer service:

  • As value of the id property, a public WebID profile URL.

  • As value of the name property, the name of the generator software.

  • As value of the inbox property, the Inbox of the summarizer service.

  • As value of the type property, the fixed string Service .

• The context property should contain the URL of the claim.

• The inReplyTo property should contain the identifier of the Offer that was sent by the claim bot to the summarizer service.

• The object property should contain in-line the complete content of the Offer that was sent by the claim bot to the summarizer service.

• The published property should contain in ISO 8601 format the datetime of the original post message.

In Example 4, we illustrate the structure of an LDN+AS2 message that the summarizer service can send to the claim bot in to tentatively accept the Offer send in Example 3.

{
    "@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://mycontributions.info/service/x/profile/card#me",
        "name": "Zotero Service Provider",
        "inbox": "http://mycontributions.info/service/x/inbox/",
        "type": "Service"
    },
    "context": "https://parlaiment.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": "http://mycontributions.info/service/m/profile/card#me",
          "name": "Mastodon Bot",
          "inbox": "http://mycontributions.info/service/m/inbox/",
          "type": "Service"
        },
        "object": {
          "id": "https://parlaiment.nl/questions/2025-21-121291",
          "type": "Document"
        }
    }
}

4.3.2. Reject

To reject an offer for the summarization of a claim, the summarizer service should send a Reject LDN+AS2 message to the Inbox of the claim bot with the following properties:

• The id property should contain a new minted identifier for every toot message.

• The type property is the fixed string Reject .

• The actor property should contain information about the summarizer service:

  • As value of the id property, a public WebID profile URL.

  • As value of the name property, the name of the generator software.

  • As value of the inbox property, the Inbox of the summarizer service.

  • As value of the type property, the fixed string Service .

• The context property should contain the URL of the claim.

• The inReplyTo property should contain the identifier of the Offer that was sent by the claim bot to the summarizer service.

• The object property should contain in-line the complete content of the Offer that was sent by the claim bot to the summarizer service.

• The published property should contain in ISO 8601 format the datetime of the original post message.

• A summary property may be available that contains free text explaining the reason for rejecting the Offer .

In Example 5, we illustrate the structure of an LDN+AS2 message that the summarizer service can send to the claim bot in reject the Offer send in Example 3.

{
    "@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://mycontributions.info/service/x/profile/card#me",
        "name": "Zotero Service Provider",
        "inbox": "http://mycontributions.info/service/x/inbox/",
        "type": "Service"
    },
    "context": "https://parlaiment.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": "http://mycontributions.info/service/m/profile/card#me",
          "name": "Mastodon Bot",
          "inbox": "http://mycontributions.info/service/m/inbox/",
          "type": "Service"
        },
        "object": {
          "id": "https://parlaiment.nl/questions/2025-21-121291",
          "type": "Document"
        }
    },
    "summary": "Page does not exist"
}

4.3.3. Announce

To announce the result for the summarization of a claim, the summarizer service should send an Announce LDN+AS2 message to the Inbox of the claim bot with the following properties:

• The id property should contain a new minted identifier for every toot message.

• The type property is the fixed string Announce .

• The actor property should contain information about the summarizer service:

  • As value of the id property, a public WebID profile URL.

  • As value of the name property, the name of the generator software.

  • As value of the inbox property, the Inbox of the summarizer service.

  • As value of the type property, the fixed string Service .

• The context property should contain the URL of the claim.

• The inReplyTo property should contain the identifier of the Offer that was sent by the claim bot to the summarizer service.

• The object property should contain information where to find the Service Result document that contains the extracted metadata for a claim:

  • As value of the id property, a public URL to a summarization document should be provide.

  • As value of the type property, the fixed string Document .

• The published property should contain in ISO 8601 format the datetime of the original post message.

In Example 6, we illustrate the structure of an LDN+AS2 message that the summarizer service can send to the claim bot to announce the summary for the claim of Example 3.

{
    "@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://mycontributions.info/service/x/profile/card#me",
        "name": "Zotero Service Provider",
        "inbox": "https://mycontributions.info/service/x/inbox/",
        "type": "Service"
    },
    "context": "https://parlaiment.nl/questions/2025-21-121291",
    "inReplyTo": "urn:uuid:75806b42-41f5-46fb-8519-6e964c93c19e",
    "object": {
        "id": "https://mycontributions.info/service/x/result/2024/08/14/9a3b6978a49f9aaf055181e5993c5d89.json",
        "type": "Document"
    }
}

Service Result summarization results can be serialized using many formats. Within a claims network it is essential for network partners to reach a common agreement on the expected output format. Examples of potential formats include, but are not limited to, CSL JSON, schema.org and Bibo.

4.4. Claim bot to Academic social network service

TDB

5. Trust

TDB