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

Re: Query and access F2F document template

From: Graham Klyne <GK@ninebynine.org>
Date: Thu, 09 Jun 2011 13:44:37 +0100
Message-ID: <4DF0C035.6020700@ninebynine.org>
To: Simon Miles <simon.miles@kcl.ac.uk>
CC: Provenance Working Group WG <public-prov-wg@w3.org>
Simon,

I've just managed to put some proposal details into the wiki:

http://www.w3.org/2011/prov/wiki/F2F1_Access_and_Query_Proposal#Accessing_provenance_information

I haven't used your skeleton section headings, because they didn't immediately 
fit what I was planning to draft, but I think their intent has been expounded.

Mainly I wanted to capture a separation between the low-level access mechanism 
and discovery of the URI used to access the provenance.  We can review that and 
decide whether to reallocate/adapt materials to your headings, or accept mine.

#g
--

Graham Klyne wrote:
> Simon, I think this is in line with what I have in mind.  I'm intending 
> to spend some time tomorrow (Thursday) on this.
> 
> #g
> -- 
> 
> Simon Miles wrote:
>> Graham,
>>
>> Thanks. Yes, I agree your scope limitation and the two cases suggested
>> make sense, at least with regard to explaining POWDER's approach.
>>
>> As for terminology, please feel free to raise specific concerns. My
>> feeling is that we would ideally write something which can immediately
>> make sense to someone developing a web client application which
>> provides access to the provenance of data it manipulates, which I take
>> to mean using language intuitive for the web in general but also not
>> being ambiguous. Any suggestion in meeting this ideal is gratefully
>> received.
>>
>> Thanks,
>> Simon
>>
>> On 6 June 2011 09:53, Graham Klyne <GK@ninebynine.org> wrote:
>>> Simon,
>>>
>>> I've made a note to come up with something.  In the first instance, I 
>>> imagine it
>>> being very scope-limited, and may be hedged with operational 
>>> restrictions, but I
>>> think that's in line with your approach.
>>>
>>> Specifically, I think there are two cases to consider initially:
>>> (1) given the URI of any document retrieved via HTTP, to obtain its 
>>> provenance
>>> (2) given an HTML document obtained by any means, to obtain its 
>>> provenance
>>>
>>> (I'm still a little concerned/confused by the way that the 
>>> terminology of
>>> resources and representations is being used, but I propose to prepare 
>>> something
>>> concrete then figure how it sits with the terminological approach.)
>>>
>>> #g
>>> -- 
>>>
>>>
>>> Simon Miles wrote:
>>>> Hello all (and A&Q TF especially),
>>>>
>>>> Yogesh, the WG chairs and I would like to propose a skeleton for the
>>>> document that the query and access TF will supply for the F2F1
>>>> meeting.
>>>>
>>>> A key aspect of this document is that, due to the short time before
>>>> the meeting, it is deliberately narrow in scope.  As agreed following
>>>> Olaf's prior proposals, we want to build on the incubator group
>>>> chapter 6, by taking aims and assumptions from that document.
>>>> However, we've reduced these to two key questions (suggested by Luc)
>>>> for the F2F1:
>>>>  1. Given the identity, I, of a resource state representation and a
>>>> location, L, from which to retrieve provenance, how do we obtain the
>>>> provenance of the representation from the location?
>>>>  2. How can a browser find I and L (as above) for an HTML document
>>>> that was downloaded, so that its provenance may be retrieved?
>>>>
>>>> Please see the rest of the document skeleton for details:
>>>>   http://www.w3.org/2011/prov/wiki/F2F1_Access_and_Query_Proposal
>>>>
>>>> We welcome any comments on the skeleton structure proposed, including
>>>> the scope decided for this document.
>>>>
>>>> One specific request to Graham: you suggested Section 4 of the POWDER
>>>> as providing a solution for the above questions (at least with regard
>>>> to HTTP, HTML, ATOM). It looks straightforward enough to me what such
>>>> a solution would look like (the same as described in the POWDER
>>>> proposal but with provenance specific MIME types?), but it would be
>>>> very helpful if you could sketch the proposal on the Wiki page as you
>>>> understand it best.
>>>>
>>>> Thanks,
>>>> Simon
>>>>
>>>
>>> ______________________________________________________________________
>>> This email has been scanned by the MessageLabs Email Security System.
>>> For more information please visit http://www.messagelabs.com/email
>>> ______________________________________________________________________
>>>
>>
>>
>>
> 
> 
Received on Thursday, 9 June 2011 12:47:22 GMT

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