- From: Graham Klyne <graham.klyne@zoo.ox.ac.uk>
- Date: Mon, 17 Oct 2011 16:51:55 +0100
- 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 UTC