RE: PAQ document update, target renamed as context

Hi Graham,

Here are a bag of comments for Sec 1-3 of the latest revision.

== Sec 1.2 ==
*) "The context-URI used to describe this restricted view of a resource is also
related to the resource itself, and requests for provenance about that resource
may return provenance information that uses one or more context-URIs to refer to
it."
- Do you mean there may be multiple context-uri's that refer to that same view
of a resource, and these context-uri's may appear in the provenance information
for that view of a resource? 

== Sec 2 ==
*) "Thus, any provenance information may be associated with a URI, ..."
- Call it "Provenace-URI" and link to the concept definition in Sec 1.1
*) "...and provision is made for the provenance-URI to be discoverable"
- Somehow, hyperlinks to "provenance-URI" concept definition does not seem work.
i.e. they are formated like links but dont have a target url.

== Sec 3 ==
*) "The provenance-URI may be known in advance, ..."
- Hyperlink of provenance-uri and other concept definitions seem to be
inconsistent. Present in many places, missing in some.

*) "Once provenance information information is retrieved, one needs how to
identify the view ..."
- I believe it should be "one needs to know how to".

*) "Because the resource provider controls the response when the resource is
accessed, direct indication of these URIs is possible."
- We just finished saying that provenance may be provided by others besides the
resource provider ("...could be provided by parties other than the provider of
the original resource."). Should we state that we dont consider third party
scenarios here, but later in Sec 4?

== Sec 3.1 ==
*) "When used in conjunction with an HTTP success response code (2xx), this HTTP
header indicates that provenance-URI is the URI of some provenance for the
requested resource and that the associated context is identified as
context-URI."
- The provenance-URI is for the resource context described by the context-URI,
not necessarilly for the requested resource (though it is, by default, if the
anchor is missing). We seem to be imposing a restriction that the context-URI
should describe the requested resource. Suggest rewording.
- I believe there is no guarantee that the provenance-URI will provide
provenance information about the context-URI. Suggest we use *should* rather
than (implicitly) *must* to state that the returned provenance-uri should have
provenance information about the resource view identified by the context-uri.

*) "An HTTP response may include multiple provenance link headers... Likewise,
an HTTP response may include... "
- Besides the above issue of the provenance being related to the resource being
accessed (rather than the context-uri), I would like some clarity on what the
multiple "anchor" mean. I would expect when multiple provenance-URIs and
context-URIs are returned through multiple "Link:" headers, then one or all the
provenance-URIs *may* describe one or all the context-URIs. It is upto the
accessor to access each of the provenance-URIs to determine which of them
describe which context-URIs. If this is indeed the intention, can it be made
clearer? Also, it is not clear what resource you mean by "the resource may": the
provenance resource or the resource being accessed by the HTTP GET/HEAD?

*) "ISSUE: Are the provenance resources indicated in this way to be considered
authoritative?"
- +1 for handling trust in provenance independently.

== Sec 3.2 ==
*) The "Appendix A. Notes on Using the Link Header with the HTML4 Format"
suggests three possible ways of serializing extension relationship types (such
as "provenance") into HTML4: an absolute URI, using the HEAD element's profile
attribute prefix, or an RDFa namespace prefix. We seem to be using none of the
three and the "provenance" relationship we use in the "rel" attribute is not a
URI. Should we instead adopt an absolute URI for the relationship type (e.g.
"http://www.w3.org/2011/prov/linktype/provenance") or reuse the RDFa's
prov:hasProvenance that we introduce? Or is my reading of that appendix entry
incorrect and does not apply to extension relation types that are registered
with IETF? Ditto for the "anchor" relation.

*) "The provenance-URI given by the provenance link element identifies the
provenance-URI for the document. ..."
- I have concerns as before for HTTP Web Links on whether the context-URI *must*
describe the document (or prior views) and the provenance-URI *must* have
provenance information about the resoure views identified by the context-URIs,
or they *should* in both cases. I prefer the latter, with the possiblity of
providing context-URIs for resources other than the current document, and
provenance-URIs of resource views other than the current document.
*) "indicating a number of different resources that are known to the creator of
the document"
- Can we state "provenance resources" rather than an unqualified "resource" for
clarity?

== Sec 3.2.1 ==
*) Any reason why provenance service URI relation has not been added to the HTTP
Web Linking section as a new relation type? Is is just to finish discussions
about the relation before just migrating its use to HTTP Web Linking?
*) Since we call it provenance-service-uri here, should the concepts section
(Sec 1.1) also call it the same rather than Service-URI?
*) One confusion I had was that a provenance service URI may also be used to
dereference a provenance URI (e.g if the provenance URI were a urn:uuid:NNN).
Re-reading the Concepts, it was not the case and it was only used to query by
context-URI. Not sure if an explicit disambiguation is required.
*) "though, in practice, there may be little point in providing both provenance
and provenance-service links"
- One reason may be that just a single provenance-URI is provided as part of the
document or resource access (for direct access to provenance without an extra
roundtrip), but several others may be retrieved using the provenance service URI
for more detailed comparisons.

== 3.4 ==
*) "use the format-specific metadata to include a context-URI and/or
provenance-URI"
- and/or a provenance service URI
- An additional option may be to embed the provenance information directly
within the metadata. I know Yolanda brought this up earlier
(http://www.w3.org/2011/prov/wiki/F2F1_Access_and_Query_Proposal#Issues_beyond_s
cope)

Best,
--Yogesh

| -----Original Message-----
| From: public-prov-wg-request@w3.org [mailto:public-prov-wg-request@w3.org]
| On Behalf Of Graham Klyne
| Sent: Wednesday, August 17, 2011 7:21 AM
| To: Paul Groth; Yogesh Simmhan; W3C provenance WG
| Subject: PAQ document update, target renamed as context
| 
| Hi,
| 
| Following discussions with Paul, and also with reference to ISSUE 74
| (http://www.w3.org/2011/prov/track/issues/74), I've made an editorial pass
| through the document to change references to "target" to "context", in line
with
| RFC5988 usage.  I've renamed the corresponding link relation type to be
| "anchor", consistent with usage in defining the HTTP Link: header.
| 
| I have also added a new sub-section in the introduction which discusses the
| relationship between resources, contexts and provenance, which I believe
| captures the essence of discussions particularly between myself and Paul.
| There's probably some remaining work to align or connect this with terminology
| in the Model document, but my immediate focus has been to try to capture the
| essential details as they affect provenance access.
| 
|
http://dvcs.w3.org/hg/prov/raw-file/tip/paq/provenance-access.html#provenance--
| context-and-resources
| 
| #g
| --
|

Received on Thursday, 18 August 2011 00:43:03 UTC