Re: Access and query TF - actions for WG


I think the discussion in this thread calls for a clarification 
(reformulation) in the scope section.

It seems so far that there is an agreement that a URI that identifies 
the provenance of a thing should be provided, and there is disagreement 
on whether we should specify the location or the mechanism (service) 
used to locate the provenance.
This does not seem to be reflected in the scope section, where the 
location of where the provenance is to be retrieved is given and the 
identity of provenance is not.


On 20/06/2011 14:40, 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.)
> #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.

Received on Monday, 20 June 2011 18:39:59 UTC