- From: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- Date: Mon, 17 Oct 2011 20:25:13 +0100
- 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. Luc 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