Re: Access and query TF - actions for WG

Hi Khalid,

I agree with your point below. From a coordination point of view, I
suggest we keep the scope as it is until Thursday, giving everyone a
chance to comment on the current scope, proposals and issues, and then
revise the scope to better cover the proposals we have.


On 20 June 2011 19:40, Khalid Belhajjame <> wrote:
> Hi,
> 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.
> khalid
> 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.
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit
> ______________________________________________________________________

Dr Simon Miles
Lecturer, Department of Informatics
Kings College London, WC2R 2LS, UK
+44 (0)20 7848 1166

Received on Tuesday, 21 June 2011 12:32:14 UTC