Re: Access and query TF - actions for WG

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 
> http://www.w3.org/2011/prov/wiki/F2F1_Access_and_Query_Proposal#Comments)
> 
> 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.
>

Received on Monday, 20 June 2011 11:44:12 UTC