1. Access and Query Task Force Status at F2F1 Simon Miles

2. Starting point  The WG agreed to use the report of the W3C incubator group on provenance as a starting point for discussing access and query of provenance  This refers to:  Passing provenance of resource state representations via HTTP by value, by reference, or mixed  Embedding provenance or references to it in HTTP messages, or in HTML, RDF or other representations supporting embedded metadata  Negotiation over the kind, granularity and form of provenance they receive

3. Scope for F2F1  For the first F2F, we solicited proposals to address two provenance access questions  Because they were inspired by the XG report, they made particular assumptions about the form of access information  The proposals did not all share the same initial assumptions, and so the questions were generalised to reflect this

4. Scoping questions (generalised)  Given information regarding where to access data on the provenance of a resource state representation, what form does that information take and how do we obtain the provenance data?  How can a browser find the information on where to access provenance data, referred to above, for an HTML document that was downloaded, so that its provenance may be retrieved?

5. Multiple URIs  These questions were originally expressed with the assumption that the information took the form of an identifier for the representation, I, plus a location from which to retrieve it, L. The second question then assumed that I and L are embedded in the HTML document.  In fact, the proposals referred to multiple URIs:  R: The URI of the resource  I: The URI of the resource state representation  L:The URI of some provenance service  P:The URI of some provenance information

6. Summary of proposals for Q1  Use HTTP Link in response to accessing the resource (R) to give a URI for a thing’s provenance (P)  Use HTTP to GET the provenance of a thing, by deferencing a URI for that provenance (P)  Use HTTP to GET the provenance of a thing (I) from a provenance service (L)  Use a SPARQL endpoint as as provenance service (L)  A RESTful provenance service (L) where the thing’s (I) metadata expresses how to parameterise access

7. Summary of proposals for Q2  Use HTML Link to give a URI for a page’s provenance (P)  Use an HTML Profile for provenance metadata (I + L)  User POWDER metadata to give a default provenance service (L)  Use HTML Meta or microdata to give provenance access info (I + L)

8. Suggested guiding principles  Graham proposed some principles, which I try to paraphrase below:  Aim to use simple solutions unless the requirement for more complex ones is presented  Justify why any complexity is introduced  Work by iterating over a draft of the final deliverable

9. Suggested decision points (1)  There may be data regarding the provenance of a thing accessible from multiple sources.  The information required to obtain access to some provenance of a thing may be supplied in many different ways, and we do not aim to enumerate them all.  The WG effort will concern how the provider of a thing can supply information required to obtain access to some provenance of that thing (which may, as a side effect, include recommendations on how others can do the same).

10. Suggested decision points (2)  Regarding some provenance data obtained from dereferencing a provenance URI, calling a provenance service, or some other means. Which of the following is true?  (a) It is apparent from the data itself what single thing it describes the provenance of.  (b) Provenance data documents a set of things and how they are related by past occurrences, so to extract the provenance of any one thing requires knowing how it is identified in the data.  (c) Something else.  Regarding some provenance data obtained from dereferencing a provenance URI, calling a provenance service, or some other means. Which of the following is true?  (a) To meet the standard, it should be immutable.  (b) It can change over time without restriction.  (c) To meet the standard, there are particular ways in which it should not change, e.g. any one account should remain as it was

11. Suggested decision points (3)  We should use HTTP negotiation to determine the format of provenance information accessed, rather than specifying another mechanism  We should use queries (i.e. SPARQL) to determine the content of provenance information accessed, e.g. granularity, rather than specifying another mechanism

12. Future work and further issues  The TF needs to determine how it decides between competing proposals  This may mean  agreeing general points as above  adopting simple solutions before considering complex ones  justifying by reference to use cases  Other issues raised by the group:  Guidance for publishers of provenance  Provenance moving from one location to another  Specifying multiple provenance sources in one embedding  Ensuring data and provenance can be kept within the same file