Pingback

From Read Write Web Community Group
Revision as of 12:10, 30 September 2012 by Mcarvalh (Talk | contribs)

Jump to: navigation, search

Introduction

There are many situations on the web where you want to let some agent know that you are publishing something about them. XML-RPC pingback led the way here, and is widely deployed on the blogosphere. The semantic pingback ontology is a declarative version of the xml-rpc work, and adds a relation to make it as easy to program as writing and parsing an html form.

Protocol

The Pingback Ontology

Namespace

Writing a Pingback Service

Anyone can write a pingback service, and any resource can link to the pingback service of their choosing - even their very own.

A pingback service consists of:

1. A pingbback:Container

A resource whose HTML representation would contain the following form

   <html xmlns:pingback="http://purl.org/net/pingback/">
       ....
       <body about="" typeof="pingback:Container">
       ....
          <form method="POST" action="">
               source: <input type="text" name="source"/> (pingback:source of the new Pingback Item)<br/>
               target: <input type="text" name="target"/> (pingback:target of the new Pingback Item)<br/>
               comment: <input type="text" name="comment"/>  (sioc:content of the new Pingback Item)<br/>
               <input type="submit" value="Send"/>
          </form>
      ....
       </body>
    </html>

where the importance is that the attribute value pairs be as above.

Here is the RDFa representation of a complete page which contains the form, and which would pass validation tests:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" xmlns:pingback="http://purl.org/net/pingback/">
   <head>
	<title>Pingback Service</title>
	<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
   </head>
   <body typeof="pingback:Container">
   <form method="post" action="">
       <p>source: <input type="text" property="pingback:source" name="source" /></p>
       <p>target: <input type="text" property="pingback:target" name="target" /></p>
       <p>comment: <input maxlength="256" type="text" name="comment" /></p>
       <p><input type="submit" name="submit" value="Send" /></p>
   </form>
   </body>
</html>

2. A script to process the returned form POST

And ping the owner of the target resource. Such a script should initially parse the form and verify that it provides a pingback service (parsing the form should at least return a triple containing "<> a pingback:Container .". The script should also check that the source does indeed link to the target. Depending on the type of object the source is, the pingback server could propose different options to the target owner:

  • if the source is a foaf:Person linking to the target via foaf:knows the service could propose to add an inverse relation
  • if the source is an image, or an annotated resource the service could suggest adding it to some bookmark feed
  • any other number of options...

Optionally the resource created by the POST could be a pingback:Item which could itself have it's own URL and be processable by the the client who initiated the ping (allowing him perhaps to delete it) or the target of the ping...

3. Response -- Status Codes

Each time a pingback service needs to inform clients of a status change in their request, it should send a specific HTTP return code and optionally a description. Here is a list of possible return codes that can be used for pingback.

Success codes:

  • 201 Created - this code should be returned after the pingback service has successfully sent/created a ping. It should be noted that a verification process has been performed and that this is the final return message.
  • 202 Accepted - this code should be returned after the pingback service queued/deferred a ping request for later processing. No verification has been done at this point.


Error codes:

  • 401 Unauthorized - this code should be returned if the authentication fails.
  • 403 Forbidden - this code should be returned if the authentication was successful but the endpoint doesn't allow Pingbacks with the given source or target agent.

Client

Sequence

Server-Side Pingback

Client-Side Pingback

Client-Side Pingback.png File:Client-Side Pingback.odg

  • Romeo opens a trusted page which contains a Pingback App
  • The Pingback App searches for a pingback:to property in Julite's Profile
    • Search for the pingback:to property in Julite's Profile via Trusted Page Server-Side
    • or Search for the pingback:to property in Julite's Profile via CORS Client-Side
  • Romeo sends Pingback via CORS
    • Romeo authenticates with his WebID
      • Romeo sends his WebID certificate to Juliet's Pingback Service
      • Juliet's Pingback Service verifies Romeo's WebID
      • Pingback successful sent
    • or Romeo authenticates with OAuth
      • Romeo doens't authenticate via CORS
      • Romeo sends Pingback via form submit
      • Juliet's Pingback Service redirects to OAuth Service
      • Juliet's Pingback Service verifies the OAuth token
      • Pingback successful sent

Security

Implementations

Services

  • http://pingback.aksw.org/ is a public pingback service that will send an email to the owner of the target document if it can find an address there. The code is open source.
  • https://my-profile.eu/ allows sending of semantic pingbacks, as well as subscribing to a local service where each user can receive notifications (and also subscribe to an Atom feed to see them). If it doesn't find a pingback:container at the resource indicated by pingback:to, it will try instead to display the pingback service described by the pingback:to relation. Otherwise, if no pingback:to resource is found, it will attempt to look for a foaf:mbox address and then send an email.

Issues

  • Should one really be able to send an attribute/value form automatically to an endpoint? What if some service used exactly the same attribute/values as the pingback point, but the result of sending such a POST had a very different meaning (perhaps obliging you to buy a product)?
    • Should the form be marked up with RDFa then, requiring the service to first download the page and analyse the form markup? This seems to be a simple solution, that solves the problem nicely. (have added the rdfa in the form above)
    • would this issue be solved by sending a SPARQL update?
  • Check if there is a conflict / the current spec follows the definitions of Linked Data Basic Profile 1.0

Alternatives

SPARQL Update

The SMOB (Semantic Microblogging) project uses a SPARQL update method

--- Please give some pointers for the following section ---

There is the design Charles MacKenzie used for his distributed tweet system. The user profile has a pointer to their dropbox. This is an append-only resource.

The person who says they are their friend adds the friend triple to their dropbox. This is done for example with a SPARUL update message POSTed to the dropbox. This uses existing code on the client side.

OpenSocial

OpenSocial has a Relationship Create API, but on first inspection at least it has the following drawbacks:

  • User Ids are local. They are not URIs, so it won't create a distributed solution easily.
  • OpenSocial works with URI patters, which are hard coded, but user agents should not be making guesses about the meaning of a URL see WebArch URI Opacity section
  • The format to send a friend request is XML or JSON. That is a lot more complex than the Pingback which uses simple forms

References