Linked Data Notifications Distributed Update Notification and Propagation on the Web of Data

Linked Data Notifications
Distributed Update Notification and Propagation on the Web of Data
Natanael Arndt
August 29, 2016 (modified September 2, 2016)
AKSW Colloquium

Motivation and Problem
CC-BY-SA: Linking Open Data cloud diagram 2014,
by Max Schmachtenberg, Christian Bizer, Anja Jentzsch and Richard Cyganiak.
http://lod-cloud.net/
• The Web of Data is a highly interlinked Data Cloud
• This enables us to …
• retrieve structured data about things
• discover links among datasets
• answer questions involving multiple datasets
1 / 18

Motivation and Problem
CC-BY-SA: Linking Open Data cloud diagram 2014,
by Max Schmachtenberg, Christian Bizer, Anja Jentzsch and Richard Cyganiak.
http://lod-cloud.net/
• But currently there is no established way for active communication
• This is needed for …
• social interaction:
messages, status update, friending; DSSN)
• subscription to updates of datasets; graph synchronization
• distributed collaboration on structured data
• enterprise use cases, such as distributed supply chain management
2 / 18

Linked Data Notiﬁcations (LDN)

Linked Data Notifications (LDN): W3C Working Draft
• A Working Draft by the W3C Social Web Working Group
• Specialized use of Linked Data Platform (LDP)
• https://www.w3.org/TR/2016/WD-ldn-20160824/ [Capadisli and Guy, 2016]
Linked Data Notifications is a protocol to facilitate exchanging messages
between applications which serve as senders, receivers and/or consumers of
RDF data.
(Sarven Capadisli and Amy Guy: Linked Data Notifications)
3 / 18

Linked Data Notifications (LDN): Introduction
• Decoupling between applications and data storage
• A notification has its own URI which can be retrieved and reused
• The specification does not define the vocabulary of the notification contents
• Authentication and verification of notifications is encouraged
4 / 18

Linked Data Notifications (LDN): Summary
Sender • Creates the notification body
• Sends the notification as POST to the Inbox URL
Consumer • Retrieves the contents of the Inbox URL via GET
Receiver • Responds to GET requests to the Inbox URL
• Accepts POST requests at the Inbox URL to create notifications
• Optionally enforces constraints on notifications
Sender Consumer
Receiver
Inbox
(LDP Container)
POST
GET
5 / 18

Linked Data Notiﬁcations (LDN): Protocol – Discovery
• An Inbox can be discovered from any resource
• The starting point for discovery is the target
• The sender MUST make a request for a ldp:inbox relation
(HEAD-Link and Linked Data)
Sender
Receiver
Inbox
(LDP Container)
HEAD/GET
target
ldp:inbox
ldp:inbox
ldp:inbox
6 / 18

Linked Data Notifications (LDN): Protocol – Sending and Receiving
• Senders MUST deliver notifications in a POST request to the Inbox URL
• The Receiver can delay processing of the notification: 202 Accepted
• Or immediately answer with 201 Created or the appropriate 4xx
• Payload defaults to JSON-LD, but can be negotiated
• “The sender MUST NOT assume that the receiver can fetch or infer anything
additional from the payload, and thus MUST include everything they want the
receiver to know.”
Sender
Receiver
Inbox
(LDP Container)
POST
2xx/4xx
7 / 18

Linked Data Notiﬁcations (LDN): Protocol – Consuming
• The Receiver responds to GET requests on the Inbox URL
• Notiﬁcations must be discoverable through ldp:contains
• Payload defaults to JSON-LD, but can be negotiated
Consumer
Receiver
Inbox
(LDP Container)
GET
ldp:contains
8 / 18

Linked Data Notifications (LDN): Protocol – Security, Privacy and Content
Considerations
• Inbox URLs can announce shape constraints
• consumers may want to take precautions when consuming notifications
• Receivers SHOULD ensure or verify the sender
• whitelist for write access
• require authentication
• retrieve a copy of the notification from the sender’s domain to verify its origin
• checking a digital signature which accompanies the notification
9 / 18

Linked Data Notiﬁcations (LDN): Summary
Sender Consumer
Receiver
Inbox
(LDP Container)
POST
HEAD/GET
target
ldp:inbox
ldp:inbox
ldp:inbox
2xx/4xx
GET
retrieve
(verification)
Original
Comment Resource
10 / 18

Other Approaches
• The DSSN Stack [Tramp et al., 2012] with PubSubHubbub and Semantic
Pingback
• Applications in Structured Feedback [Arndt et al., 2016] and Publish and
Subscribe for RDF in Enterprise Value Networks [Frommhold et al., 2016]
11 / 18

Other Approaches: Publish and Subscribe for RDF in Enterprise Value Net-
works
12 / 18

Other Approaches: Semantic Pingback and Structured Feedback
RPC Layer
Resource Layer
Linking Resource
(Source)
Linked Resource
(Target)(typed) linking
observes
announces
RPC request
autodiscovery
fetches
1
2
3
4
5
(updates)
6
Publisher
Link Reveiver
Pingback Server
Link Publisher
Pingback Client
(Link Propagator)
(notiﬁes)
7
13 / 18

Other Approaches: Semantic Pingback and Structured Feedback
Sender
Subscriber
(aka. Consumer)
Recource Hosting Service
Some Graph
Semantic Pingback
Service
PubSubHubbub
Hub
Comment Container
1. create/store
3. ping/notify
4.
retrieve
(verification)
sioc:container_of
5.
update
6. notify
8. notify
0. subscribes
7. retrieve
GET
2. HEAD/GET
target
pingback:to
• In contrast to LDN the roll of the Receiver is distributed among the Semantic Pingback Service and the PubSubHubbub Hub
• The roll of the Inbox is done by the Comment Container, while it doesn’t necessarily be a LDP, but any Linked Data RDF
• The Actual notiﬁcation resource stays at its origin and doesn’t need to be copied and transfered for the protocol
14 / 18

Discussion
• This Working Draft is a good starting point for active communication on
Linked Data
• A W3C standard can help us to actually use RDF for communication and
create meaningful communication
• Less polling, more pushing
15 / 18

Discussion
• Why using exactly JSON-LD as default and not any other RDF serialization?
• Why do all participants MUST support JSON-LD?
• Why should the payload replicate and contain the complete notiﬁcation
resource and the references information? Why not build links and reference
it?
• “Decoupling between applications and data storage“ (4). Maybe also the tasks
of the services and the diﬀerent kinds of data storages can be decoupled.
• Why restrict the protocol to LDP and not also allow the resources to e. g. be
managed by a SPARQL 1.1 endpoint?
16 / 18

References I
Arndt, N., Junghanns, K., Meissner, R., Frischmuth, P., Radtke, N., Frommhold,
M., and Martin, M. (2016).
Structured feedback: A distributed protocol for feedback and patches
on the web of data.
In Proceedings of the Workshop on Linked Data on the Web co-located with the
25th International World Wide Web Conference (WWW 2016), volume 1593 of
CEUR Workshop Proceedings, Montréal, Canada.
http://ceur-ws.org/Vol-1593/article-02.pdf.
Capadisli, S. and Guy, A. (2016).
Linked data notiﬁcations.
https://www.w3.org/TR/2016/WD-ldn-20160824/.
work in progress.
17 / 18

References II
Frommhold, M., Arndt, N., Tramp, S., and Petersen, N. (2016).
Publish and Subscribe for RDF in Enterprise Value Networks.
In Proceedings of the Workshop on Linked Data on the Web co-located with the
25th International World Wide Web Conference (WWW 2016), CEUR Workshop
Proceedings, Montréal, Canada.
http://ceur-ws.org/Vol-1593/article-09.pdf.
Tramp, S., Frischmuth, P., Ermilov, T., Shekarpour, S., and Auer, S. (2012).
An Architecture of a Distributed Semantic Social Network.
Semantic Web Journal, Special Issue on The Personal and Social Semantic
Web.
http://www.semantic-web-journal.net/sites/default/files/swj201_4.pdf.
18 / 18

Linked Data Notifications Distributed Update Notification and Propagation on the Web of Data

More Related Content

What's hot

Viewers also liked

Similar to Linked Data Notifications Distributed Update Notification and Propagation on the Web of Data

Recently uploaded