Webmention

The documentation of this experimental work is kept here for historical reasons, however the service is placed out of commission. If you want to build independently built applications that can send, receive, or consume data that is decoupled from the user-interface, with the notion of reusable notifications, as well as interoperable with the rest of the W3C stack, I recommend using the W3C Recommendation Linked Data Notifications.

This is my site’s webmention endpoint. Send POST requests to this URL (https://csarven.ca/webmention) with source, property (optional) and target (optional) parameters, or use the form below, to let me know that you’ve linked to a URL on my site. This endpoint can handle claims using RDF and microformats 2 data patterns found at the source.

As of 2015-07-27, this webmention endpoint offers a way to be more flexibile and precise about the claims than the current webmention design. The approach taken at this endpoint is intended to be a superset on how to deal with mentions i.e., making the receiver aware of a hyperlink with a relation which may be of interest.

Webmention works essentially in two steps: 1) a claim is made 2) the said claim is verified, and possibly displayed. Thus, the source URL is the most essential component, regardless of whether the information for the property or target is provided. At the end of the day, the receiver makes all of the decisions on if and how to deal with the claim - in which, there is no formal specification that is globally accepted nor forced. Naturally this is a good thing. The information that is provided in the POST is just that, a claim. It may or may not be of interest to the receiver, and the receiver makes no promise to do anything with it. Making decisions e.g., optimization, trust, driven from the claim would be premature. Hence, decision making around optimization and trust, for instance, are best left outside of the original claim. The ability to receive only the source URL is the simplest design.

We are now free to build rest of the blocks by optionally accepting the property and target parameters:

The property parameter indicates the type of relation between the source and the target (which is found at the source URL). Its value may be a term e.g., u-in-reply-to, a IRI e.g., http://rdfs.org/sioc/ns#reply_of, or a prefixed name e.g., as:inReplyTo. The property information allows us to make precise claims, i.e., mentions, and consequently 1) it gives an opportunity for the receiver to decide whether to even make a single GET on the source URL, 2) better narrowing down or filtering of the claim.

In a similar way to the property information, having the target allows us to further narrow down on the claim i.e., we can check if we want to deal with a claim made to that particular target URL, regardless of the property information being present or not.

Table of possible POSTs with interpretations:

What might be a good practice here? In my opinion, the sender should aim to be precise about the claim by providing all three components: source, property, and target, to the receiver. What do you think?