Re: PAQ document update, target renamed as context

Hey,

On Saturday 20 August 2011 11:34:21 Graham Klyne wrote:
> Hi Yogesh,
> [...]
> > | > == 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.
> > 
> > I see your point and agree on the need for making it easy for authors.
> > But do you see us breaking compatibility with the appendix, especially
> > since it states: "Surveys of existing HTML content have shown that
> > unregistered link
> > 
> >    relation types that are not URIs are (perhaps inevitably) common.
> >    Consuming HTML implementations should not consider such unregistered
> >    short links to be errors, but rather relation types with a local
> >    scope (i.e., their meaning is specific and perhaps private to that
> >    document)."
> 
> I think I've now dropped that reference as causing more confusion than
> helpful information.  Responding to the substantive comment here, if we
> register the "provenance" relation type, I think the concern is addressed.
> 
> > Should we say that in HTML, authors should serialize the "provenance"
> > relation as (e.g.) "http://www.w3.org/2011/prov/rel/provenance" or
> > "provenance", but the former is preferred? Note that this does not apply
> > to the HTTP relation that can continue to be just "provenance" since it
> > is going to be a registered extension. On the other hand, if we do get
> > "provenance" registered as a HTTP web link extension relation, even
> > using "provenance" in HTML is credible.
> 
> I'd rather there not be alternatives - not good for interoperability.  I
> think we already have too many alternative ways of presenting things,
> which makes more work for consumers of provenance.

I agree with both of you, the simpler the better.
I just want to point out that by proposing the use of "provenance" instead of 
(e.g.) "http://www.w3.org/2011/prov/rel/provenance" we explicitly violate the 
HTML4 spec, which could be understood as contempt.

> [...]
> > | > - 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
> > | _bey ond_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"
> > 
> > I wonder if we should have an equivalent of this for HTML too (i.e.
> > embedding provenance directly into the document). Luc did have a comment
> > yesterday on the call about provenance by values and by reference. This
> > may be another issue to consider if it is in scope or not.
> 
> Similar comment to above.  This section is discursive, and to that extent
> it *can* apply to HTML too.  If there's a real need for this, another
> group can specify it.  I think we have more than enough coverage for now.

Are you saying that we should ignore the possibility of embedded provenance?
When it comes to provenance-based quality (or trustworthiness) assessment, I 
would prefer provenance information that "travels" with the data it is about, 
instead of relying (solely) on provenance services (that might not work 
anymore when I want to do the assessment). Hence, I would consider embedded 
provenance as a real need.

Greetings,
Olaf

Received on Sunday, 21 August 2011 16:55:35 UTC