Fwd: Change Proposal for HttpRange-14

FYI

---------- Forwarded message ----------
From: Jeni Tennison <jeni@jenitennison.com>
Date: 22 March 2012 21:21
Subject: Change Proposal for HttpRange-14
To: public-lod community <public-lod@w3.org>
Cc: Jonathan A Rees <rees@mumble.net>, Leigh Dodds <leigh@ldodds.com>, Dave
Reynolds <dave@epimorphics.com>, Ian Davis <me@iandavis.com>


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