Change Proposal for HttpRange-14

Hi there,

Hopefully you're all aware that there's a Call for Change Proposals [1] to amend the TAG's long-standing HttpRange-14 decision [2]. Jonathan Rees has put together a specification that expresses that decision in a more formal way [3], against which changes need to be made.

Leigh Dodds, Dave Reynolds, Ian Davis and I have put together a Change Proposal [4], which I've copied below.

From a publishing perspective, the basic change is that it becomes acceptable for publishers to publish data about non-information resources with a 200 response; if a publisher want to provide licensing/provenance information they can use a wdrs:describedby statement to point to a separate resource about which such information could be provided.

From a consumption perspective, the basic change is that consumers can no longer assume that a 2XX response implies that the resource is an information resource, though they can make that inference if the resource is the object of a wdrs:describedby statement or has been reached by following a 303 redirection of a 'describedby' Link header.

The aim of this email is not to start a discussion about the merits of this or any other Change Proposal, but to make a very simple request: if you agree with these changes, please can you add your name to the document at:

  https://docs.google.com/document/d/1aSI7LpD4UDuHiDNqx8qN1W400QeZdzWYD-CRuU0Xmk0/edit

That document also contains a link to the Google Doc version of the proposal [4] if you want to add comments.

We will not be making substantive changes to this Change Proposal: if you want to suggest a different set of changes to the HttpRange-14 decision, I heartily recommend that you create a Change Proposal yourself! :) You should feel free to use this Change Proposal as a basis for yours if you want. Note that the deadline for doing so is 29th March (ie one week from today) so that the proposals can be discussed at the TAG F2F meeting the following week.

Thanks,

Jeni

[1] http://www.w3.org/2001/tag/doc/uddp/change-proposal-call.html
[2] http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html
[3] http://www.w3.org/2001/tag/doc/uddp/
[4] https://docs.google.com/document/d/1ognNNOIcghga9ltQdoi-CvbNS8q-dOzJjhMutJ7_vZo/edit

---
Summary

This proposal contains two substantive changes.

First, it enables publishers to link to URI documentation for a given probe URI by providing a 200 response to that probe URI that contains a statement including a ‘describedby’ relationship from the probe URI to the URI documentation.

Second, a 200 response to a probe URI no longer implies that the probe URI identifies an information resource; instead, this can only be inferred if the probe URI is the object of a ‘describedby’ relationship.

Rationale

While there are instances of linked data websites using 303 redirections, there are also many examples of people making statements about URIs (particularly using HTML link relations, RDFa, microdata, and microformats) where those statements indicate that the URI is supposed to identify a non-information resource such as a Person or Book.

Rather than simply telling these people that they are Doing It Wrong, “Understanding URI Hosting Practice as Support for URI Documentation Discovery” should ensure that:

 * applications that interpret such data do not draw wrong conclusions about these URIs simply because they return a 200 response without a describedby Link header
 * publishers of this data can easily upgrade to making the distinction between the non-information resource that the page holds information about and the information resource that is the page itself, should they discover that they need to

Details

In section 4.1, in place of the second paragraph and following list, substitute:

  There are three ways to locate a URI documentation link in an HTTP response:

  * using the Location: response header of a 303 See Other response [httpbis-2], 
    e.g.

    303 See Other
    Location: http://example.com/uri-documentation>

  • using a Link: response header with link relation 'describedby' ([rfc5988], 
    [powder]), e.g.

    200 OK
    Link: <http://example.com/uri-documentation>; rel="describedby"

  • using a ‘describedby’ ([powder]) relationship within the RDF graph created 
    by interpreting the content of a 200 response, eg:

    200 OK
    Content-Type: text/turtle

    PREFIX :<http://www.iana.org/assignments/relation/>
    <http://example.com> 
      :describedby <http://example.com/uri-documentation> ;
      .

Before the last paragraph of section 4.2 insert the following two paragraphs:

  In the third case, where the ‘describedby’ relationship is used, 
  <http://www.iana.org/assignments/relation/describedby> and 
  <http://www.w3.org/2007/05/powder-s#describedby> must be treated as equivalent, 
  as defined in Section 4.1.4 Semantic Linkage Using the describedby Property of 
  the POWDER Recommendation [powder].

In the last paragraph of section 4.1, for “(But see below for the case when retrieval is successful.)” substitute “The next section describes how to interpret a 200 response, and therefore applies in the last two cases described above.”

In section 4.2, in place of the first paragraph (after the Editorial Note), substitute:

  If there is a nominal representation Z from the probe URI (a 2XX response), 
  and the application is aware of a ‘describedby’ relationship of which the 
  probe URI is the object, which may be the case because

  * the probe URI is itself a URI linked to through one of the mechanisms 
    listed in Section 4.1 or
  * Z itself contains a statement in which the probe URI is the object of a 
    ‘describedby’ relationship

  then this is equivalent to there being a nominal URI documentation carrier 
  for the probe URI that says that Z is a current representation of the 
  resource identified by the probe URI, and, moreover, that the identified 
  resource is an "information resource" (see below). In other cases, no such 
  inference can be made (the application cannot tell whether the probe URI 
  identifies an information resource or not).

We also recommend that a clear guide on best practices when publishing and consuming data should be written, possibly an update to [cooluris].

Impact

Positive Effects

  * common usage of URIs in sites supporting RDFa, microdata and microformats are no longer deemed to be Doing It Wrong, which means this data can be interpreted in the way that it was intended by those publishers by conformant applications
  * publishers that cannot change server configuration (to use 303s or Link headers) can still use separate URIs to identify a non-information resource and the information resource that describes it
  * publishers who (through ignorance or preference) originally publish data about non-information resources without using 303s or Link headers can retain those URIs and add the ‘describedby’ statement 
  * it is possible to have multiple description documents for a given URI, where a 303 response only allows one
  * it means the same method can be used to provide descriptions of non-information resources as is used for providing descriptions of information resources, which aids adoption
  * it means there is a standard method for providing links from documentation to the thing that it documented

Negative Effects

  * existing applications that assume that a 200 response is only given for an information resource may make false inferences about what a probe URI identifies (but this happens already, as people already publish data in this way)
  * there are more cases where applications will have to draw on reasoning from other properties (eg declared types of resources) to work out what a URI identifies
  * where a URI is intended to identify a NIR but provides a 200 response, there remains no method of addressing the documentation that is returned by that 200 response (to assert its license, provenance etc); a set of best practices for linked data publishers would need to spell out what publishers should do and how consumers should interpret the information provided within the response and that found at the end of any ‘describedby’ links

Conformance Classes Changes

There is no mention of conformance classes in the document.

Risks

There are no risks.

References

[cooluris]
Leo Sauermann and Richard Cyganiak. Cool URIs for the Semantic Web. W3C Interest Group Note, 03 December 2008. (See http://www.w3.org/TR/2008/NOTE-cooluris-20081203/.)
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Thursday, 22 March 2012 20:21:46 UTC