Re: Access and query TF - actions for WG

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 
>>> 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 13:44:56 UTC