Re: PROV-ISSUE-618 (pingback-in-prov-aq): Should pingback be described in PROV-AQ? [Accessing and Querying Provenance]

On Thu, Jan 31, 2013 at 6:50 PM, Timothy Lebo <> wrote:
> Following up from today's call, what is Stian's proposal?
> I must admit that I have been following each of his feedback emails.

Well if you followed those emails, it should be clear! ;-))

The proposal is from my review at

My proposal is that the pingback works like a 'send me a URL' thing,
just like a pingback in a blog is. I don't pingback to your blog
service with a copy of my new blog post, I just give you the link,
which your blog might or might not publish.  So the link in this case
would be a provenance-URIs <> or
a provenance-query-service <>, to be
associated with some target-URI (read prov:Entity)
<>.   If this is honoured, then
subsequent requests to find provenance for
<> (as in section 2) would
include the new links.

The good thing is that now this also provides a way for third-parties
to provide additional data that can be returned by the provenance
service described in first half of PROV-AQ - and so just like the
first half does not detail how the actual provenance data is retrieved
or got there in the first place, but mainly provides links to other
resources which return the provenance or let you query it; then the
second half should be about how to add those links. Currently there
are no way to add those links.

The original proposal the pingback service seems more like a "Please
store this provenance for me" service - which would go counter to the
disclaimers in the first half about how you should place different
trust on provenance from different sources (the hosted 3rd party
provenance would appear authoritative if it comes from the same server
as the resource) - and not have an obvious link to the lookup.
Obviously this raises many other problems such as updates, alternative
representation of the same resource, metaprovenance, Date headers,
etc.  If you just want to do "Please store and host this resource
(RDF) for me and give me a URL" - then there are many existing methods
to do so - the simplest being HTTP PUT on the desired URI, a more
elaborate one could be AtomPub or even.. ) out of bands with WebDAV
(ugh) and (S)FTP.

Here is my alternative proposal for this section:

(Same blurb about finding prov:pingback)

  C: HEAD HTTP/1.1

  S: 200 OK
  S: Link: <>;
Each resource MAY be associated with one or more prov:pingback services.

A client MAY post a pingback request to any or all of the returned
prov:pingback services.

  C: POST HTTP/1.1
  C: Content-Type: text/uri-list

  S: 204 No Content
  S: Link: <>;
  S: Link: <>;
  S: Link: <>;

This client request above indicates that the two provenance-URIs at contains provenance mentioning or its target-URI (-- either
forward or backwards, we don't know).

The client MAY include provenance query services which can describe
the target-URI by including the corresponding {prov:hasQueryService}
Link headers. The anchor MUST be included, and SHOULD be the
target-URI of the resource which this pingback service belongs to,
unless the submitted query service would expect a different target-URI
to describe the given resource.

  C: POST HTTP/1.1
  C: Link: <>;
  C: Content-Type: text/uri-list
  C: Content-Length: 0

In the above example, the client did not submit any provenance-URIs
and the URI list is therefore empty.

The client MAY similarly include {prov:hasProvenance} Link headers to
specify a different anchor. The provenance-URIs of those headers MUST
also be included in the content if the POSTed Content-Type is

The pingback service MAY resolve the submitted URIs to validate and
check the provenance data, however reasonable care should be taken to
prevent malicious use of the pingback service for attacks such as
distributed denial of service (DDoS) and cross-site request forgery

The server MAY, immediately or at a later time, include the submitted
*provenance-URI*s in responses to subsequent request to the provenance
service for the target-URI. (insert usual blurb about not trust on
such provenance)

The server SHOULD include a self-referential prov:pingback Link
header, which MUST include the anchor for the target-URI this pingback
service corresponds to. This serves the purpose for the client to
verify it has submitted a pingback to the correct service, in case it
has followed an untrusted prov:pingback Link header. The client MAY
for this purpose POST an empty text/uri-list to avoid side effects.

The server SHOULD indicate immediate acceptance by including the
corresponding {prov:hasProvenance} {Link} headers for the accepted
*provenance-URI*s. If all submitted provenance-URIs have been
immediately accepted, the server SHOULD respond with HTTP status {200
OK} or {204 No Content}.

If server acceptance is pending for any of the submitted URIs, for
instance because the provenance-URIs are being validated or due to be
approved by a moderator, the server SHOULD respond with HTTP status
{202 Accepted}, and only include corresponding {prov:hasProvenance}
{Link} headers for those provenance-URIs that have been immediately

The server MAY respond with {401 Unauthorized} and standard
{{WWW-Authenticate}} headers if authentication is needed. The server
SHOULD respond with {403 Forbidden} if for any reason it refuses to
accept one or more of the submitted provenance-URIs or
provenance-service-URIs. If some URIs were accepted, but others were
refused, the server SHOULD respond with {403 Forbidden} and include
generated prov:hasProvenance and prov:hasQueryService Link headers for
the immediately accepted URIs.

(The above needs to be cleaned up so that it talks equally about
prov:hasProvenance and prov:hasQueryService in the error handling -
and also to separate better the protocol and the example).

Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Friday, 1 February 2013 16:49:35 UTC