Access and Query Task ForceStatus 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 (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?

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

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

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)

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

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

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

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