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

An overview of a processing flow in the claims network is listed below. The details of such a processing flow will be presented in section 4.

• [1] Alice, a Dutch researcher, wants to claim a new contribution artifact 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 she sends a carbon-copy (cc) of this notification to a claim bot at the Mastodon handle @logbot@bots.surf.nl .

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

• [4] The claim bot reads the claimed artifact URL-F from the incoming toot 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.

Non-functional requirements of a decentralized claims network includes: scalability to handle the processing of researcher claims on a national level, performance levels to process and update claims service pages in near-real time, resilience against network outages, and adherence to interoperability affordances using open standards and protocols.

3. Terminology

To discuss the claims network, 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 append-only Web resource that contains descriptive metadata about claims artifacts 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

A claim is a notification attributed to a researcher, presenting an artifact as evidence of their research activity.

Claim bot

An automated process that works on behalf of the researcher to collect claims, descriptive metadata about claim artifacts and updates a activity log on behalf 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.

Claim summary

An RDF source in the JSON-LD format containing a summary of a claim artifact including provenance information about the claim itself.

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 notifications that are exchanged in the claims network.

Notification

A notification is a JSON-LD message 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 artifact, generates descriptive metadata about the artifact.

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. General Process Flow

A claims network consists of multiple actors exchanging information through a combination of application-specific notifications (e.g., Mastodon API notifications, if Mastodon serves as the implementation for the academic social networking service) and application-neutral claims network notifications. The application-neutral messaging format follows the Event Notifications in Value-Adding Networks messaging patterns, which will be explained in the next section.

The processing workflow in a claim network is depicted in Figure 2 and is explained below.

Figure 2: notification exchanges in a claims network

Step (1) The processing workflow in Figure 2 when a researcher, depicted as Alice , creates a toot in an academic social networking service presenting a contribution to her scholarly record. In our example we will use Mastodon as the implementation of such a service. Each claim toot contains at least a URL to an artifact and a references to a Mastodon account of a claim bot . An example of such a toot could be:

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

In our examples we assume that this toot is available at the URL https://social.edu.nl/@alice/112891078566219289 . The toot with this URL we call the claim. The URL https://parliament.nl/questions/2025-21-121291 we will call the (claim) artifact.

Step (2) A process in the associated with claim bot monitors toots that are directed to the Mastodon account of the claim bot. This process picks up the new toot from Alice.

Step (3) The process of Step 2, transforms each artifact in the toot (claim) into an Event Notifications in Value-Adding Networks (EN) LDN+AS2 Announce notification and deliver this notification to the LDN Inbox of the claim bot.

Step (4) For each LDN+AS2 Announce notification the claim bot creates an LDN+AS2 Offer notification directed to a summarizer service requesting the summarization of the artifact mentioned in the claim.

Step (5) A summarizer service (tentatively) accepts the request for summarization of the artifact and sends an LDN+AS2 Accept notification to the claim bot.

Step (6) The summarizer service retrieves the Web resource of the artifact and generates a metadata summary. This service result is made available at a public URL. In our examples we assume this URL to be https://summary.surf.nl/result/12712-128219.jsonld .

Step (7) The summarizer service sends an LDN+AS2 Announce notification to the claim bot with the location of the service result.

Step (8) The claim bot uses the service result of the summarizer service to publish an RDF claim summary. The claim bot sends an LDN+AS2 Announce notification to a activity log with the location of the claim summary. The activity log uses this information to document open science activities of the researcher.

Step (9) The claim bot send a toot to Alice informing her about the update of the activity log.

5. 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 notifications that are specified below.

5.1. Academic social network service to claim bot

The academic social network service to claim bot 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 my first question to the Dutch parliament! 
https://parliament.nl/questions/2025-21-121291 /cc @logbot@bots.surf.nl 

We assume that the claims network includes the capability to transform (toot) notifications that are forwarded to the claims bot into an LDN+AS2 notification. 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 notifications for each incoming toot directed at the claim bot.

5.1.1. Announce

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

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

• 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 academic social networking service post.

    • 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 academic social networking service post.

In Example 2, we illustrate the structure of an LDN+AS2 notification corresponding to the toot 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://bots.surf.nl/profile/card#me",
      "name": "Mastodon Bot",
      "type": "Service"
    },
    "object": {
      "id": "https://social.edu.nl/@alice/112891078566219289",
      "content": "<p>I just submitted my first question to the Dutch parliament! https://parliament.nl/questions/2025-21-121291 /cc @logbot@bots.surf.nl",
      "url": [
        {
          "type": "Link",
          "href": "https://parliament.nl/questions/2025-21-121291"
        }
      ],
      "type": "Note"
    }
}

5.2. Claim bot to summarizer service

The claim bot to summarizer service pattern is used by a claim bot to request the generation of descriptive metadata for an artifact at one or more summarizer services. Example 1, contains an example of such an artifact: https://parliament.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 notifications 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.

5.2.1. Offer

To request a summary for an artifact an LDN2+AS2 notification 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.

• 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 artifact:

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

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

• The published property should contain in ISO 8601 format the datetime of the original academic social networking service post.

In Example 3, we illustrate the structure of an LDN+AS2 notification 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": "https://bots.surf.nl/profile/card#me",
      "name": "Mastodon Bot",
      "inbox": "https://bots.surf.nl/inbox/",
      "type": "Service"
    },
    "object": {
      "id": "https://parliament.nl/questions/2025-21-121291",
      "type": "Document"
    }
}

5.3. Summarizer to claim bot service

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

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

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

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

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

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

• [4] If summarization of artifact has a (possible empty) result, then an Announce LDN+AS2 notification 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 notifications.

5.3.1. Accept

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

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

• 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 artifact.

• 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 academic social networking service post.

In Example 4, we illustrate the structure of an LDN+AS2 notification 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://summary.surf.nl/profile/card#me",
        "name": "Zotero Service Provider",
        "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://bots.surf.nl/profile/card#me",
          "name": "Mastodon Bot",
          "inbox": "https://bots.surf.nl/inbox/",
          "type": "Service"
        },
        "object": {
          "id": "https://parliament.nl/questions/2025-21-121291",
          "type": "Document"
        }
    }
}

5.3.2. Reject

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

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

• 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 artifact.

• 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 academic social networking service post.

• 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 notification 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://summary.surf.nl/profile/card#me",
        "name": "Zotero Service Provider",
        "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://bots.surf.nl/profile/card#me",
          "name": "Mastodon Bot",
          "inbox": "https://bots.surf.nl/inbox/",
          "type": "Service"
        },
        "object": {
          "id": "https://parliament.nl/questions/2025-21-121291",
          "type": "Document"
        }
    },
    "summary": "Page does not exist"
}

5.3.3. Announce

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

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

• 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 artifact.

• 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 an artifact:

  • 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 academic social networking service post.

In Example 6, we illustrate the structure of an LDN+AS2 notification that the summarizer service can send to the claim bot to announce the summary for the artifact 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://bots.surf.nl/profile/card#me",
        "name": "Zotero Service Provider",
        "inbox": "https://bots.surf.nl/inbox/",
        "type": "Service"
    },
    "context": "https://parliament.nl/questions/2025-21-121291",
    "inReplyTo": "urn:uuid:75806b42-41f5-46fb-8519-6e964c93c19e",
    "object": {
        "id": "https://bots.surf.nl/result/12712-128219.jsonld",
        "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.

Example 7 provides an example schema.org summarization service result https://summary.surf.nl/result/12712-128219.jsonld of Example 6.

{
  "@context": "https://schema.org/",
  "id" : "https://parliament.nl/questions/2025-21-121291",
  "type" : "http://purl.org/net/xbiblio/csl#post-weblog",
  "author" : {
     "id" : "https://orcid.org/0000-0000-0000-0001",
     "familyName" : "Hayes",
     "givenName" : "Alice",
     "type" : "Person"
  },
  "datePublished" : "2025",
  "language" : "en-US",
  "title" : "Violating the ban on killing eels with a salt bath."
}

5.4. Claim bot to the activity log service

The claim bot to the activity log service pattern is used by a claim bot to update an activity log about a summary that was made for a claim. Example 1, contains an example of such a claim: https://parliament.nl/questions/2025-21-121291 . Example 7, provides an example of a summary that was generated for that claim. To publish the summary in an application-neutral format while including its provenance, we propose a Claim Summary RDF source, of which we will provide an example in the following subsection, an explained in section 6. This claim summary will be offered to an activity log using an LDN+AS2 event notification.

5.4.1. Claim Summary

A claim summary is a JSON-LD serialization of a claim summary including provenance information about the source of this claim. The about section of the claim summary contains the RDF version of the claim using the Schema.org vocabulary. The creator and isBasedOn sections provides information the account on the academic social networking service that made the claim. The mainEntity provides the URL of the claim. And, the sdPublisher and sdDatePublished provides information about the claim bot service that was responsible for collecting metadata about the claim.

The claim summary should be published by the claim bot as a publicly available Web resource. Example 8 provides an example of such a claim summary based on the claim of Example 1 and the generated summary of Example 7. We assume this claim summary is available at https://bots.surf.nl/summary/237123-21318.jsonld .

{
    "@context" : "https://mycontributions.info/contexts/claim.jsonld",
    "id" : "urn:uuid:80965c07-59b4-429c-bdf9-50932284425c",
    "type" : "Claim",
    "about" : {
       "https://summary.surf.nl/result/12712-128219.jsonld" : {
          "id" : "https://parliament.nl/questions/2025-21-121291",
          "type" : "https://schema.org/WebPage",
          "author" : {
             "id" : "https://orcid.org/0000-0000-0000-0001",
             "familyName" : "Hayes",
             "givenName" : "Alice",
             "type" : "Person"
          },
          "datePublished" : "2025",
          "language" : "en-US",
          "title" : "Violating the ban on killing eels with a salt bath."
       }
    },
    "creator" : {
       "id" : "https://social.edu.nl/@alice",
       "name" : "Alice Hayes",
       "type" : "Person"
    },
    "isBasedOn" : "https://social.edu.nl/@alice/112891078566219289",
    "mainEntity" : "https://parliament.nl/questions/2025-21-121291",
    "sdDatePublished" : "2025-02-02T06:45:54.000Z",
    "sdPublisher" : {
       "id" : "https://bots.surf.nl/profile/card#me",
       "type" : "Service",
       "name" : "Mastodon Bot"
    }
 }

5.4.2. Announce

To announce a new claim summary, the claim bot sends an Announce LDN+AS2 notification to the LDN Inbox of the activity log service with the following properties:

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

• The type property is the fixed string Announce .

• The actor property should contain information about the claim bot:

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

  • As value of the name property, the name of the claim bot.

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

• The origin property should contain information about claim bot software:

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

  • As value of the name property, the name of the claim bot software.

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

• The object property should contain information claim summary:

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

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

• The published property should contain in ISO 8601 format the datetime of the original academic social networking service post.

Example 9 provides an example of an Announce LDN+AS2 notification sent by the claim bot using claim summary of Example 8 published at https://bots.surf.nl/summary/237123-21318.jsonld .

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "urn:uuid:535dff96-1082-43b8-b1ce-66933bee768a",
  "type": "Announce",
  "published": "2025-02-02T06:48:39.000Z",
  "actor": {
    "id": "https://bots.surf.nl/profile/card#me",
    "name": "Mastodon Bot",
    "type": "Service"
  },
  "origin": {
    "id": "https://mastodon.bit.are.us/profile",
    "name": "Mastodon Bot Software",
    "type": "Service"
  },
  "object": {
    "id": "https://bots.surf.nl/summary/237123-21318.jsonld",
    "type": "Document"
  }
}

6. Claim Summary

A claim summary is an RDF source in the JSON-LD format containing a summary of a claim artifact including provenance information about the claim itself. Each claim summary has the following properties:

• The id property should contain a new minted identifier for every claim summary.

• The type property is the fixed string Claim .

• The about property provides information about an artifact in a claim. The value of an about is a single entry with a global unique identifier. The entry should contain:

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

  • As value of the type property, a Schema.org CreativeWork or one of its subtypes.

  • All other properties and sub-properties are conform to the CreativeWork schema of one of its subtypes.

• The creator property provides information about the academic social networking service account that made the claim, with:

  • As value of the id property, the URL of the academic social networking service account that made the claim.

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

  • As value of the name property, the full name associated with the academic social networking service account.

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

• The mainEntity property should contain the URL of the artifact that is mentioned in the claim.

• The sdDatePublished property should contain the ISO 8601 publication date of the claim summary.

• The sdPublisher property should contain information about the claim bot, with:

  • As value of the id property, the public WebID profile of the claim bot

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

  • As value of the name property, the name of the claim bot.

An example of a claim summary document is provided in Example 8.

7. Activity Log

An activity log is a public machine-readable append-only Web resource that contains descriptive metadata about claims artifacts created by a researcher combined with provenance information about the claim itself.

Individual claim summaries are published as RDF resources. A logical next step would be to make all these RDF resources accessible through an RDF endpoint. In a claims network, we follow the Linked Data Fragments architecture, which does not prescribe a specific publication platform for such logs. A collection of claim summaries can be made available as a downloadable dump. This solution would be expensive for clients. At the high end a SPARQL end point would provide clients with a query interface, but a high implementation cost for servers. In the middle a Quad Pattern Fragments service could be setup that is relatively a low bandwidth solution for a server and a bit higher implementation cost for clients.

8. Discovery of network components

TDB

9. Trust

TDB

10. Process Flow with Trust

TDB