Re: Access and query TF - actions for WG

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?

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?


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 12:03:02 UTC