The World Wide Web is an infrastructure to publish and retrieve information through web resources. It evolved from a static Web 1.0 to a multimodal and interactive communication and information space which is used to collaboratively contribute and discuss web resources, which is better known as Web 2.0. The evolution into a Semantic Web (Web 3.0) proceeds. One of its remarkable advantages is the decentralized and interlinked data composition. Hence, in contrast to its data distribution, workflows and technologies for decentralized collaborative contribution are missing. In this paper we propose the Structured Feedback protocol as an interactive addition to the Web of Data. It ofers support for users to contribute to the evolution of web resources, by providing structured data artifacts as patches for web resources, as well as simple plain text comments. Based on this approach it enables crowd-supported quality assessment and web data cleansing processes in an ad-hoc fashion most web users are familiar with. •Information systems ! Web applications; Collaborative and social computing systems and tools; Web services; Resource Description Framework (RDF);
The Internet and the World Wide Web (WWW) in
particular provide an infrastructure for retrieving information
corresponding author
through web resources. With the advent of discussion
forums, blogs, short message services like Twitter and
online social networks like Facebook, the web evolved towards
the Web 2.0. With the Semantic Web resp. Web of Data,
the web is now evolving towards a Web 3.0 consisting of
structured and linked data resources (Linked Data, cf. [
Building on the existing stack, we propose an open
protocol on the Web of Data, which is distributed across multiple
services, to integrate a collaborative feedback mechanism
on structured and unstructured web resources. The
protocol integrates elements of the architecture for a Distributed
Semantic Social Network (cf. [
Current mechanisms to provide feedback on web resources are, but are not limited to, leaving a comment through a form provided by a publisher of a webpage, publishing a comment along with a link to the web resource on an online social network or doing so on a personal weblog. The problems with this kind of commenting are: either it is hard for the publisher of the web resource to get an overview of the available feedback to his content, or the user who leaves the comment is limited to the possibilities provided by the publisher to express the feedback and is not able to select the location of the comment and maybe specify the audience on her own. In contrast to this situation, we are proposing a crossover approach, which serves the upsides of the cur1http://dig.csail.mit.edu/breadcrumbs/node/215 rent situation to both parties, commenters and publishers. It gives commenters the possibility to publish comment resources at their leisure in an arbitrary location on the web. It is integrated in the DSSN and has the possibility to be integrated in further online social networks. Publishers are actively informed about distributed comments on the web. In addition, it provides better possibilities to express the user’s feedback by creating structured patches to be sent to the publisher, which in turn are easier to apply than a verbal description about a mistake.
Nevertheless, the social network is just a part of the WWW
and the Linked Open Data Cloud [
The paper is structured as follows: general requirements to a distributed structured feedback protocol are formulated in section 2, followed by relevant preliminaries, such as the DSSN, Semantic Pingback, PubSubHubbub and our interpretation of Linked Data, in section 3. The proposed protocol is specified in detail in section 4. Further we are documenting our reference implementation in section 5, which is the basis for our demonstration and evaluation in section 6. We are discussing the state of the art and related work in section 7. Finally a conclusion and an outlook on future work is given in section 8.
Throughout the paper we are referring to several RDF terms using simplified QNames 2. The prefix definitions are as follows: @prefix fb-res: <http://resource.feedback.aksw.org/> . @prefix fb-feed: <http://feed.feedback.aksw.org/> . @prefix dbpedia: <http://dbpedia.org/resource/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns\#> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix sioc: <http://rdfs.org/sioc/ns\#> . @prefix sioct: <http://rdfs.org/sioc/types\#> . @prefix pingback: <http://purl.org/net/pingback/> . @prefix cs: <http://purl.org/vocab/changeset/schema\#> . @prefix prov: <http://www.w3.org/ns/prov\#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema\#> .
In the following we present the requirements for an open federated commenting system on the web. The requirements are targeted by our proposed architecture and protocol through diferent components.
Comment Resources should be stored in any location on the web. Preferably the location should be publicly available 2https://www.w3.org/TR/2009/REC-xml-names -20091208/ and has to be identifiable and locatable by a URL. The location of a Comment Resource should be selected by its author.
Besides the classic way of giving feedback for a Web Resource by adding a simple full text comment it should be possible to give a more precise structured comment to a resource. This enables users to directly fix the mistake and provide the resource publisher with a patch to apply to the Web Resource, instead of verbally describing the position of a mistake in a document. This behavior is comparable to the concept of pull-requests in software engineering e. g. on git-based collaboration platforms.
All comments related to a specific Web Resource have to
be aggregated in a single place, which is referenceable from
this Web Resource. This aggregated resource has to contain
references to the original comments. The Comment
Container can be an RDF resource or an RSS web feed (cf. [
The Comment Container has to be updated if new Comment Resources for the respective Web Resource are created. This is needed to have an up-to-date resource available to the content publisher to get informed about new comments and be able to integrate structured patches into his data set.
Web users which are interested in a specific Web Resource should be able to subscribe to a Comment Container related to the Web Resource of interest. This Comment Container should be kept up to date regarding new comments. Subscribers have to be actively informed of updates on Comment Containers they are subscribed to.
The proposed architecture and protocol is based on several
existing technologies and protocols used on the Web of Data.
From a general perspective it is based on HTTP. Specifically
it is relying on and following the widely used Linked Data
principles (cf. [
Distributed Semantic Social Network
The Distributed Semantic Social Network (DSSN) is an
architecture for an open online social network which is
distributed across the web. It is based on Web 2.0 and
Semantic Web technologies, such as WebID for authentication,
the FOAF vocabulary to describe personal profiles,
Semantic Pingback (cf. section 3.2) and PubSubHubbub (cf.
section 3.3) for active communication on the Semantic Web
[
Semantic Pingback3 (cf. [
PubSubHubbub is a publish subscribe protocol for the
web (cf. [
Since Linked Data is a basis of the Semantic Pingback
protocol (cf. section 3.2) and the Structured Feedback protocol
makes use of this paradigm, too, we provide some words on
our interpretation. The four rules as formulated in [
The Structured Feedback protocol relies on those rules, by assuming that all resources are identified using an HTTP URI and it is possible to query the URI of a Web Resource, Comment Resource and Comment Container, and RDF data is returned, either directly or by content-negotiation using HTTP Accept-Headers. Further links are used to connect the resources and services, and all resources are published according to these rules.
One issue we were facing with Linked Data was that
nothing is mentioned about retrieving named graphs. According
to the RDF Recommendation [
When applying those rules to an RDF dataset, we have interpreted these two rules to be executed on the default graph4, while we have extended these two rules by the following two rules to target the other named graphs of an RDF dataset: 3. If a named graph with the same URI, as the node, as graph name is defined and accessible, returning all quad-statements of the identified named graph; and 4. All quad-statements of a named graphs with a blank node as graph name, where the blank node is contained in the set of blank nodes following the second rule, are returned.
The suggested additional rules, are interpreted in a fully backward compatible way, which means, only if a serialization format with RDF dataset support is accepted by the requesting client, the quad-statements are returned. 4.
The proposed approach, Structured Feedback, is an open protocol, distributed across multiple communicating components. It is based on several Semantic Web and DSSN protocols. Especially it is following the Linked Data paradigm (cf. section 3.4) and applies the Semantic Pingback (cf. section 3.2) and PubSubHubbub (cf. section 3.3) protocols. All components interacting through the protocol are depicted in fig. 1 .
Any resource published on the WWW. It can be represented in any format, but has to be identifiable and retrievable by a URL. It is encouraged to use resources in an RDF format, but baseline functionality is possible for other types as well. The Web Resource has to announce a Semantic Pingback Service and a Comment Container as shown in listing 1, or using the according header link relations rel="pingback" and rel="alternate". dbpedia:Leipzig pingback:to <http://pingback.feedback.aksw.org/> ; sioc:feed fb-feed:dbpedia-Leipzig .
Listing 1: A minimal example of the necessary
triples of a Web Resource to announce a Semantic
Pingback Service and a Comment Container
4This interpretation should be inline with the
nonnormative section “Content Negotiation of RDF Datasets”
of the RDF Recommendation [
contained in Comment Resource
sioc:reply_of creates retriev e s
contained in retrieves
Web Resource sioc:fee
d pig n b a c k k:o t c a b vie/pig n c r k:e s c a b pig n ates d creates/up
H T T P H E at AD om: Lin i k l nk rel= " h u b " r e t riv e e s Semantic Pingback
Service
Listing 3: An example of a Comment Resource containing a commit and a revision proposed as a patch for a Web Resource
An application providing an interface for a user to create a Comment Resource related to a given Web Resource and store it in a Resource Hosting Service. The Annotation Client can be shipped together with the Web Resource, e. g. as a JavaScript Application, a third party Web Service, or a stand alone client application. Depending on the implementation, the Annotation Client is also responsible of acting as a Pingback Client and triggering a Semantic Pingback ping to the Semantic Pingback Service, advertised by the commented Web Resource.
The Semantic Pingback Service implements the Semantic Pingback protocol (cf. section 3.2) and accepts ping requests. On arrival of a valid ping it is responsible for arranging an update of the Comment Container. This service further implements the publisher role of the PubSubHubbub protocol (cf. section 3.3). If updates are available on the container it sends an update notification to the PubSubHubbub Hub. The roles of the Semantic Pingback Service might as well be split into separate controllers responsible of receiving the Semantic Pingback ping, updating the Comment Container and notifying the PubSubHubbub Hub. This would result in a high flexibility for distribution and federation, but highly depends on the implementation and is out of scope for specification of this protocol.
To be able to keep all comments on one Web Resource in
a single container the Comment Container was added. It is
comparable to the roll of an RSS-Feed (cf. [
"2016-01-19T09:55:25.470Z"^^xsd:dateTime ; sioc:content "I'd like to ask ..." .
Subscriber alt
HTTP GET <Web Resource> pingback:to
A sequential overview of the protocol is given in figs. 2 and 3. The protocol is initiated by the Annotation Client in ifg. 2 , which provides a means for a user to create a comment for any Web Resource. The Annotation Client retrieves the Web Resource from its Data Set and looks for a pingback:to6 6It is recommended to us the simple Semantic Pingback protocol instead of the XML/RPC based protocol.
HTTP GET <WebResource> create/update notify retrieve or pingback:service relation to the Semantic Pingback Service in charge of the requested resource. The user creates a Comment Resource using the Annotation Client, which has to contain a sioc:reply_of relation to the commented Web Resource. The Annotation Client then takes care of storing the Comment Resource in a Resource Hosting Service from where it is available as Linked Data. A Resource Hosting Service can be any SPARQL service or even a publicly available static webpage hoster, which is writable by the Annotation Client, e. g. through access delegation. After the Comment Resource was published the Annotation Client notifies the Semantic Pingback Service by sending a pingback request with the Comment Resource as source and the commented Web Resource as target. Depending on the implementation this task can also be completed by the Hosting Service, but to keep the selection of a Hosting Service as lfexible as possible it is a good idea to hand over this task to the Annotation Client. When the pingback request was received by the Pingback Service it retrieves the Comment Resource from the Hosting Service for verification of the ping, as depicted in fig. 3 . When the Comment Resource was verified by the Semantic Pingback Service it updates the corresponding Comment Container of the Web Resource. After the Comment Container was updated the Semantic Pingback Service (Publisher) notifies the PubSubHubbub Hub of the update, which in turn retrieves the updated Comment Container (Topic) and informs its subscribers about the update.
We have built a reference implementation in order to validate the interoperability of the components and verify the viability of the protocol. In the following section we discuss some design decisions and problems, which occurred during the implementation. 5.1
The Annotation Client is a piece of software that enables
a user to create comments or structured patches on Web
Resources. The actual implementation of the Annotation
Client is a JavaScript website extension. It identifies the
resource URI of the current HTML representation by
looking for the relation links foaf:primaryTopic, alternate and
describedby in the header. Then it requests the respective
RDF resource as RDF/JSON7 (cf. [
The Annotation Client presents two dialogs (cf. section 6). At invocation it prompts a simple form for plain comments. To identify the author of the feedback, a URI to the WebID or any other personal web resource is requested. In this implementation the URI needs to be entered by the user himself using the respective input in the frontend. For future implementations the user identity could be obtained using OAuth or could be provided by the including platform, on which the extension is running. A second dialog, invocable by the user provides an editable list of all properties of the currently selected resource to the user. It provides basic property editing, deletion and insertion operations. In this dialog, the user as well has to provide an identifying URI and additionally a commit message.
The Annotation Client generates upon changes, deletions
and insertions done by the user, changesets according to
the changeset vocabulary [
After the resource was successfully written to the Resource
Hosting Service the Annotation Client directly sends the
pingback request to the Semantic Pingback Service. This
behavior is in contras to the specification in [
For the reference implementation of the architecture we
have created a simple read/write hosting platform for RDF
resources and RDF graphs in Python, inspired by the Linked
Data Platform [
Before a resource is sent to the Resource Hosting Service, the client executes a GET request to the services base URL 7RDF/JSON was preferred over JSON-LD because it has one strait forward way of data representation, which has no need for an extra parser to work with the data. 8https://github.com/AKSW/AnnotationClient to request an available URI. This request was introduced to avoid collisions of resources on the Resource Hosting Service as well as to have some kind of guaranty from the service, that the URI will be publicly routable on the Internet. A free resource URI is generated using a random hash and a subsequent SPARQL-ASK query to the internal store. The actual write operations are implemented as POST and PUT requests directly on the resource URI. This again makes sure that the resource will be available as Linked Data. The body of these requests has to contain the same data, which should be returned on a GET request to the same URI. The source code for the Resource Hosting Service is available on GitHub9. 5.3
The Semantic Pingback Service was implemented in PHP based on the existing generic Semantic Pingback reference implementation10. This implementation stores received pings in a MySQL database. The Semantic Pingback Service also comes with a web-form to manually send pingbacks to the service, this can help “self-publishers” of Comment Resources to also integrate their resources in the protocol lfow. When a valid pingback was received, the controller for the management of the Comment Container is invoked by a callback function.
The retrieved Comment Resource is stored internally in a Saft11 resp. EasyRdf12 Triple Store with a MySQL backend. Due to the lack of widely available implementations of serializers for RDF formats with support for RDF datasets, the generation of the Comment Container resources and graphs was mainly done using basic string operations. To enable a flexible usage of one instance of the service for multiple data sets by providing feeds for any resource in the data set, the generation of the URI for the Comment Containers was implemented dynamically. Following to the host name and base path of the instance the feed URI is generated based on the according Web Resource. For example the feed URI for the resource http://aksw.org/Groups/ES is http://feed.feedback.aksw.org/aksw.org/Groups/ES. The PubSubHubbub publication part is done using the php-publisher implementation provided by the pubsubhubbub project13.
As PubSubHubbub hub we are using Google’s instance14. To increase the independence from central infrastructure, we also want to provide a PubSubHubbub hub implementation in the future. The source code for the Semantic Pingback Service is available on GitHub15. 6.
DEMONSTRATION AND EVALUATION Based on our reference implementation of the relevant services in the protocol we have built a test setup16. It comprises a Resource Hosting Service to store Comment 9https://github.com/AKSW/ResourceHosting 10https://github.com/AKSW/SemanticPingback-Server 11http://safting.github.io/ 12http://www.easyrdf.org/ 13https://github.com/pubsubhubbub/php-publisher 14http://pubsubhubbub.appspot.com/ 15https://github.com/AKSW/FeedbackServer 16http://feedback.aksw.org/ Resources17 (cf. section 5.2) and a Semantic Pingback Service18 (cf. section 5.3), which receives pingbacks, manages the Comment Containers and updates the PubSubHubbub hub. The Annotation Client (cf. section 5.1) is deployed on our work group homepage19 and already increases the quality of the published data.
Using the user scripts browser extension Greasemonkey20 for Mozilla Firefox we could also load the Annotation Client on other data sets, e. g. DBpedia21, and include them in tests of the infrastructure as well. Figure 4 shows screenshots of the Annotation Client loaded on the DBpedia Web Resource dbpedia:Counterparts. Figure 4 (A) shows the dialog for entering a simple text comment to a resource (A.1), the URL entered in the top input is used to identify the author (A.2). The generated Comment Resource is stored as sioct :Comment on the Resource Hosting Service. In fig. 4 (B) the resource editor is displayed. It provides basic functionality to edit existing properties (B.1), to delete (B.2) and to add new properties (B.3). Similar to the simple text comment form, the user should provide a URL for identification (B.4) and additionally a commit message to describe the change (B.5).
In section 2 we have formulated some requirements which we want to evaluate now.
The first requirement was “Decentralized Storage of Comment Resources”. This requirement is fulfilled firstly with the possibility of separating the Resource Hosting Service from the place, where the original Web Resource is stored. Secondly, by the openness of the protocol and the possibility to use any other Resource Hosting Service and manually send a pingback or use a standalone Annotation Client (cf. sections 5.1 and 5.2).
The second requirement was “Structured Feedback for
Web Resources”. This requirement is met by the usage of cs
:ChangeSet resources (cf. [
The third requirement was “Comment Container for Web Resource”. It is fulfilled with the Comment Containers. A container is identifiable by a URI and can be retrieved as whole, including its items following the proposed adopted Linked Data interpretation of section 3.4, or as a single resource with references to the contained items. The Comment Container is referenced from the Web Resource with a sioc:feed relation.
The fourth requirement was “Active Updating of the Comment Container with new Comment Resources”. It is targeted by using Semantic Pingback (cf. section 5.3). If a new Comment Resource is created the Annotation Client sends a ping with a reference to the Comment Resource, which then is integrated in the Comment Container by the Semantic Pingback Service.
The last formulated requirement was “Active Notification for Subscribers of Comments on Web Resources”. This requirement is fulfilled by the usage of the PubSubHubbub system (cf. section 5.3). It enables interested third party 17http://resource.feedback.aksw.org/ 18http://pingback.feedback.aksw.org/ and .feedback.aksw.org/ 19http://aksw.org/ resp. http://feedback.aksw.org/ 20http://www.greasespot.net/ 21http://dbpedia.org/ http://feed agents to subscribe to the Comment Container of a Web Resource, to receive updates.
The decentralized approach of the protocol allows to
distribute all of the services involved. Resource Hosting
Services can be independently selected or deployed by a
commenter, the Pingback Service as well as the PubSubHubbub
Hub is selected or deployed by a resource publisher. Thus
there is no single point of failure for the web wide
infrastructure, only individual services can go down, as currently
sometimes web sites do. Another thread to the protocol
could be vandalism or spamming. This and further threads
to the Semantic Web are elaborated in [
For content providers it is often important to gather feedback from their users or to allow a discussion among the users about the presented topic. There are several possibilities for content providers to support such discussions. Generally, these possibilities resp. approaches can be categorized according to the level of distribution as follows: 1. Central to the content provider (simple commenting forms), 2. Integrated in a third party centralized online social network (Commenting Plug-Ins, Social Buttons), and 3. Web wide distributed commenting techniques.
A simple commenting form (1.) is usually already provided by webloging software or web content management systems, such as Wordpress22, Serendipity23, or Typo324. Another option to be included into the website infrastructure of a content provider is Discourse25. It provides a commenting form to be integrated on a website, but unlike other third party approaches (cf. 2.) it allows website providers to decide where to host the users comments, by also providing the back-end software as Open Source. Those techniques allow users to leave a comment directly on the website of the publisher, where the comment is also stored in the domain of the content provider.
The second way of allowing user feedback on a website is the integration of an external web service or online social network (2.). This can happen by integrating social 22https://codex.wordpress.org/Comments_in_WordPress 23http://www.s9y.org/3.html 24https://typo3.org/typo3-cms/key-features/complete -feature-list/ 25http://www.discourse.org/ A
A.2 A.1
B
B.3
B.4 B.5 B.1 buttons (Google+, Facebook like, Twitter, Reddit) to encourage users to share the link to a web resource together with a comment on an external online social network. Instead of referring the users to an external website it is also possible to directly integrate a commenting form of the external web service through a JavaScript plug-in. A very commonly used provider for this possibility is Disqus26, besides the commenting form it provides a central server to host all the user comments and has a Facebook and Twitter integration. Facebook also provides its own Comments Plugin27. With this plug-in integrated into a website, users are able to leave comments on a website using their Facebook account for authentication and can share the comment on the Facebook online social network as well. All comments are stored in a central location on Facebook’s servers.
Independent of the decision of the website publisher, for
users it is always possible to write comments in any place
on the web (3.), such as web forums, personal weblogs,
review platforms, or any online social network. This results
in a web wide distributed commenting system. While this
is generally out of control for the content provider and it
is hard to gather all feedback on a specific resource, it
allows the best flexibility for the user. Techniques to
target this issue are Trackback and Pingback (cf. [
In respect of these three categories, the proposed Structured Feedback protocol is a crossover approach. It allows the integration of an Annotation Client directly into the website of the publisher to encourage users to leave comments. Also the website publisher keeps track of the comments in a Comment Container stored at a location of his choice. Users still have the choice whether to use the integrated client or any external commenting platform or even a standalone client. By following the proposed protocol, Comment Resources can be stored in any place of the web, while its still possible to inform the content publisher via Semantic Pingback. Interested third parties can subscribe to the comments on a resource using PubSubHubbub.
Sidewiki was a project introduced by Google in 200928, it is implemented in the Google Toolbar for Firefox and Internet Explorer, a Plug-In for Chrome or a Bookmarklet for other browsers, but is no longer available29. It allowed users to share annotations for web resources with other users of 28https://googleblog.blogspot.com/2009/09/help-and-learn -from-others-as-you.html 29https://google.com/sidewiki/, HTTP Status Code 404 the service. As it seems it relied on a central infrastructure, which was discontinued after just two years in 201130.
The Web Annotation Working Group at the World Wide
Web Consortium31 [
The protocol flow of Web Annotations is analogous to our proposed protocol, while we mainly concentrate on propagating feedback in the form of patches to Linked Data Resources, the Web Annotations try to find a more general solution for arbitrary resources on the web. Similar to our approach the distribution of the protocol and the sovereignty of the resource and annotations publishers is a main requirement. “Web annotations can be linked, shared between services, tracked back to their origins, searched and discovered, and stored wherever the author wishes; the vision is for a decentralized and open annotation infrastructure”32. Based on the big overlap in the targeted problems, both approaches can be seen as a contribution to the same discussion about a solution for the problem from diferent perspectives. Where we contribute the glue part between social semantic web and distributed annotation. While both approaches can complement each other and maybe also interoperate in the in tackling this issue in the sense of a heterogeneous WWW.
Besides the possibility of leaving a simple text comment
for a publisher, revyu.com (cf. [
Our approach can be seen as a further advancement of
[
CONCLUSION AND FUTURE WORK In this paper, we have presented a protocol for giving feedback to resources on the Web of Data. The protocol is distributed in a way, that resource publishers and comment authors can independently decide on, where to host their infrastructure and especially resources. Using Semantic Pingback, publishers are informed about newly created comments on the web and an aggregated Comment Container is created as comment feed for a Web Resource. Further with PubSubHubbub it even enables third party agents to subscribe their services to the feed and follow newly created comments (Comment Container). The formulated requirements, “Decentralized Storage of Comment Resources”, “Structured Feedback for Web Resources”, “Comment Container for Web Resource”, “Active Updating of the Comment Container with new Comment Resources” and “Active Notification for Subscribers of Comments on Web Resources” are met by the protocol and implementation (cf. section 6). We have deployed the system on our workgroup homepage19 to demonstrate its functionality and to increase the quality of the published data.
The proposed protocol is integrated in the DSSN and a
web wide infrastructure of social services. Further with the
establishment of such a feedback protocol, data curation
processes as well as web wide distributed co-evolution strategies
for linked data sets would be promoted. As future work the
Comment Containers should be integrate in resource
curation platforms, such as OntoWiki [
The Annotation Client will be further develop to support the inclusion into arbitrary web pages, without causing side efects in the CSS-styling or JavaScript execution. We have already got in touch with the DBpedia maintainers to integrate our system on dbpedia.org. This would enable a wide deployment and usage of the protocol. 33https://de.wikipedia.org/wiki/Wikipedia:Gesichtete_ Versionen (German)
This work was partly supported by the following grants from the German Federal Ministry of Education and Research (BMBF) for the LEDS Project under grant agreement No 03WKCG11C and the European Union’s Horizon 2020 research and innovation programme for the SlideWiki Project under grant agreement No 688095.