--- a/paq/provenance-access.html Tue Aug 09 17:42:57 2011 +0100
+++ b/paq/provenance-access.html Tue Aug 09 17:59:12 2011 +0100
@@ -110,31 +110,33 @@
<p>
@@TODO Introductory text
</p>
- <h2>Concepts</h2>
- <p>
- In defining the specification below, we make use of the following concepts.
- <dl>
- <dt>Provenance information</dt>
- <dd>refers to provenance represented in some fashion.</dd>
- <dt>Provenenance-URI</dt>
- <dd>A URI denoting some provenance information.</dd>
- <dt>Target</dt>
- <dd>an entity about which one wants to know the provenance.</dd>
- <dt>Target-URI</dt>
- <dd>a URI denoting a target, which allows the target to be found in some provenance information.</dd>
- <dt>Provenance service</dt>
- <dd>a service that provides a Provenance-URI or provenance information given a Target-URI.</dd>
- <dt>Service-URI</dt>
- <dd>the URI of a Provenance Service.</dd>
- <dt>Resource</dt>
- <dd>a web resource. A resource may be associated with multiple targets, which may correspond to different IVPs of the original resource.</dd>
- </dl>
- </p>
+ <section>
+ <h2>Concepts</h2>
+ <p>
+ In defining the specification below, we make use of the following concepts.
+ <dl>
+ <dt>Provenance information</dt>
+ <dd>refers to provenance represented in some fashion.</dd>
+ <dt>Provenenance-URI</dt>
+ <dd>A URI denoting some provenance information.</dd>
+ <dt>Target</dt>
+ <dd>an entity about which one wants to know the provenance.</dd>
+ <dt>Target-URI</dt>
+ <dd>a URI denoting a target, which allows the target to be found in some provenance information.</dd>
+ <dt>Provenance service</dt>
+ <dd>a service that provides a Provenance-URI or provenance information given a Target-URI.</dd>
+ <dt>Service-URI</dt>
+ <dd>the URI of a Provenance Service.</dd>
+ <dt>Resource</dt>
+ <dd>a web resource. A resource may be associated with multiple targets, which may correspond to different IVPs of the original resource.</dd>
+ </dl>
+ </p>
- <p class="issue">
- Say something about resources and targets and IVP. Probably needs to refer to the model document discussion of IVP. Roughly, "target" is an IVP of some web resource (which may just be the resource itself. Also discuss that provenance information is expected to be static: it is only meaningful to the extent that is is always true for the designated target. Example provenance about weather in London at http://www.metoffice.gov.uk/weather/uk/se/london_forecast_weather.html might reasonably say that it is published by the Met Office. But a claim that "Updated: 1641 on Tue 9 Aug 2011" would be true only for an IVP of that resource in a constrained time window.
- </p>
+ <p class="issue">
+ Say something about resources and targets and IVP. Probably needs to refer to the model document discussion of IVP. Roughly, "target" is an IVP of some web resource (which may just be the resource itself. Also discuss that provenance information is expected to be static: it is only meaningful to the extent that is is always true for the designated target. Example provenance about weather in London at http://www.metoffice.gov.uk/weather/uk/se/london_forecast_weather.html might reasonably say that it is published by the Met Office. But a claim that "Updated: 1641 on Tue 9 Aug 2011" would be true only for an IVP of that resource in a constrained time window.
+ </p>
+ </section>
</section>
@@ -721,23 +723,8 @@
There are clearly a number of capabilities needed for a provenance-aware application that are not covered by the mechanisms described above. But most of these amount to implementation details and decisions for a particular application, and as such are beyond the scope of this document to specify.
</p>
<p>
- One feature not covered above that might be a candidate for specification is a common format for a data package that combines original content along with provenance-related metadata or data. At this stage, it is not clear what format that might take, but some possible candidates are:
- <ul>
- <li>MIME multipart/related [[RFC2387]]: both email and HTTP are based on MIME or MIME-derivatives, so this has the advantage of working well with the network transfer mechanisms discussed in the scenario.
- </li>
- <li>
- Composite object-packaging work from the digital library community, or which there are several (ORE, MPEG-21, BagIt @@refs) to name a handful. Practical implementations of these seem to commonly be based on the ZIP file format.
- </li>
- <li>
- Packaging formats along the lines of those used for shipping Java web applications or (basically, a ZIP file with a manifest and some imposed structure)
- </li>
- <li>
- Ongoing work in the research community (e.g. <a href="http://eprints.ecs.soton.ac.uk/21587/">Why Linked Data is Not Enough for Scientists</a>, ePub, etc.) to encapsulate data, code, annotations and metadata into a common exchangeable format.
- </li>
- </ul>
- </p>
- <p>
- Given the extent of work already performed in this field, it seems to me that rather than recommending a particular approach at this stage, we would do better to catalogue some available solutions and see which ones (if any) that implementers choose to run with. In any case, it seems that a specification that is specific for provenance to the exclusion of other metadata is unlikely to obtain traction, as provenance is just part of a wider landscape of information quality, trust, preservation and more.
+ One feature not covered above that might be a candidate for specification is a common format for a data package that combines original content along with provenance-related metadata or data. At this stage, it is not clear what format that might take, but some possible candidates are discussed in <a href="#arbitrary-target" class="sectionRef"></a>.
+ In any case, it seems to me that a specification that is specific for provenance to the exclusion of other metadata is unlikely to obtain traction, as provenance is just part of a wider landscape of information quality, trust, preservation and more.
</p>
</section>
</section>