W3C home > Mailing lists > Public > public-lod@w3.org > April 2010

Re: semantic pingback improvement request for foaf

From: Story Henry <henry.story@bblfish.net>
Date: Fri, 16 Apr 2010 13:56:53 +0100
Cc: public-lod community <public-lod@w3.org>, foaf-protocols@lists.foaf-project.org, Sören Auer <auer@informatik.uni-leipzig.de>, Philipp Frischmuth <pfrischmuth@googlemail.com>
Message-Id: <9059BAFC-571F-46A3-8854-F6169A0746DD@bblfish.net>
To: Sebastian Tramp <tramp@informatik.uni-leipzig.de>
On 16 Apr 2010, at 11:48, Sebastian Tramp wrote:

> quote Story Henry (15.4.2010):
>> I often get asked how one solve the friend request problem on open social networks that use foaf in the hyperdata way.
> Hi Henry,
> thank you for your introduction to these different solutions.
> As one of the members of AKSW who is responsible for the Semantic Pingback approach it is nice for me to see that our solution is discussed in a broader audience.
> Of course, the development of Semantic Pingback was driven with foaf+ssl in mind, but we also wanted to preserve backward compatibility for existing pingback clients (where possible).

Oh. I had not thought of it as being related to foaf+ssl initially in particular.

> One of the main advantages of pingback (and thus Semantic Pingback) is the low entrance barrier for clients which want to trigger a pingback-request. This is done via a X-Pingback field in HTTP header of a pingback enabled resource. The auto discovery via header field is both simple and powerful. simple because a pingback clients does not need to use an XML parser (or an rdf parser)

In the initial part described above this is true, and only if the HEAD contains
the X-Pingback link header.  (Otherwise you do need to parse the content)

But later in the xml-rpc part it does absolutely require an XML parser, and furthermore it re-invents all the HTTP error/success headers in the XML, and one cannot say that what it did was an improvement.

> and powerful because also JPGs, PDFs and any other resource can be pingback enabled and the client only needs to request for the HEAD of a resource which is another advantage of pingback (thus the client is not forced to load a potential huge resource)

yes, that makes a lot of sense.

The out of date piece is more on sending a ping, and parsing the response, which is overly complicated, in large part not RESTful - eg it could return a URL to refer to the ping request object - but more below....

> The reason for introducing the ping:service property in Semantic Pingback is more a integration issue (e.g. to query for such information via sparql).

yes, that relation is very useful.

> The suggested no.1 auto suggestion method for a resource is still the header field (this policy preserves backward compatibility, allowing wordpress users to ping a linked data resource).

yes, the backward compatibility is also very useful, and should be kept. 

> According to your "Improved Semantic PingBack" approach (5). I understand your motivation to wipe-out the XMLRPC part of such a spec and maybe a POST request could be an alternative for such an RPC call

I don't think that one should wipe out the XMLPRC piece in fact. I should make that clearer in the proposed definition of the ping:service relation. I was thinking one could extend it. Toby Inkster just made the point very well in another thread on the foaf-protocols mailing list


When you POST a content, you are in fact doing something like reverse conneg. One error of the ping back service is to be entirely defined in terms of a representation. But that can be fixed. There is no reason not to extend it to other
representations. HTML forms as specified here


send content in either of two mime types 

 - application/x-www-form-urlencoded 
 - multipart/form-data

The other error of xmlrpc is to re-invent HTTP content negotiation at the
XML layer. So that it encapsulates error conditions in the XML-response.
It is therefore not quite true, that XML-RPC does not require an XML parser.

> (however, this buries the compatibility to the blogosphere).

It need not. We could have it so that ping back servers that are only referred to
via the service:pingback relation in rdf, can offer only the new ping method.

The other thing would be to have a new relation. In the case of friending services in foaf, it is unlikely that people will have their foaf served with X-Pingback headers.

> But in order to be as lightweight as the original spec is, we should then introduce a new header-field as well to allow easy auto-discovery of such a Post-Pingback endpoint as well.
> Since the XMLRPC related header is named X-Pingback, I suggest to use X-Pingback-Post for this thus lifting post-pingbacks as an alternative request to xmlrpcs.

XML-RPC sends the information to the server also via a POST, so I am not sure that
this would be the right way to distinguish them.  

I would be more in favour of calling the new relation Pingback without the X, and
proposing it as an RFC. Given that we could establish this purely semantically, we should be able to get a lot more support.  But that could take a bit more time, and perhaps only something to do at a later point.

So I believe that Pingback needs to be fixed. The xml/rpc piece is just wrong. The easiest way may be to start off with another relation 


perhaps defined as I suggested, and then to find ways to tie this in more carefully with the xml-rpc ping back service.

The reason I think we should develop the html form solution is that we can integrate this very nicely then with RDFa and RDFForms 

( perhaps http://esw.w3.org/PushBackDataToLegacySourcesRDForms )

And most of all it is RESTful, and it gives the human with no machine a simple way to ping a server by hand. So with one method we could have something that works with html, human users, rdfa, machines, etc... It should be easy then to add a backward compatible layer for xml-rpc too.

> Semantic Pingback clients need to implement one of these methods while Semantic Pingback server should implement both to allow both request types and stay compatible.


The next thing to look at would be if there are any particular issues that we need
in the friend request use case. I think automating the friend request with a simple HTML form could really get the viral part of FOAF going. For some reason that essential piece has not been developed. (I don't understand myself why we did not think about it before - perhaps just that we were not in the Web 3.0 decade yet.)

Anyway, we are looking for a space to maintain the ontology. Is this something you would be interested in adding to your semantic pingback page? 

I for sure would love to add a little Scala CGI to allow the automation of friend requests. I think this could really take off.


> best regards
> S.Tramp
>>  0. Search engine solution
>>  1. HTTP Referer Header
>>  2. Referer with foaf+ssl
>>  3. Pingback
>>  4. Semantic Ping Back
>>    http://aksw.org/Projects/SemanticPingBack
>> Most important perhaps is the pingback service relation
>>    http://purl.org/net/pingback/service
>> 5. Improved Semantic Ping Back
>> Here is what I propose
>> @prefix ping: <http://purl.org/net/pingback/> .
>> @prefix owl: <http://www.w3.org/2002/07/owl#> .
>> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>> service:ping a rdf:Property;
>>  rdfs:domain foaf:Agent;  #probably a restriction to be removed, or be refined...
>>  rdfs:range xxx:POSTResource;
>>  rdfs:comment """
>> This relation specifies a method for services that wish to let
>>   document owner know that they are linking to this resource.
>> The relation relates a WebId to a collection (named ?coll from here
>>  on). A new resource of type PingEvent can be created in that collection
>>  by POST ing a  URL that mentions the given WebId.
>>  The content that should be sent to the collection is what would be the result
>> of POSTing the following form
>>   <form action="POST" action="?coll">
>> referer: <input type="text" name="referer"/><br/>
>> comment: <input type="text" name="comment"/>
>>   </form>
>>  The representation returned by a GET on the POSTResource can even return
>>  the above html form, making it human readable.
>>  ( A nice improvement would be for the form to contain rdfa markup, that
>>   would make it clear what the semantics of the form was, by using relations
>>   described in this ontology )
>>  The resource created should be a named ping request, which itself
>> can be described using this ontology.
>>  """ .
>> This it seems to me would be so transparently simple as to be self explanatory
>> to any web developer, increasing uptake and reducing the need for explanation -
>> especially if the resource returns a web form as described above.
>>  6. Improving Semantic PingBack with foaf+ssl
>>  --------------------------------------------
>> Just as with 2, semantic ping back can be improved with foaf+ssl, helping
>> the ping back service identify the user making the ping request. This can be very
>> useful in linked data worlds between large databases that may be pinging each other
>> very often. This would allow trusted agent's pings to be accepted more automatically
>> than new ones.
>> 	Henry Story
>> [1] http://www.the-art-of-web.com/system/logs/
>> [1] http://esw.w3.org/Foaf%2Bssl/FAQ
>> Social Web Architect
>> http://bblfish.net/
> -- 
> Sebastian Tramp - Department of Computer Science; University of Leipzig
> Tel/Fax: +49 341 97 323-66/-29 http://bis.uni-leipzig.de/SebastianTramp
Received on Friday, 16 April 2010 12:57:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:16:05 UTC