A Like notification created by sloph, displayed by dokieli.

A notification about a comment created by a user (JSON-LD).

{ "@context": { "sioc": "http://rdfs.org/sioc/ns#" } "@id": "", "@type": "sioc:Comment", "sioc:content": "This is a great article!", "as:inReplyTo": { "@id": "http://example.org/article" }, "sioc:created_at": { "@value": "2015-12-23T16:44:21Z" } }

• Script

A: Solid Words (a sender), B: Linked Edit Rules (a sender), C: OnScreen (a consumer) displaying notifications sent by A and B.

Accommodating different targets

<p>Per <em>R4 Adaptability</em>, we want LDN to be available for all resources in any publishing context. We consider lowering the bar for publishers of target resources to be a worthwhile trade-off against slightly increased complexity for senders and consumers. This is why we require that senders and consumers must be equipped to discover Inboxes through both HTTP headers and RDF content. </p> <p>Since binary formats such as images and video cannot contain an RDF relation, the HTTP header is essential for including them. It also allows the inclusion of resources for which it is undesirable or impractical to add individual Inbox relations, such as to elements in a dataset; or circumstances where the developer responsible for the Inbox relation is unable to modify the content. Conversely, non-informational resources (represented with fragment URIs or 303 redirects) are unable to express HTTP headers. Their relation to an Inbox must be expressed in an RDF source. However, if a sender or consumer has a domain-specific requirement to <em>only</em> ever target non-informational resources, they are exempt from the requirement of discovery via HTTP headers.</p>

Acknowledgements

<p>This material is based on work supported by the Qatar Computing Research Institute (QCRI), and by the DFG project “Opening Scholarly Communication in Social Sciences” (grant agreement AU 340/9-1).</p>

• Acknowledgements

Amy Guy

• Person

An announcement of a specific citation relation between two entities (Turtle).

@prefix as: <https://www.w3.org/ns/activitystreams#> . @prefix cito: <http://purl.org/spar/cito/> . <> a as:Announce as:object <https://linkedresearch.org/resources#r-903b83> ; as:target <https://csarven.ca/dokieli#architecture> . <https://linkedresearch.org/resources#r-903b83> cito:citesAsPotentialReading <https://csarven.ca/linked-data-notifications#protocol> .

• Script

Analysis and Evaluation

<p>The LDN protocol describes the discovery of a resource’s Inbox whence notifications are sent or consumed, and the sending and exposure of those notifications. Here we analyse how well features of LDN achieve the <a href='#requirements-and-design-considerations'>requirements</a> identified previously, and compare this to related work.</p> <p>We have already examined <a href='#implementations'>implementations</a> of the specification and described how they interoperate with each other; this can be further tested by running the <a href='https://linkedresearch.org/ldn/tests/'>test suite</a>: https://linkedresearch.org/ldn/tests/. We can use this towards an evaluation of its feasibility and effectiveness at interoperability. Given the relatively early stage in the standardisation process (LDN entered Candidate Recommendation in 2016-11), the fast adoption of the LDN specification, quantity of the implementations, and their diversity is promising and further shows LDN’s feasibility. Furthermore, during the development of the specification issues have been raised or discussed by 28 different people (excluding the authors; 21 outside of the Social Web Working Group, 7 within) and the specification has undergone formal review by internationalisation, accessibility, and security specialists. We also discuss in more depth particular challenges that were raised and resolved as part of this process.</p> <section resource='#comparison-summary' rel='schema:hasPart' inlist='' id='comparison-summary'> <h3 property='schema:name'>Comparison summary</h3> <div property='schema:description' datatype='rdf:HTML'> <p>Here we compare existing notification mechanisms from related work. The criteria includes our <a href='#requirements-and-design-considerations'>requirements and design considerations</a> (<em>Rx</em>) along with additional technical information which helps to capture some design differences (<em>Tx</em>).</p> <table id='comparison-of-notification-mechanisms'> <caption>Comparison of notification mechanisms</caption> <thead> <tr> <th>Mechanism</th> <th>T1</th> <th>T2</th> <th>T3</th> <th>R1</th> <th>R2</th> <th>R3</th> <th>R4-A</th> <th>R4-B</th> <th>R4-C^p</th> <th>R4-C^v</th> <th>R4-C^o</th> <th>R5</th> </tr> </thead> <tfoot> <tr> <td colspan='14'> <dl class='abbr'> <dt>T1</dt><dd>Notification type</dd> <dt>T2</dt><dd>Delivery method</dd> <dt>T3</dt><dd>Dependencies</dd> <dt>R1</dt><dd>Modularity (application classes: S Sender, R Receiver, C Consumer, U Subscriber/User)</dd> <dt>R2</dt><dd>Reusability</dd> <dt>R3</dt><dd>Persistence - required? how?</dd> <dt>R4-A</dt><dd>Target representation</dd> <dt>R4-B</dt><dd>Notification body</dd> <dt>R4-C^p</dt><dd>Payload processing required?</dd> <dt>R4-C^v</dt><dd>Verification - required? how?</dd> <dt>R4-C^o</dt><dd>Requirements for referenced resources?</dd> <dt>R5</dt><dd>Subscription</dd> </dl> <hr></hr> <dl class='abbr'> <dt>–</dt><dd>not applicable, out of scope</dd> <dt>/</dt><dd>not specified, in scope</dd> <dt>X</dt><dd>explicitly disallowed</dd> <dt>app</dt><dd>application specific decision</dd> <dt>!</dt><dd>required (<em>MUST</em>)</dd> <dt>+</dt><dd>recommended (<em>SHOULD</em>)</dd> <dt>O</dt><dd>optional (<em>MAY</em>)</dd> <dt>PuSH</dt><dd>PubSubHubbub</dd> </dl> <hr></hr> <dl class='abbr'> <dt>^h</dt><dd>HTML recommended</dd> <dt>^j</dt><dd>Alternate RDF formats can be negotiated</dd> <dt>^k</dt><dd><code>source</code> and <code>target</code> key–value pairs is required</dd> <dt>^q</dt><dd>Provenance records with <a href='http://www.w3.org/TR/prov-o/'>PROV Ontology</a></dd> <dt>^r</dt><dd>RDF representation recommended</dd> <dt>^ra</dt><dd>SPARQL results transformed to RSS/Atom</dd> <dt>^s</dt><dd><a href='https://www.sitemaps.org/protocol.html'>Sitemaps</a></dd> <dt>^t</dt><dd>Described in an RDF store or dataset</dd> </dl> </td> <!-- Notes for how I removed some ?s: * target representation is - when there’s no discovery step for the sender ie. subscription based * verification required is - when there’s a subscription relationship because we assume the receiver trusts the sender -rhiaro --> </tr> </tfoot> <tbody> <tr> <th>Semantic Pingback</th> <td>Linkback</td> <td>POST</td> <td>RDF</td> <td>S R</td> <td>/</td> <td>/</td> <td>Any^r</td> <td>form urlencoded^k</td> <td>!</td> <td>! parse source</td> <td>Any^r</td> <td>X</td> </tr> <tr> <th>Webmention</th> <td>Linkback</td> <td>POST</td> <td>HTML</td> <td>S R</td> <td>–</td> <td>–</td> <td>Any^h</td> <td>form urlencoded^k</td> <td>!</td> <td>! parse source</td> <td>Any^h</td> <td>X</td> </tr> <tr> <th>Provenance Pingback</th> <td>Linkback</td> <td>POST</td> <td>RDF</td> <td>S R</td> <td>/</td> <td>/</td> <td>/</td> <td>URI list</td> <td>/</td> <td>/</td> <td>RDF^q</td> <td>X</td> </tr> <tr> <th>DSNotify</th> <td>Fat ping</td> <td>POST, PUT</td> <td>XML, PuSH</td> <td>S U</td> <td>/</td> <td>–</td> <td>–</td> <td>XML</td> <td>/</td> <td>–</td> <td>RDF^t</td> <td>!</td> </tr> <tr> <th>sparqlPuSH</th> <td>Fat ping</td> <td>POST</td> <td>XML, SPARQL, PuSH</td> <td>S U</td> <td>–</td> <td>–</td> <td>–</td> <td>XML^ra</td> <td>/</td> <td>–</td> <td>RDF^t</td> <td>!</td> </tr> <tr> <th>ResourceSync</th> <td>Fat ping</td> <td>POST</td> <td>XML, PuSH</td> <td>S U</td> <td>/</td> <td>–</td> <td>–</td> <td>XML^s</td> <td>/</td> <td>–</td> <td>?</td> <td>!</td> </tr> <tr> <th>Linked Data Notifications</th> <td>Fat ping</td> <td>POST</td> <td>JSON-LD</td> <td>S R C</td> <td>!</td> <td>! URI</td> <td>Any</td> <td>JSON-LD^j</td> <td>+ app</td> <td>+ app</td> <td>–</td> <td>O app</td> </tr> </tbody> </table> <p>Given that each application requires to follow the steps listed in <q><a href='#sender-to-receiver'>Sender to receiver interaction</a></q> and <q><a href='#consumer-to-receiver'>Consumer to receiver interactions</a></q> the metrics are dependent on the performance of client and server to do HTTP requests and responses, and their respective payloads.</p> </div> </section> <section resource='#compatibility-with-existing-systems' rel='schema:hasPart' inlist='' id='compatibility-with-existing-systems'> <h3 property='schema:name'>Compatibility with existing systems</h3> <div property='schema:description' datatype='rdf:HTML'> <p>Per <a href='#modularity' rel='dio:fulfillsRequirement' about='#protocol'>R1</a> and <a href='#adaptability' rel='dio:fulfillsRequirement' about='#protocol'>R4</a> we have tried to optimise LDN for use as a module of a larger system. The success of this is demonstrated by implementations which use LDN alongside existing protocols according to their specific needs.</p> <p>The Solid suite of tools, Virtuoso+ODS-Briefcase, and dokieli use <cite><a href='https://www.w3.org/wiki/WebAccessControl'>Web Access Control</a></cite> along with an authentication mechanism to apply fine grained access controls to restrict who can send notifications, or who can retrieve notifications from the Inbox. sloph demonstrates an Inbox as a <cite><a href='http://www.webhooks.org/'>Webhooks</a></cite> callback URL, for requesting notifications from APIs which post JSON-based payloads. <cite><a href='https://www.w3.org/TR/activitypub/'>ActivityPub</a></cite> is a W3C <abbr title='Candidate Recommendation'>CR</abbr> for decentralised social media [<a href='#ref-19' class='ref'>19</a>]. It uses LDN for delivery of notifications with the <a href='https://www.w3.org/ns/activitystreams'>ActivityStreams 2.0</a> (AS2) vocabulary, and specifies additional specialised receiver behaviour; also used by sloph. dokieli uses the <cite><a href='https://www.w3.org/TR/annotation-protocol/'>Web Annotation Protocol</a></cite>, an LDP-based mechanism for creating new content, which acts as a trigger for notifications to be sent to the Inbox of the annotation target. The <cite><a href='http://fcrepo.github.io/fcrepo-specification/'>Fedora API Specification</a></cite> is in the process of being formalised (as an extension of LDP) by the Fedora community. The repository event stream draws upon the LDN specification, allowing LDN consumers and senders to react asynchronously to repository events.</p> <p>Any existing <abbr title='Linked Data Platform'>LDP</abbr> implementation can serve as an LDN receiver. Simply advertising any <code>ldp:Container</code> as the Inbox for a resource is sufficient. We confirmed this with four LDP servers which were developed independently with different code bases, prior to the LDN specification (CarbonLDP, Fedora Commons, Solid Server, Virtuoso).</p> <p>LDN has been integrated into existing domain specific systems: dokieli, Fedora Commons, IndieAnndroid, Linked Edit Rules, sloph, solid-client, Solid Words. Standalone implementations of LDN are also straightforward as a result of this modularity, ie: errol, mayktso, onscreen, pyLDN, RDF-LinkedData-Notifications, solid-inbox, solid-notifications.</p> </div> </section> <section resource='#optimising-implementation' rel='schema:hasPart' inlist='' id='optimising-implementation'> <h3 property='schema:name'>Optimising implementation</h3> <div property='schema:description' datatype='rdf:HTML'> <p rel='dio:generatesIssue' about='#design-intent-best-practices'><span typeof='dio:DesignIssue' resource='#design-intent-best-practices' rel='dio:generatedByIntent' property='schema:description' datatype='rdf:HTML' about='#design-issue-optimising-implementation'>We have considered tradeoffs between the HTTP operations receivers and publishers are <em>required</em> to respond to, and ways in which developers may wish to optimise senders or consumers by reducing outbound requests.<meta resource='dio:Resolved' rel='dio:hasStatus' about='#design-issue-optimising-implementation'></meta></span></p> <p resource='#solution-optimising-implementation-get-head-link' rel='dio:hasMandatedSolution' about='#design-issue-optimising-implementation'> <meta typeof='dio:MandatedSolution' resource='#design-decision' rel='dio:leadsTo'></meta> <span typeof='dio:Argument' resource='#argument-optimising-implementation-get-head-link' property='dio:hasArgument'><span property='schema:description' datatype='rdf:HTML'><code>HEAD</code> requests are low cost, and <code>GET</code> requests may be high cost if the body of the resource is large.</span></span> <span typeof='dio:Justification' resource='#justification-optimising-implementation-get-head-link' property='dio:hasJustification'><span property='schema:description' datatype='rdf:HTML'>Given that an Inbox may be discovered from the HTTP headers of a resource, senders and consumers can optimise by attempting a <code>HEAD</code> request for discovery, and only continuing with a <code>GET</code> request if the <code>HEAD</code> is not successful. On the other hand, senders and consumers may be attempting discovery upon RDF resources which they already intend to parse into their own storage. In this case, there is no need for a <code>HEAD</code> request, as a <code>GET</code> will yield both HTTP <code>Link</code> headers and an RDF body, either of which could include the Inbox triple. This means that resources advertising an Inbox must respond to <code>GET</code> requests (even if only with HTTP headers) and may respond to <code>HEAD</code> requests.</span></span> </p> </div> </section> <section resource='#data-formats' rel='schema:hasPart' inlist='' id='data-formats'> <h3 property='schema:name'>Data Formats and Content Negotiation</h3> <div property='schema:description' datatype='rdf:HTML'> <p rel='dio:generatesIssue' about='#design-intent-linked-data'><span typeof='dio:DesignIssue' resource='#design-intent-linked-data' rel='dio:hasStatus' property='schema:description' datatype='rdf:HTML' about='#design-issue-data-formats'>Handling data irrespective of the particular RDF serialisation permits some flexibility, but can be costly to support. We take into account: (a) application interoperability, (b) maintenance of RDF parsers and serialisation libraries, (c) complexity of their inclusion in applications, (d) run-time efficiency.<meta resource='dio:Resolved' rel='dio:hasStatus' about='#design-issue-data-formats'></meta></span></p> <p resource='#solution-data-formats-json-ld' rel='dio:hasMandatedSolution' about='#design-issue-data-formats'> <meta typeof='dio:MandatedSolution' resource='#design-decision' rel='dio:leadsTo'></meta> <span typeof='dio:Argument' resource='#argument-data-formats-json-ld' property='dio:hasArgument'><span property='schema:description' datatype='rdf:HTML'>To address these issues, LDN requires all applications to create and understand the JSON-LD syntax, both for the contents of Inbox as well as for individual notifications. Choosing a single serialisation to <em>require</em> is necessary for consistent interoperability, as well as keeping processing requirements or external code dependencies minimal.</span></span> <span typeof='dio:Justification' resource='#justification-data-formats-json-ld' property='dio:hasJustification'><span property='schema:description' datatype='rdf:HTML'>JSON-LD is advantageous in being familiar for developers who are <cite><a href='http://manu.sporny.org/2014/json-ld-origins-2/' typeof='dio:Evidence' rel='dio:hasEvidence'>used to JSON-based APIs but not RDF</a></cite> [<a href='#ref-20' class='ref'>20</a>], and it is compatible with existing JSON libraries or in some cases native programming language data structures.</span></span> </p> <p resource='#solution-data-formats-content-negotiation' rel='dio:hasAlternativeSolution' about='#design-issue-data-formats'>Optionally, <span typeof='dio:Argument' resource='#argument-data-formats-content-negotiation' property='dio:hasArgument'><span property='schema:description' datatype='rdf:HTML'>applications may attempt to exchange different RDF serialisations by performing content negotiation</span></span> (<span typeof='dio:Justification' resource='#justification-data-formats-content-negotiation' property='dio:hasJustification'><span property='schema:description' datatype='rdf:HTML'>receivers can expose <code>Accept-Post</code> headers for senders, and consumers can send <code>Accept</code> headers to receivers</span></span>).</p> </div> </section> <section resource='#precision' rel='schema:hasPart' inlist='' id='precision'> <h3 property='schema:name'>Precision</h3> <div property='schema:description' datatype='rdf:HTML'> <p>In placing no constraints on the contained information, LDN enables a sender to be precise and lossless with the data it is transmitting. Approaches which send only URLs rely on the receiver interpreting a third-party resource, which may or may not contain structured markup or be under the control of the sender. Approaches which offer additional guidance to aid the receiver in interpreting the source document(s) nonetheless still restricts the sender. LDN therefore offers flexibility to senders, increasing the potential uses for the notification mechanism. LDN compensates for increased complexity on the receiver’s end by recommending filtering mechanisms, and moving some of the burden of understanding notifications to the consumer role. As such LDN can cover a broader variety of use cases.</p> </div> </section> <section resource='#accommodating-different-targets' rel='schema:hasPart' inlist='' id='accommodating-different-targets'> <h3 property='schema:name'>Accommodating different targets</h3> <div property='schema:description' datatype='rdf:HTML'> <p>Per <em>R4 Adaptability</em>, we want LDN to be available for all resources in any publishing context. We consider lowering the bar for publishers of target resources to be a worthwhile trade-off against slightly increased complexity for senders and consumers. This is why we require that senders and consumers must be equipped to discover Inboxes through both HTTP headers and RDF content. </p> <p>Since binary formats such as images and video cannot contain an RDF relation, the HTTP header is essential for including them. It also allows the inclusion of resources for which it is undesirable or impractical to add individual Inbox relations, such as to elements in a dataset; or circumstances where the developer responsible for the Inbox relation is unable to modify the content. Conversely, non-informational resources (represented with fragment URIs or 303 redirects) are unable to express HTTP headers. Their relation to an Inbox must be expressed in an RDF source. However, if a sender or consumer has a domain-specific requirement to <em>only</em> ever target non-informational resources, they are exempt from the requirement of discovery via HTTP headers.</p> </div> </section>

• Evaluation

Andrei Sambra

• Person

Anonymous Reviewer

• Person

Anonymous Reviewer

• Person

Anonymous Reviewer

• Person

Anonymous Reviewer

• Person

Anonymous Reviewer replied on 2017-01-27 11:35:59

<div typeof='oa:TextualBody' resource='#note-20170127113559' property='rdf:value' datatype='rdf:HTML'> <p>The article presents the Linked Data Notifications (LDN) protocol, a candidate W3C recommendation, and how it relates to similar notification protocols. Starting with requirements based on Linked Data design principles and the need for re-decentralisation of the Web the article makes a structured comparison of notification mechanisms today and discusses the various implementations of LDN.</p> <p>This is an architecture type of article in which the requirements and design considerations (section 3) are the base on which the rest of the contribution is built; naturally, some of those requirements are based on opinion but this is exactly the kind of topic to present at ESWC to foster fruitful discussion. For example, the requirement for reusability could be seen as a potential risk for privacy; what is the benefit of reusable notifications to balance that risk? Who would benefit the most from this principle (users, application developers, other) and in what way? A similar discussion could be made for R3 (persistence and retrievability).</p> <p>It would help if those requirements were discussed a little more in the paper and if they could be placed more clearly in the wider framework/paradigm of Web re-decentralisation (including stakeholders) to give a sense of ‘completeness’ when it comes to notification protocols.</p> <p>One final point is that certain references (e.g. [3] do not seem to be cited in the text).</p> </div>

• Annotation
• Note

Anonymous Reviewer replied on 2017-01-27 11:37:48

<div typeof='oa:TextualBody' resource='#note-20170127113748' property='rdf:value' datatype='rdf:HTML'> <p>LDNs provide an important mechanism for the current effort (as described in the paper) to re-decentralise the web. The paper is well written. It describes the motivation for LDNs, gives examples and compares LDNs to related efforts.</p> <p>I have only minor comments:</p> <ol> <li>one may add in section 2 "related work" a mention of <a href='https://tools.ietf.org/html/draft-snell-atompub-notification-01'>atomPub</a> , and add this also to table 2 "comparison of notification mechanisms"</li> <li>for the standardisation process of LDNs this may not be crucial, but one may want to examine benchmarks for notification processing. This could help to evaluate different LDNs applications in terms of their performance. This criterion may become critical during broad adoption, with billions of notifications generated every day.</li> </ol> </div>

• Annotation
• Note

Anonymous Reviewer replied on 2017-01-27 11:41:05

<div typeof='oa:TextualBody' resource='#note-20170127114105' property='rdf:value' datatype='rdf:HTML'> <p>This paper presents a communication protocol for Linked Data Notifications, reusable messages on the Web that follow the Linked Data principles.</p> <p>The paper is generally well written and easy to follow. The authors motivate their work well and provide a detailed description of the protocol and its implementations.</p> <h4>Strong points</h4> <ul> <li>The requirements for the protocol are well established.</li> <li>The protocol itself is well formalised and described.</li> <li>Existence of a number of implementations, both standalone ones and the ones developed previously to the LDN.</li> <li>Protocol flexibility and the compatibility with the Linked Data Platform.</li> <li>The work is quite relevant.</li> </ul> <h4>Weak points</h4> <p>The lack of a real evaluation. Section 6, although titled "Analysis and Evaluation", is actually a comprehensive analysis and discussion of various aspects of the presented work. Section 6.1 is the closest to the evaluation of the work, however the level of details in this section is not satisfactory in that regard. The authors could maybe extend this section with an in depth analysis of the differences between their work and other system that are mentioned, and a discussion on why these differences are important and how LDN provides improvements over them.</p> <h4>Other comments</h4> <p>In the abstract, the authors state: "This permits end users more freedom to switch between the online tools they use, as well as generating greater value when notifications from different sources can be used in combination." Maybe it would be interesting if the authors could mention a few use cases of this added value in a separate section as a strong point for the motivation of the work.</p> <p>In my opinion, the definition of notification is quite broad and not very clear ("A notification is a retrievable resource which returns RDF"). Is my URI a notification? A URI of an ontology class?</p> <p>Further explanation perhaps clarifies a bit, but the whole context should be clear in the first sentence.</p> <p>The interaction steps between consumer and receiver (Section 4.2) might be a bit confusing to the reader. Does step (3) always follow step (2), e.g., the consumer first asks for the listing of notifications and then choses one to retrieve, or it is possible to have only one of the two steps before step (4), e.g., the consumer decides whether it is interested in the listing, or individual notification, or perhaps both.</p> <p>Also, in my opinion comparing to Section 4.1, the steps in Section 4.2 are described with less detail and rigour.</p> <p>In Section 5 the authors state: "We note that any LDP implementation is a conforming LDN receiver; we refer here to the ones we have tested". Maybe the authors could mention the reasons why other LDP implementations are not tested, or how they have chosen the implementations that are tested.</p> <p>The figures in Section 5 are not very readable in the printed version. I understand that the online version of the article reads better, but the authors should maybe consider improving the representations in printed form.</p> <p>The conclusions section presents only a summary of the paper. But what are the conclusions? Are there any limitations of the presented work and if so which ones? Is there any future work planned?</p> <p>Not all figures and tables are referenced in the text, I would suggest the authors to include these references.</p> <p>Reference [3] is not referenced in the text.</p> <p>In my opinion, the references section could be improved. For example, conference and workshop abbreviations could be extended, exact workshops mentioned (e.g., in [9]). Furthermore, links are omitted in the printed version of the paper which makes the section strange and it is not clear what is the type of the work that is referenced (e.g., conference, technical report, web article, technical specification)</p> </div>

• Annotation
• Note

Anonymous Reviewer replied on 2017-01-27 11:43:21

<div typeof='oa:TextualBody' resource='#note-20170127114321' property='rdf:value' datatype='rdf:HTML'> <p>The paper is well written and mostly understandable, though it might be a good idea to rephrase some of the explanation in the section on Requirements and Design Considerations, specifically R4-B, which is confusing and not easy to understand. </p> <p>I would also like more clarity on the following:</p> <ol> <li>Performance metrics to measure how well the protocol performs in practice.</li> <li>The most interesting part of the protocol is the (re)use of the received notification by the consumers. The paper should include explicit justification with concrete examples on why an application (consumer) would want to use an outdated notification exposed by some receiver. Most obvious examples are blog posts etc, but that seems to be the only obvious use case. It is also worth thinking about how a service like stack overflow can be re-purposed using LDN and what would be the benefits.</li> </ol> <p>It is also easy to see why a formal semantics for the protocol would make sense. Apart from getting implementations to conform to a test suite, it is worth getting them to conform to a formal semantics specification. This is something that the authors should make a part of their future work.</p> <p>I also see the evaluation as being quite limited, as there is no user-driven evaluation result that have been reported. While it is still early days for the protocol, without a clear idea of what it means for the consumers and how much it contributes to improving the overall data integration for a specific use-case or domain, it is hard to see the utility of implementing this as part of a larger system.</p> </div>

• Annotation
• Note

argument-data-formats-content-negotiation

applications may attempt to exchange different RDF serialisations by performing content negotiation

• Argument

argument-data-formats-json-ld

To address these issues, LDN requires all applications to create and understand the JSON-LD syntax, both for the contents of Inbox as well as for individual notifications. Choosing a single serialisation to <em>require</em> is necessary for consistent interoperability, as well as keeping processing requirements or external code dependencies minimal.

• Argument

argument-optimising-implementation-get-head-link

<code>HEAD</code> requests are low cost, and <code>GET</code> requests may be high cost if the body of the resource is large.

• Argument

Christoph Lange

• Person

Comparison summary

<p>Here we compare existing notification mechanisms from related work. The criteria includes our <a href='#requirements-and-design-considerations'>requirements and design considerations</a> (<em>Rx</em>) along with additional technical information which helps to capture some design differences (<em>Tx</em>).</p> <table id='comparison-of-notification-mechanisms'> <caption>Comparison of notification mechanisms</caption> <thead> <tr> <th>Mechanism</th> <th>T1</th> <th>T2</th> <th>T3</th> <th>R1</th> <th>R2</th> <th>R3</th> <th>R4-A</th> <th>R4-B</th> <th>R4-C^p</th> <th>R4-C^v</th> <th>R4-C^o</th> <th>R5</th> </tr> </thead> <tfoot> <tr> <td colspan='14'> <dl class='abbr'> <dt>T1</dt><dd>Notification type</dd> <dt>T2</dt><dd>Delivery method</dd> <dt>T3</dt><dd>Dependencies</dd> <dt>R1</dt><dd>Modularity (application classes: S Sender, R Receiver, C Consumer, U Subscriber/User)</dd> <dt>R2</dt><dd>Reusability</dd> <dt>R3</dt><dd>Persistence - required? how?</dd> <dt>R4-A</dt><dd>Target representation</dd> <dt>R4-B</dt><dd>Notification body</dd> <dt>R4-C^p</dt><dd>Payload processing required?</dd> <dt>R4-C^v</dt><dd>Verification - required? how?</dd> <dt>R4-C^o</dt><dd>Requirements for referenced resources?</dd> <dt>R5</dt><dd>Subscription</dd> </dl> <hr></hr> <dl class='abbr'> <dt>–</dt><dd>not applicable, out of scope</dd> <dt>/</dt><dd>not specified, in scope</dd> <dt>X</dt><dd>explicitly disallowed</dd> <dt>app</dt><dd>application specific decision</dd> <dt>!</dt><dd>required (<em>MUST</em>)</dd> <dt>+</dt><dd>recommended (<em>SHOULD</em>)</dd> <dt>O</dt><dd>optional (<em>MAY</em>)</dd> <dt>PuSH</dt><dd>PubSubHubbub</dd> </dl> <hr></hr> <dl class='abbr'> <dt>^h</dt><dd>HTML recommended</dd> <dt>^j</dt><dd>Alternate RDF formats can be negotiated</dd> <dt>^k</dt><dd><code>source</code> and <code>target</code> key–value pairs is required</dd> <dt>^q</dt><dd>Provenance records with <a href='http://www.w3.org/TR/prov-o/'>PROV Ontology</a></dd> <dt>^r</dt><dd>RDF representation recommended</dd> <dt>^ra</dt><dd>SPARQL results transformed to RSS/Atom</dd> <dt>^s</dt><dd><a href='https://www.sitemaps.org/protocol.html'>Sitemaps</a></dd> <dt>^t</dt><dd>Described in an RDF store or dataset</dd> </dl> </td> <!-- Notes for how I removed some ?s: * target representation is - when there’s no discovery step for the sender ie. subscription based * verification required is - when there’s a subscription relationship because we assume the receiver trusts the sender -rhiaro --> </tr> </tfoot> <tbody> <tr> <th>Semantic Pingback</th> <td>Linkback</td> <td>POST</td> <td>RDF</td> <td>S R</td> <td>/</td> <td>/</td> <td>Any^r</td> <td>form urlencoded^k</td> <td>!</td> <td>! parse source</td> <td>Any^r</td> <td>X</td> </tr> <tr> <th>Webmention</th> <td>Linkback</td> <td>POST</td> <td>HTML</td> <td>S R</td> <td>–</td> <td>–</td> <td>Any^h</td> <td>form urlencoded^k</td> <td>!</td> <td>! parse source</td> <td>Any^h</td> <td>X</td> </tr> <tr> <th>Provenance Pingback</th> <td>Linkback</td> <td>POST</td> <td>RDF</td> <td>S R</td> <td>/</td> <td>/</td> <td>/</td> <td>URI list</td> <td>/</td> <td>/</td> <td>RDF^q</td> <td>X</td> </tr> <tr> <th>DSNotify</th> <td>Fat ping</td> <td>POST, PUT</td> <td>XML, PuSH</td> <td>S U</td> <td>/</td> <td>–</td> <td>–</td> <td>XML</td> <td>/</td> <td>–</td> <td>RDF^t</td> <td>!</td> </tr> <tr> <th>sparqlPuSH</th> <td>Fat ping</td> <td>POST</td> <td>XML, SPARQL, PuSH</td> <td>S U</td> <td>–</td> <td>–</td> <td>–</td> <td>XML^ra</td> <td>/</td> <td>–</td> <td>RDF^t</td> <td>!</td> </tr> <tr> <th>ResourceSync</th> <td>Fat ping</td> <td>POST</td> <td>XML, PuSH</td> <td>S U</td> <td>/</td> <td>–</td> <td>–</td> <td>XML^s</td> <td>/</td> <td>–</td> <td>?</td> <td>!</td> </tr> <tr> <th>Linked Data Notifications</th> <td>Fat ping</td> <td>POST</td> <td>JSON-LD</td> <td>S R C</td> <td>!</td> <td>! URI</td> <td>Any</td> <td>JSON-LD^j</td> <td>+ app</td> <td>+ app</td> <td>–</td> <td>O app</td> </tr> </tbody> </table> <p>Given that each application requires to follow the steps listed in <q><a href='#sender-to-receiver'>Sender to receiver interaction</a></q> and <q><a href='#consumer-to-receiver'>Consumer to receiver interactions</a></q> the metrics are dependent on the performance of client and server to do HTTP requests and responses, and their respective payloads.</p>

Compatibility with existing systems

<p>Per <a href='#modularity' rel='dio:fulfillsRequirement' about='#protocol'>R1</a> and <a href='#adaptability' rel='dio:fulfillsRequirement' about='#protocol'>R4</a> we have tried to optimise LDN for use as a module of a larger system. The success of this is demonstrated by implementations which use LDN alongside existing protocols according to their specific needs.</p> <p>The Solid suite of tools, Virtuoso+ODS-Briefcase, and dokieli use <cite><a href='https://www.w3.org/wiki/WebAccessControl'>Web Access Control</a></cite> along with an authentication mechanism to apply fine grained access controls to restrict who can send notifications, or who can retrieve notifications from the Inbox. sloph demonstrates an Inbox as a <cite><a href='http://www.webhooks.org/'>Webhooks</a></cite> callback URL, for requesting notifications from APIs which post JSON-based payloads. <cite><a href='https://www.w3.org/TR/activitypub/'>ActivityPub</a></cite> is a W3C <abbr title='Candidate Recommendation'>CR</abbr> for decentralised social media [<a href='#ref-19' class='ref'>19</a>]. It uses LDN for delivery of notifications with the <a href='https://www.w3.org/ns/activitystreams'>ActivityStreams 2.0</a> (AS2) vocabulary, and specifies additional specialised receiver behaviour; also used by sloph. dokieli uses the <cite><a href='https://www.w3.org/TR/annotation-protocol/'>Web Annotation Protocol</a></cite>, an LDP-based mechanism for creating new content, which acts as a trigger for notifications to be sent to the Inbox of the annotation target. The <cite><a href='http://fcrepo.github.io/fcrepo-specification/'>Fedora API Specification</a></cite> is in the process of being formalised (as an extension of LDP) by the Fedora community. The repository event stream draws upon the LDN specification, allowing LDN consumers and senders to react asynchronously to repository events.</p> <p>Any existing <abbr title='Linked Data Platform'>LDP</abbr> implementation can serve as an LDN receiver. Simply advertising any <code>ldp:Container</code> as the Inbox for a resource is sufficient. We confirmed this with four LDP servers which were developed independently with different code bases, prior to the LDN specification (CarbonLDP, Fedora Commons, Solid Server, Virtuoso).</p> <p>LDN has been integrated into existing domain specific systems: dokieli, Fedora Commons, IndieAnndroid, Linked Edit Rules, sloph, solid-client, Solid Words. Standalone implementations of LDN are also straightforward as a result of this modularity, ie: errol, mayktso, onscreen, pyLDN, RDF-LinkedData-Notifications, solid-inbox, solid-notifications.</p>

concept-scheme

• Concept Scheme

Conclusions

<p>In this article we describe LDN, a protocol for decentralised semantic notifications, currently undergoing standardisation at the W3C. Key elements are:</p> <ul> <li>Notifications as retrievable, reusable entities with their own URIs.</li> <li>Distinct conformance classes for senders, receivers, and consumers.</li> <li>Deliberately not defining the vocabulary of notification contents to allow for use in a range of different application domains.</li> <li>Flexibility of authentication and verification, for the same reason.</li> </ul> <p>We outlined design requirements, describe how LDN meets these, and compare this with related work. We consider LDN to have greater modularity and adaptability to different scenarios, as well as good conformance with Linked Data principles. This specification has potential to have high impact in increasing interoperability between decentralised Linked Data applications in related domains, as well as generating new discoverable content for the LOD Cloud. This is evidenced by 17 diverse implementations which can be shown to interoperate with each other, including generic libraries and datastores, and domain-specific applications. Being on the W3C standards track increases the likelihood of further adoption.</p> <!-- Future work? --> <!-- <p>We have yet to assess the implications of applications modifying data that another application also makes use of. This would be a useful study for decentralisation in general.</p> -->

• Conclusion

Consumer to receiver interactions

<p>The following steps (in order without skipping) describe the interaction between consumer and receiver:</p> <p>(1) A consumer selects a target and discovers the location of its Inbox in the same way as the sender; (2) A receiver responds to <code>GET</code> requests made to the Inbox URL with a listing of the URLs of notifications that have previously been accepted, linked to the Inbox with the <code>ldp:contains</code> predicate; <span resource='#persistence-and-retrievability' rel='dio:fulfillsRequirement' about='#protocol'>(3) The receiver responds to <code>GET</code> requests made to the individual notification URLs with JSON-LD (or optionally other serialisations);</span> <span resource='#reusable-notifications' rel='dio:fulfillsRequirement' about='#protocol'>(4) Following the retrieval of notification listings or individual notifications, the consumer may perform further processing, combine with some other data, or simply present the results in a suitable human-readable way.</span></p>

Data Formats and Content Negotiation

<p rel='dio:generatesIssue' about='#design-intent-linked-data'><span typeof='dio:DesignIssue' resource='#design-intent-linked-data' rel='dio:hasStatus' property='schema:description' datatype='rdf:HTML' about='#design-issue-data-formats'>Handling data irrespective of the particular RDF serialisation permits some flexibility, but can be costly to support. We take into account: (a) application interoperability, (b) maintenance of RDF parsers and serialisation libraries, (c) complexity of their inclusion in applications, (d) run-time efficiency.<meta resource='dio:Resolved' rel='dio:hasStatus' about='#design-issue-data-formats'></meta></span></p> <p resource='#solution-data-formats-json-ld' rel='dio:hasMandatedSolution' about='#design-issue-data-formats'> <meta typeof='dio:MandatedSolution' resource='#design-decision' rel='dio:leadsTo'></meta> <span typeof='dio:Argument' resource='#argument-data-formats-json-ld' property='dio:hasArgument'><span property='schema:description' datatype='rdf:HTML'>To address these issues, LDN requires all applications to create and understand the JSON-LD syntax, both for the contents of Inbox as well as for individual notifications. Choosing a single serialisation to <em>require</em> is necessary for consistent interoperability, as well as keeping processing requirements or external code dependencies minimal.</span></span> <span typeof='dio:Justification' resource='#justification-data-formats-json-ld' property='dio:hasJustification'><span property='schema:description' datatype='rdf:HTML'>JSON-LD is advantageous in being familiar for developers who are <cite><a href='http://manu.sporny.org/2014/json-ld-origins-2/' typeof='dio:Evidence' rel='dio:hasEvidence'>used to JSON-based APIs but not RDF</a></cite> [<a href='#ref-20' class='ref'>20</a>], and it is compatible with existing JSON libraries or in some cases native programming language data structures.</span></span> </p> <p resource='#solution-data-formats-content-negotiation' rel='dio:hasAlternativeSolution' about='#design-issue-data-formats'>Optionally, <span typeof='dio:Argument' resource='#argument-data-formats-content-negotiation' property='dio:hasArgument'><span property='schema:description' datatype='rdf:HTML'>applications may attempt to exchange different RDF serialisations by performing content negotiation</span></span> (<span typeof='dio:Justification' resource='#justification-data-formats-content-negotiation' property='dio:hasJustification'><span property='schema:description' datatype='rdf:HTML'>receivers can expose <code>Accept-Post</code> headers for senders, and consumers can send <code>Accept</code> headers to receivers</span></span>).</p>

decentralisation

• Concept

design-decision

We build on existing W3C standards and Linked Data principles. In particular, the storage of notifications is compatible with the <cite>Linked Data Platform</cite> standard; notifications are identified by HTTP URIs; and notification contents are available as JSON-LD. A key architectural decision is the separation of concerns between <em>senders</em>, <em>receivers</em>, and <em>consumers</em> of notifications. Implementations of the protocol can play one or more of these roles, and interoperate successfully with implementations playing the complementary roles. This means that notifications generated by one application can be reused by a completely different application, accessed via the store where the notification data resides, through shared Linked Data vocabularies. LDN also pushes the decentralised approach further by allowing any <em>target</em> resource to advertise its Inbox anywhere on the Web; that is, targets do not need to be coupled to or controlled by a receiver, and can make use of a third-party <em>Inbox as a service</em>.

• DesignDecision
• MandatedSolution

design-intent

We argue that notification data should not be locked into particular systems. We designed the <em>Linked Data Notifications (LDN)</em> protocol to support sharing and reuse of notifications <em>across</em> applications, regardless of how they were generated or what their contents are. We describe how the principles of identification, addressability and semantic representation can be applied to notifications on the Web. Specifying LDN as a formal protocol allows independently implemented, heterogeneous applications which generate and use notifications, to seamlessly work together. Thus, LDN supports the decentralisation of the Web as well as encourages the generation and consumption of Linked Data.

• DesignIntent

design-intent-best-practices

best practices for applications

• DesignIntent

design-intent-linked-data

Web notification protocol that conforms to the Linked Data design principles

• DesignIntent

design-issue

In a decentralised architecture, notifications can be a key element for federation of information, and application integration. However in <span typeof='dio:Active' resource='#design-issue-status' rel='dio:hasStatus'>centralised systems which prevail today</span>, this data is structured arbitrarily and typically only usable by the application that generated it in the first place. Current efforts towards <em>re-decentralising</em> the Web [<a href='#ref-1' class='ref'>1</a>, <a href='#ref-2' class='ref'>2</a>, <a href='#ref-3' class='ref'>3</a>] are moving towards architectures in which data storage is decoupled from application logic, freeing end users to switch between applications, or to let multiple applications operate over the same data. So far, notifications are considered to be <em>ephemeral</em> resources which may disappear after transport, and thus are excluded from being designed for reuse.

• DesignIssue

design-issue-data-formats

Handling data irrespective of the particular RDF serialisation permits some flexibility, but can be costly to support. We take into account: (a) application interoperability, (b) maintenance of RDF parsers and serialisation libraries, (c) complexity of their inclusion in applications, (d) run-time efficiency.<meta resource='dio:Resolved' rel='dio:hasStatus' about='#design-issue-data-formats'></meta>

• DesignIssue

design-issue-optimising-implementation

We have considered tradeoffs between the HTTP operations receivers and publishers are <em>required</em> to respond to, and ways in which developers may wish to optimise senders or consumers by reducing outbound requests.<meta resource='dio:Resolved' rel='dio:hasStatus' about='#design-issue-optimising-implementation'></meta>

• DesignIssue

design-issue-status

• Active

Example Notifications

<p>For more example notification payloads, see the <a href='https://www.w3.org/TR/ldn/'>LDN specification</a>.</p> <figure resource='#sending-notification-request' rel='schema:hasPart' inlist='' id='sending-notification-request' class='listing'> <pre typeof='fabio:Script' property='schema:description' about='#sending-notification-request'><code>{</code><code> "@context": { "sioc": "http://rdfs.org/sioc/ns#" }</code><code> "@id": "",</code><code> "@type": "sioc:Comment",</code><code> "sioc:content": "This is a great article!",</code><code> "as:inReplyTo": { "@id": "http://example.org/article" },</code><code> "sioc:created_at": { "@value": "2015-12-23T16:44:21Z" }</code><code>}</code></pre> <figcaption property='schema:name'>A notification about a comment created by a user (JSON-LD).</figcaption> </figure> <figure resource='#notification-qualified-relation' rel='schema:hasPart' inlist='' id='notification-qualified-relation' class='listing'> <pre typeof='fabio:Script' property='schema:description' about='#notification-qualified-relation'><code>@prefix as: &lt;https://www.w3.org/ns/activitystreams#&gt; .</code><code>@prefix cito: &lt;http://purl.org/spar/cito/&gt; .</code><code>&lt;&gt; a as:Announce</code><code> as:object &lt;https://linkedresearch.org/resources#r-903b83&gt; ;</code><code> as:target &lt;https://csarven.ca/dokieli#architecture&gt; .</code><code>&lt;https://linkedresearch.org/resources#r-903b83&gt;</code><code> cito:citesAsPotentialReading</code><code> &lt;https://csarven.ca/linked-data-notifications#protocol&gt; .</code></pre> <figcaption property='schema:name'>An announcement of a specific citation relation between two entities (Turtle).</figcaption> </figure>

Graph view of the Linked Data Notifications article generated using Gruff.

http://manu.sporny.org/2014/json-ld-origins-2/

• Evidence

Implementations

<p>Here we summarise the 17 LDN implementations we are aware of to date. They are built by 10 different teams or individuals using different tool stacks (5 clientside JavaScript, 3 PHP, 3 NodeJS, 3 Python, 1 Perl, 1 Virtuoso Server Pages, 1 Java) and have submitted <a href='https://github.com/w3c/ldn/tree/master/implementations'>implementation reports</a> as part of the W3C standardisation process. We note that any <a href='https://www.w3.org/wiki/LDP_Implementations'>LDP implementation</a> is a conforming LDN receiver; we refer here to the ones we have tested. We discuss the value of these implementations further in the <a href='#analysis-and-evaluation'>Evaluation</a> section.</p> <table id='ldn-implementations'> <caption>LDN Implementations</caption> <thead> <tr> <th>Implementation</th> <th>Class^{<a href='#implementations-key'>*</a>}</th> <th>Description</th> </tr> </thead> <tfoot><tr> <td colspan='3'> <dl class='abbr'> <dt><sup id='implementations-key'>*</sup></dt><dd>Conformance classes: S – sender, C – consumer, R – receiver.</dd> <dt><sup id='author-implementations'>a</sup></dt><dd>Implementations by the authors</dd> </dl> <p>Source: <a href='https://github.com/w3c/ldn/tree/master/implementations'>https://github.com/w3c/ldn/tree/master/implementations</a></p> </td> </tr></tfoot> <tbody> <tr> <th><a href='https://carbonldp.com'>CarbonLDP</a></th> <td>R</td> <td>Data storage platform (LDP)</td> </tr> <tr> <th><a href='https://dokie.li/'>dokieli</a>^a</th> <td>S,C</td> <td>Clientside editor and annotator</td> </tr> <tr> <th><a href='https://github.com/linkeddata/errol'>errol</a>^a</th> <td>S</td> <td>Generic message sending client</td> </tr> <tr> <th><a href='http://fedora-commons.org/'>Fedora Commons</a></th> <td>R</td> <td>Open source repository platform (LDP)</td> </tr> <tr> <th><a href='https://github.com/Kongaloosh/IndieAnndroid'>IndieAnndroid</a></th> <td>R</td> <td>Personal blogging platform</td> </tr> <tr> <th><a href='https://github.com/albertmeronyo/linked-edit-rules'>Linked Edit Rules</a></th> <td>S</td> <td>Statistical dataset consistency checker</td> </tr> <tr> <th><a href='https://github.com/csarven/mayktso'>mayktso</a>^a</th> <td>R</td> <td>Personal data store (LDP)</td> </tr> <tr> <th><a href='https://github.com/rhiaro/onscreen'>OnScreen</a>^a</th> <td>C</td> <td>Notifications display client</td> </tr> <tr> <th><a href='https://github.com/albertmeronyo/pyldn'>pyldn</a></th> <td>R</td> <td>Standalone Inbox</td> </tr> <tr> <th><a href='https://github.com/kjetilk/p5-rdf-linkeddata-notifications'>RDF-LinkedData-Notifications</a></th> <td>R</td> <td>Standalone Inbox</td> </tr> <tr> <th><a href='https://github.com/rhiaro/sloph'>sloph</a>^a</th> <td>S,R</td> <td>Social publishing &amp; quantified self</td> </tr> <tr> <th><a href='https://github.com/melvincarvalho/vocab'>Solid Words</a></th> <td>S</td> <td>Foreign language learning app</td> </tr> <tr> <th><a href='https://github.com/solid/solid-client'>solid-client</a></th> <td>S</td> <td>Clientside library for LDP</td> </tr> <tr> <th><a href='https://github.com/solid/solid-inbox'>solid-inbox</a></th> <td>C</td> <td>Clientside social message reader</td> </tr> <tr> <th><a href='https://github.com/solid/solid-notifications'>solid-notifications</a></th> <td>S,C</td> <td>Clientside library for LDN</td> </tr> <tr> <th><a href='https://github.com/solid/node-solid-server'>solid-server</a></th> <td>R</td> <td>Personal data storage server (LDP)</td> </tr> <tr> <th><a href='https://github.com/openlink/virtuoso-opensource'>Virtuoso</a>+<a href='http://ods.openlinksw.com/wiki/ODS/OdsBriefcase'>ODS Briefcase</a></th> <td>R,C</td> <td>Personal data storage server (LDP)</td> </tr> </tbody> </table> <p>We highlight social scholarly communication use cases with <cite><a href='https://dokie.li/'>dokieli</a></cite>, a clientside editor for decentralised scientific article publishing, annotations and social interactions [<a href='#ref-17' class='ref'>17</a>]. dokieli uses LDN to send and consume notifications: When a reader comments on a fragment of text in an article, the application discovers the article’s Inbox and sends a notification about the annotation. dokieli also consumes notifications from this Inbox to fetch and display the annotation as marginalia (<a href='#figure-dokieli-annotation'>figure 2</a>). A reader can share a dokieli-enabled article with their contacts; dokieli discovers each contact’s Inbox and sends a notification there (<a href='#figure-dokieli-share'>figure 3</a>). When editing an article, the author can add a citation. If an Inbox is discovered in the cited article, dokieli sends a notification there to indicate what part of the article was cited by whom and where. dokieli-enabled articles also consume citation notifications to display these metrics for the author and other readers (<a href='#figure-dokieli-citation'>figure 4</a>).</p> <figure resource='#figure-dokieli-annotation' rel='schema:hasPart' inlist='' id='figure-dokieli-annotation'> <video poster='https://dokie.li/media/images/dokieli-annotation.jpg' width='800' controls='controls' preload='none' rel='schema:hasPart' inlist='' id='video-dokieli-annotation'> <source type='video/webm' src='https://dokie.li/media/video/dokieli-annotation.webm' typeof='fabio:Film' resource='https://dokie.li/media/video/dokieli-annotation.webm' rel='schema:hasPart' about='#video-dokieli-annotation'></source> </video> <figcaption property='schema:name'><a href='https://dokie.li/media/video/dokieli-annotation.webm'>Video</a> of dokieli Web Annotation</figcaption> </figure> <figure resource='#figure-dokieli-share' rel='schema:hasPart' inlist='' id='figure-dokieli-share'> <video poster='https://dokie.li/media/images/dokieli-share.jpg' width='800' controls='controls' preload='none' rel='schema:hasPart' id='video-dokieli-share'> <source type='video/webm' src='https://dokie.li/media/video/dokieli-share.webm' typeof='fabio:Film' resource='https://dokie.li/media/video/dokieli-share.webm' rel='schema:hasPart' about='#video-dokieli-share'></source> </video> <figcaption property='schema:name'><a href='https://dokie.li/media/video/dokieli-share.webm'>Video</a> of dokieli Share</figcaption> </figure> <figure resource='#figure-dokieli-citation' rel='schema:hasPart' inlist='' id='figure-dokieli-citation'> <video rel='schema:hasPart' about='' width='800' preload='none' poster='https://dokie.li/media/images/dokieli-citation.jpg' id='video-dokieli-citation' controls='controls'> <source typeof='fabio:Film' type='video/webm' src='https://dokie.li/media/video/dokieli-citation.webm' resource='https://dokie.li/media/video/dokieli-citation.webm' rel='schema:hasPart' about='#video-dokieli-citation'></source> </video> <figcaption property='schema:name'><a href='https://dokie.li/media/video/dokieli-citation.webm'>Video</a> of semantic inline citations</figcaption> </figure> <p>Notifications sent by dokieli can be reused by any consuming applications that recognise the vocabulary terms; similarly, dokieli can consume notifications sent by different applications.</p> <p>Further social use cases are demonstrated by <cite><a href='https://rhiaro.co.uk/sloph'>sloph</a></cite>, a personal publishing and quantified self platform which acts as a node in a decentralised social network. When new content is created on the server, sloph performs discovery on URLs it finds as values of particular properties of the new content, as well as any URLs in the body of the content, and sends notifications accordingly. For instance:</p> <ul> <li>If a <em>Like</em> activity is generated on the server, sloph uses the <code>object</code> of the <em>Like</em> as the target for a notification. Since dokieli uses the same vocabulary for social interactions (<cite><a href='https://www.w3.org/ns/activitystreams-core'>ActivityStreams 2.0</a></cite> [<a href='#ref-18' class='ref'>18</a>]), if the target is a dokieli article, this <em>Like</em> will be displayed (<a href='#figure-sloph-dokieli'>figure 5</a>).</li> <li>If the user publishes a blog post containing a link, which may be semantically annotated to indicate the reason for linking, sloph sends a notification to any Inbox discovered at that link.</li> <li>As a receiver, sloph accepts all incoming notifications, but holds for moderation (i.e. places behind access control) any that it cannot automatically verify refer to third-party content published on another domain. If an article written with dokieli publishes a citation of a blog post which advertises a sloph Inbox, sloph will fetch the article and verify whether the relation matches the contents of the notification before exposing the notification for re-use.</li> </ul> <p><cite><a href='http://www.linkededitrules.org/'>Linked Edit Rules</a></cite> and <cite><a href='https://melvincarvalho.github.io/vocab/'>Solid Words</a></cite> are specialised senders. Linked Edit Rules checks the consistency of statistical datasets against structured constraints, and delivers the consistency report as a notification to the user. Solid Words is a clientside game for learning new words in a foreign language; it delivers the player’s score for each round to their Inbox. <cite><a href='https://apps.rhiaro.co.uk/onscreen'>OnScreen</a></cite> is a (crude) generic consumer; as such, it can display notifications sent by both of the aforementioned senders (<a href='#figure-ldn-senders'>figure 6</a>).</p> <figure resource='#figure-sloph-dokieli' rel='schema:hasPart' inlist='' id='figure-sloph-dokieli'> <img alt='Screenshots of sloph and dokieli' src='https://csarven.ca/media/images/articles/screenshot-ldn-sloph-dokieli.jpg'></img> <figcaption property='schema:name'>A <em>Like</em> notification created by sloph, displayed by dokieli.</figcaption> </figure> <figure resource='#figure-ldn-senders' rel='schema:hasPart' inlist='' id='figure-ldn-senders'> <img alt='Screenshots of Solid Words, Linked Edit Rules, and OnScreen' src='https://csarven.ca/media/images/articles/screenshot-ldn-senders.jpg'></img> <figcaption property='schema:name'>A: Solid Words (a sender), B: Linked Edit Rules (a sender), C: OnScreen (a consumer) displaying notifications sent by A and B.</figcaption> </figure>

Inbox

• Concept

Introduction

<p>Notifications are sent over the Web for a variety of purposes, including social applications: <q>You have been invited to a graduation party!</q>, <q>Tim commented on your blog post!</q>, <q>Liz tagged you in a photo</q>. The notification data may be displayed to a human to acknowledge, or used to trigger some other application-specific process (or both). <span typeof='dio:DesignIssue' resource='#design-intent' rel='dio:generatedByIntent' property='schema:description' datatype='rdf:HTML' about='#design-issue' id='issue'>In a decentralised architecture, notifications can be a key element for federation of information, and application integration. However in <span typeof='dio:Active' resource='#design-issue-status' rel='dio:hasStatus'>centralised systems which prevail today</span>, this data is structured arbitrarily and typically only usable by the application that generated it in the first place. Current efforts towards <em>re-decentralising</em> the Web [<a href='#ref-1' class='ref'>1</a>, <a href='#ref-2' class='ref'>2</a>, <a href='#ref-3' class='ref'>3</a>] are moving towards architectures in which data storage is decoupled from application logic, freeing end users to switch between applications, or to let multiple applications operate over the same data. So far, notifications are considered to be <em>ephemeral</em> resources which may disappear after transport, and thus are excluded from being designed for reuse.</span></p> <p typeof='dio:DesignIntent' resource='#design-issue' rel='dio:generatesIssue' property='schema:description' id='design-intent' datatype='rdf:HTML' about='#design-intent'>We argue that notification data should not be locked into particular systems. We designed the <em>Linked Data Notifications (LDN)</em> protocol to support sharing and reuse of notifications <em>across</em> applications, regardless of how they were generated or what their contents are. We describe how the principles of identification, addressability and semantic representation can be applied to notifications on the Web. Specifying LDN as a formal protocol allows independently implemented, heterogeneous applications which generate and use notifications, to seamlessly work together. Thus, LDN supports the decentralisation of the Web as well as encourages the generation and consumption of Linked Data.</p> <p typeof='dio:DesignDecision' resource='#protocol' rel='dio:governsDesign' property='schema:description' id='design-decision' datatype='rdf:HTML' about='#design-decision'>We build on existing W3C standards and Linked Data principles. In particular, the storage of notifications is compatible with the <cite>Linked Data Platform</cite> standard; notifications are identified by HTTP URIs; and notification contents are available as JSON-LD. A key architectural decision is the separation of concerns between <em>senders</em>, <em>receivers</em>, and <em>consumers</em> of notifications. Implementations of the protocol can play one or more of these roles, and interoperate successfully with implementations playing the complementary roles. This means that notifications generated by one application can be reused by a completely different application, accessed via the store where the notification data resides, through shared Linked Data vocabularies. LDN also pushes the decentralised approach further by allowing any <em>target</em> resource to advertise its Inbox anywhere on the Web; that is, targets do not need to be coupled to or controlled by a receiver, and can make use of a third-party <em>Inbox as a service</em>.</p> <p>LDN is a W3C <a href='https://www.w3.org/TR/ldn/' rel='cito:citesAsAuthority cito:citesAsSourceDocument' about=''>Candidate Recommendation</a> via the <cite><a href='https://www.w3.org/wiki/Socialwg'>Social Web Working Group</a></cite> [<a href='#ref-4' class='ref'>4</a>]. <span rel='dio:supportedBy' about='#design-decision'>The first two authors (<span resource='https://csarven.ca/#i'>Sarven Capadisli</span> and <span resource='https://rhiaro.co.uk/#me'>Amy Guy</span>) of this article are the co-editors of the specification.</span></p> <p>Use cases for decentralised notifications are particularly evident in social networking (status updates, interactions, games); scholarly communication (reviews, citations); and changes of state of resources (datasets, versioning, sensor readings, experimental observations). We describe the requirements which guided the development of the protocol and discuss related work, including current alternative approaches and complementary protocols which can work alongside LDN. We summarise the protocol itself, and specific architectural considerations that were made. We built a test suite which can be used to confirm that implementations conform with the specification, and we describe 17 implementations which interoperate with each other.</p> <div resource='#concept-scheme' rel='schema:hasPart' id='concept-scheme' about=''> <p typeof='skos:ConceptScheme' resource='#concept-scheme'><span property='skos:definition'>As the following terms used throughout this article may be subject to different interpretations by different communities, we provide some definitions here.</span></p> <p rel='skos:hasTopConcept'>By <strong typeof='skos:Concept' resource='#concept-scheme' rel='skos:topConceptOf' property='skos:prefLabel' id='concept-decentralisation' about='#concept-decentralisation'>decentralisation</strong>, we mean <span property='skos:definition' about='#concept-decentralisation'>data and applications are loosely coupled, and users are empowered to choose where their data is stored or held. We focus on Web-based decentralisation, where content is transported over HTTP, and resources are identified with URIs.</span> An <strong typeof='skos:Concept' resource='#concept-scheme' rel='skos:topConceptOf' property='skos:prefLabel' id='concept-inbox' about='#concept-inbox'>Inbox</strong> is <span property='skos:definition' about='#concept-inbox'>a container or directory (attached to a Web resource) which is used to store and serve a collection of notifications.</span> A <strong typeof='skos:Concept' resource='#concept-scheme' rel='skos:topConceptOf' property='skos:prefLabel' id='concept-notification' about='#concept-notification'>notification</strong> is <span property='skos:definition' about='#concept-notification'>a retrievable resource which returns RDF. The contents of notifications are intended to describe a change in state of some other resource, or contain new information for the attention of a user or process, and may be subject to constraints of the Inbox it is contained in.</span> </p> </div> <!-- <p>Using this article as the target for notifications, we welcome readers' feedback via LDN.</p> -->

justification-data-formats-content-negotiation

receivers can expose <code>Accept-Post</code> headers for senders, and consumers can send <code>Accept</code> headers to receivers

• Justification

justification-data-formats-json-ld

JSON-LD is advantageous in being familiar for developers who are <cite><a href='http://manu.sporny.org/2014/json-ld-origins-2/' typeof='dio:Evidence' rel='dio:hasEvidence'>used to JSON-based APIs but not RDF</a></cite> [<a href='#ref-20' class='ref'>20</a>], and it is compatible with existing JSON libraries or in some cases native programming language data structures.

• Justification

justification-optimising-implementation-get-head-link

Given that an Inbox may be discovered from the HTTP headers of a resource, senders and consumers can optimise by attempting a <code>HEAD</code> request for discovery, and only continuing with a <code>GET</code> request if the <code>HEAD</code> is not successful. On the other hand, senders and consumers may be attempting discovery upon RDF resources which they already intend to parse into their own storage. In this case, there is no need for a <code>HEAD</code> request, as a <code>GET</code> will yield both HTTP <code>Link</code> headers and an RDF body, either of which could include the Inbox triple. This means that resources advertising an Inbox must respond to <code>GET</code> requests (even if only with HTTP headers) and may respond to <code>HEAD</code> requests.

• Justification

Linked Data Notifications: a resource-centric communication protocol

<section id='abstract'> <h2>Abstract</h2> <div property='schema:abstract' datatype='rdf:HTML'> <p>In this article we describe the Linked Data Notifications (LDN) protocol, which is a <a href='https://www.w3.org/TR/ldn/'>W3C Candidate Recommendation</a>. Notifications are sent over the Web for a variety of purposes, for example, by social applications. The information contained within a notification is structured arbitrarily, and typically only usable by the application which generated it in the first place. In the spirit of Linked Data, we propose that notifications should be reusable by multiple authorised applications. Through separating the concepts of <em>senders</em>, <em>receivers</em> and <em>consumers</em> of notifications, and leveraging Linked Data principles of shared vocabularies and URIs, LDN provides a building block for decentralised Web applications. This permits end users more freedom to switch between the online tools they use, as well as generating greater value when notifications from different sources can be used in combination. We situate LDN alongside related initiatives, and discuss additional considerations such as security and abuse prevention measures. We evaluate the protocol’s effectiveness by analysing multiple, independent implementations, which pass a suite of formal tests and can be demonstrated interoperating with each other.</p> </div> </section> <section id='keywords'> <h2>Keywords</h2> <div> <ul rel='schema:about'> <li><a resource='http://dbpedia.org/resource/Communications_protocol' href='https://en.wikipedia.org/wiki/Communications_protocol'>Communications protocol</a></li> <li><a resource='http://dbpedia.org/resource/Decentralization' href='https://en.wikipedia.org/wiki/Decentralization'>Decentralisation</a></li> <li><a resource='http://dbpedia.org/resource/Linked_data' href='https://en.wikipedia.org/wiki/Linked_data'>Linked Data</a></li> <li><a resource='http://dbpedia.org/resource/Social_web' href='https://en.wikipedia.org/wiki/Social_web'>Social web</a></li> </ul> </div> </section> <section resource='#introduction' rel='schema:hasPart' inlist='' id='introduction'> <h2 property='schema:name'>Introduction</h2> <div property='schema:description' datatype='rdf:HTML'> <p>Notifications are sent over the Web for a variety of purposes, including social applications: <q>You have been invited to a graduation party!</q>, <q>Tim commented on your blog post!</q>, <q>Liz tagged you in a photo</q>. The notification data may be displayed to a human to acknowledge, or used to trigger some other application-specific process (or both). <span typeof='dio:DesignIssue' resource='#design-intent' rel='dio:generatedByIntent' property='schema:description' datatype='rdf:HTML' about='#design-issue' id='issue'>In a decentralised architecture, notifications can be a key element for federation of information, and application integration. However in <span typeof='dio:Active' resource='#design-issue-status' rel='dio:hasStatus'>centralised systems which prevail today</span>, this data is structured arbitrarily and typically only usable by the application that generated it in the first place. Current efforts towards <em>re-decentralising</em> the Web [<a href='#ref-1' class='ref'>1</a>, <a href='#ref-2' class='ref'>2</a>, <a href='#ref-3' class='ref'>3</a>] are moving towards architectures in which data storage is decoupled from application logic, freeing end users to switch between applications, or to let multiple applications operate over the same data. So far, notifications are considered to be <em>ephemeral</em> resources which may disappear after transport, and thus are excluded from being designed for reuse.</span></p> <p typeof='dio:DesignIntent' resource='#design-issue' rel='dio:generatesIssue' property='schema:description' id='design-intent' datatype='rdf:HTML' about='#design-intent'>We argue that notification data should not be locked into particular systems. We designed the <em>Linked Data Notifications (LDN)</em> protocol to support sharing and reuse of notifications <em>across</em> applications, regardless of how they were generated or what their contents are. We describe how the principles of identification, addressability and semantic representation can be applied to notifications on the Web. Specifying LDN as a formal protocol allows independently implemented, heterogeneous applications which generate and use notifications, to seamlessly work together. Thus, LDN supports the decentralisation of the Web as well as encourages the generation and consumption of Linked Data.</p> <p typeof='dio:DesignDecision' resource='#protocol' rel='dio:governsDesign' property='schema:description' id='design-decision' datatype='rdf:HTML' about='#design-decision'>We build on existing W3C standards and Linked Data principles. In particular, the storage of notifications is compatible with the <cite>Linked Data Platform</cite> standard; notifications are identified by HTTP URIs; and notification contents are available as JSON-LD. A key architectural decision is the separation of concerns between <em>senders</em>, <em>receivers</em>, and <em>consumers</em> of notifications. Implementations of the protocol can play one or more of these roles, and interoperate successfully with implementations playing the complementary roles. This means that notifications generated by one application can be reused by a completely different application, accessed via the store where the notification data resides, through shared Linked Data vocabularies. LDN also pushes the decentralised approach further by allowing any <em>target</em> resource to advertise its Inbox anywhere on the Web; that is, targets do not need to be coupled to or controlled by a receiver, and can make use of a third-party <em>Inbox as a service</em>.</p> <p>LDN is a W3C <a href='https://www.w3.org/TR/ldn/' rel='cito:citesAsAuthority cito:citesAsSourceDocument' about=''>Candidate Recommendation</a> via the <cite><a href='https://www.w3.org/wiki/Socialwg'>Social Web Working Group</a></cite> [<a href='#ref-4' class='ref'>4</a>]. <span rel='dio:supportedBy' about='#design-decision'>The first two authors (<span resource='https://csarven.ca/#i'>Sarven Capadisli</span> and <span resource='https://rhiaro.co.uk/#me'>Amy Guy</span>) of this article are the co-editors of the specification.</span></p> <p>Use cases for decentralised notifications are particularly evident in social networking (status updates, interactions, games); scholarly communication (reviews, citations); and changes of state of resources (datasets, versioning, sensor readings, experimental observations). We describe the requirements which guided the development of the protocol and discuss related work, including current alternative approaches and complementary protocols which can work alongside LDN. We summarise the protocol itself, and specific architectural considerations that were made. We built a test suite which can be used to confirm that implementations conform with the specification, and we describe 17 implementations which interoperate with each other.</p> <div resource='#concept-scheme' rel='schema:hasPart' id='concept-scheme' about=''> <p typeof='skos:ConceptScheme' resource='#concept-scheme'><span property='skos:definition'>As the following terms used throughout this article may be subject to different interpretations by different communities, we provide some definitions here.</span></p> <p rel='skos:hasTopConcept'>By <strong typeof='skos:Concept' resource='#concept-scheme' rel='skos:topConceptOf' property='skos:prefLabel' id='concept-decentralisation' about='#concept-decentralisation'>decentralisation</strong>, we mean <span property='skos:definition' about='#concept-decentralisation'>data and applications are loosely coupled, and users are empowered to choose where their data is stored or held. We focus on Web-based decentralisation, where content is transported over HTTP, and resources are identified with URIs.</span> An <strong typeof='skos:Concept' resource='#concept-scheme' rel='skos:topConceptOf' property='skos:prefLabel' id='concept-inbox' about='#concept-inbox'>Inbox</strong> is <span property='skos:definition' about='#concept-inbox'>a container or directory (attached to a Web resource) which is used to store and serve a collection of notifications.</span> A <strong typeof='skos:Concept' resource='#concept-scheme' rel='skos:topConceptOf' property='skos:prefLabel' id='concept-notification' about='#concept-notification'>notification</strong> is <span property='skos:definition' about='#concept-notification'>a retrievable resource which returns RDF. The contents of notifications are intended to describe a change in state of some other resource, or contain new information for the attention of a user or process, and may be subject to constraints of the Inbox it is contained in.</span> </p> </div> <!-- <p>Using this article as the target for notifications, we welcome readers' feedback via LDN.</p> --> </div> </section> <section resource='#related-work' rel='schema:hasPart' inlist='' id='related-work'> <h2 property='schema:name'>Related Work</h2> <div typeof='deo:RelatedWork' resource='#related-work' property='schema:description' datatype='rdf:HTML'> <p>Here we review previous and ongoing efforts towards delivering notifications in a decentralised manner. Many systems which make use of notifications operate either in a completely centralised way, or are decentralised only in the sense that different instances of the <em>same</em> codebase need to interoperate; we restrict our review to mechanisms which do not expect the notification to be received or used only by the same software or platform which sent it.</p> <p>The contents of a notification is either: 1) URLs, indicating relations between Web resources, or 2) a ‘fat ping’ containing a blob of information. Semantic Pingback, Webmention, and Provenance Pingback follow the first form, and are also known as <cite>linkbacks</cite>, the suite of protocols that essentially allows Web documents to automatically reciprocate hyperlinks. This has the advantage that a verification mechanism can be tightly specified (the URL of the target must appear in the content of the source), but the disadvantage that notifications are only available for use cases involving Web publishing.</p> <p id='semantic-pingback-and-webmention'><cite><a href='https://aksw.github.io/SemanticPingback/'>Semantic Pingback</a></cite> [<a href='#ref-2' class='ref'>2</a>] and <cite><a href='https://www.w3.org/TR/webmention'>Webmention</a></cite> [<a href='#ref-5' class='ref'>5</a>] both update the original <cite><a href='http://www.hixie.ch/specs/pingback/pingback'>Pingback</a></cite> [<a href='#ref-6' class='ref'>6</a>] mechanism by replacing the XML-RPC transport mechanism by a <code>x-www-form-urlencoded</code> request with two parameters (<code>source</code> and <code>target</code>). Resources which are the target for a notification advertise the respective receiving service or endpoint via a <code>Link</code> relation, either in HTTP headers or HTML. Semantic Pingback additionally enables discovery of the Pingback service where target is available as RDF. While the content at source may indicate (in any convention or serialisation format) the type of relation between the source and target URLs, this information about the relation is not transmitted to the receiver’s endpoint; only the source and target URLs are sent. As such, there is also no way to distinguish between multiple potential mentions of the target at the source; this is left up to the receiver to interpret. Semantic Pingback does encourage generation of additional semantics about the relation(s) between the source and the target by processing the source as RDF if possible, and also defines specific ways for a receiving server to handle incoming pingback data in order to add the source data to an RDF knowledge base [<a href='#ref-2' class='ref'>2</a>]. Beyond verifying that the source contains the URL of the target, Webmention does not specify any further requirements of the receiving server; nor is it expected that “mentions” are retrievable once they have been sent. </p> <p id='provenance-pingback'>A <cite><a href='http://www.w3.org/TR/prov-aq/#provenance-pingback'>Provenance Pingback</a></cite> endpoint is also advertised via the HTTP <code>Link</code> header; it accepts a list of URIs for provenance records describing uses of the resource [<a href='#ref-7' class='ref'>7</a>]. Provenance Pingback does not specify any further behaviour by the receiving server, but the contents at the URIs listed in the notification body must be semantic data.</p> <p>Other notification mechanisms send more information than just URLs in the notification body; due to each mechanism’s focused use case, the payload is restricted to a particular vocabulary.</p> <p><cite><a href='http://www.cibiv.at/~niko/dsnotify/'>DSNotify</a></cite> is a centralised service which crawls datasets and observes changes to links with the specific use case of preserving link integrity between Linked Open Data resources. Third-party applications can register with the sending service to receive notifications of changes in the form of a specific XML payload [<a href='#ref-8' class='ref'>8</a>]. With the <cite><a href='https://www.w3.org/2001/sw/wiki/SparqlPuSH'>sparqlPuSH</a></cite> service, users may input a SPARQL query, the results of which are the specific updates they are interested in. The query is run periodically by the service, and the results are converted to RSS and Atom feeds, which is sent to a <a href='http://pubsubhubbub.github.io/PubSubHubbub/pubsubhubbub-core-0.4.html'>PubSubHubbub</a> hub to which the user can subscribe [<a href='#ref-9' class='ref'>9</a>]. The <cite><a href='http://www.openarchives.org/rs/notification/1.0/notification'>ResourceSync Change Notification</a></cite> specification also sends update notifications via a <abbr title='PubSubHubbub'>PuSH</abbr> hub, this time with an XML payload based on the Sitemap format [<a href='#ref-10' class='ref'>10</a>]. Each of these mechanisms is triggered by subscription requests. That is, a user must actively solicit messages from a particular service, rather than having a way for a service to select a notification target and autonomously discover where to send notifications to.</p> </div> </section> <section resource='#requirements-and-design-considerations' rel='schema:hasPart' inlist='' id='requirements-and-design-considerations'> <h2 property='schema:name'>Requirements and Design Considerations</h2> <div property='schema:description' datatype='rdf:HTML'> <p>In this section we discuss our considerations for a <span typeof='dio:DesignIntent' property='schema:description' datatype='rdf:HTML' about='#design-intent-linked-data'>Web notification protocol that conforms to the Linked Data design principles</span>, as well as <span typeof='dio:DesignIntent' property='schema:description' datatype='rdf:HTML' about='#design-intent-best-practices'>best practices for applications</span>. We use these considerations to establish both concrete requirements and points of implementation-specific flexibility for the protocol.</p> <section resource='#modularity' rel='schema:hasPart' inlist='' id='modularity'> <h3 property='schema:name'>R1 Modularity</h3> <div typeof='dio:DesignRequirement' resource='#design-intent' rel='dio:addressedBy' property='schema:description' datatype='rdf:HTML' about='#modularity'> <p>To encourage modularity of applications, one should differentiate between different classes of implementation of the protocol. Two parties are involved in the creation of a notification: a <em>sender</em>, generating the notification data, and a <em>receiver</em>, storing the created resource. We also have the role of a <em>consumer</em>, which reads the notification data and repurposes it in some way. A software implementation can of course play two or all three of these roles; the important part is that it need not. A consuming application can read and use notification data without being concerned about ever sending or storing notifications.</p> </div> </section> <section resource='#reusable-notifications' rel='schema:hasPart' inlist='' id='reusable-notifications'> <h3 property='schema:name'>R2 Reusable notifications</h3> <div typeof='dio:DesignRequirement' resource='#design-intent' rel='dio:addressedBy' property='schema:description' datatype='rdf:HTML' about='#reusable-notifications'> <p>The relationship between the <em>consumer</em> and <em>receiver</em> roles is key to notifications being reusable. A consumer must be able to autonomously find the location of notifications for or about the particular resource it is interested in. To achieve this we place a requirement on the receiver to expose notifications it has been sent in such away to permit other applications to access them; and specify how any resource can advertise its receiving endpoint for consumers to discover. To promote fair use or remixing of notification contents, applications can incorporate rights and licensing information into the data. Similarly, applications may include additional information on licensing resources that the notification refers to. The presence of this type of information is important for consumers to assess the (re)usability of data.</p> </div> </section> <section resource='#persistence-and-retrievability' rel='schema:hasPart' inlist='' id='persistence-and-retrievability'> <h3 property='schema:name'>R3 Persistence and Retrievability</h3> <div typeof='dio:DesignRequirement' resource='#design-intent' rel='dio:addressedBy' property='schema:description' datatype='rdf:HTML' about='#persistence-and-retrievability'> <meta resource='#design-intent-best-practices' rel='dio:addressedBy'></meta> <meta resource='#design-issue-optimising-implementation' rel='dio:identifies'></meta> <p>There is a social expectation and technical arguments for ensuring the persistence of identifiers of Web resources [<a href='#ref-11' class='ref'>11</a>]. This is inconsistent with the traditionally ephemeral nature of notifications. Applications may benefit from referring to or reusing notifications if the notifications are known to be available in the long term, or indicate their expected lifespan [<a href='#ref-12' class='ref'>12</a><!-- , <a href="https://www.w3.org/TR/dwbp/#UniqueIdentifiers" title="Best Practice 9: Use persistent URIs as identifiers of datasets"></a>, <a href="https://tools.ietf.org/html/rfc7089"></a>-->].</p> <p>A <em>RESTful architecture</em> [<a href='#ref-13' class='ref'>13</a>] is well suited for persistent notifications, as it involves organisation of atomic resources, their discovery and description, and a lightweight API for the <abbr title='create, read, update, and delete'>CRUD</abbr> (create, read, update, and delete) operations [<a href='#ref-14' class='ref'>14</a>]. This enforces the notion that notifications are considered resources in their own right, with their own dereferencable URIs.</p> <p>We need to consider both the needs of software systems and humans when large amounts of notification data are being generated and shared between diverse applications which may be operating without knowledge of each other. To organise and manage large amount of notifications over time, mechanisms should be in place to break representations of collections of notifications into multiple paged responses that may be easier to consume by applications.</p> <p>Relatedly, receivers may carry out resource management or garbage collection, or permit consumers or other applications to do so. For example, an application to consume messages might let an authenticated and authorised user ‘mark as read’ by adding a triple to the notification contents.</p> </div> </section> <section resource='#adaptability' rel='schema:hasPart' inlist='' id='adaptability'> <h3 property='schema:name'>R4 Adaptability</h3> <div typeof='dio:DesignRequirement' property='schema:description' datatype='rdf:HTML' about='#adaptability'> <meta resource='#design-intent-linked-data' rel='dio:addressedBy'></meta> <meta resource='#design-issue-data-formats' rel='dio:identifies'></meta> <p>Linked Data applications benefit from domain-driven designs; that is, functionality being small and focussed on a particular purpose, rather than generic. We believe a notification protocol should be adaptable for different domains, but that there is no need to create multiple domain-specific notification protocols; the fundamental mechanics are the same.</p> <p typeof='dio:DesignRequirement' resource='#adaptability' rel='dio:refines' property='schema:description' datatype='rdf:HTML' about='#target-representation' id='target-representation'><strong>R4-A</strong>: Any resource may be the <em>target</em> of a notification. By target, we mean a notification may be addressed <em>to</em> the resource, be <em>about</em> the resource, or for a sender to otherwise decide that it is appropriate to draw the attention of the resource (or resource owner) to the information in the notification body. As such, any Web resource must be able to advertise an endpoint to which it can receive notifications. Resources can be RDF or non-RDF (such as an image, or CSV dataset), and may be informational (a blog post, a user profile) or non-informational (a person).</p> <p typeof='dio:DesignRequirement' resource='#adaptability' rel='dio:refines' property='schema:description' datatype='rdf:HTML' about='#notification-body' id='notification-body'><strong>R4-B</strong>: We do not purport to be able to design a notifications ontology which is appropriate for every domain. Thus we consider the <em>contents</em> of a notification to be application specific. From a sender’s perspective, we derive two core principles: a notification can contain <em>any data</em>; a notification can use <em>any vocabulary</em>. From a consumer’s perspective, interoperability between different applications occurs through vocabulary reuse, and shared understanding of terms. This is in accordance with Linked Data principles in general. The practical upshot of this is that a calendar application which consumes event invitations using the <cite><a href='https://www.w3.org/TR/rdfcal/'>RDF Calendar</a></cite> vocabulary is likely to completely ignore notifications containing the <cite><a href='https://www.w3.org/TR/prov-o/'>PROV Ontology</a></cite>, even if it finds them all stored in the same place. For two independent applications operating in the <em>same</em> domain, a shared understanding of appropriate vocabulary terms is assumed.</p> <div typeof='dio:DesignRequirement' resource='#adaptability' rel='dio:refines' property='schema:description' datatype='rdf:HTML' about='#notification-verification' id='notification-verification'> <p>However from a receiver’s perspective, exposing itself to receive any blobs of RDF data from unknown senders may be problematic. Thus, <strong>R4-C</strong>: it should be possible for the receiver to enforce restrictions and accept only notifications that are acceptable according to its own criteria (deemed by e.g., user configuration; domain-specific receivers). This can be used as an anti-spam measure, a security protection, or for attaining application and data integrity.</p> <p>Rejecting notifications which do not match a specific pattern in their contents, or the <em>shape</em> of the data, is one way to filter. For example, if the Inbox owner knows that they will only ever use a consuming application which processes friend requests, they can configure their receiver to filter out anything that does not match the pattern for a friend request, helping their consumer to be more efficient. If the notification constraints are also advertised by the receiving service as structured descriptions, generation and consumption of the notifications can be further automated. Possible specifications for doing so are W3C <cite><a href='https://www.w3.org/TR/shacl/'>Shapes Constraint Language (SHACL)</a></cite> [<a href='#ref-15' class='ref'>15</a>] or <cite><a href='https://shexspec.github.io/spec/'>ShEx</a></cite>.</p> <p>Receivers may wish to filter notifications by verifying the sender, through for example a whitelist or a Web of trust. This requires an authentication mechanism and since different authentication mechanisms are appropriate for different applications, the notification protocol should ideally be usable alongside various methods such as clientside certificates, e.g., WebID+TLS, token-based, e.g., OAuth 2.0, or digital signatures.</p> <p>As <q>anyone can say anything about anything</q> a receiver may choose to resolve any external resources referred to by the notification, and cross-check the notification contents against authoritative sources. This is similar to how Semantic Pingback and Webmention require fetching and parsing of the source URL to verify existence of the target link.</p> </div> </div> </section> <section resource='#subscribing' rel='schema:hasPart' inlist='' id='subscribing'> <h3 property='schema:name'>R5 Subscribing</h3> <div typeof='dio:DesignRequirement' resource='#design-intent' rel='dio:addressedBy' property='schema:description' datatype='rdf:HTML' about='#subscribing'> <p>In general, applications may require that new notifications are pushed to them in real-time, or to request them at appropriate intervals. To take this into account, we expand our definition of senders, receivers and consumers with the following interaction expectations: notifications are <em>pushed</em> from senders to receivers; and <em>pulled</em> from receivers by consumers.</p> <p>Thus, an application which offers an endpoint or callback URL to which notifications should be sent directly is a receiver, and an application which fetches notifications from an endpoint on its own schedule is a consumer. Much of the related work <em>requires</em> notifications to be explicitly solicited to trigger sending. Since in a decentralised model, receivers may not be aware of possible sources for notifications, our sender-receiver relationship depends on the sender’s autonomy to make such decisions by itself. This does not preclude the scenario in which a receiver may wish to solicit notifications from a particular sender, but as there are already subscription mechanisms in wide use on the Web, we do not need to specify it as part of LDN. For example, <cite><a href='https://www.w3.org/TR/websub/'>WebSub</a></cite> (recent W3C evolution of PubSubHubbub), the <cite>WebSocket Protocol</cite>, or <cite>HTTP Web Push</cite>.</p> </div> </section> <p>Given our adoption of Linked Data principles and a RESTful architecture, a further design decision was to ensure minimal compatibility with the <cite><a href='https://www.w3.org/TR/ldp/'>Linked Data Platform</a></cite> (LDP) specification [<a href='#ref-16' class='ref'>16</a>]. LDP is a RESTful read-write API for RDF resources, which groups related resources together into constructs known as <q>Containers</q>. Thus, existing LDP servers can be used to store notifications, as new notifications can be created by <code>POST</code>ing RDF to a container.</p> </div> </section> <section resource='#protocol' rel='schema:hasPart' inlist='' id='protocol'> <h2 property='schema:name'>The LDN Protocol</h2> <div typeof='deo:Contribution dio:Design' resource='#protocol' property='schema:description' datatype='rdf:HTML'> <p>The <dfn id='ldn'>Linked Data Notifications (<abbr title='Linked Data Notifications'>LDN</abbr>)</dfn> protocol describes how servers (receivers) can receive messages pushed to them by applications (senders), as well as how other applications (consumers) may retrieve those messages. Any resource can advertise a receiving endpoint (Inbox) for notification messages. Messages are expressed in RDF, and can contain arbitrary data. It is not dependent on a complete implementation of LDP, but comprises an easy-to-implement subset. LDN is a <cite><a href='https://www.w3.org/TR/ldn'>W3C Candidate Recommendation</a></cite> [<a href='#ref-4' class='ref'>4</a>].</p> <figure resource='#figure-linked-data-notifications-overview' rel='schema:hasPart' inlist='' id='figure-linked-data-notifications-overview'> <object width='640' type='image/svg+xml' rel='schema:image' height='305' data='https://www.w3.org/TR/ldn/linked-data-notifications-overview.svg'>Overview diagram of Linked Data Notifications showing the Sender, Receiver, Consumer roles and their interactions with Target, Inbox, and Notification resources.</object> <figcaption property='schema:name'>Overview of Linked Data Notifications</figcaption> </figure> <section resource='#sender-to-receiver' rel='schema:hasPart' inlist='' id='sender-to-receiver'> <h3 property='schema:name'>Sender to receiver interactions</h3> <div property='schema:description' datatype='rdf:HTML'> <p>The following steps (in order without skipping) describe the interaction between sender and receiver:</p> <p>(1) A sender is triggered, either by a human or an automatic process, to deliver a notification; (2) The sender chooses a target resource to send notifications to; (3) The sender discovers the location of the target’s <em>Inbox</em> through the <code>ldp:inbox</code> relation in the HTTP <code>Link</code> header or RDF body of the target resource; (4) The sender creates the body of the notification according to the needs of application; (5) The sender makes a <code>POST</code> to the Inbox URL, containing the body in JSON-LD or in another serialisation acceptable by the server; (6) The receiver optionally applies filtering rules, and sends the appropriate HTTP response code to accept or reject the notification; (7) The receiver exposes the notification data (according to appropriate access control) for use by consumers.</p> </div> </section> <section resource='#consumer-to-receiver' rel='schema:hasPart' inlist='' id='consumer-to-receiver'> <h3 property='schema:name'>Consumer to receiver interactions</h3> <div property='schema:description' datatype='rdf:HTML'> <p>The following steps (in order without skipping) describe the interaction between consumer and receiver:</p> <p>(1) A consumer selects a target and discovers the location of its Inbox in the same way as the sender; (2) A receiver responds to <code>GET</code> requests made to the Inbox URL with a listing of the URLs of notifications that have previously been accepted, linked to the Inbox with the <code>ldp:contains</code> predicate; <span resource='#persistence-and-retrievability' rel='dio:fulfillsRequirement' about='#protocol'>(3) The receiver responds to <code>GET</code> requests made to the individual notification URLs with JSON-LD (or optionally other serialisations);</span> <span resource='#reusable-notifications' rel='dio:fulfillsRequirement' about='#protocol'>(4) Following the retrieval of notification listings or individual notifications, the consumer may perform further processing, combine with some other data, or simply present the results in a suitable human-readable way.</span></p> </div> </section> <section resource='#example-notifications' rel='schema:hasPart' inlist='' id='example-notifications'> <h3 property='schema:name'>Example Notifications</h3> <div property='schema:description' datatype='rdf:HTML'> <p>For more example notification payloads, see the <a href='https://www.w3.org/TR/ldn/'>LDN specification</a>.</p> <figure resource='#sending-notification-request' rel='schema:hasPart' inlist='' id='sending-notification-request' class='listing'> <pre typeof='fabio:Script' property='schema:description' about='#sending-notification-request'><code>{</code><code> "@context": { "sioc": "http://rdfs.org/sioc/ns#" }</code><code> "@id": "",</code><code> "@type": "sioc:Comment",</code><code> "sioc:content": "This is a great article!",</code><code> "as:inReplyTo": { "@id": "http://example.org/article" },</code><code> "sioc:created_at": { "@value": "2015-12-23T16:44:21Z" }</code><code>}</code></pre> <figcaption property='schema:name'>A notification about a comment created by a user (JSON-LD).</figcaption> </figure> <figure resource='#notification-qualified-relation' rel='schema:hasPart' inlist='' id='notification-qualified-relation' class='listing'> <pre typeof='fabio:Script' property='schema:description' about='#notification-qualified-relation'><code>@prefix as: &lt;https://www.w3.org/ns/activitystreams#&gt; .</code><code>@prefix cito: &lt;http://purl.org/spar/cito/&gt; .</code><code>&lt;&gt; a as:Announce</code><code> as:object &lt;https://linkedresearch.org/resources#r-903b83&gt; ;</code><code> as:target &lt;https://csarven.ca/dokieli#architecture&gt; .</code><code>&lt;https://linkedresearch.org/resources#r-903b83&gt;</code><code> cito:citesAsPotentialReading</code><code> &lt;https://csarven.ca/linked-data-notifications#protocol&gt; .</code></pre> <figcaption property='schema:name'>An announcement of a specific citation relation between two entities (Turtle).</figcaption> </figure> </div> </section> </div> </section> <section resource='#implementations' rel='schema:hasPart' inlist='' id='implementations'> <h2 property='schema:name'>Implementations</h2> <div property='schema:description' datatype='rdf:HTML'> <p>Here we summarise the 17 LDN implementations we are aware of to date. They are built by 10 different teams or individuals using different tool stacks (5 clientside JavaScript, 3 PHP, 3 NodeJS, 3 Python, 1 Perl, 1 Virtuoso Server Pages, 1 Java) and have submitted <a href='https://github.com/w3c/ldn/tree/master/implementations'>implementation reports</a> as part of the W3C standardisation process. We note that any <a href='https://www.w3.org/wiki/LDP_Implementations'>LDP implementation</a> is a conforming LDN receiver; we refer here to the ones we have tested. We discuss the value of these implementations further in the <a href='#analysis-and-evaluation'>Evaluation</a> section.</p> <table id='ldn-implementations'> <caption>LDN Implementations</caption> <thead> <tr> <th>Implementation</th> <th>Class^{<a href='#implementations-key'>*</a>}</th> <th>Description</th> </tr> </thead> <tfoot><tr> <td colspan='3'> <dl class='abbr'> <dt><sup id='implementations-key'>*</sup></dt><dd>Conformance classes: S – sender, C – consumer, R – receiver.</dd> <dt><sup id='author-implementations'>a</sup></dt><dd>Implementations by the authors</dd> </dl> <p>Source: <a href='https://github.com/w3c/ldn/tree/master/implementations'>https://github.com/w3c/ldn/tree/master/implementations</a></p> </td> </tr></tfoot> <tbody> <tr> <th><a href='https://carbonldp.com'>CarbonLDP</a></th> <td>R</td> <td>Data storage platform (LDP)</td> </tr> <tr> <th><a href='https://dokie.li/'>dokieli</a>^a</th> <td>S,C</td> <td>Clientside editor and annotator</td> </tr> <tr> <th><a href='https://github.com/linkeddata/errol'>errol</a>^a</th> <td>S</td> <td>Generic message sending client</td> </tr> <tr> <th><a href='http://fedora-commons.org/'>Fedora Commons</a></th> <td>R</td> <td>Open source repository platform (LDP)</td> </tr> <tr> <th><a href='https://github.com/Kongaloosh/IndieAnndroid'>IndieAnndroid</a></th> <td>R</td> <td>Personal blogging platform</td> </tr> <tr> <th><a href='https://github.com/albertmeronyo/linked-edit-rules'>Linked Edit Rules</a></th> <td>S</td> <td>Statistical dataset consistency checker</td> </tr> <tr> <th><a href='https://github.com/csarven/mayktso'>mayktso</a>^a</th> <td>R</td> <td>Personal data store (LDP)</td> </tr> <tr> <th><a href='https://github.com/rhiaro/onscreen'>OnScreen</a>^a</th> <td>C</td> <td>Notifications display client</td> </tr> <tr> <th><a href='https://github.com/albertmeronyo/pyldn'>pyldn</a></th> <td>R</td> <td>Standalone Inbox</td> </tr> <tr> <th><a href='https://github.com/kjetilk/p5-rdf-linkeddata-notifications'>RDF-LinkedData-Notifications</a></th> <td>R</td> <td>Standalone Inbox</td> </tr> <tr> <th><a href='https://github.com/rhiaro/sloph'>sloph</a>^a</th> <td>S,R</td> <td>Social publishing &amp; quantified self</td> </tr> <tr> <th><a href='https://github.com/melvincarvalho/vocab'>Solid Words</a></th> <td>S</td> <td>Foreign language learning app</td> </tr> <tr> <th><a href='https://github.com/solid/solid-client'>solid-client</a></th> <td>S</td> <td>Clientside library for LDP</td> </tr> <tr> <th><a href='https://github.com/solid/solid-inbox'>solid-inbox</a></th> <td>C</td> <td>Clientside social message reader</td> </tr> <tr> <th><a href='https://github.com/solid/solid-notifications'>solid-notifications</a></th> <td>S,C</td> <td>Clientside library for LDN</td> </tr> <tr> <th><a href='https://github.com/solid/node-solid-server'>solid-server</a></th> <td>R</td> <td>Personal data storage server (LDP)</td> </tr> <tr> <th><a href='https://github.com/openlink/virtuoso-opensource'>Virtuoso</a>+<a href='http://ods.openlinksw.com/wiki/ODS/OdsBriefcase'>ODS Briefcase</a></th> <td>R,C</td> <td>Personal data storage server (LDP)</td> </tr> </tbody> </table> <p>We highlight social scholarly communication use cases with <cite><a href='https://dokie.li/'>dokieli</a></cite>, a clientside editor for decentralised scientific article publishing, annotations and social interactions [<a href='#ref-17' class='ref'>17</a>]. dokieli uses LDN to send and consume notifications: When a reader comments on a fragment of text in an article, the application discovers the article’s Inbox and sends a notification about the annotation. dokieli also consumes notifications from this Inbox to fetch and display the annotation as marginalia (<a href='#figure-dokieli-annotation'>figure 2</a>). A reader can share a dokieli-enabled article with their contacts; dokieli discovers each contact’s Inbox and sends a notification there (<a href='#figure-dokieli-share'>figure 3</a>). When editing an article, the author can add a citation. If an Inbox is discovered in the cited article, dokieli sends a notification there to indicate what part of the article was cited by whom and where. dokieli-enabled articles also consume citation notifications to display these metrics for the author and other readers (<a href='#figure-dokieli-citation'>figure 4</a>).</p> <figure resource='#figure-dokieli-annotation' rel='schema:hasPart' inlist='' id='figure-dokieli-annotation'> <video poster='https://dokie.li/media/images/dokieli-annotation.jpg' width='800' controls='controls' preload='none' rel='schema:hasPart' inlist='' id='video-dokieli-annotation'> <source type='video/webm' src='https://dokie.li/media/video/dokieli-annotation.webm' typeof='fabio:Film' resource='https://dokie.li/media/video/dokieli-annotation.webm' rel='schema:hasPart' about='#video-dokieli-annotation'></source> </video> <figcaption property='schema:name'><a href='https://dokie.li/media/video/dokieli-annotation.webm'>Video</a> of dokieli Web Annotation</figcaption> </figure> <figure resource='#figure-dokieli-share' rel='schema:hasPart' inlist='' id='figure-dokieli-share'> <video poster='https://dokie.li/media/images/dokieli-share.jpg' width='800' controls='controls' preload='none' rel='schema:hasPart' id='video-dokieli-share'> <source type='video/webm' src='https://dokie.li/media/video/dokieli-share.webm' typeof='fabio:Film' resource='https://dokie.li/media/video/dokieli-share.webm' rel='schema:hasPart' about='#video-dokieli-share'></source> </video> <figcaption property='schema:name'><a href='https://dokie.li/media/video/dokieli-share.webm'>Video</a> of dokieli Share</figcaption> </figure> <figure resource='#figure-dokieli-citation' rel='schema:hasPart' inlist='' id='figure-dokieli-citation'> <video rel='schema:hasPart' about='' width='800' preload='none' poster='https://dokie.li/media/images/dokieli-citation.jpg' id='video-dokieli-citation' controls='controls'> <source typeof='fabio:Film' type='video/webm' src='https://dokie.li/media/video/dokieli-citation.webm' resource='https://dokie.li/media/video/dokieli-citation.webm' rel='schema:hasPart' about='#video-dokieli-citation'></source> </video> <figcaption property='schema:name'><a href='https://dokie.li/media/video/dokieli-citation.webm'>Video</a> of semantic inline citations</figcaption> </figure> <p>Notifications sent by dokieli can be reused by any consuming applications that recognise the vocabulary terms; similarly, dokieli can consume notifications sent by different applications.</p> <p>Further social use cases are demonstrated by <cite><a href='https://rhiaro.co.uk/sloph'>sloph</a></cite>, a personal publishing and quantified self platform which acts as a node in a decentralised social network. When new content is created on the server, sloph performs discovery on URLs it finds as values of particular properties of the new content, as well as any URLs in the body of the content, and sends notifications accordingly. For instance:</p> <ul> <li>If a <em>Like</em> activity is generated on the server, sloph uses the <code>object</code> of the <em>Like</em> as the target for a notification. Since dokieli uses the same vocabulary for social interactions (<cite><a href='https://www.w3.org/ns/activitystreams-core'>ActivityStreams 2.0</a></cite> [<a href='#ref-18' class='ref'>18</a>]), if the target is a dokieli article, this <em>Like</em> will be displayed (<a href='#figure-sloph-dokieli'>figure 5</a>).</li> <li>If the user publishes a blog post containing a link, which may be semantically annotated to indicate the reason for linking, sloph sends a notification to any Inbox discovered at that link.</li> <li>As a receiver, sloph accepts all incoming notifications, but holds for moderation (i.e. places behind access control) any that it cannot automatically verify refer to third-party content published on another domain. If an article written with dokieli publishes a citation of a blog post which advertises a sloph Inbox, sloph will fetch the article and verify whether the relation matches the contents of the notification before exposing the notification for re-use.</li> </ul> <p><cite><a href='http://www.linkededitrules.org/'>Linked Edit Rules</a></cite> and <cite><a href='https://melvincarvalho.github.io/vocab/'>Solid Words</a></cite> are specialised senders. Linked Edit Rules checks the consistency of statistical datasets against structured constraints, and delivers the consistency report as a notification to the user. Solid Words is a clientside game for learning new words in a foreign language; it delivers the player’s score for each round to their Inbox. <cite><a href='https://apps.rhiaro.co.uk/onscreen'>OnScreen</a></cite> is a (crude) generic consumer; as such, it can display notifications sent by both of the aforementioned senders (<a href='#figure-ldn-senders'>figure 6</a>).</p> <figure resource='#figure-sloph-dokieli' rel='schema:hasPart' inlist='' id='figure-sloph-dokieli'> <img alt='Screenshots of sloph and dokieli' src='https://csarven.ca/media/images/articles/screenshot-ldn-sloph-dokieli.jpg'></img> <figcaption property='schema:name'>A <em>Like</em> notification created by sloph, displayed by dokieli.</figcaption> </figure> <figure resource='#figure-ldn-senders' rel='schema:hasPart' inlist='' id='figure-ldn-senders'> <img alt='Screenshots of Solid Words, Linked Edit Rules, and OnScreen' src='https://csarven.ca/media/images/articles/screenshot-ldn-senders.jpg'></img> <figcaption property='schema:name'>A: Solid Words (a sender), B: Linked Edit Rules (a sender), C: OnScreen (a consumer) displaying notifications sent by A and B.</figcaption> </figure> </div> </section> <section resource='#analysis-and-evaluation' rel='schema:hasPart' inlist='' id='analysis-and-evaluation'> <h2 property='schema:name'>Analysis and Evaluation</h2> <div typeof='deo:Evaluation' resource='#analysis-and-evaluation' property='schema:description' datatype='rdf:HTML'> <p>The LDN protocol describes the discovery of a resource’s Inbox whence notifications are sent or consumed, and the sending and exposure of those notifications. Here we analyse how well features of LDN achieve the <a href='#requirements-and-design-considerations'>requirements</a> identified previously, and compare this to related work.</p> <p>We have already examined <a href='#implementations'>implementations</a> of the specification and described how they interoperate with each other; this can be further tested by running the <a href='https://linkedresearch.org/ldn/tests/'>test suite</a>: https://linkedresearch.org/ldn/tests/. We can use this towards an evaluation of its feasibility and effectiveness at interoperability. Given the relatively early stage in the standardisation process (LDN entered Candidate Recommendation in 2016-11), the fast adoption of the LDN specification, quantity of the implementations, and their diversity is promising and further shows LDN’s feasibility. Furthermore, during the development of the specification issues have been raised or discussed by 28 different people (excluding the authors; 21 outside of the Social Web Working Group, 7 within) and the specification has undergone formal review by internationalisation, accessibility, and security specialists. We also discuss in more depth particular challenges that were raised and resolved as part of this process.</p> <section resource='#comparison-summary' rel='schema:hasPart' inlist='' id='comparison-summary'> <h3 property='schema:name'>Comparison summary</h3> <div property='schema:description' datatype='rdf:HTML'> <p>Here we compare existing notification mechanisms from related work. The criteria includes our <a href='#requirements-and-design-considerations'>requirements and design considerations</a> (<em>Rx</em>) along with additional technical information which helps to capture some design differences (<em>Tx</em>).</p> <table id='comparison-of-notification-mechanisms'> <caption>Comparison of notification mechanisms</caption> <thead> <tr> <th>Mechanism</th> <th>T1</th> <th>T2</th> <th>T3</th> <th>R1</th> <th>R2</th> <th>R3</th> <th>R4-A</th> <th>R4-B</th> <th>R4-C^p</th> <th>R4-C^v</th> <th>R4-C^o</th> <th>R5</th> </tr> </thead> <tfoot> <tr> <td colspan='14'> <dl class='abbr'> <dt>T1</dt><dd>Notification type</dd> <dt>T2</dt><dd>Delivery method</dd> <dt>T3</dt><dd>Dependencies</dd> <dt>R1</dt><dd>Modularity (application classes: S Sender, R Receiver, C Consumer, U Subscriber/User)</dd> <dt>R2</dt><dd>Reusability</dd> <dt>R3</dt><dd>Persistence - required? how?</dd> <dt>R4-A</dt><dd>Target representation</dd> <dt>R4-B</dt><dd>Notification body</dd> <dt>R4-C^p</dt><dd>Payload processing required?</dd> <dt>R4-C^v</dt><dd>Verification - required? how?</dd> <dt>R4-C^o</dt><dd>Requirements for referenced resources?</dd> <dt>R5</dt><dd>Subscription</dd> </dl> <hr></hr> <dl class='abbr'> <dt>–</dt><dd>not applicable, out of scope</dd> <dt>/</dt><dd>not specified, in scope</dd> <dt>X</dt><dd>explicitly disallowed</dd> <dt>app</dt><dd>application specific decision</dd> <dt>!</dt><dd>required (<em>MUST</em>)</dd> <dt>+</dt><dd>recommended (<em>SHOULD</em>)</dd> <dt>O</dt><dd>optional (<em>MAY</em>)</dd> <dt>PuSH</dt><dd>PubSubHubbub</dd> </dl> <hr></hr> <dl class='abbr'> <dt>^h</dt><dd>HTML recommended</dd> <dt>^j</dt><dd>Alternate RDF formats can be negotiated</dd> <dt>^k</dt><dd><code>source</code> and <code>target</code> key–value pairs is required</dd> <dt>^q</dt><dd>Provenance records with <a href='http://www.w3.org/TR/prov-o/'>PROV Ontology</a></dd> <dt>^r</dt><dd>RDF representation recommended</dd> <dt>^ra</dt><dd>SPARQL results transformed to RSS/Atom</dd> <dt>^s</dt><dd><a href='https://www.sitemaps.org/protocol.html'>Sitemaps</a></dd> <dt>^t</dt><dd>Described in an RDF store or dataset</dd> </dl> </td> <!-- Notes for how I removed some ?s: * target representation is - when there’s no discovery step for the sender ie. subscription based * verification required is - when there’s a subscription relationship because we assume the receiver trusts the sender -rhiaro --> </tr> </tfoot> <tbody> <tr> <th>Semantic Pingback</th> <td>Linkback</td> <td>POST</td> <td>RDF</td> <td>S R</td> <td>/</td> <td>/</td> <td>Any^r</td> <td>form urlencoded^k</td> <td>!</td> <td>! parse source</td> <td>Any^r</td> <td>X</td> </tr> <tr> <th>Webmention</th> <td>Linkback</td> <td>POST</td> <td>HTML</td> <td>S R</td> <td>–</td> <td>–</td> <td>Any^h</td> <td>form urlencoded^k</td> <td>!</td> <td>! parse source</td> <td>Any^h</td> <td>X</td> </tr> <tr> <th>Provenance Pingback</th> <td>Linkback</td> <td>POST</td> <td>RDF</td> <td>S R</td> <td>/</td> <td>/</td> <td>/</td> <td>URI list</td> <td>/</td> <td>/</td> <td>RDF^q</td> <td>X</td> </tr> <tr> <th>DSNotify</th> <td>Fat ping</td> <td>POST, PUT</td> <td>XML, PuSH</td> <td>S U</td> <td>/</td> <td>–</td> <td>–</td> <td>XML</td> <td>/</td> <td>–</td> <td>RDF^t</td> <td>!</td> </tr> <tr> <th>sparqlPuSH</th> <td>Fat ping</td> <td>POST</td> <td>XML, SPARQL, PuSH</td> <td>S U</td> <td>–</td> <td>–</td> <td>–</td> <td>XML^ra</td> <td>/</td> <td>–</td> <td>RDF^t</td> <td>!</td> </tr> <tr> <th>ResourceSync</th> <td>Fat ping</td> <td>POST</td> <td>XML, PuSH</td> <td>S U</td> <td>/</td> <td>–</td> <td>–</td> <td>XML^s</td> <td>/</td> <td>–</td> <td>?</td> <td>!</td> </tr> <tr> <th>Linked Data Notifications</th> <td>Fat ping</td> <td>POST</td> <td>JSON-LD</td> <td>S R C</td> <td>!</td> <td>! URI</td> <td>Any</td> <td>JSON-LD^j</td> <td>+ app</td> <td>+ app</td> <td>–</td> <td>O app</td> </tr> </tbody> </table> <p>Given that each application requires to follow the steps listed in <q><a href='#sender-to-receiver'>Sender to receiver interaction</a></q> and <q><a href='#consumer-to-receiver'>Consumer to receiver interactions</a></q> the metrics are dependent on the performance of client and server to do HTTP requests and responses, and their respective payloads.</p> </div> </section> <section resource='#compatibility-with-existing-systems' rel='schema:hasPart' inlist='' id='compatibility-with-existing-systems'> <h3 property='schema:name'>Compatibility with existing systems</h3> <div property='schema:description' datatype='rdf:HTML'> <p>Per <a href='#modularity' rel='dio:fulfillsRequirement' about='#protocol'>R1</a> and <a href='#adaptability' rel='dio:fulfillsRequirement' about='#protocol'>R4</a> we have tried to optimise LDN for use as a module of a larger system. The success of this is demonstrated by implementations which use LDN alongside existing protocols according to their specific needs.</p> <p>The Solid suite of tools, Virtuoso+ODS-Briefcase, and dokieli use <cite><a href='https://www.w3.org/wiki/WebAccessControl'>Web Access Control</a></cite> along with an authentication mechanism to apply fine grained access controls to restrict who can send notifications, or who can retrieve notifications from the Inbox. sloph demonstrates an Inbox as a <cite><a href='http://www.webhooks.org/'>Webhooks</a></cite> callback URL, for requesting notifications from APIs which post JSON-based payloads. <cite><a href='https://www.w3.org/TR/activitypub/'>ActivityPub</a></cite> is a W3C <abbr title='Candidate Recommendation'>CR</abbr> for decentralised social media [<a href='#ref-19' class='ref'>19</a>]. It uses LDN for delivery of notifications with the <a href='https://www.w3.org/ns/activitystreams'>ActivityStreams 2.0</a> (AS2) vocabulary, and specifies additional specialised receiver behaviour; also used by sloph. dokieli uses the <cite><a href='https://www.w3.org/TR/annotation-protocol/'>Web Annotation Protocol</a></cite>, an LDP-based mechanism for creating new content, which acts as a trigger for notifications to be sent to the Inbox of the annotation target. The <cite><a href='http://fcrepo.github.io/fcrepo-specification/'>Fedora API Specification</a></cite> is in the process of being formalised (as an extension of LDP) by the Fedora community. The repository event stream draws upon the LDN specification, allowing LDN consumers and senders to react asynchronously to repository events.</p> <p>Any existing <abbr title='Linked Data Platform'>LDP</abbr> implementation can serve as an LDN receiver. Simply advertising any <code>ldp:Container</code> as the Inbox for a resource is sufficient. We confirmed this with four LDP servers which were developed independently with different code bases, prior to the LDN specification (CarbonLDP, Fedora Commons, Solid Server, Virtuoso).</p> <p>LDN has been integrated into existing domain specific systems: dokieli, Fedora Commons, IndieAnndroid, Linked Edit Rules, sloph, solid-client, Solid Words. Standalone implementations of LDN are also straightforward as a result of this modularity, ie: errol, mayktso, onscreen, pyLDN, RDF-LinkedData-Notifications, solid-inbox, solid-notifications.</p> </div> </section> <section resource='#optimising-implementation' rel='schema:hasPart' inlist='' id='optimising-implementation'> <h3 property='schema:name'>Optimising implementation</h3> <div property='schema:description' datatype='rdf:HTML'> <p rel='dio:generatesIssue' about='#design-intent-best-practices'><span typeof='dio:DesignIssue' resource='#design-intent-best-practices' rel='dio:generatedByIntent' property='schema:description' datatype='rdf:HTML' about='#design-issue-optimising-implementation'>We have considered tradeoffs between the HTTP operations receivers and publishers are <em>required</em> to respond to, and ways in which developers may wish to optimise senders or consumers by reducing outbound requests.<meta resource='dio:Resolved' rel='dio:hasStatus' about='#design-issue-optimising-implementation'></meta></span></p> <p resource='#solution-optimising-implementation-get-head-link' rel='dio:hasMandatedSolution' about='#design-issue-optimising-implementation'> <meta typeof='dio:MandatedSolution' resource='#design-decision' rel='dio:leadsTo'></meta> <span typeof='dio:Argument' resource='#argument-optimising-implementation-get-head-link' property='dio:hasArgument'><span property='schema:description' datatype='rdf:HTML'><code>HEAD</code> requests are low cost, and <code>GET</code> requests may be high cost if the body of the resource is large.</span></span> <span typeof='dio:Justification' resource='#justification-optimising-implementation-get-head-link' property='dio:hasJustification'><span property='schema:description' datatype='rdf:HTML'>Given that an Inbox may be discovered from the HTTP headers of a resource, senders and consumers can optimise by attempting a <code>HEAD</code> request for discovery, and only continuing with a <code>GET</code> request if the <code>HEAD</code> is not successful. On the other hand, senders and consumers may be attempting discovery upon RDF resources which they already intend to parse into their own storage. In this case, there is no need for a <code>HEAD</code> request, as a <code>GET</code> will yield both HTTP <code>Link</code> headers and an RDF body, either of which could include the Inbox triple. This means that resources advertising an Inbox must respond to <code>GET</code> requests (even if only with HTTP headers) and may respond to <code>HEAD</code> requests.</span></span> </p> </div> </section> <section resource='#data-formats' rel='schema:hasPart' inlist='' id='data-formats'> <h3 property='schema:name'>Data Formats and Content Negotiation</h3> <div property='schema:description' datatype='rdf:HTML'> <p rel='dio:generatesIssue' about='#design-intent-linked-data'><span typeof='dio:DesignIssue' resource='#design-intent-linked-data' rel='dio:hasStatus' property='schema:description' datatype='rdf:HTML' about='#design-issue-data-formats'>Handling data irrespective of the particular RDF serialisation permits some flexibility, but can be costly to support. We take into account: (a) application interoperability, (b) maintenance of RDF parsers and serialisation libraries, (c) complexity of their inclusion in applications, (d) run-time efficiency.<meta resource='dio:Resolved' rel='dio:hasStatus' about='#design-issue-data-formats'></meta></span></p> <p resource='#solution-data-formats-json-ld' rel='dio:hasMandatedSolution' about='#design-issue-data-formats'> <meta typeof='dio:MandatedSolution' resource='#design-decision' rel='dio:leadsTo'></meta> <span typeof='dio:Argument' resource='#argument-data-formats-json-ld' property='dio:hasArgument'><span property='schema:description' datatype='rdf:HTML'>To address these issues, LDN requires all applications to create and understand the JSON-LD syntax, both for the contents of Inbox as well as for individual notifications. Choosing a single serialisation to <em>require</em> is necessary for consistent interoperability, as well as keeping processing requirements or external code dependencies minimal.</span></span> <span typeof='dio:Justification' resource='#justification-data-formats-json-ld' property='dio:hasJustification'><span property='schema:description' datatype='rdf:HTML'>JSON-LD is advantageous in being familiar for developers who are <cite><a href='http://manu.sporny.org/2014/json-ld-origins-2/' typeof='dio:Evidence' rel='dio:hasEvidence'>used to JSON-based APIs but not RDF</a></cite> [<a href='#ref-20' class='ref'>20</a>], and it is compatible with existing JSON libraries or in some cases native programming language data structures.</span></span> </p> <p resource='#solution-data-formats-content-negotiation' rel='dio:hasAlternativeSolution' about='#design-issue-data-formats'>Optionally, <span typeof='dio:Argument' resource='#argument-data-formats-content-negotiation' property='dio:hasArgument'><span property='schema:description' datatype='rdf:HTML'>applications may attempt to exchange different RDF serialisations by performing content negotiation</span></span> (<span typeof='dio:Justification' resource='#justification-data-formats-content-negotiation' property='dio:hasJustification'><span property='schema:description' datatype='rdf:HTML'>receivers can expose <code>Accept-Post</code> headers for senders, and consumers can send <code>Accept</code> headers to receivers</span></span>).</p> </div> </section> <section resource='#precision' rel='schema:hasPart' inlist='' id='precision'> <h3 property='schema:name'>Precision</h3> <div property='schema:description' datatype='rdf:HTML'> <p>In placing no constraints on the contained information, LDN enables a sender to be precise and lossless with the data it is transmitting. Approaches which send only URLs rely on the receiver interpreting a third-party resource, which may or may not contain structured markup or be under the control of the sender. Approaches which offer additional guidance to aid the receiver in interpreting the source document(s) nonetheless still restricts the sender. LDN therefore offers flexibility to senders, increasing the potential uses for the notification mechanism. LDN compensates for increased complexity on the receiver’s end by recommending filtering mechanisms, and moving some of the burden of understanding notifications to the consumer role. As such LDN can cover a broader variety of use cases.</p> </div> </section> <section resource='#accommodating-different-targets' rel='schema:hasPart' inlist='' id='accommodating-different-targets'> <h3 property='schema:name'>Accommodating different targets</h3> <div property='schema:description' datatype='rdf:HTML'> <p>Per <em>R4 Adaptability</em>, we want LDN to be available for all resources in any publishing context. We consider lowering the bar for publishers of target resources to be a worthwhile trade-off against slightly increased complexity for senders and consumers. This is why we require that senders and consumers must be equipped to discover Inboxes through both HTTP headers and RDF content. </p> <p>Since binary formats such as images and video cannot contain an RDF relation, the HTTP header is essential for including them. It also allows the inclusion of resources for which it is undesirable or impractical to add individual Inbox relations, such as to elements in a dataset; or circumstances where the developer responsible for the Inbox relation is unable to modify the content. Conversely, non-informational resources (represented with fragment URIs or 303 redirects) are unable to express HTTP headers. Their relation to an Inbox must be expressed in an RDF source. However, if a sender or consumer has a domain-specific requirement to <em>only</em> ever target non-informational resources, they are exempt from the requirement of discovery via HTTP headers.</p> </div> </section> </div> </section> <section resource='#conclusions' rel='schema:hasPart' inlist='' id='conclusions'> <h2 property='schema:name'>Conclusions</h2> <div typeof='deo:Conclusion' resource='#conclusions' property='schema:description' datatype='rdf:HTML'> <p>In this article we describe LDN, a protocol for decentralised semantic notifications, currently undergoing standardisation at the W3C. Key elements are:</p> <ul> <li>Notifications as retrievable, reusable entities with their own URIs.</li> <li>Distinct conformance classes for senders, receivers, and consumers.</li> <li>Deliberately not defining the vocabulary of notification contents to allow for use in a range of different application domains.</li> <li>Flexibility of authentication and verification, for the same reason.</li> </ul> <p>We outlined design requirements, describe how LDN meets these, and compare this with related work. We consider LDN to have greater modularity and adaptability to different scenarios, as well as good conformance with Linked Data principles. This specification has potential to have high impact in increasing interoperability between decentralised Linked Data applications in related domains, as well as generating new discoverable content for the LOD Cloud. This is evidenced by 17 diverse implementations which can be shown to interoperate with each other, including generic libraries and datastores, and domain-specific applications. Being on the W3C standards track increases the likelihood of further adoption.</p> <!-- Future work? --> <!-- <p>We have yet to assess the implications of applications modifying data that another application also makes use of. This would be a useful study for decentralisation in general.</p> --> </div> </section> <section resource='#acknowledgements' rel='schema:hasPart' prefix='scoro: http://purl.org/spar/scoro/' inlist='' id='acknowledgements'> <h2 property='schema:name'>Acknowledgements</h2> <div typeof='deo:Acknowledgements' property='schema:description' datatype='rdf:HTML' about='#acknowledgements'> <p>This material is based on work supported by the Qatar Computing Research Institute (QCRI), and by the DFG project “Opening Scholarly Communication in Social Sciences” (grant agreement AU 340/9-1).</p> </div> </section> <section id='references'> <h2>References</h2> <div> <ol> <li id='ref-1'>Mansour, E., Sambra, A., Hawke, S., Zereba, M., Capadisli, S., Ghanem, A., Aboulnaga, A., Berners-Lee, T.: <cite>A Demonstration of the Solid Platform for Social Web Applications</cite>, WWW, Demo, 2016, <a href='http://www2016.net/proceedings/companion/p223.pdf' rel='schema:citation'>http://www2016.net/proceedings/companion/p223.pdf</a></li> <li id='ref-2'>Tramp, S., Frischmuth, P., Ermilov, T., Shekarpour, S., Auer, S.: <cite>An Architecture of a Distributed Semantic Social Network</cite>, Semantic Web Journal, 2012, <a href='http://www.semantic-web-journal.net/sites/default/files/swj201_4.pdf' rel='schema:citation'>http://www.semantic-web-journal.net/sites/default/files/swj201_4.pdf</a></li> <li id='ref-3'>Arndt, N., Junghanns, K., Meissner, R., Frischmuth, F., Radtke, N., Frommhold, M., Martin, M.: <cite>Structured Feedback</cite>, WWW, LDOW, 2016, <a href='http://events.linkeddata.org/ldow2016/papers/LDOW2016_paper_02.pdf' rel='schema:citation'>http://events.linkeddata.org/ldow2016/papers/LDOW2016_paper_02.pdf</a></li> <li id='ref-4'>Capadisli, S., Guy, A.: <cite>Linked Data Notifications</cite>, W3C Candidate Recommendation, 2016, <a href='https://www.w3.org/TR/ldn/' rel='schema:citation'>https://www.w3.org/TR/ldn/</a></li> <li id='ref-5'>Parecki, A.: <cite>Webmention</cite>, W3C Proposed Recommendation, 2016, <a href='https://www.w3.org/TR/webmention/' rel='schema:citation'>https://www.w3.org/TR/webmention/</a></li> <li id='ref-6'>Langridge, S., Hickson, I.: <cite>Pingback 1.0</cite>, 2002, <a href='http://www.hixie.ch/specs/pingback/pingback' rel='schema:citation'>http://www.hixie.ch/specs/pingback/pingback</a></li> <li id='ref-7'>Klyne, G., Groth, P.: <cite>PROV-AQ: Provenance Access and Query</cite>, W3C Note, 2013, <a href='http://www.w3.org/TR/prov-aq/' rel='schema:citation'>http://www.w3.org/TR/prov-aq/</a></li> <li id='ref-8'>Haslhofer, B., Popitsch, N.: <cite>DSNotify – Detecting and Fixing Broken Links in Linked Data Sets</cite>, WWW, 2010, <a href='http://eprints.cs.univie.ac.at/81/1/2010_WWW_DSNotify.pdf' rel='schema:citation'>http://eprints.cs.univie.ac.at/81/1/2010_WWW_DSNotify.pdf</a></li> <li id='ref-9'>Passant, A., Mendes, P.N.: <cite>sparqlPuSH: Proactive notification of data updates in RDF stores using PubSubHubbub</cite>, SFSW, CEUR Workshop Proceedings, Vol. 699, 2010, <a href='http://ceur-ws.org/Vol-699/Paper6.pdf' rel='schema:citation'>http://ceur-ws.org/Vol-699/Paper6.pdf</a></li> <li id='ref-10'>Klein, M., Van de Sompel, H., Warner, S., Klyne, G., Haslhofer, B., Nelson, M., Lagoze, C., Sanderson, R.: ResourceSync Framework Specification – Change Notification, 2016, <a href='http://www.openarchives.org/rs/notification/1.0/notification' rel='schema:citation'>http://www.openarchives.org/rs/notification/1.0/notification</a></li> <li id='ref-11'>Berners-Lee, T.: <cite>Cool URIs don't change</cite>, W3C, 1998, <a href='https://www.w3.org/Provider/Style/URI.html' rel='schema:citation'>https://www.w3.org/Provider/Style/URI.html</a></li> <li id='ref-12'>Archer, P., Loutas, N., Goedertier S., Kourtidis, S.: <cite>Study On Persistent URIs</cite>, 2012, <a href='http://philarcher.org/diary/2013/uripersistence/' rel='schema:citation'>http://philarcher.org/diary/2013/uripersistence/</a></li> <li id='ref-13'>Fielding, R. T.: <cite>Architectural Styles and the Design of Network-based Software Architectures</cite>. Doctoral dissertation, University of California, Irvine, 2000, <a href='http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm' rel='schema:citation'>http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm</a></li> <li id='ref-14'>Page, K.R., De Roure, D.C., Martinez, K.: <cite>REST and Linked Data: a match made for domain driven development?</cite>, WWW, WS-REST, 2011, <a href='http://ws-rest.org/2011/proc/a5-page.pdf' rel='schema:citation'>http://ws-rest.org/2011/proc/a5-page.pdf</a></li> <li id='ref-15'>Knublauch, H., Kontokostas, D.: <cite>Shapes Constraint Language</cite>, W3C Working Draft, 2016, <a href='https://www.w3.org/TR/shacl/' rel='schema:citation'>https://www.w3.org/TR/shacl/</a></li> <li id='ref-16'>Speicher, S., Arwe, J., Malhotra, A.: <cite>Linked Data Platform</cite>, W3C Recommendation, 2015, <a href='https://www.w3.org/TR/ldp/' rel='schema:citation'>https://www.w3.org/TR/ldp/</a></li> <li id='ref-17'>Capadisli, S., Guy, A., Auer S., Berners-Lee, T.: <cite>dokieli</cite>, 2016, <a href='https://csarven.ca/dokieli' rel='schema:citation'>https://csarven.ca/dokieli</a></li> <li id='ref-18'>Snell, J., Prodromou, E.: <cite>Activity Streams 2.0</cite>, W3C Candidate Recommendation, 2016, <a href='https://www.w3.org/TR/activitystreams-core/' rel='schema:citation'>https://www.w3.org/TR/activitystreams-core/</a></li> <li id='ref-19'>Webber, C., Tallon, J.: <cite>ActivityPub</cite>, W3C Candidate Recommendation, 2016, <a href='https://www.w3.org/TR/activitypub/' rel='schema:citation'>https://www.w3.org/TR/activitypub/</a></li> <li id='ref-20'>Sporny, M.: <cite>JSON-LD and Why I Hate the Semantic Web</cite>, 2014, <a href='http://manu.sporny.org/2014/json-ld-origins-2/' rel='schema:citation'>http://manu.sporny.org/2014/json-ld-origins-2/</a></li> </ol> </div> </section>

• Article
• Document
• Document
• Entity
• Post
• ScholarlyArticle

MIT

• Organization

note-20161219125430

• TextualBody

note-20161227093752

• TextualBody

note-20170127113559

• TextualBody

note-20170127113748

• TextualBody

note-20170127114105

• TextualBody

note-20170127114321

• TextualBody

note-20170206130644

• TextualBody

note-20170206130733

• TextualBody

note-20170206131454

• TextualBody

note-20170206131536

• TextualBody

note-20170223115735

• TextualBody

note-20170602162144

• TextualBody

notification

• Concept

notification-body

<strong>R4-B</strong>: We do not purport to be able to design a notifications ontology which is appropriate for every domain. Thus we consider the <em>contents</em> of a notification to be application specific. From a sender’s perspective, we derive two core principles: a notification can contain <em>any data</em>; a notification can use <em>any vocabulary</em>. From a consumer’s perspective, interoperability between different applications occurs through vocabulary reuse, and shared understanding of terms. This is in accordance with Linked Data principles in general. The practical upshot of this is that a calendar application which consumes event invitations using the <cite><a href='https://www.w3.org/TR/rdfcal/'>RDF Calendar</a></cite> vocabulary is likely to completely ignore notifications containing the <cite><a href='https://www.w3.org/TR/prov-o/'>PROV Ontology</a></cite>, even if it finds them all stored in the same place. For two independent applications operating in the <em>same</em> domain, a shared understanding of appropriate vocabulary terms is assumed.

• DesignRequirement

notification-verification

<p>However from a receiver’s perspective, exposing itself to receive any blobs of RDF data from unknown senders may be problematic. Thus, <strong>R4-C</strong>: it should be possible for the receiver to enforce restrictions and accept only notifications that are acceptable according to its own criteria (deemed by e.g., user configuration; domain-specific receivers). This can be used as an anti-spam measure, a security protection, or for attaining application and data integrity.</p> <p>Rejecting notifications which do not match a specific pattern in their contents, or the <em>shape</em> of the data, is one way to filter. For example, if the Inbox owner knows that they will only ever use a consuming application which processes friend requests, they can configure their receiver to filter out anything that does not match the pattern for a friend request, helping their consumer to be more efficient. If the notification constraints are also advertised by the receiving service as structured descriptions, generation and consumption of the notifications can be further automated. Possible specifications for doing so are W3C <cite><a href='https://www.w3.org/TR/shacl/'>Shapes Constraint Language (SHACL)</a></cite> [<a href='#ref-15' class='ref'>15</a>] or <cite><a href='https://shexspec.github.io/spec/'>ShEx</a></cite>.</p> <p>Receivers may wish to filter notifications by verifying the sender, through for example a whitelist or a Web of trust. This requires an authentication mechanism and since different authentication mechanisms are appropriate for different applications, the notification protocol should ideally be usable alongside various methods such as clientside certificates, e.g., WebID+TLS, token-based, e.g., OAuth 2.0, or digital signatures.</p> <p>As <q>anyone can say anything about anything</q> a receiver may choose to resolve any external resources referred to by the notification, and cross-check the notification contents against authoritative sources. This is similar to how Semantic Pingback and Webmention require fetching and parsing of the source URL to verify existence of the target link.</p>

• DesignRequirement

Optimising implementation

<p rel='dio:generatesIssue' about='#design-intent-best-practices'><span typeof='dio:DesignIssue' resource='#design-intent-best-practices' rel='dio:generatedByIntent' property='schema:description' datatype='rdf:HTML' about='#design-issue-optimising-implementation'>We have considered tradeoffs between the HTTP operations receivers and publishers are <em>required</em> to respond to, and ways in which developers may wish to optimise senders or consumers by reducing outbound requests.<meta resource='dio:Resolved' rel='dio:hasStatus' about='#design-issue-optimising-implementation'></meta></span></p> <p resource='#solution-optimising-implementation-get-head-link' rel='dio:hasMandatedSolution' about='#design-issue-optimising-implementation'> <meta typeof='dio:MandatedSolution' resource='#design-decision' rel='dio:leadsTo'></meta> <span typeof='dio:Argument' resource='#argument-optimising-implementation-get-head-link' property='dio:hasArgument'><span property='schema:description' datatype='rdf:HTML'><code>HEAD</code> requests are low cost, and <code>GET</code> requests may be high cost if the body of the resource is large.</span></span> <span typeof='dio:Justification' resource='#justification-optimising-implementation-get-head-link' property='dio:hasJustification'><span property='schema:description' datatype='rdf:HTML'>Given that an Inbox may be discovered from the HTTP headers of a resource, senders and consumers can optimise by attempting a <code>HEAD</code> request for discovery, and only continuing with a <code>GET</code> request if the <code>HEAD</code> is not successful. On the other hand, senders and consumers may be attempting discovery upon RDF resources which they already intend to parse into their own storage. In this case, there is no need for a <code>HEAD</code> request, as a <code>GET</code> will yield both HTTP <code>Link</code> headers and an RDF body, either of which could include the Inbox triple. This means that resources advertising an Inbox must respond to <code>GET</code> requests (even if only with HTTP headers) and may respond to <code>HEAD</code> requests.</span></span> </p>

Overview of Linked Data Notifications

Philipp Mayr

• Person

Philipp Mayr replied on 2017-02-23 11:57:35

<div typeof='oa:TextualBody' resource='#note-20170223115735' property='rdf:value' datatype='rdf:HTML'> <p>signing in via orcid was possible.</p> </div>

• Annotation
• Note

Precision

<p>In placing no constraints on the contained information, LDN enables a sender to be precise and lossless with the data it is transmitting. Approaches which send only URLs rely on the receiver interpreting a third-party resource, which may or may not contain structured markup or be under the control of the sender. Approaches which offer additional guidance to aid the receiver in interpreting the source document(s) nonetheless still restricts the sender. LDN therefore offers flexibility to senders, increasing the potential uses for the notification mechanism. LDN compensates for increased complexity on the receiver’s end by recommending filtering mechanisms, and moving some of the burden of understanding notifications to the consumer role. As such LDN can cover a broader variety of use cases.</p>

R1 Modularity

<p>To encourage modularity of applications, one should differentiate between different classes of implementation of the protocol. Two parties are involved in the creation of a notification: a <em>sender</em>, generating the notification data, and a <em>receiver</em>, storing the created resource. We also have the role of a <em>consumer</em>, which reads the notification data and repurposes it in some way. A software implementation can of course play two or all three of these roles; the important part is that it need not. A consuming application can read and use notification data without being concerned about ever sending or storing notifications.</p>

• DesignRequirement

R2 Reusable notifications

<p>The relationship between the <em>consumer</em> and <em>receiver</em> roles is key to notifications being reusable. A consumer must be able to autonomously find the location of notifications for or about the particular resource it is interested in. To achieve this we place a requirement on the receiver to expose notifications it has been sent in such away to permit other applications to access them; and specify how any resource can advertise its receiving endpoint for consumers to discover. To promote fair use or remixing of notification contents, applications can incorporate rights and licensing information into the data. Similarly, applications may include additional information on licensing resources that the notification refers to. The presence of this type of information is important for consumers to assess the (re)usability of data.</p>

• DesignRequirement

R3 Persistence and Retrievability

<meta resource='#design-intent-best-practices' rel='dio:addressedBy'></meta> <meta resource='#design-issue-optimising-implementation' rel='dio:identifies'></meta> <p>There is a social expectation and technical arguments for ensuring the persistence of identifiers of Web resources [<a href='#ref-11' class='ref'>11</a>]. This is inconsistent with the traditionally ephemeral nature of notifications. Applications may benefit from referring to or reusing notifications if the notifications are known to be available in the long term, or indicate their expected lifespan [<a href='#ref-12' class='ref'>12</a><!-- , <a href="https://www.w3.org/TR/dwbp/#UniqueIdentifiers" title="Best Practice 9: Use persistent URIs as identifiers of datasets"></a>, <a href="https://tools.ietf.org/html/rfc7089"></a>-->].</p> <p>A <em>RESTful architecture</em> [<a href='#ref-13' class='ref'>13</a>] is well suited for persistent notifications, as it involves organisation of atomic resources, their discovery and description, and a lightweight API for the <abbr title='create, read, update, and delete'>CRUD</abbr> (create, read, update, and delete) operations [<a href='#ref-14' class='ref'>14</a>]. This enforces the notion that notifications are considered resources in their own right, with their own dereferencable URIs.</p> <p>We need to consider both the needs of software systems and humans when large amounts of notification data are being generated and shared between diverse applications which may be operating without knowledge of each other. To organise and manage large amount of notifications over time, mechanisms should be in place to break representations of collections of notifications into multiple paged responses that may be easier to consume by applications.</p> <p>Relatedly, receivers may carry out resource management or garbage collection, or permit consumers or other applications to do so. For example, an application to consume messages might let an authenticated and authorised user ‘mark as read’ by adding a triple to the notification contents.</p>

• DesignRequirement

R4 Adaptability

<meta resource='#design-intent-linked-data' rel='dio:addressedBy'></meta> <meta resource='#design-issue-data-formats' rel='dio:identifies'></meta> <p>Linked Data applications benefit from domain-driven designs; that is, functionality being small and focussed on a particular purpose, rather than generic. We believe a notification protocol should be adaptable for different domains, but that there is no need to create multiple domain-specific notification protocols; the fundamental mechanics are the same.</p> <p typeof='dio:DesignRequirement' resource='#adaptability' rel='dio:refines' property='schema:description' datatype='rdf:HTML' about='#target-representation' id='target-representation'><strong>R4-A</strong>: Any resource may be the <em>target</em> of a notification. By target, we mean a notification may be addressed <em>to</em> the resource, be <em>about</em> the resource, or for a sender to otherwise decide that it is appropriate to draw the attention of the resource (or resource owner) to the information in the notification body. As such, any Web resource must be able to advertise an endpoint to which it can receive notifications. Resources can be RDF or non-RDF (such as an image, or CSV dataset), and may be informational (a blog post, a user profile) or non-informational (a person).</p> <p typeof='dio:DesignRequirement' resource='#adaptability' rel='dio:refines' property='schema:description' datatype='rdf:HTML' about='#notification-body' id='notification-body'><strong>R4-B</strong>: We do not purport to be able to design a notifications ontology which is appropriate for every domain. Thus we consider the <em>contents</em> of a notification to be application specific. From a sender’s perspective, we derive two core principles: a notification can contain <em>any data</em>; a notification can use <em>any vocabulary</em>. From a consumer’s perspective, interoperability between different applications occurs through vocabulary reuse, and shared understanding of terms. This is in accordance with Linked Data principles in general. The practical upshot of this is that a calendar application which consumes event invitations using the <cite><a href='https://www.w3.org/TR/rdfcal/'>RDF Calendar</a></cite> vocabulary is likely to completely ignore notifications containing the <cite><a href='https://www.w3.org/TR/prov-o/'>PROV Ontology</a></cite>, even if it finds them all stored in the same place. For two independent applications operating in the <em>same</em> domain, a shared understanding of appropriate vocabulary terms is assumed.</p> <div typeof='dio:DesignRequirement' resource='#adaptability' rel='dio:refines' property='schema:description' datatype='rdf:HTML' about='#notification-verification' id='notification-verification'> <p>However from a receiver’s perspective, exposing itself to receive any blobs of RDF data from unknown senders may be problematic. Thus, <strong>R4-C</strong>: it should be possible for the receiver to enforce restrictions and accept only notifications that are acceptable according to its own criteria (deemed by e.g., user configuration; domain-specific receivers). This can be used as an anti-spam measure, a security protection, or for attaining application and data integrity.</p> <p>Rejecting notifications which do not match a specific pattern in their contents, or the <em>shape</em> of the data, is one way to filter. For example, if the Inbox owner knows that they will only ever use a consuming application which processes friend requests, they can configure their receiver to filter out anything that does not match the pattern for a friend request, helping their consumer to be more efficient. If the notification constraints are also advertised by the receiving service as structured descriptions, generation and consumption of the notifications can be further automated. Possible specifications for doing so are W3C <cite><a href='https://www.w3.org/TR/shacl/'>Shapes Constraint Language (SHACL)</a></cite> [<a href='#ref-15' class='ref'>15</a>] or <cite><a href='https://shexspec.github.io/spec/'>ShEx</a></cite>.</p> <p>Receivers may wish to filter notifications by verifying the sender, through for example a whitelist or a Web of trust. This requires an authentication mechanism and since different authentication mechanisms are appropriate for different applications, the notification protocol should ideally be usable alongside various methods such as clientside certificates, e.g., WebID+TLS, token-based, e.g., OAuth 2.0, or digital signatures.</p> <p>As <q>anyone can say anything about anything</q> a receiver may choose to resolve any external resources referred to by the notification, and cross-check the notification contents against authoritative sources. This is similar to how Semantic Pingback and Webmention require fetching and parsing of the source URL to verify existence of the target link.</p> </div>

• DesignRequirement

R5 Subscribing

<p>In general, applications may require that new notifications are pushed to them in real-time, or to request them at appropriate intervals. To take this into account, we expand our definition of senders, receivers and consumers with the following interaction expectations: notifications are <em>pushed</em> from senders to receivers; and <em>pulled</em> from receivers by consumers.</p> <p>Thus, an application which offers an endpoint or callback URL to which notifications should be sent directly is a receiver, and an application which fetches notifications from an endpoint on its own schedule is a consumer. Much of the related work <em>requires</em> notifications to be explicitly solicited to trigger sending. Since in a decentralised model, receivers may not be aware of possible sources for notifications, our sender-receiver relationship depends on the sender’s autonomy to make such decisions by itself. This does not preclude the scenario in which a receiver may wish to solicit notifications from a particular sender, but as there are already subscription mechanisms in wide use on the Web, we do not need to specify it as part of LDN. For example, <cite><a href='https://www.w3.org/TR/websub/'>WebSub</a></cite> (recent W3C evolution of PubSubHubbub), the <cite>WebSocket Protocol</cite>, or <cite>HTTP Web Push</cite>.</p>

• DesignRequirement

Related Work

<p>Here we review previous and ongoing efforts towards delivering notifications in a decentralised manner. Many systems which make use of notifications operate either in a completely centralised way, or are decentralised only in the sense that different instances of the <em>same</em> codebase need to interoperate; we restrict our review to mechanisms which do not expect the notification to be received or used only by the same software or platform which sent it.</p> <p>The contents of a notification is either: 1) URLs, indicating relations between Web resources, or 2) a ‘fat ping’ containing a blob of information. Semantic Pingback, Webmention, and Provenance Pingback follow the first form, and are also known as <cite>linkbacks</cite>, the suite of protocols that essentially allows Web documents to automatically reciprocate hyperlinks. This has the advantage that a verification mechanism can be tightly specified (the URL of the target must appear in the content of the source), but the disadvantage that notifications are only available for use cases involving Web publishing.</p> <p id='semantic-pingback-and-webmention'><cite><a href='https://aksw.github.io/SemanticPingback/'>Semantic Pingback</a></cite> [<a href='#ref-2' class='ref'>2</a>] and <cite><a href='https://www.w3.org/TR/webmention'>Webmention</a></cite> [<a href='#ref-5' class='ref'>5</a>] both update the original <cite><a href='http://www.hixie.ch/specs/pingback/pingback'>Pingback</a></cite> [<a href='#ref-6' class='ref'>6</a>] mechanism by replacing the XML-RPC transport mechanism by a <code>x-www-form-urlencoded</code> request with two parameters (<code>source</code> and <code>target</code>). Resources which are the target for a notification advertise the respective receiving service or endpoint via a <code>Link</code> relation, either in HTTP headers or HTML. Semantic Pingback additionally enables discovery of the Pingback service where target is available as RDF. While the content at source may indicate (in any convention or serialisation format) the type of relation between the source and target URLs, this information about the relation is not transmitted to the receiver’s endpoint; only the source and target URLs are sent. As such, there is also no way to distinguish between multiple potential mentions of the target at the source; this is left up to the receiver to interpret. Semantic Pingback does encourage generation of additional semantics about the relation(s) between the source and the target by processing the source as RDF if possible, and also defines specific ways for a receiving server to handle incoming pingback data in order to add the source data to an RDF knowledge base [<a href='#ref-2' class='ref'>2</a>]. Beyond verifying that the source contains the URL of the target, Webmention does not specify any further requirements of the receiving server; nor is it expected that “mentions” are retrievable once they have been sent. </p> <p id='provenance-pingback'>A <cite><a href='http://www.w3.org/TR/prov-aq/#provenance-pingback'>Provenance Pingback</a></cite> endpoint is also advertised via the HTTP <code>Link</code> header; it accepts a list of URIs for provenance records describing uses of the resource [<a href='#ref-7' class='ref'>7</a>]. Provenance Pingback does not specify any further behaviour by the receiving server, but the contents at the URIs listed in the notification body must be semantic data.</p> <p>Other notification mechanisms send more information than just URLs in the notification body; due to each mechanism’s focused use case, the payload is restricted to a particular vocabulary.</p> <p><cite><a href='http://www.cibiv.at/~niko/dsnotify/'>DSNotify</a></cite> is a centralised service which crawls datasets and observes changes to links with the specific use case of preserving link integrity between Linked Open Data resources. Third-party applications can register with the sending service to receive notifications of changes in the form of a specific XML payload [<a href='#ref-8' class='ref'>8</a>]. With the <cite><a href='https://www.w3.org/2001/sw/wiki/SparqlPuSH'>sparqlPuSH</a></cite> service, users may input a SPARQL query, the results of which are the specific updates they are interested in. The query is run periodically by the service, and the results are converted to RSS and Atom feeds, which is sent to a <a href='http://pubsubhubbub.github.io/PubSubHubbub/pubsubhubbub-core-0.4.html'>PubSubHubbub</a> hub to which the user can subscribe [<a href='#ref-9' class='ref'>9</a>]. The <cite><a href='http://www.openarchives.org/rs/notification/1.0/notification'>ResourceSync Change Notification</a></cite> specification also sends update notifications via a <abbr title='PubSubHubbub'>PuSH</abbr> hub, this time with an XML payload based on the Sitemap format [<a href='#ref-10' class='ref'>10</a>]. Each of these mechanisms is triggered by subscription requests. That is, a user must actively solicit messages from a particular service, rather than having a way for a service to select a notification target and autonomously discover where to send notifications to.</p>

• RelatedWork

Requirements and Design Considerations

<p>In this section we discuss our considerations for a <span typeof='dio:DesignIntent' property='schema:description' datatype='rdf:HTML' about='#design-intent-linked-data'>Web notification protocol that conforms to the Linked Data design principles</span>, as well as <span typeof='dio:DesignIntent' property='schema:description' datatype='rdf:HTML' about='#design-intent-best-practices'>best practices for applications</span>. We use these considerations to establish both concrete requirements and points of implementation-specific flexibility for the protocol.</p> <section resource='#modularity' rel='schema:hasPart' inlist='' id='modularity'> <h3 property='schema:name'>R1 Modularity</h3> <div typeof='dio:DesignRequirement' resource='#design-intent' rel='dio:addressedBy' property='schema:description' datatype='rdf:HTML' about='#modularity'> <p>To encourage modularity of applications, one should differentiate between different classes of implementation of the protocol. Two parties are involved in the creation of a notification: a <em>sender</em>, generating the notification data, and a <em>receiver</em>, storing the created resource. We also have the role of a <em>consumer</em>, which reads the notification data and repurposes it in some way. A software implementation can of course play two or all three of these roles; the important part is that it need not. A consuming application can read and use notification data without being concerned about ever sending or storing notifications.</p> </div> </section> <section resource='#reusable-notifications' rel='schema:hasPart' inlist='' id='reusable-notifications'> <h3 property='schema:name'>R2 Reusable notifications</h3> <div typeof='dio:DesignRequirement' resource='#design-intent' rel='dio:addressedBy' property='schema:description' datatype='rdf:HTML' about='#reusable-notifications'> <p>The relationship between the <em>consumer</em> and <em>receiver</em> roles is key to notifications being reusable. A consumer must be able to autonomously find the location of notifications for or about the particular resource it is interested in. To achieve this we place a requirement on the receiver to expose notifications it has been sent in such away to permit other applications to access them; and specify how any resource can advertise its receiving endpoint for consumers to discover. To promote fair use or remixing of notification contents, applications can incorporate rights and licensing information into the data. Similarly, applications may include additional information on licensing resources that the notification refers to. The presence of this type of information is important for consumers to assess the (re)usability of data.</p> </div> </section> <section resource='#persistence-and-retrievability' rel='schema:hasPart' inlist='' id='persistence-and-retrievability'> <h3 property='schema:name'>R3 Persistence and Retrievability</h3> <div typeof='dio:DesignRequirement' resource='#design-intent' rel='dio:addressedBy' property='schema:description' datatype='rdf:HTML' about='#persistence-and-retrievability'> <meta resource='#design-intent-best-practices' rel='dio:addressedBy'></meta> <meta resource='#design-issue-optimising-implementation' rel='dio:identifies'></meta> <p>There is a social expectation and technical arguments for ensuring the persistence of identifiers of Web resources [<a href='#ref-11' class='ref'>11</a>]. This is inconsistent with the traditionally ephemeral nature of notifications. Applications may benefit from referring to or reusing notifications if the notifications are known to be available in the long term, or indicate their expected lifespan [<a href='#ref-12' class='ref'>12</a><!-- , <a href="https://www.w3.org/TR/dwbp/#UniqueIdentifiers" title="Best Practice 9: Use persistent URIs as identifiers of datasets"></a>, <a href="https://tools.ietf.org/html/rfc7089"></a>-->].</p> <p>A <em>RESTful architecture</em> [<a href='#ref-13' class='ref'>13</a>] is well suited for persistent notifications, as it involves organisation of atomic resources, their discovery and description, and a lightweight API for the <abbr title='create, read, update, and delete'>CRUD</abbr> (create, read, update, and delete) operations [<a href='#ref-14' class='ref'>14</a>]. This enforces the notion that notifications are considered resources in their own right, with their own dereferencable URIs.</p> <p>We need to consider both the needs of software systems and humans when large amounts of notification data are being generated and shared between diverse applications which may be operating without knowledge of each other. To organise and manage large amount of notifications over time, mechanisms should be in place to break representations of collections of notifications into multiple paged responses that may be easier to consume by applications.</p> <p>Relatedly, receivers may carry out resource management or garbage collection, or permit consumers or other applications to do so. For example, an application to consume messages might let an authenticated and authorised user ‘mark as read’ by adding a triple to the notification contents.</p> </div> </section> <section resource='#adaptability' rel='schema:hasPart' inlist='' id='adaptability'> <h3 property='schema:name'>R4 Adaptability</h3> <div typeof='dio:DesignRequirement' property='schema:description' datatype='rdf:HTML' about='#adaptability'> <meta resource='#design-intent-linked-data' rel='dio:addressedBy'></meta> <meta resource='#design-issue-data-formats' rel='dio:identifies'></meta> <p>Linked Data applications benefit from domain-driven designs; that is, functionality being small and focussed on a particular purpose, rather than generic. We believe a notification protocol should be adaptable for different domains, but that there is no need to create multiple domain-specific notification protocols; the fundamental mechanics are the same.</p> <p typeof='dio:DesignRequirement' resource='#adaptability' rel='dio:refines' property='schema:description' datatype='rdf:HTML' about='#target-representation' id='target-representation'><strong>R4-A</strong>: Any resource may be the <em>target</em> of a notification. By target, we mean a notification may be addressed <em>to</em> the resource, be <em>about</em> the resource, or for a sender to otherwise decide that it is appropriate to draw the attention of the resource (or resource owner) to the information in the notification body. As such, any Web resource must be able to advertise an endpoint to which it can receive notifications. Resources can be RDF or non-RDF (such as an image, or CSV dataset), and may be informational (a blog post, a user profile) or non-informational (a person).</p> <p typeof='dio:DesignRequirement' resource='#adaptability' rel='dio:refines' property='schema:description' datatype='rdf:HTML' about='#notification-body' id='notification-body'><strong>R4-B</strong>: We do not purport to be able to design a notifications ontology which is appropriate for every domain. Thus we consider the <em>contents</em> of a notification to be application specific. From a sender’s perspective, we derive two core principles: a notification can contain <em>any data</em>; a notification can use <em>any vocabulary</em>. From a consumer’s perspective, interoperability between different applications occurs through vocabulary reuse, and shared understanding of terms. This is in accordance with Linked Data principles in general. The practical upshot of this is that a calendar application which consumes event invitations using the <cite><a href='https://www.w3.org/TR/rdfcal/'>RDF Calendar</a></cite> vocabulary is likely to completely ignore notifications containing the <cite><a href='https://www.w3.org/TR/prov-o/'>PROV Ontology</a></cite>, even if it finds them all stored in the same place. For two independent applications operating in the <em>same</em> domain, a shared understanding of appropriate vocabulary terms is assumed.</p> <div typeof='dio:DesignRequirement' resource='#adaptability' rel='dio:refines' property='schema:description' datatype='rdf:HTML' about='#notification-verification' id='notification-verification'> <p>However from a receiver’s perspective, exposing itself to receive any blobs of RDF data from unknown senders may be problematic. Thus, <strong>R4-C</strong>: it should be possible for the receiver to enforce restrictions and accept only notifications that are acceptable according to its own criteria (deemed by e.g., user configuration; domain-specific receivers). This can be used as an anti-spam measure, a security protection, or for attaining application and data integrity.</p> <p>Rejecting notifications which do not match a specific pattern in their contents, or the <em>shape</em> of the data, is one way to filter. For example, if the Inbox owner knows that they will only ever use a consuming application which processes friend requests, they can configure their receiver to filter out anything that does not match the pattern for a friend request, helping their consumer to be more efficient. If the notification constraints are also advertised by the receiving service as structured descriptions, generation and consumption of the notifications can be further automated. Possible specifications for doing so are W3C <cite><a href='https://www.w3.org/TR/shacl/'>Shapes Constraint Language (SHACL)</a></cite> [<a href='#ref-15' class='ref'>15</a>] or <cite><a href='https://shexspec.github.io/spec/'>ShEx</a></cite>.</p> <p>Receivers may wish to filter notifications by verifying the sender, through for example a whitelist or a Web of trust. This requires an authentication mechanism and since different authentication mechanisms are appropriate for different applications, the notification protocol should ideally be usable alongside various methods such as clientside certificates, e.g., WebID+TLS, token-based, e.g., OAuth 2.0, or digital signatures.</p> <p>As <q>anyone can say anything about anything</q> a receiver may choose to resolve any external resources referred to by the notification, and cross-check the notification contents against authoritative sources. This is similar to how Semantic Pingback and Webmention require fetching and parsing of the source URL to verify existence of the target link.</p> </div> </div> </section> <section resource='#subscribing' rel='schema:hasPart' inlist='' id='subscribing'> <h3 property='schema:name'>R5 Subscribing</h3> <div typeof='dio:DesignRequirement' resource='#design-intent' rel='dio:addressedBy' property='schema:description' datatype='rdf:HTML' about='#subscribing'> <p>In general, applications may require that new notifications are pushed to them in real-time, or to request them at appropriate intervals. To take this into account, we expand our definition of senders, receivers and consumers with the following interaction expectations: notifications are <em>pushed</em> from senders to receivers; and <em>pulled</em> from receivers by consumers.</p> <p>Thus, an application which offers an endpoint or callback URL to which notifications should be sent directly is a receiver, and an application which fetches notifications from an endpoint on its own schedule is a consumer. Much of the related work <em>requires</em> notifications to be explicitly solicited to trigger sending. Since in a decentralised model, receivers may not be aware of possible sources for notifications, our sender-receiver relationship depends on the sender’s autonomy to make such decisions by itself. This does not preclude the scenario in which a receiver may wish to solicit notifications from a particular sender, but as there are already subscription mechanisms in wide use on the Web, we do not need to specify it as part of LDN. For example, <cite><a href='https://www.w3.org/TR/websub/'>WebSub</a></cite> (recent W3C evolution of PubSubHubbub), the <cite>WebSocket Protocol</cite>, or <cite>HTTP Web Push</cite>.</p> </div> </section> <p>Given our adoption of Linked Data principles and a RESTful architecture, a further design decision was to ensure minimal compatibility with the <cite><a href='https://www.w3.org/TR/ldp/'>Linked Data Platform</a></cite> (LDP) specification [<a href='#ref-16' class='ref'>16</a>]. LDP is a RESTful read-write API for RDF resources, which groups related resources together into constructs known as <q>Containers</q>. Thus, existing LDP servers can be used to store notifications, as new notifications can be created by <code>POST</code>ing RDF to a container.</p>

Ruben Verborgh

• Person

Ruben Verborgh replied on 2016-12-27 09:37:52

<div typeof='oa:TextualBody' resource='#note-20161227093752' property='rdf:value' datatype='rdf:HTML'> <p>This document presents Linked Data Notifications, a protocol for the exchange of interoperable messages between different applications. The work by itself is highly relevant and a crucial building block for decentralized applications on the Web. What I’m missing in this document (but this is fixable) is a clearer need and urgency from the beginning, perhaps more strongly tied to use cases. Its description makes LDN feel too much as “nice to have” rather than “crucial”, even though the requirements section makes some points clear (but not their urgency nor relation to use cases). Both in the discussion of related work and in the evaluation, I’d like to see a deeper understanding of current limitations, and how LDN addresses is and at what cost. More specifically, what are the problems of LDN, and are they inherent or fixable? In general, several conclusions are left open to the reader; the text can be more explicit about what is good and bad; paragraphs can be written in a more purpose-driven way such that it is always clear where the text is are going and what point it aims to make.</p> <h4>Abstract</h4> <ul> <li>It is confusing that the first sentence talks about “Linked Data Notifications”, and the second continues with “Notifications”—even though they are talking about different things. Therefore, some might read this as “The information contained within a [Linked Data] notification is structured arbitrarily”, which is of course not true. Perhaps move the first sentence to a later point?</li> <li>The problem and its urgency are insufficiently clear. Currently, it is written as a couple of <em>nice to haves</em>, such as “more freedom”, “greater value”. Why is it a problem that notifications are only usable by those who generate it? The reader still needs to connect the dots, whereas I expect the text to do this explicitly.</li> </ul> <h4>Introduction</h4> <ul> <li>The opposition of decentralized and centralized systems is not fully accurate. The current explanation is that notifications in decentralized systems can be a key element, but that they are arbitrarily structured in centralized systems. However, it is the other way round: current systems currently structure messages arbitrarily, because they are the only consumers of these messages. If we want to decentralize this, the messages need to have a similar structure. So structure is an additional requirement of decentralization, and I would suggest to write it down as such. (Additionally, I’m not sure about “typically only usable by the application that generated it”: why would systems consume their own notifications? Aren’t these for humans anyway?)</li> <li>As in the abstract, I think that the need is not sufficiently clear. What scenarios do you want to enable that are difficult or impossible today? One paragraph mentions use cases, but it comes quite late and feels more as a list of examples rather than motivating use cases. Furthermore, the current problems in those use cases are not listed.</li> <li>Several technical decisions are mentioned, but their reasons are not. Why was the mentioned key architectural decision taken? I’d say that, in the introduction, the rationale is far more important than the decisions.</li> <li>The list of definitions at the end doesn’t seem to come at the right place. The term “Inbox” has been used previously. The definition of a notification as a “retrievable resource which returns RDF” is incompatible with the resource/representation notions of HTTP. I would suggest to define a notification independently of RDF. You can say the resource has RDF representations, but a resource doesn’t “return” anything.</li> </ul> <h4>Related Work</h4> <ul> <li>I’m missing the overall notion here of how notifications conceptually work, as we dive straight into the details. Perhaps a figure would be helpful here.</li> <li>Crucially, I’m missing a discussion of the limitations of existing approaches. Why are some of the things you list, like “no way to distinguish between multiple potential mentions” an actual problem?</li> <li>Should there be some common use cases of notifications here?</li> </ul> <h4>Requirements and Design Considerations</h4> <ul> <li>In general, clear and insightful. It could become even stronger if supported by guiding use cases in the preceding sections.</li> <li>(Minor) The implied link between REST and lightweight API/CRUD is not technically correct.</li> <li>For R4, sketching use cases above in more detail might be helpful.</li> <li>R4-B can maybe zoom into partial/layered understanding thanks to Linked Data; I think this is crucial for intelligent systems. For instance, a receiver might say “you received a calendar appointment”, whereas a more specialized receiver says “you have a meeting with X and Y”.</li> <li>(Minor) I’d place R4-C at the start of a paragraph, like the others, for scanability.</li> </ul> <h4>The LDN Protocol</h4> <ul> <li>It seems strange that “the sender chooses a target resource to send notifications to”. It seems to me this would either be given by the notification, or through a subscription mechanism. The sender probably doesn’t have a lot of “choice” in this.</li> <li>Is JSON-LD a hard requirement? Can’t clients and servers agree at runtime about the serialization?</li> <li>In general, nice resource-oriented design of the protocol.</li> <li>A comparison table between LDN and the other protocols mentioned in Related Work could be insightful.</li> </ul> <h4>Implementations</h4> <ul> <li>The videos clarify a lot. Maybe they even can come earlier as motivating examples. I would suggest to perhaps create a use case section for this early on.</li> <li>The examples about the specialised senders are very exciting. Checking consistency isn’t something I had initially thought of with notifications, maybe it is good to emphasize such uses as well, which clearly go beyond traditional applications. I’m also seeing a link here with things such as GitHub and continuous integration.</li> </ul> <h4>Analysis and Evaluation</h4> <ul> <li>This section appears to be a verification rather than an evaluation. Given the scope of the document, a qualitative evaluation would indeed be a possibility. For instance, an insightful comparison of the shortcomings of existing systems and the benefits of the proposed system, followed by a discussion of the trade-offs that were necessary to realize those benefits.</li> <li>On a similar note, it is unclear what each of the sections exactly evaluates. “Comparison summary”: what is the result of the evaluation here? “Compatibility with existing systems”: this is perhaps the clearest, but the conclusion about compatibility is implicit. “Optimizing implementation[s]”, “Data Formats and Content Negotiation”: what is evaluated? “Accommodating different targets”: how well is LDN doing compared to the others?</li> <li>It seems that the linked test suite is still incomplete: its “use these tests” section if relatively empty. As such, it us unclear how it can be “[used] towards an evaluation of its feasibility”.</li> <li>I don’t find the comparison summary too insightful. I’m not sure what I’m supposed to see in the table. What is good and bad? What is important, what is desirable? I would suggest to highlight the problems and assets somewhat more clearly.</li> <li>The purpose of the section “Optimising implementation[s]” is unclear to me. The statements that “HEAD requests are low cost” and “GET requests may be high cost” is underspecified; what is a cost and for whom? You just seem to be talking about bandwidth here, which is not the only cost.</li> <li>The decisions regarding content negotiation are appropriate and future-proof.</li> </ul> <h4>Conclusions</h4> <ul> <li>Not too many conclusions here, unfortunately; only a summary. What are the lessons learned? What would you do differently next time? How do your findings generalize to to other domains? What impact can this have (this is minimally stated) and why? What is needed/still needs to be done to have such an impact?</li> </ul> <h4>Other remarks</h4> <ul> <li>There seem to be additional fields at the bottom (author, published) that are not relevant here.</li> <li>This is subjective, but I find the reposted/liked/… stream at the bottom hard to follow. Given the central importance of such social interactions to the topic, it might be worthwhile to simplify their presentation.</li> </ul> </div>

• Annotation
• Note

Sarven Capadisli

• Person

Sarven Capadisli replied on 2016-12-19 12:54:30

<div typeof='oa:TextualBody' resource='#note-20161219125430' property='rdf:value' datatype='rdf:HTML'> <figure resource='https://csarven.ca/media/images/articles/graph-linked-data-notifications.png' rel='schema:hasPart'> <a href='https://csarven.ca/media/images/articles/graph-linked-data-notifications.png' resource='https://csarven.ca/linked-data-notifications' rel='foaf:depicts'> <img width='100%' alt='Graph view of the Linked Data Notifications article' src='https://csarven.ca/media/images/articles/graph-linked-data-notifications.png'></img> </a> <figcaption property='schema:name'>Graph view of the Linked Data Notifications article generated using <a href='http://franz.com/agraph/gruff/'>Gruff</a>.</figcaption> </figure> <p>This image will be updated from time to time to include the changes, e.g., social interactions, on this resource.</p> </div>

• Annotation
• Note

Sarven Capadisli replied on 2017-02-06 13:06:44

<div typeof='oa:TextualBody' resource='#note-20170206130644' property='rdf:value' datatype='rdf:HTML'> <p>Once fetched by a 3rd-party, any piece of information could potentially be subject to privacy. Hence, this is orthogonal to whether the notifications are ephemeral or persistent. In R4-C, we briefly touch on various authentication methods which could be used alongside LDN with the idea that notifications are not necessarily public but only visible or reusable by intended parties. The receivers decide (based on their use case) which consumers (based on any criteria) can reuse. They achieve this by setting authentication and authorization settings on the notifications.</p> </div>

• Annotation
• Note

Sarven Capadisli replied on 2017-02-06 13:07:33

<div typeof='oa:TextualBody' resource='#note-20170206130733' property='rdf:value' datatype='rdf:HTML'> <p>We agree that this is an important metric to have for conforming applications. We have highlighted as one of the requirements of the design (R3), e.g., anticipating the possibility of multi-page responses, but the LDN specification leaves this to other, existing standards. However, we do not currently have such data from conforming applications.</p> </div>

• Annotation
• Note

Sarven Capadisli replied on 2017-02-06 13:14:54

<div typeof='oa:TextualBody' resource='#note-20170206131454' property='rdf:value' datatype='rdf:HTML'> <p>In the Introduction section we mention the possibility of decoupling application logic from storage, and thus <q>freeing end users to switch between applications, or to let multiple applications operate over the same data</q>. Also <q>to support sharing and reuse of notifications across applications, regardless of how they were generated or what their contents are.</q></p> <p>As per the LDN specification, the consumer is required to go through each of the steps in order because for instance the Inbox URL may change, and the only way for the consumer to be aware of this is to start the discovery process from the target. We can phrase this more clearly. Naturally, applications can still do what they prefer, however such behaviour is outside LDN’s scope.</p> <p>In the revision of your review, could you please point out more specifically in what way Section 4.2 is appearing less detailed and less rigorous than 4.1? We believe that both sections have equal specificity since they describe the required steps.</p> <p>We are going to clarify the fact that the ones that are tested only reflect the implementations which came forward to the W3C standardisation process, and as documented in the W3C GitHub repository. In the article, we had already linked to the source.</p> <p>One conclusion that we are going to emphasise more explicitly is what’s stated in Section 6 “Analysis and Evaluation”, i.e. that the fast adoption of the LDN specification proves its feasibility. For future work, we would need inspect how related specifications e.g., paging, authentication/authorization, are used alongside LDN.</p> </div>

• Annotation
• Note

Sarven Capadisli replied on 2017-02-06 13:15:36

<div typeof='oa:TextualBody' resource='#note-20170206131536' property='rdf:value' datatype='rdf:HTML'> <p>Given that each application requires to follow the steps listed in Sections 4.1 “Sender to receiver interaction” and Section 4.2 “Consumer to receiver interactions” the metrics are dependent on the performance of client and server to do HTTP requests/responses, and their respective payloads. We will point this out more clearly.</p> <p>How applications should advertise or consume notifications is use-case dependent. Therefore, it is difficult to justify if/how for example an “outdated notification” should or not, and how much of it be exposed. It would be premature to make generalisations from this.</p> </div>

• Annotation
• Note

Sender to receiver interactions

<p>The following steps (in order without skipping) describe the interaction between sender and receiver:</p> <p>(1) A sender is triggered, either by a human or an automatic process, to deliver a notification; (2) The sender chooses a target resource to send notifications to; (3) The sender discovers the location of the target’s <em>Inbox</em> through the <code>ldp:inbox</code> relation in the HTTP <code>Link</code> header or RDF body of the target resource; (4) The sender creates the body of the notification according to the needs of application; (5) The sender makes a <code>POST</code> to the Inbox URL, containing the body in JSON-LD or in another serialisation acceptable by the server; (6) The receiver optionally applies filtering rules, and sends the appropriate HTTP response code to accept or reject the notification; (7) The receiver exposes the notification data (according to appropriate access control) for use by consumers.</p>

solution-data-formats-content-negotiation

solution-data-formats-json-ld

solution-optimising-implementation-get-head-link

Sören Auer

• Person

target-representation

<strong>R4-A</strong>: Any resource may be the <em>target</em> of a notification. By target, we mean a notification may be addressed <em>to</em> the resource, be <em>about</em> the resource, or for a sender to otherwise decide that it is appropriate to draw the attention of the resource (or resource owner) to the information in the notification body. As such, any Web resource must be able to advertise an endpoint to which it can receive notifications. Resources can be RDF or non-RDF (such as an image, or CSV dataset), and may be informational (a blog post, a user profile) or non-informational (a person).

• DesignRequirement

The LDN Protocol

<p>The <dfn id='ldn'>Linked Data Notifications (<abbr title='Linked Data Notifications'>LDN</abbr>)</dfn> protocol describes how servers (receivers) can receive messages pushed to them by applications (senders), as well as how other applications (consumers) may retrieve those messages. Any resource can advertise a receiving endpoint (Inbox) for notification messages. Messages are expressed in RDF, and can contain arbitrary data. It is not dependent on a complete implementation of LDP, but comprises an easy-to-implement subset. LDN is a <cite><a href='https://www.w3.org/TR/ldn'>W3C Candidate Recommendation</a></cite> [<a href='#ref-4' class='ref'>4</a>].</p> <figure resource='#figure-linked-data-notifications-overview' rel='schema:hasPart' inlist='' id='figure-linked-data-notifications-overview'> <object width='640' type='image/svg+xml' rel='schema:image' height='305' data='https://www.w3.org/TR/ldn/linked-data-notifications-overview.svg'>Overview diagram of Linked Data Notifications showing the Sender, Receiver, Consumer roles and their interactions with Target, Inbox, and Notification resources.</object> <figcaption property='schema:name'>Overview of Linked Data Notifications</figcaption> </figure> <section resource='#sender-to-receiver' rel='schema:hasPart' inlist='' id='sender-to-receiver'> <h3 property='schema:name'>Sender to receiver interactions</h3> <div property='schema:description' datatype='rdf:HTML'> <p>The following steps (in order without skipping) describe the interaction between sender and receiver:</p> <p>(1) A sender is triggered, either by a human or an automatic process, to deliver a notification; (2) The sender chooses a target resource to send notifications to; (3) The sender discovers the location of the target’s <em>Inbox</em> through the <code>ldp:inbox</code> relation in the HTTP <code>Link</code> header or RDF body of the target resource; (4) The sender creates the body of the notification according to the needs of application; (5) The sender makes a <code>POST</code> to the Inbox URL, containing the body in JSON-LD or in another serialisation acceptable by the server; (6) The receiver optionally applies filtering rules, and sends the appropriate HTTP response code to accept or reject the notification; (7) The receiver exposes the notification data (according to appropriate access control) for use by consumers.</p> </div> </section> <section resource='#consumer-to-receiver' rel='schema:hasPart' inlist='' id='consumer-to-receiver'> <h3 property='schema:name'>Consumer to receiver interactions</h3> <div property='schema:description' datatype='rdf:HTML'> <p>The following steps (in order without skipping) describe the interaction between consumer and receiver:</p> <p>(1) A consumer selects a target and discovers the location of its Inbox in the same way as the sender; (2) A receiver responds to <code>GET</code> requests made to the Inbox URL with a listing of the URLs of notifications that have previously been accepted, linked to the Inbox with the <code>ldp:contains</code> predicate; <span resource='#persistence-and-retrievability' rel='dio:fulfillsRequirement' about='#protocol'>(3) The receiver responds to <code>GET</code> requests made to the individual notification URLs with JSON-LD (or optionally other serialisations);</span> <span resource='#reusable-notifications' rel='dio:fulfillsRequirement' about='#protocol'>(4) Following the retrieval of notification listings or individual notifications, the consumer may perform further processing, combine with some other data, or simply present the results in a suitable human-readable way.</span></p> </div> </section> <section resource='#example-notifications' rel='schema:hasPart' inlist='' id='example-notifications'> <h3 property='schema:name'>Example Notifications</h3> <div property='schema:description' datatype='rdf:HTML'> <p>For more example notification payloads, see the <a href='https://www.w3.org/TR/ldn/'>LDN specification</a>.</p> <figure resource='#sending-notification-request' rel='schema:hasPart' inlist='' id='sending-notification-request' class='listing'> <pre typeof='fabio:Script' property='schema:description' about='#sending-notification-request'><code>{</code><code> "@context": { "sioc": "http://rdfs.org/sioc/ns#" }</code><code> "@id": "",</code><code> "@type": "sioc:Comment",</code><code> "sioc:content": "This is a great article!",</code><code> "as:inReplyTo": { "@id": "http://example.org/article" },</code><code> "sioc:created_at": { "@value": "2015-12-23T16:44:21Z" }</code><code>}</code></pre> <figcaption property='schema:name'>A notification about a comment created by a user (JSON-LD).</figcaption> </figure> <figure resource='#notification-qualified-relation' rel='schema:hasPart' inlist='' id='notification-qualified-relation' class='listing'> <pre typeof='fabio:Script' property='schema:description' about='#notification-qualified-relation'><code>@prefix as: &lt;https://www.w3.org/ns/activitystreams#&gt; .</code><code>@prefix cito: &lt;http://purl.org/spar/cito/&gt; .</code><code>&lt;&gt; a as:Announce</code><code> as:object &lt;https://linkedresearch.org/resources#r-903b83&gt; ;</code><code> as:target &lt;https://csarven.ca/dokieli#architecture&gt; .</code><code>&lt;https://linkedresearch.org/resources#r-903b83&gt;</code><code> cito:citesAsPotentialReading</code><code> &lt;https://csarven.ca/linked-data-notifications#protocol&gt; .</code></pre> <figcaption property='schema:name'>An announcement of a specific citation relation between two entities (Turtle).</figcaption> </figure> </div> </section>

• Contribution
• Design

Tim Berners-Lee

• Person

Tobias Käfer

• Person

Tobias Käfer replied on 2017-06-02 16:21:44

<div typeof='oa:TextualBody' resource='#note-20170602162144' property='rdf:value' datatype='rdf:HTML'> <p>Re: our ESWC discussion</p> <p>Just out of curiosity, how do you know that an inbox is empty under the Open World Assumption?</p> </div>

• Annotation
• Note

University of Bonn

• Organization

University of Edinburgh

• Organization

Video of dokieli Share

Video of dokieli Web Annotation

Video of semantic inline citations

video-dokieli-annotation

• Film

video-dokieli-citation

• Film

video-dokieli-share

• Film