Re: Access and query TF - actions for WG

Hi Graham,

A question is interleaved.

On 06/20/2011 02:40 PM, Graham Klyne wrote:
> Luc Moreau wrote:
>> Hi Graham,
>> Thanks for the clarification.
>> It seems that our two proposals only differ by this:
>> - your proposal is to provide a provenance-URI where to retrieve 
>> provenance
>> - mine is to provide an identity I and a service location L, out of 
>> which a provenance-URI can be composed.
>> Otherwise, I think the proposals are identical.
>> Would you agree?
> Er, yes, but that seems to me to be more different than similar.  I 
> think the notion of "composing" a URI from an identity and a location 
> is problematic and unnecessary.
> In my view, we just have an identifier, or several identifiers without 
> specifying how it is (they are) minted, (some of) which MAY also be a 
> location.  Either way, any identifier can be used with third party 
> services if so desired.
>> My only motivation for my proposal is that I can use identity I with 
>> multiple services L1, L2, ... of my choice
>> to obtain different provenance.
>> It would be good to see whether we want to consider this requirement 
>> or not? Any views in the WG?
> Of course.  I think I've indicated mine :)
> (For the avoidance of doubt: I think the possibility of use with third 
> party services *is* a requirement, but I don't think we need to say 
> anything special about the construction of the identifier to make that 
> possible.)

OK, I can use HTTP HEAD in order to obtain provenance-URI for some resource.
This provenance-URI will be returned by the same service as the one 
providing the resource.

How can I obtain an alternative provenance from another service?  I 
don't understand I
would get an alternative provenance-URI?


> #g
> -- 
>> Cheers,
>> Luc
>> On 06/20/2011 11:29 AM, Graham Klyne wrote:
>>> Luc Moreau wrote:
>>>> Hi Graham,
>>>> Thanks for your comments. You didn't respond to this point, I think:
>>>> >What is provenance-uri? is it unique? is provenance found at one 
>>>> and only one place? is there one and only one authority to provide 
>>>> provenance information about something?
>>> I thought I did, but if I did I was clearly not clear enough.  A 
>>> provenance URI is a URI that is used to identify the provenance of 
>>> some resource.
>>> Comments:
>>> - it may or may not be dereferencable (preferred web style is that 
>>> it is dereferencable, but that's not a requirement of being a 
>>> provenance URI).
>>> - it is not unique - there may be several such URIs for a resource 
>>> (but, presumably, the publisher of a resource may have a preferred 
>>> such URI)
>>> - therefore, there may be several sources for provenance about a 
>>> resource, but the general issue of which is to be considered an 
>>> "authority" is dependent on context that I submit is outside the 
>>> scope of the working group.
>>> I think this covers the scenarios to which you allude below.
>>> #g
>>> -- 
>>>> (see 
>>>> When we see a product/advert/etc (e.g. a box of cereals in a 
>>>> supermarket), we can
>>>> scan its barcode, get its identity, and its provenance from the 
>>>> manufacturer.
>>>> Your solution seems to support that.
>>>> I would also like to go to a 'consumer group' offering a provenance 
>>>> service, and get a different
>>>> account of the provenance of that product. That's why I suggest to 
>>>> separate the identity of the
>>>> 'thing' from the location where we retrieve provenance.
>>>> Of course, combing them (I and L) together provide a URI, from 
>>>> which provenance is retrieved.
>>>> So, on this point, we agree: no point inventing another protocol to 
>>>> retrieve provenance. The key
>>>> is to find where to retrieve provenance from.
>>>> Cheers,
>>>> Luc
>>>> On 06/20/2011 08:19 AM, Graham Klyne wrote:
>>>>> So that's it, I think my proposals cover the common cases.  I 
>>>>> recognize that I have not solved the case of a non-dereferenceable 
>>>>> provenance URI, of where the original server does not provide a 
>>>>> provenance URI, or where the server needs to know if provenance 
>>>>> may be required later when serving a resource.  But I see these as 
>>>>> orthogonal problems whose solutions we can better craft when we 
>>>>> have a basic common-case framework in place, and I can imagine 
>>>>> possible solutions for both of these (both essentially third-party 
>>>>> information services that do not need to be provenance-specific).  
>>>>> I was always clear that my proposals were not exhaustive, but I do 
>>>>> think they form a sufficient basis for initial work.

Professor Luc Moreau
Electronics and Computer Science   tel:   +44 23 8059 4487
University of Southampton          fax:   +44 23 8059 2865
Southampton SO17 1BJ               email:
United Kingdom           

Received on Monday, 20 June 2011 15:48:29 UTC