Re: PAQ document update, target renamed as context

Yogesh,

Many thanks for these.  Most have been incorporated per [1].  I have a questions 
about a couple.  Further responses inline.

[1] http://dvcs.w3.org/hg/prov/raw-file/deb150cfc5af/paq/provenance-access.html

Yogesh Simmhan wrote:
> 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? 

That is not prohibited, but not what I primarily intended.

I've added this: "Some given provenance information may use multiple 
context-URIs if there are provenance assertions referring to the same underlying 
resource in different contexts.  For example, a provenance resource describing a 
W3C document might include information about all revisions of the document using 
statements that use the different context-URIs for the revisions."


> == 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

Done.

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

Fixed.  Was typo in the definition.


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

It's true, and not entirely accidiental.  I figure that if I hyperlink *every* 
occurrence the text would look a bit cluttered, so I'm trying to select key 
occurrences in each section or paragraph.  If this is a problem, we can review.

For now, I'll try to use a rough rule of thumb of not hyperlinking a given term 
more than once in any paragraph.  We could make that per sub-section.  Another 
rule of thumb would be that the reader should be able to find a hyperlink for a 
key term within a screenful of text containing that term.


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

Yes, thanks.

> 
> *) "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?

Yes: I've changed that to: "(Mechanisms that can be independent of the resource 
provision are discussed in section 4. Provenance discovery services)"

> 
> == 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 think I see.  I've changed "for the requested resource" to "associated with 
the requested resource", which I think conveys a looser binding.

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

I think I see your point, but I am concerned that making that possibility 
explicit here might be confusing for a reader.  I wonder if this would be better 
served by a new sub-section in sect 2 about interpreting provenance information?

I've tagged this as an issue in the document for now.

> 
> *) "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?

Yes, this is a point that needs clarifying.  It is also a (small) difference 
between using "Link anchor=..." vs two separate link headers.

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

Thanks:)  If a new subsection is introduced dealing with interpretation of 
provenance, I think this could be covered there.  I see it as related to the 
context-URIs issue you raise.

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

I was in two minds about leaving that reference in.  The reason I did was that 
it discusses the correspondence between HTTP link headers and HTML <link> 
elements, and provides some general background information.  In view of your 
comment, I'm inclined to remove the note.

Separately, using an absolute URI would have an advantage of making the HTML 
more directly aligned with RDF usage (if we use the RDF property URI), but the 
disadvantage of requiring a harder-to-remember URI rather than a fairly 
intuitive name.  My intuition is that it would be more approachable for authors 
and developers creating HTML to just use the name.

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

(In case I wasn't clear before, I agree with your position of this being SHOULD 
rather than MUST.)

Again, I wonder if this is better addressed in a new sub-section towards the front.

> *) "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?

Done.

> == 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?

This is a new section, pending wider review.  It's a fairly radical change from 
what I did before, so I guess I was waiting to see if people were happy with the 
general approach, before fully integrating it.

I've added an "issue" note to the document so this point doesn't get lost.

> *) Since we call it provenance-service-uri here, should the concepts section
> (Sec 1.1) also call it the same rather than Service-URI?

I agree it would be better to be consistent; my current inclination is to change 
the text here to just say "service-URI" (and cross-link), which I've done.

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

I'm not sure I understand the concern/confusion here.  I am guessing this refers 
to the fact that, as defined, a provenance-service can return either 
provenance-URIs, provenance information or both.  Cf. section 4.1.  I'm still 
not sure that both these cases are needed, as they do represent a degree of 
overlapping functionality, but I can't say which one (if any) might be eliminated.

If this is not it, can you give a more con crete example?

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

Good point.  Rephased as: "though, in simple cases, we anticipate that 
provenance and provenance-service link relations would not both be used".

> == 3.4 ==
> *) "use the format-specific metadata to include a context-URI and/or
> provenance-URI"
> - and/or a provenance service URI

Good catch.  Done.

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

Revised that para to read "For formats which have provision for including 
metadata within the file (e.g. JPEG images, PDF documents, etc.), use the 
format-specific metadata to include a context-URI, provenance-URI and/or 
service-URI. Format-specific metadata provision might also be used to include 
provenance information directly in the resource"

#g
--


> --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 Friday, 19 August 2011 14:06:12 UTC