Web of Data Link Maintenance Protocol - Maintaining Links Between Changing Linked Data Sources

Protocol Specification

This Version:
http://www4.wiwiss.fu-berlin.de/bizer/silk/wodlmp/20090616/
Latest Version:
http://www4.wiwiss.fu-berlin.de/bizer/silk/wodlmp
Authors:
Julius Volz (Technische Universität Chemnitz, Germany)
Chris Bizer (Freie Universität Berlin, Germany)
Martin Gaedke (Technische Universität Chemnitz, Germany)

 


Abstract

With general-purpose linking toolkits like Silk becoming available for the Web of Data, the question is raised how to keep generated linksets current between continuously changing data sources. This document proposes a link synchronization protocol which covers different use cases of maintaining links between two data sources.

Table of Contents


1. Introduction

This document proposes a simple protocol for the synchronization of links and notification about changes between interlinked data sources. In the patterns used by this protocol, a source dataset generates links pointing to a target dataset. The protocol then allows the transfer of these links to the target, which may choose to include them in its own dataset. Furthermore, to keep links current, the protocol enables the source dataset to stay informed about changes in target resources. This is achieved either by periodical polling of the target or by the source subscribing to a list of resources which should be monitored in the target.


2. Use Cases

Depending on the setting, users might want to use different features of the protocol. The following sections list the common use cases the proposed protocol should support.

In this use case, we want to send a set of generated links to the target dataset so that the target may include them in its own datastore. Furthermore, subsequent updates (i.e. adds/deletes) to the transferred links or a complete deletion of all links saved at the target by the source should be possible.



Note: in this use case, the "Link Notification" does not contain any subscription to changes in resources which were used to generate the transferred links.

2.2 Request Target Change List

In this use case, the source data source asks the target to supply a list of list of all changes that have occured to resources in a target dataset within a specified time range. The source may then use this information for periodical link recomputation. The protocol should allow filtering by change types, such as additions, updates and deletions of resources.



This case of selective link recomputation requires periodical polling of the remote data source by the source, but has the advantage of working without maintaining a persistent relationship between the linked data sources.

2.3 Subscribe to Target Changes

A more complex form of link recomputation is enabled by this use case. The source informs the target dataset about a group of generated links and for each transferred link, supplies the resources which were used to compute it. The target saves this information and monitors the resources used to compute the links. If one of them changes or is deleted, the target notifies the source about these changes. The source may then use this information to recompute affected links and possibly delete invalidated ones. In this case, it notifies the target about deleted links, which cancels the subscription of resources relevant to these links.



Note: in this use case, the "Link Notification" contains resources to monitor for every transferred link.

This case of link recomputation requires no periodical polling by the source, transfers only relevant resource changes, but requires the maintenance of a persistent relationship between the source and target (in the form of the resource change subscription).


3. Protocol Messages

The protocol messages are presented here in a symbolical form as well as in an example XML serialization. However, the concrete implementation of the protocol in Silk uses SOAP as a serialization and message passing mechanism.

3.1 Link Notification

Direction: Source → Target

The "Link Notification" message notifies the target about a group of links that have been set from the source to the target. For each link, the source may include a group of relevant resources from which the link was derived. These are monitored by the target and a "Change Notification" message is sent back to the client in case one of these resources changes. This allows the target to recompute and delete invalidated links. Optionally, the target side may choose to store the transferred links in its own dataset.

Contents:

source message endpoint URI,
ARRAY “links” (
	source resource URI,
	target resource URI,
	link type,
	ARRAY “subscribe to resources” (
		resource URI
	)
)

XML serialization:

<Message type="link_notification">
	<Endpoint uri="source endpoint URI">

	<Link>
		<SourceResource uri="source URI" />
		<TargetResource uri="target URI" />
		<LinkType uri="link type" />

		<SubscribeTo uri="subscribed resource 1" />
		<SubscribeTo uri="subscribed resource 2" />
		...
	</Link>

	<Link />...</Link>
	...

</Message>

3.2 Cancel Subscription

Direction: Source → Target

The "Cancel Subscription" message is used by the source to cancel any existing resource subscriptions it may have with a target. This is useful to reset the relationship between a source and target in case of desynchronization.

Contents:

source message endpoint URI

XML serialization:

<Message type="cancel_subscription">
	<Endpoint uri="source endpoint URI">
</Message>

3.3 Change Notification

Direction: Target → Source

The "Change Notification" message notifies the source of changed resources in the target. This allows the source to recompute links which were derived from the changed resources and possibly delete invalidated links.

Contents:

current target sequence number,
ARRAY “changed resources” (
	resource URI,
	change type,
	sequence number
)

XML serialization:

<Message type="change_notification">
	<CurrentSeqnum>current target sequence number</CurrentSeqnum>
	<Resource uri="resource URI 1" type="change type" seqnum="seqnum 1" />
	<Resource uri="resource URI 2" type="change type" seqnum="seqnum 2" />
	...
</Message>

3.4 Link Deletion Notification

Direction: Source → Target

The "Link Deletion Notification" message notifies the target that a group of links have been deleted in the source. This instructs the target to delete these links and any subscribed resources attached to them.

Contents:

ARRAY “links” (
	source resource URI,
	target resource URI,
	link type
)

XML serialization:


<Message type="link_deletion_notification">
	<Link>
		<SourceResource uri="source URI" />
		<TargetResource uri="target URI" />
		<LinkType uri="link type" />
	</Link>

	<Link />...</Link>
	...

</Message>

3.5 Get Changes

Direction: Source → Target

The "Get Changes" message requests a list of resource changes in the target that occured in a given time range. Optionally, a filter for specific types of changes may be used. The target will answer this request by a "Change Notification" message.

Contents:

from sequence number,
[to sequence number],
[change type filter]

XML serialization:

<Message type="get_changes">
	<From seqnum="from seqnum" />
	[<To seqnum="to seqnum" />]
	[<Filter type="add|change|delete" />]
</Message>

4. Change Log