W3C home > Mailing lists > Public > public-prov-wg@w3.org > November 2011

Re: rel links in HTTP and HTML

From: Graham Klyne <graham.klyne@zoo.ox.ac.uk>
Date: Fri, 25 Nov 2011 08:20:50 +0000
Message-ID: <4ECF4FE2.6080106@zoo.ox.ac.uk>
To: Timothy Lebo <lebot@rpi.edu>
CC: Provenance Working Group WG <public-prov-wg@w3.org>
On 23/11/2011 16:34, Timothy Lebo wrote:
> Graham and Paul,
>
> I'm finally sitting down with the PAQ, and I'm pretty excited about the technique described in "Resource accessed by HTTP" [1]. The nice part about this is that HTTP can be used regardless of what type of content or format is being transferred. Further, one could "poll back" to see if any new provenance URIs show up.
>
>
> Very similar representational techniques are described in "Resource presented as HTML" [2], and the need for this is also clear because we want to "bake in" the provenance URIs so that they "go along for the ride" when copied and manipulated.
>
>
>
> Given the similar (identical?) rel link techniques across these two sections, I was curious about their association:
>
> 1) If the rel links are returned in HTTP, should they also appear in the HTML?
> 2) Should the rel links provided be equivalent in the HTML and HTTP?
>
>
> I recognize that I'm exposing some naivety with some of the HTTP fundamentals,

I don't think so.  It's a reasonable question.

Short answer:

My view is that there's no requirement for HTTP links to match HTML links.  An 
provider application may choose to do this, but is not required to do so.

Longer answer:

The intent of this document was to show how existing features of the web can be 
used to provide access and query capabilities to provenance data.  It is not, of 
itself, normative.

For me, this document succeeds if it shows developers to write applications that 
provide access to and consume provenance information without inventing new 
protocols.

At this stage, it's not clear what the interoperability requirements will be. 
It's fairly clear from the early requirements that were raised against the 
original PAQ document there are a number of diverse views about how provenance 
information may be discovered and accessed, leading to a diversity of possible 
mechanisms.  Such diversity is not of itself conducive to universal 
interoperability.  I think that's fine as long as we're not creating new 
protocols:  when we have more real experience with actual provenance-generating 
and -using applications, we may be able to make some more specific recommendations.

So, for now, my view is that developers should be free to experiment with 
different combinations and learn what will work in practice.  Later (after this 
WG), we can try and codify that learning.  This means not placing arbitrary 
requirements on how they use existing mechanisms (other than those requirements 
that already exist for those mechanisms).

#g
--

> [1] http://dvcs.w3.org/hg/prov/raw-file/default/paq/provenance-access.html#resource-accessed-by-http
> [2] http://dvcs.w3.org/hg/prov/raw-file/default/paq/provenance-access.html#resource-presented-as-html
Received on Friday, 25 November 2011 10:11:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:04 UTC