Access and Query Task Force Status at F2F1 Simon Miles

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

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

Scoping questions  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?  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.

Summary of proposals  Use HTTP Link to give a URI for a thing’s provenance  Use HTTP to retrieve the provenance of a thing, given a URI for that provenance  Use HTTP to retrieve the location of a provenance service with data on a thing’s provenance  A provenance service as a SPARQL Graph Store or variant  A RESTful provenance service where the thing’s metadata expresses how to parameterise access  Use HTML Link to give a URI for a thing’s provenance  Use an HTML Profile for provenance metadata  User POWDER metadata to give a default provenance service  Use HTML Meta or microdata to give provenance access info

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).

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

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