<p id="vrttt"><del id="vrttt"></del></p>

    <ruby id="vrttt"><b id="vrttt"></b></ruby>
    <p id="vrttt"><cite id="vrttt"></cite></p>
    <pre id="vrttt"></pre><ruby id="vrttt"></ruby>

    <ruby id="vrttt"></ruby>


    ResourceSync Framework Specification - Change Notification

    20 July 2017

    This version:
    Latest version:
    Previous version:
    Martin Klein, Herbert Van de Sompel - Los Alamos National Laboratory
    Simeon Warner - Cornell University
    Graham Klyne - University of Oxford
    Bernhard Haslhofer - University of Vienna
    Michael Nelson - Old Dominion University
    Carl Lagoze - University of Michigan
    Robert Sanderson - The Getty


    The ResourceSync core specification introduces a pull-based synchronization framework for the web that consists of various capabilities that a Source can implement to allow Destinations to remain synchronized with its evolving resources. This ResourceSync Change Notification specification describes an additional, push-based, capability that a Source can support. It is aimed at reducing synchronization latency and entails a Source sending notifications to subscribing Destinations.

    Status of this Document

    This specification is one of several documents comprising the ResourceSync Framework Specifications. Feedback is most welcome on the ResourceSync Google Group.

    Table of Contents

    1. Introduction
        1.1 Motivating Example
        1.2 Notational Conventions
    2. Change Notification Channels
    3. Change Notification
    4. Transport Protocol: WebSub
        4.1 Source Submits Notifications to Hub
        4.2 Destination Subscribes to Hub to Receive Notifications
        4.3 Dub Delivers Notifications to Destination
        4.4 Destination Unsubscribes from Hub
    5. Advertising Change Notification Channels
    6. References


    A. Acknowledgements
    B. Change Log

    1. Introduction

    This specification describes a Change Notification capability defined for the ResourceSync framework. The push-based notification capability is aimed at decreasing the synchronization latency between a Source and a Destination that is inherent in the pull-based capabilities defined in the ResourceSync core specification. The Change Notification capability consists of a Source sending notifications about changes to its resources, for example the creation or deletion of a resource. Another specification describes a Framework Notification capability that consists of a Source sending out notifications about changes to its implementation of the ResourceSync framework, for example the publication of a new Resource List or the updating of a Change List.

    1.1. Motivating Example

    Applications based on Linked Data integrate resources from various datasets, with resources likely changing at a different pace. The BBC Linked Data applications that integrate data from, among others, Last.FM, DBpedia, MusicBrainz, and GeoNames serve as examples. The accuracy of services based on such an integrated resource collection depends on the contributing resources being up-to-date. The update frequency of LiveDBPedia resources, for example, has been observed to average around two changes per second. This provides a significant synchronization challenge that the Change Notification capability aims to address.

    1.2. Definitions and Namespace Prefix Bindings

    This specification uses the terms "resource", "representation", "request", "response", "content negotiation", "client", and "server" as described in Architecture of the World Wide Web.

    Throughout this document, the following namespace prefix bindings are used:

    PrefixNamespace URIDescription
    nonehttp://www.sitemaps.org/schemas/sitemap/0.9 Sitemap XML elements defined in the Sitemap protocol
    rshttp://www.k1q4ktil.top/rs/terms/ Namespace for elements and attributes introduced in this specification

    Table 1: Namespace prefix bindings used in this document

    2. Change Notification Channels

    Change Notifications are sent to inform Destinations about resource change events, specifically, when a Source's resource that is subject to synchronization was created, updated, or deleted. The payload for these notifications is described in Section 3. Notifications are sent from Source to Destination on one or more channels provided by a push technology discussed in Section 4.

    Figure 1 displays the structure of the ResourceSync framework for a Source that has a single set of resources, showing the Source Description and the Capability List at the top. The Capability List advertises four distinct capabilities: a Resource List, a Change List, a Resource Dump, and a Change Dump. The figure also shows a Change Notification channel (yellow hexagon) and indicates it is used to send information about resource changes for a specific set of resources. Changes to these resources are communicated as change notifications via the Change Notification channel.

    A Change Notification channel

    Figure 1: A Change Notification channel in the ResourceSync framework structure

    The ResourceSync framework allows a Source to offer multiple sets of resources in which case the Source Description points to multiple Capability Lists, one for each set of resources. In this case, a dedicated Change Notification channel must be provided for each distinct set of resources for which Change Notification is supported. A notification about a change to a resource is sent via the Change Notification channel that is associated with the set of resources under which the resource resides. If a resource resides under multiple sets of resources, a notification is sent on each of the Change Notification channels associated with those sets of resources. Change Notifications must be sent on different channels.

    Figure 2 depicts a scenario where a Source offers multiple sets of resources and its Source Description therefore points to multiple Capability Lists, one for each set of resources, in this case Capability List 1 and Capability List 2. Figure 2 shows that each set of resources has a designated Change Notification channel. Change Notification Channel 1, for example, is used to send change notifications about changes to resources that are part of the set of resources covered by Capability List 1.

    Note that the creation and deletion of Change Notification channels is reflected in updated Capability Lists (see Section 5). This specification does not define a separate notification about notification channels.

    Change Notification channels for multiple Capability Lists

    Figure 2: Change Notification channels for multiple sets of resources

    3. Change Notification

    A change notification is sent on the appropriate Change Notification channel, as described in Section 2, if a Source wishes to notify a Destination that one or more of its resources subject to synchronization have changed. By subscribing to a Change Notification channel, a Destination can reduce synchronization latency and avoid periodically polling the Source's Change Lists - if they exist - to determine whether resource changes have occurred.

    The format of a change notification is very similar to the Change List format introduced in Section 12 of the core specification. All entries in a change notification must be provided in forward chronological order: the resource with the least recent change datetime must be listed at the beginning of the change notification payload, while the resource with the most recent change datetime must be listed at the end. The format is based on the <urlset> document format introduced by the Sitemap protocol. It has the <urlset> root element and the following structure:

    Change notifications do not use the <sitemapindex> document format introduced by the Sitemap protocol. In the event that there are a very large number of simultaneous changes at a Source, the notifications must be split into a sequence of change notifications using <urlset> documents.

    Example 1 shows the payload of a change notification containing the description of changes to two resources.

    <?xml version="1.0" encoding="UTF-8"?>
    <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
      <rs:ln rel="up"
      <rs:md capability="change-notification"
          <rs:md change="created"
          <rs:md change="updated"

    Example 1: The payload of a change notification

    4. Transport Protocol: WebSub

    In order to bootstrap the notification capabilities of the ResourceSync framework, a single transport protocol is chosen: WebSub. WebSub is a simple, HTTP-based publish/subscribe protocol that is expected to perform well for use cases that do not require change notifications to be sent at a very high frequency.

    The below description of the use of WebSub for Change Notifications is essentially the same as the description of its use for Framework Notifications. However, in the interest of self-containdeness of the respective specifications, and because Change Notifications and Framework Notifications must be sent on different channels, the description is repeated in both specifications.

    Table 2 maps terminology used in ResourceSync and WebSub. In order to implement the publish/subscribe paradigm, WebSub introduces a hub that acts as a conduit between Source and Destination. A hub can be operated by the Source itself or by a third party. It is uniquely identified by the hub URI. WebSub's topic corresponds with the notion of channel used in this specification. A topic is uniquely identified by its topic URI. Hence, per set of resources, the Source has a dedicated topic (and hence topic URI) for change notifications.

    Source Publisher
    Destination Subscriber
    Channel Topic
    Notification Notification

    Table 2: Mapping of terminologies between ResourceSync and WebSub

    The remainder of this section describes the use of WebSub in ResourceSync. It only provides the information about the WebSub protocol that is essential to gain an adequate understanding of the overall mechanism. Details about the WebSub protocol are available in the WebSub specification. Figure 3 shows an overview of HTTP interactions between Source, Hub, and Destination. They will be detailed in the remainder of this section.

    HTTP interactions between Source, Hub, and Destination

    Figure 3: HTTP interactions between Source, Hub, and Destination

    4.1. Source Submits Notifications to Hub

    The WebSub protocol provides no specific guidelines regarding the way in which a Source should communicate notifications to a hub. The mechanism for ResourceSync change notifications is as follows:

    Example 2 shows the HTTP POST issued by the Source against its hub to submit the change notification payload of Example 1. For brevity, the payload is not shown in its entirety. The third party hub URI is http://hub.example.org/websub/ and the Source's topic URI (channel) for change notifications pertaining to dataset1 is http://example.com/dataset1/change/.

    POST /websub/ HTTP/1.1
    Host: http://hub.example.org
    Content-Type: application/xml
    Link: <http://example.com/dataset1/change/> ; rel="self",
     <http://hub.example.org/websub/> ; rel="hub",
     <http://www.example.com/dataset1/capabilitylist.xml> ; rel="resourcesync"
    Content-Length: 849
    <?xml version="1.0" encoding="UTF-8"?>
    <urlset ...

    Example 2: The HTTP POST used by a Source to submit a change notification payload to its hub

    4.2. Destination Subscribes to Hub to Receive Notifications

    A Destination subscribes to a Source's topic using the process described in the section "Subscribing and Unsubscribing" of WebSub. The process consists of mandatory subscription request and subscription verification phases:

    Example 3 shows the HTTP POST issued by a Destination against the hub URI http://hub.example.org/websub/ requesting a subscription to the Source's topic URI (channel) http://example.com/dataset1/change/ as a means to receive change notifications pertaining to dataset1 at its callback URI http://destination.example.net/callback/.

    POST /websub/ HTTP/1.1
    Host: http://hub.example.org
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 141

    Example 3: A Destination's request to a hub to subscribe to a Source's notification channel

    Example 4 shows the HTTP GET issued by the hub against the Destination's callback URI to verify that it was the Destination's intent to subscribe.

    GET /callback/?hub.mode=subscribe&hub.topic=http%3A%2F%2FAexample.com%2Fdataset1%2Fchange%2F
    &hub.challenge=c0cc4630-5116-11e3-8f96-0800200c9a66&hub.lease_seconds=2400 HTTP/1.1
    Host: http://destination.example.net
    Connection: Close

    Example 4: A hub's request to verify a Destination's intent to subscribe

    Example 5 shows the response by a Destination to the hub's subscription verification request of Example 4. It indicates that the Destination wants the subscription.

    HTTP/1.1 200 OK
    Date: Tue, 19 Nov 2013 12:42::13 GMT
    Content-Type: text/plain; charset=UTF-8
    Content-Length: 36
    Connection: Close

    Example 5: A hub's request to verify a Destination's intent to subscribe

    4.3. Hub Delivers Notifications to Destination

    When the hub receives a change notification from the Source, it passes it on to the subscribing Destination(s). The process, shown as "Hub notifies Destination" in Figure 3, is as follows:

    Example 6 shows the HTTP POST that the hub issues against the Destination's callback URI to relay the notification it received from the Source in Example 2. For brevity, the payload is not shown in its entirety.

    POST /callback/ HTTP/1.1
    Host: http://destination.example.net
    Content-Type: application/xml
    Link: <http://example.com/dataset1/change/> ; rel="self",
     <http://hub.example.org/websub/> ; rel="hub",
     <http://www.example.com/dataset1/capabilitylist.xml> ; rel="resourcesync"
    Content-Length: 849
    <?xml version="1.0" encoding="UTF-8"?>
    <urlset ...

    Example 6: The HTTP POST used by a hub to submit a Source's change notification payload to a Destination

    4.4. Destination Unsubscribes from Hub

    The mechanism by which a Destination unsubscribes from a Source's topic URI is as described in Section 4.1 but uses unsubscribe as the value of hub.mode instead of subscribe.

    5. Advertising Change Notification Channels

    Change Notification capabilities are advertised via Capability Lists, as is the case with the capabilities defined in the core ResourceSync specification. As each set of resources has its dedicated Change Notification channel, that channel is advertised in the Capability List that corresponds with the respective set of resources.

    Figure 4 displays a Change Notification channel advertised in a Capability List. The figure shows a structure with only one Capability List that advertises its designated Change Notification channel. Other Capability Lists, each of which pertain to a different set of resources, would advertise their respective notification channels. In addition to Change Notifications, the Capability List can advertise other capabilities such as a Resource List and Change List as introduced in the core specification, and archive capabilities as introduced in the archiving specification.

    Change Notification channel discovery

    Figure 4: Change Notification channel discovery

    Example 7 shows the Capability List from Example 13 of the core specification with discovery links for a Change Notification channel added. The WebSub topic URI is provided in the <loc> element, whereas the hub URI is provided using a <rs:ln> child element of <loc>. That <rs:ln> must have hub as the value of the rel attribute and the hub URI as the value of the href attribute. Note the introduction of the change-notification value for the capability attribute to indicate the Change Notification capability.

    <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
       <rs:ln rel="describedby"
       <rs:ln rel="up"
       <rs:md capability="capabilitylist"/>
           <rs:md capability="resourcelist"/>
           <rs:md capability="resourcedump"/>
           <rs:md capability="changelist"/>
           <rs:md capability="changedump"/>
          <rs:ln rel="hub" href="http://hub.example.org/websub/"/>
          <rs:md capability="change-notification"/>

    Example 7: A Capability List with an entry to discover a WebSub change notification channel

    6. References

    Genestoux, Julien and Aaron Parecki, eds. WebSub, W3C Candidate Recommendation, April 11, 2017.
    Sitemaps XML Format. sitemaps.org, last updated February 27, 2008. Available at: http://www.sitemaps.org/protocol.html
    [Web Architecture]
    Jacobs, Ian, and Norman Walsh, eds. Architecture of the World Wide Web, Volume One. W3C Recommendation. World Wide Web Consortium, December 15, 2004. Available at: http://www.w3.org/TR/webarch/

    A. Acknowledgements

    This specification is the collaborative work of NISO and the Open Archives Initiative. Initial funding for ResourceSync was provided by the Alfred P. Sloan Foundation. UK participation was supported by Jisc.

    B. Change Log

    Date Editor Description
    2017-07-20 simeon, martin, herbert Update to use WebSub instead of PubSubHubbub, consistently use change-notification capability value
    2017-01-18 herbert, simeon link to Internet Archive copy of PubSubHubbub, no change to content
    2016-08-10 herbert, martin, simeon version 1.0, removed Framework Notification from the spec, made updates related to Core Framework changes
    2014-03-24 graham, herbert version 0.9, removed ResourceSync-specific requirements from communication between Source and hub
    2013-12-18 herbert, martin, rob, simeon version 0.8.1, using PubSubHubbub
    2013-11-12 martin, herbert, rob, simeon version 0.8, using WebSockets

    Creative Commons License
    This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.