Re: httpRange-14 Change Proposal

(speaking as chair here -- I'll send some technical comments separately)

Jeni: thank you so much for posting this.

Jonathan: might I ask that you update the agenda and required reading for 
the F2F to include this and any other proposals or e-mails that you feel 
the TAG should read in preparation for the F2F?

Thank you both.

Noah

On 3/25/2012 5:47 AM, Jeni Tennison wrote:
> Hi,
>
> Please find below a Change Proposal for the consideration of the TAG in response to [1] on behalf of (alphabetically):
>
> Ian Davis
> Leigh Dodds
> Nick Gibbins (University of Southampton)
> Hugh Glaser
> Steve Harris
> Masahide Kanzaki
> Gregg Kellogg
> Niklas Lindström
> Jerry Persons
> Dave Reynolds
> Bill Roberts
> Andy Seaborne
> John Sheridan
> Ben O'Steen
> Damian Steer
> Thomas Steiner
> Ed Summers
> Jeni Tennison
> Davy Van Deursen
>
> and with thanks to other members of the LOD mailing list who helped identify areas that required clarification. The original version is at [2].
>
> [1] http://www.w3.org/2001/tag/doc/uddp/change-proposal-call.html
> [2] https://docs.google.com/document/d/1ognNNOIcghga9ltQdoi-CvbNS8q-dOzJjhMutJ7_vZo/edit
>
> ---
>
> # Summary #
>
> This proposal contains two substantive changes.
>
> First, a 200 response to a probe URI no longer by itself implies that the probe URI identifies an information resource or that the response is a representation of the resource identified by the probe URI; instead, this can only be inferred if the probe URI is the object of a ‘describedby’ relationship or the target of a 303 redirection.
>
> Second, 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.
>
>
> # Rationale
>
> While there are instances of linked data websites using 303 redirections, there are also many examples of people making statements about hash-less 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. The Appendix provides examples of these.
>
> 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
>
>   * 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.
>
> 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 to add separate identifiers
>
>   * 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
>
>   * it provides a standard means of explicitly adding in data information that would otherwise only be available if a resource is accessed by HTTP, which means that reasoning dumps of crawls of the web (eg from webdatacommons.org) becomes more consistent with what could be inferred from the crawl itself
>
>   * browser location bars don’t change when navigating to URIs that provide a 200 response, which means less copy/paste errors and user confusion when trying to encourage people to use URIs for non-information resources and not those for their documentation
>
> ## 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
>
>   * when documentation is served with a 200 response from a probe URI and does not contain a 'describedby' statement, some agents (including the publisher) might use it to identify the documentation and others a non-information resource. Publishers still need to provide support for two distinct URIs if they want to enable more consistent use of the probe URI; 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/.)
>
> # Appendix: Examples of 200 Responses for NIRs
>
> ## http://www.logosportswear.com/product/1531
>
> response with a 301 redirection to
> http://www.logosportswear.com/product/1531/harbor-cruise-boat-tote which contains the RDFa statement
>
>   <http://www.logosportswear.com/product/1531>
>     a<http://rdf.data-vocabulary.org/#Product>  ;
>     .
>
> The URI is intended to identify a product, not a web page.
>
>
> ## http://developer.yahoo.com/yui/docs/YAHOO.util.Dom.html
>
> contains RDFa statements that state that this web page contains events, methods and properties:
>
>   <http://developer.yahoo.com/yui/docs/YAHOO.util.Dom.html>
>     yui:attributes<#configattributes>;
>     yui:description """
>                         Provides helper methods for DOM elements.
>                     """;
>     yui:events<#events>;
>     yui:methods<#methods>;
>     yui:name "YAHOO.util.Dom";
>     yui:properties<#properties>  .
>
>  From the statements, the intention is for the URI to identify the (programming language) Object, not a web page (despite the .html on the end!).
>
>
> ## http://gondwanaland.com/mlog/2005/03/13/semweb-not-by-committee/
>
> contains the RDFa statements
>
>   <http://gondwanaland.com/mlog/2005/03/13/semweb-not-by-committee/>
>      dcterms:publisher<http://gondwanaland.com/mlog/>  ;
>      sioc:has_owner<https://creativecommons.net/ml/>  ;
>      .
>
> The range of dcterms:publisher is a dcterms:Agent, but http://gondwanaland.com/mlog/ returns a 200.
>
> The range of sioc:has_owner is a sioc:UserAccount, but https://creativecommons.net/ml/ returns a 200.
>
>
> ## http://www.feedbooks.com/book/2679
>
> contains microdata statements. How you should interpret these as RDF is obviously debatable but the obvious thing to do is for a href attribute to indicate the resource that it targets, so the page includes the statements
>
>    [ a schema:Book ;
>      schema:author<http://www.feedbooks.com/author/496>  ; ]
>
> The range for schema:author is intended (I think) to be a person rather than a web page about a person, but resolving http://www.feedbooks.com/author/496 gives you a 200.
>
> (Based on the webdatacommons.org dumps, this site used to serve up RDFa that stated that<http://www.feedbooks.com/book/2679>  identified a Book; books are not web pages.)
>
>
> ## http://www.mybanktracker.com/Citibank/Profile
>
> contains the RDFa statements
>
>     <http://www.mybanktracker.com/Citibank/Profile>
>       v:dtreviewed "2012-01-05 16:42:49"@en-US;
>       v:itemreviewed<http://www.mybanktracker.com/Citibank/Profile>;
>       v:rating "4"@en-US;
>       v:reviewer<http://www.mybanktracker.com/member/lisaehrlich>;
>       .
>
> The review is clearly about Citibank and not the web page.
>
> The object of the v:reviewer property should, I imagine, be a person but is instead a web page.
>
>
> ## http://www.flickr.com/photos/andreaweckerle/2559011937/
>
> used to contain the triples (according to the webdatacommons.org data)
>
>    <http://www.flickr.com/photos/andreaweckerle/2559011937/>
>      dcterms:creator<http://www.flickr.com/photos/andreaweckerle/>
>      .
>
>    <http://www.flickr.com/photos/andreaweckerle/>
>      foaf:name "andreaweckerle"
>      .
>
> where http://www.flickr.com/photos/andreaweckerle/ resolves to a 200 but is plainly intended here to be a Person. Those statements don't seem to be there any more.
>
>
> ## http://www.businesswire.com
>
> redirects with a 302 to http://www.businesswire.com/portal/site/home/ which gives a 200 response and contains microdata that maps to the triples
>
> <http://www.businesswire.com>  a schema:Organization;
>     schema:name "BUSINESS WIRE";
>     schema:url<http://www.businesswire.com>  .
>
> which says that http://www.businesswire.com is an organisation, not a web page.
>

Received on Sunday, 25 March 2012 17:33:14 UTC