Do you really think that base your proposal on the usage on a Powder annotation is a good idea?
Sorry, but IMHO HttpRange-14 is a good enough agreement. Kind regards, On 22 March 2012 21:21, Jeni Tennison <j...@jenitennison.com> 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 > > -- Sergio Fernández CTIC - Technological Center Parque Científico y Tecnológico de Gijón C/ Ada Byron, 39 Edificio Centros Tecnológicos 33203 Gijón - Asturias - Spain Tel.: +34 984 29 12 12 Fax: +34 984 39 06 12 E-mail: sergio.fernan...@fundacionctic.org http://www.fundacionctic.org Privacy Policy: http://www.fundacionctic.org/privacidad
