Re: URIs, used in RDF, that do not have associated documentation

> On 3/28/2012 10:26 PM, トーレ　エリクソン wrote:
> > HTML Document resources represent themselves.

Noah Mendelsohn wrote: 
> Yes, but let's also keep in mind that many, many non-HTML document
> resources are served as HTML representations.
> 
> Example: let's say I have a resource that is the text of the US Declaration
> of Independence. I mint a URI for it, and as the URI assignment authority I
> can assure that the resource is the text of the declaration, not some
> particular encoding of it in HTML.
> 
> It's perfectly reasonable for me to serve this as text/html (or text/plain,
> or maybe even as image/jpeg if the image shows a rendering of the text).
> So, even in the case where the resource is a document, the media type
> doesn't tell us much about the nature of the resource. We therefore need to
> be careful when speaking about "HTML" resources; much of what's served with
> HTML representations is not in any deeper sense an HTML resource.
> 
> As you say, in the particular case where the resource in question >is <
> intended to be, specifically, an HTML document, then text/html is a fine
> way to serve it.

You are correct, an HTML document can represent a lot of things. However,
when returned as a representation, in a lot of cases it does *not*
represent an HTML document. What I always *does* represent though, is
itself, an octet stream with a media type. That is the only
representation that is unambiguous.

<rant>My problem is that people assume that the default case is that the
HTML document "resides" (I don't know a better word, hope you understand
what I mean) on the other end of the wire, when it might just exist
locally through the octet stream.</rant>

Tore

Received on Saturday, 31 March 2012 00:24:43 UTC