From W3C Wiki

Semantic Pingback

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.


See the detailed article "Friending on the Social Web", by Henry Story, Andrei Sambra and Sebastian Tramp submitted to the Federated Social Web Conference in Berlin 2011.

Friending use case

You wish to friend someone but only know their WebID (they left it on a blog comment on a site you visit).

After you add them to your friend list with a nice point and click user interface, your profile contains a graph, which in N3/Turtle is represented as:

 @prefix foaf: <> .
 @prefix them: <http://joe.example/#> .
 <> a foaf:PersonalProfileDocument;
       foaf:primaryTopic <#me> .
 <#me> foaf:knows them:i .

You should find a way to let them know that they are added to your profile, and link back to you.

You could fetch their profile, find their email address, and send them an email. But perhaps they don't publish their email, or only make it visible to friends authenticated with Foaf+ssl, which you don't have access to, not being on their friend list.

If they have the following relation in their profile at <http://joe.example/>,

 @prefix pingback: <> .
 @prefix them: <#> .
 <> pingback:to <>;
       foaf:primaryTopic them:i .

you, or better your social web agent, can simply go to <> fill out the form and ping them.

The resource which is the object of the pingback:to relation should be one that does the following (more below):

  • returns a HTML form representation with the same attribute value pairs as the original form. (specified in the pingback ontology)
  • the resource can accept the POST of the form above
  • This can create a resource that is a ping:Item, which you may also have a URL for, and could potentially delete.

The server on receiving that ping request can then notify its user some way (email, feed entry, web page visited) of your ping, and could if he wished to add you to their profile.



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 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

Pingback services

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 resource whose HTML representation would contain the following form

   <html xmlns: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"/>

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" "">
<html xmlns="" xml:lang="en" xmlns:pingback="">
	<title>Pingback Service</title>
	<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
   <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>

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...

3. 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...

List of Services

  • 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.
  • 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.

HTTP Return 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:

  • HTTP/1.1 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.
  • HTTP/1.1 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.

Failure codes:

  • To be determined..


  • 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?


This was initially discussed on the foaf-protocols mailing list in the thread semantic pingback improvement request for foaf.