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: Luc Moreau <l.moreau@ecs.soton.ac.uk>
Date: Mon, 17 Oct 2011 20:25:13 +0100
Message-ID: <EMEW3|3c1b901ccb4cdbbbac48abd463ad5fccn9GKQX08l.moreau|ecs.soton.ac.uk|4E9C8119.7050605@ecs.soton.ac.uk>
To: public-prov-wg@w3.org
Hi Graham,

How can I model a conversational protocol between a client (say 
javascript client) interacting with a service (REST service)
over HTTP?  Some of the requests issued by the client may be dependent 
on inputs from the user. I would have thought that
  the provenance of resource representations returned by the service 
would be derived (wasDerivedFrom/wasDependentOn)
from the parameters provided by the user/client.

Also, don't we want to be able to track the provenance of data passed in 
a POST message?

I am suggesting that we allow provenance-related headers in any HTTP 
message, irrespective of whether it's a request or a response.


On 17/10/2011 16:51, Graham Klyne wrote:
> 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 19:27:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:02 UTC