Re: Alternative to 303 response: Description-ID: header

The requested and delivered content type cannot be used to select or
distinguish resource vs. description because content-type is orthogonal to
description-ness. The original resource could be in RDF and its description
might be in HTML. Now if the resource is on the web, we're unlikely to ever
see the description as a result of doing a GET of its URI, since you'll get
a representation of the resource instead. You would have to find the
description someplace else. But it would make perfect sense to describe a
resource that doesn't have representations available via GET, and then to
have the description be available through GET + 303. Certainly this
description is not the original resource, so without 303 (or 207 or ...)
there would be no way to know that you didn't get the resource.

So content negotiation is a red herring in this discussion - especially with
the advent of RDFa, which as I understand it removes even the false but
heuristic notion that RDF content types carry description while everything
else is doesn't.

The information content of a resource and its description may be completely
incompatible, by the way - they could contradict one another (who is the
author of the Autobiography of Alice B. Toklas?). If the resource is a
contract, it's very important to attribute statements correctly to the
contract vs. to its description. Etc.

Jonathan

On Dec 5, 2007 3:51 PM, Dan Brickley <danbri@danbri.org> wrote:

>
> Tim Berners-Lee wrote:
>
> > There is a major problem with this, though.   Content negotiation is
> > just for different encodings of the SAME document.
> > You can content negotiate between PNG and JPG of the SAME picture.
>
> And SVG. Even quite lossily vectorised SVG...
>
> > Between text/plain and text/html of the SAME document.
> > Between RDF/xml and N3 of the SAME data.
> >
> > You cannot use conneg to return a completely different document, eg not
> > A but  metadata bout A.
> > A and A' must carry exactly the same information, module an 'acceptable'
> > degree of degradation.
> >
> > When people conneg between HTML and RDF, the HTML is generated from the
> > RDF. Else it is  a bug.
>
> I don't believe you on this, sorry!
>
> There's no webarch ordering of RDF over HTML any more than there is of
> PNG over JPG (or SVG). You're appealing to causal chains here, but I
> suspect the key point you're after is that both encodings stem from some
> common source. If I decide to generate my JPG from a PNG, or my PNG from
> a JPEG, or both from some hidden 3rd source, that's my right. But I
> think it's the "hidden 3rd source" (ie. the abstract "Work") that's the
> core idea here. You don't really mind if I generate the .rdf by
> extracting from HTML, or querying a private SQL store, do you? So long
> as they both have close enough information content that they can
> sensibly be considered to be imperfect renderings of the same (more or
> less fictional or at least hypothetical) "Work"?
>
> cheers,
>
> Dan
>
>
>