Re: Change Proposal for HttpRange-14 (What about 404 on Semantic Web?)

Hi all,

I noticed that there are general discussion about using the "described by"
relationship in 200 OK, here
https://docs.google.com/document/d/1ognNNOIcghga9ltQdoi-CvbNS8q-dOzJjhMutJ7_vZo/edit


I would like to point out that other than the 200OK and 303 See Other, we
also should consider the 404 on semantic web.

If a document returned follow the "described by" 200 OK, if we cannot find
the URI in the returned document (e.g. RDF), it should result a 404 too.

Regards,
Yang Yang

-----------------------------------

http://www.iamresearcher.com/profiles/yang2/

Web and Internet Science

Room 3027 EEE Building

Electronics and Computer Science

University of Southampton, SO17 1BJ


On Fri, Mar 23, 2012 at 4:12 PM, Hugh Glaser <hg@ecs.soton.ac.uk> wrote:

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


--