- From: Graham Klyne <GK@ninebynine.org>
- Date: Thu, 09 Jun 2011 13:44:37 +0100
- 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 UTC