W3C home > Mailing lists > Public > public-prov-wg@w3.org > June 2011

Re: Access and query TF - actions for WG

From: Simon Miles <simon.miles@kcl.ac.uk>
Date: Tue, 21 Jun 2011 13:31:36 +0100
Message-ID: <BANLkTim+rWzT5g=m3jCVr_2JSidUxeRoCA@mail.gmail.com>
To: Provenance Working Group WG <public-prov-wg@w3.org>
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.

Thanks,
Simon

On 20 June 2011 19:40, Khalid Belhajjame <Khalid.Belhajjame@cs.man.ac.uk> 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
>>>>> 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.
>>>>>
>>>>
>>>
>>
>>
>>
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>



-- 
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 13:06:31 GMT