Re: Change Proposal for HttpRange-14

Thank you Jenny, Leigh, Dave and Ian and Jonathan.
I was quite excited about Jonathan's request to start with, but then decided that the context for the decision was probably much the same as before, and so there was unlikely to be much change.
I would have hoped that by now the context in which we work would include large numbers of people who were building apps that consumed LD, and so could report whether a change would cause them a problem.
In my case, I am pretty sure there is no problem - in fact, as a developer I should be ashamed to build a system that was so sensitive to its input data that it broke if people did not adhere to the standard.

I wonder, do we have more knowledge and experience than last time?

So my question here is to people who have built a real app that consumes LD, by which I mean something in use every day by someone other than the builder and their friends - preferably where someone paid you to do it.

***Would your app break under this proposal?***

My basis for supporting this change proposal is that our experience is that apps do not break, and so I would be really keen to hear about counter-examples to show me I am wrong.
Although we may all be bored with the endless discussions, I think that it may actually be make-or-break for LD as it stands.

By the way, I read Giovanni's email as intending irony.

Best
Hugh

On 22 Mar 2012, at 20:21, Jeni Tennison wrote:

> 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
> 
> 

-- 
Hugh Glaser,  
             Web and Internet Science
             Electronics and Computer Science,
             University of Southampton,
             Southampton SO17 1BJ
Work: +44 23 8059 3670, Fax: +44 23 8059 3045
Mobile: +44 75 9533 4155 , Home: +44 23 8061 5652
http://www.ecs.soton.ac.uk/~hg/

Received on Friday, 23 March 2012 16:13:02 UTC