Linked Data Notifications (LDN)^[3] is aW3CRecommendation that describes acommunications protocol based onHTTP,URI, andRDF on how servers (receivers) can receive messages pushed to them by applications (senders), as well as how other applications (consumers) may retrieve those messages. Any web resource (like aHTML page) can advertise a receiving endpoint (inbox) for notification messages. Messages are expressed in RDF, and can contain arbitrary data.

Theweb is a decentralized system of web resources, published by multiple organizations and individuals. Web resources, such as web pages and more formally structuredlinked data, frequently include links to other resources across the web, and may comment or describe them in various ways. The receiving end, however, are not generally notified of such link creation, and thus are unable to providebacklinks without manual intervention. Interactions withinsocial media platforms, such as comments on a news article, are currently "locked" within the platform and hard to access across the web.

Severallinkback mechanisms exists, and are commonly used betweenblog systems, e.g. a "response" post in blog B about a post in blog A causes B's platform to send apingback to be shown on the original blog A. These mechanisms are, however, generally limited in which structured information can be sent, and the notifications themselves do not form part of the decentralized web and may be difficult to consume by any third party application.

A key motivation for LDN is to support notifications between decentralized Web applications,^[4] including web browsers who - not having their own HTTP server - are unable to generate a HTTP link for their reply messages. Another motivation is to structure notifications as RDF statements using anyControlled vocabulary - so that any consuming application can select the particular information they understand.

• Asender orreceiver performs aGET orHEAD to an existing HTTP resource. Itsinbox URI is discovered from either:
  • ALink: relation in the HTTP response headers of typehttp://www.w3.org/ns/ldp#inbox
  • An RDF statement embedded in the HTTP body using the RDF propertyhttp://www.w3.org/ns/ldp#inbox
• Asender creates a new notification (e.g. asJSON-LD), which itPOSTs to theinbox URI.
  • Thereceiver creates a new HTTP resource containing the posted notification and responds with201 Created and the created URI.
• Aconsumer retrieves RDF from the discoveredinbox URI usingGET, then:
  • Theconsumer parses the response body to find RDF statements with the propertyhttp://www.w3.org/ns/ldp#contains. The object of these statements give the URIs to the accepted LDN notifications.
  • Theconsumer retrieve any of the linked notification usingGET and process their RDF in an application-specific manner.
  • Notifications remain accessible, and can therefore be linked to and described in other web resources.

At each stage, the sender and consumer may performcontent negotiation to send or receive in any mutually agreedRDF serialization format, but a compliant LDN receiver must support at leastJSON-LD.

Asender orconsumer discovers the inbox for a given URI, in this example using theHEAD method:

HEADhttps://example.org/article/5HTTP/1.1

HTTP/1.1200OKLink:<https://example.org/inbox/7>; rel="http://www.w3.org/ns/ldp#inbox"

Asender sends a notification to the discovered inbox, in this example using theSchema.org vocabulary:

POSThttps://example.org/inbox/7HTTP/1.1Content-Type:application/ld+json{"@context":"http://schema.org","@type":"ReviewAction","object":{"@id":"https://example.org/article/5"},"agent":{"@type":"Person","name":"Alice"},"result":{"@type":"Review","reviewBody":"This article is the best I've ever seen!"}}

HTTP/1.1201CreatedLocation:http://example.org/inbox/f44f3f11

Aconsumer lists the content of the discovered inbox to find 3 notifications:

GEThttps://example.org/inbox/7HTTP/1.1Content-Type:application/ld+json

HTTP/1.1200OKContent-Type:application/ld+json{"@context":"http://www.w3.org/ns/ldp","@id":"https://example.org/inbox/7","contains":["https://example.org/inbox/5c6ca040","https://cdn.example.org/inbox/92d72f00","https://example.org/inbox/f44f3f11",]}

Note that the URIs of the original resource, inbox and notifications are not required to be hosted on the same HTTP server (e.g. they may be on aCDN). Theconsumer follows the links for any notifications they wish to retrieve.

In this example, theconsumer retrieves the newf44f3f11 notification, with content negotiation to prefer theTurtle RDF format:

GEThttps://example.org/inbox/f44f3f11HTTP/1.1Accept:application/ld+json;q=0.9, text/turtle;q=1.5

HTTP/1.1200OKContent-Type:text/turtle@prefixschema:<http://schema.org/>.[aschema:ReviewAction;schema:agent[aschema:Person;schema:name"Alice"];schema:object<https://example.org/article/5>;schema:result[aschema:Review;schema:reviewBody"This article is the best I've ever seen!"]].

SeveralLDN implementations exists,^[4][5] covering senders, consumers and receivers, including:

• dokieli (sender, consumer)
• errol (sender)
• Fedora Commons (receiver)
• Apache Marmotta (receiver)
• Carbon LDP (receiver)
• Linked Edit Rules (sender)
• Solid (sender, receiver, consumer)
• Virtuoso Universal Server (receiver, consumer)

AnyLinked Data Platform (LDP) implementations are also conforming Linked Data Notificationreceivers as LDN is a strict subset of LDP.^[4]

• World Wide Web Consortium standards

• CS1 errors: periodical ignored
• Articles with short description
• Short description matches Wikidata