Re: Access and query TF - actions for WG

Just for the record... I agree with the broad desiderata mentioned. I don't 
believe anything in my suggestions (elsewhere) limits these possibilities.

(The only thing I arguing against is a defined construction of identifiers to 
reflect this usage - per Web architecture, URIs whould be opaque strings.)

#g
--

Myers, Jim wrote:
> Without entering the dialog on access mechanism directly, I would like
> to note that there are examples where people have decided there's a need
> to distinguish thing and thing-as-curated-by-serviceX - The ARK
> identifier scheme, and Steven Kunze's discussion of why a two-part
> identifier (curator/thing) is valuable, is one reference, and I believe
> the Europeana Data model, where they've introduced 'proxies' for things
> that are where they hang information about the thing 'as known by' an
> organization is another. Both of these examples involve use cases where
> distributed independent actors may have knowledge of data/things they do
> not own/do not provide access to (perhaps they have copies), which seems
> like something we'll have if, for example bloggers don't keep a copy of
> the government data but do keep metadata about it.
> 
> What we decide about accounts may also influence the access mechanism...
> 
>  Jim
> 
>> -----Original Message-----
>> From: public-prov-wg-request@w3.org [mailto:public-prov-wg-
>> request@w3.org] On Behalf Of Luc Moreau
>> Sent: Monday, June 20, 2011 11:48 AM
>> To: Graham Klyne
>> Cc: public-prov-wg@w3.org
>> Subject: Re: Access and query TF - actions for WG
>>
>> Hi Graham,
>>
>> A question is interleaved.
>>
>> On 06/20/2011 02:40 PM, 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.)
>>
>> OK, I can use HTTP HEAD in order to obtain provenance-URI for some
> resource.
>> This provenance-URI will be returned by the same service as the one
>> providing the resource.
>>
>> How can I obtain an alternative provenance from another service?  I
>> don't understand I
>> would get an alternative provenance-URI?
>>
>> Luc
>>
>>> #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#Com
>> ments)
>>>>>>
>>>>>> 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.
>> --
>> Professor Luc Moreau
>> Electronics and Computer Science   tel:   +44 23 8059 4487
>> University of Southampton          fax:   +44 23 8059 2865
>> Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
>> United Kingdom                     http://www.ecs.soton.ac.uk/~lavm
>>
> 
> 
>

Received on Wednesday, 22 June 2011 08:38:48 UTC