1 / 12

Access and Query Task Force Status at F2F1

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:

blaise
Télécharger la présentation

Access and Query Task Force Status at F2F1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Access and Query Task ForceStatus 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

More Related