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

On 17/10/2011 20:25, Luc Moreau wrote:
> 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.

It seems I misunderstood your original point.  I don't oppose provenance headers 
on (say) POST requests - I think they'd still be entity headers - but we'd need 
to think clearly about what they mean, and I'd prefer to get the common (GET) 
case fully resolved first.  I don't see it making sense to put provenance 
headers on GET requests which don't have associated request entities.

<aside>
I don't see the point of your initial question above:  the provenance 
model/vocabulary is about describing provenance of Entities, not modelling 
protocols.

You may choose to model the protocol exchange separately, and if you use RDF for 
that then you must introduce appropriate resources/entities for the various 
interacting components, for which it may be appropriate to apply provenance 
information.  I think there's an ontology for that somewhere 
(http://www.w3.org/2000/Talks/www9-larch/all.htm, 
http://www.w3.org/2000/07/document-maintenance/ was related work, I think.  And 
this: http://www.w3.org/TR/HTTP-in-RDF/.)

We use the example of a crime file:  while we are creating a provenance model to 
describe provenance of the various stages of the crime file, we don't expect 
provenance to model the content of the file, or the operation of the file system 
in which it is stored.
</aside>

#g
--

> 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 Wednesday, 19 October 2011 15:52:43 UTC