W3C home > Mailing lists > Public > public-prov-wg@w3.org > October 2011

Re: PROV-ISSUE-112 (prov-in-get): provenance information in GET message [Accessing and Querying Provenance]

From: Graham Klyne <graham.klyne@zoo.ox.ac.uk>
Date: Mon, 17 Oct 2011 16:51:55 +0100
Message-ID: <4E9C4F1B.7080106@zoo.ox.ac.uk>
To: Provenance Working Group WG <public-prov-wg@w3.org>
CC: Provenance Working Group Issue Tracker <sysbot+tracker@w3.org>
I think that the provenance model should be blind to the particular mechanism 
behind a GET ... after all, HTTP itself is so blind.  What matters is that there 
is a request and a response - whether the response is generated dynamically or 
simply returns a pre-determined status resource is invisible.  (This doesn't 
preclude variable resources: in principle they could be regenerated as static 
resources each time a value on which it depends is changed: the HTTP request 
could still then simply return a static - or more precisely a pre-determined - 
resource.)

Of course, there will be situations in which the variability of a resource needs 
to be taken into account when constructing a provenance assertion.  My point is 
that this can (and IMO should) be modeled quite distinctly from the HTTP GET 
operation.  To my mind, defining the provenance model in a way that depends on 
the retrieval mechanism used is the start of a long slippery slope into untold 
complexity.  The issue would need to be reconsidered for different retrieval 
mechanisms.

HTTP provides a number of mechanisms to identify when a resource has or may be 
changed, that do not reply on identifying a particular GET request (these are 
needed to support HTTP cacheing).  If there is an HTTP cache in the request 
path, a value may be returned without the GET operation ever being seen by the 
origin server.  As well as the cache control and vary headers, there are "Entity 
Tags" - see http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.11

In summary: I think the creation of a resource representation, and any 
associated provenance, should be treated distinctly from its retrieval, or 
retrieval of its provenance information.  Even when creation of the 
representation may be triggered by a GET operation.

#g
--

On 04/10/2011 06:55, Provenance Working Group Issue Tracker wrote:
>
> PROV-ISSUE-112 (prov-in-get): provenance information in GET message [Accessing and Querying Provenance]
>
> http://www.w3.org/2011/prov/track/issues/112
>
> Raised by: Luc Moreau
> On product: Accessing and Querying Provenance
>
>
> The document says:
>
> For a document accessible using HTTP, provenance information may be indicated using an HTTP Link header field, as defined by Web Linking (RFC 5988) [LINK-REL]. The Link header field is included in the HTTP response to a GET or HEAD operation.
>
> However, the resource serialization may be generated on demand, following a GET request. Hence, its provenance may need to make a reference to the GET request itself.
>
> We should allow for provenance information to be included in HTTP Get messages also.
>
>
>
>
Received on Monday, 17 October 2011 17:49:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 13:06:46 GMT