Re: PAQ document update, target renamed as context

On 21/08/2011 17:54, Olaf Hartig wrote:
> 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.

Is this true?  I just looked through 
http://www.w3.org/TR/html401/struct/links.html and couldn't spot what was being 
violated, but I could well be missing something.


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

It depends if you mean "not specify" == "ignore".  In drafting this section, I 
was trying to acknowledge (i.e. not ignore) the possibility of embedded 
provenance, but also to avoid trying to specify something whose need is not yet 
sufficiently understood.

So while I don't rule out adding something in this area, I think we should focus 
initially on getting agreement around the cases for which there are clearer 
choices and requirements.

For the use-case you mention, for provenance bound to its data, I would probably 
suggest some wrapper format (e.g. something based on multipart/related 
content-type).  But I think there's too much other work going on in this space 
to assume that would be the most appropriate overall solution.

#g
--

Received on Thursday, 25 August 2011 13:51:55 UTC