Re: on documents and terms [was: RE: [WNET] new proposal WN URIs and related issues]

Booth, David (HP Software - Boston) wrote:
>> From: Pat Hayes [mailto:phayes@ihmc.us] 
>> . . . 
>> Not minor at all, Frank. This might get to one of the hearts 
>> of the issue.
>>
>>> "Definitely not" may be technically correct, but
>>> I think a bit more context is needed here.  The 
>>> TAG Architecture document says:
>>>
>>> "It is conventional on the hypertext Web to
>>> describe Web pages, images, product catalogs, 
>>> etc. as ³resources². The distinguishing 
>>> characteristic of these resources is that all of 
>>> their essential characteristics can be conveyed 
>>> in a message. We identify this set as 
>>> ³information resources.²
>>>
>>> This document is an example of an information
>>> resource. It consists of words and punctuation 
>>> symbols and graphics and other artifacts that 
>>> can be encoded, with varying degrees of 
>>> fidelity, into a sequence of bits. There is 
>>> nothing about the essential information content 
>>> of this document that cannot in principle be 
>>> transfered in a message. In the case of this 
>>> document, the message payload is the 
>>> representation of this document."
>> OK, reading the above carefully, in the light of 
>> David's comment, I seem to discern an implicit 
>> distinction between several things. Let me be 
>> excruciatingly pedantic here for a second, and 
>> make very, very careful distinctions between 
>> several things involved in a hypothetical HTTP 
>> GET, which to keep things as simple as possible I 
>> will assume is the successful getting of an XHTML 
>> web page from a server, with a 2xx code, no 
>> problems. There seem to be several entities 
>> involved in this.
>>
>> 1.  An "HTTP endpoint", which is a computational 
>> process running on hardware, which processes the 
>> GET request and emits http codes and bit-strings.
> 
> Yes.  This is the "information resource", defined in an operational style.
> 
> Side note: I actually used the term "logical HTTP endpoint", not just "HTTP endpoint", because an "information resource" is associated with an entire URL minus the fragment identifier, whereas a Web server is (normally?) associated with only the domain+server part (ignoring the path and query string parts).  For example, given the URI http://example.org/foo?bar#fum , http://example.org/ , http://example.org/foo and http://example.og?bar may all correspond to different "information resources", even though they would be served by the same Web server associated with example.org.
> 

I suppose we can talk about this in an operational style if we *have* to 
(sigh), but the other documents don't use this style, and it does seem 
to mix in another set of abstractions (God knows we have enough already!).

Anyway, your addition of "logical" is really important here, because 
thinking of one of these endpoints as a computational process and so on 
too explicitly (which would really be part of the *implementation* of 
the endpoint, along with the data) really does make it seem as if an RDF 
graph or RDF/XML document couldn't possibly be one of those things.

>> 2. The sequence of bits or bytes whose 
>> transmission from (1) constitutes the successful 
>> completion of the GET request.
> 
> I'm not sure what you mean here.  If you're including the bits that are part of the HTTP protocol handshake itself, then it would be more than just the "representation".  If not, then I don't know how you mean #2 to be different from #4 below.
> 
>> 3. The Web page itself: a document, consisting of 
>> characters, which conform to XHTML syntactic 
>> rules.
> 
> If it conforms to XHTML syntactic rules it sounds like you are talking about a particular instance of a document rather than a document in the abstract sense (which may change over time), so this sounds to me like a "representation".
> 

I wasn't sure about this either.  This is one of the many terminology 
problems we have in these discussions, partly because we, implicitly if 
nothing else, refer to so many technologies.  Specifically, the XHTML 
spec defines what it thinks a document is:  "A document is *a stream of 
data* that, after being combined with any other streams it references, 
is structured such that it holds information contained within elements 
that are organized as defined in the associated DTD."  [my emphasis]  Of 
course, they're not concerned with this distinction we're trying to get 
at here.

>> 4. The encoding of the Web page (3) which is used 
>> by the process (1) to produce the bitsequence (2)
> 
> This also sounds like the "representation", though stated more specfically.  The WebArch says: 'HTTP . . . uses the "Content-Type" and "Content-Encoding" header fields to further identify the format of the representation'.  See http://www.w3.org/TR/webarch/#intro
>  

I was interpreting this "encoding" as the representation that lives on 
the server (and possibly elsewhere, since there may be multiple pieces), 
or all the representation encapsulated by the endpoint, if we continue 
to use the endpoint abstraction, and which is used to construct the 
representation returned in the response.

>> 5. The encoding of the Web page (3) which is 
>> produced from the bit sequence (2) in the browser 
>> which issued the GET request and used by it 
>> render a visual form of the Web page (3) on the 
>> users's screen.
> 
> This sounds like an internal browser-dependent version of the "representation".
> 

I think.

>> and we could of course go further, distinguishing 
>> the image on the screen from its binary 
>> representation, the state of the process from the 
>> process itself, and so on (and on.)
>>
>> Now, I tend to blur some of these distinctions, 
>> myself. For example, I tend to think of 2 through 
>> 5 as simply being 'the Web page'; or if I am 
>> being more careful, to identify 2, 4 and 5 as 
>> 'renderings' or 'encodings' or 'tokens' of the 
>> single, abstract, Web page (3). And I often don't 
>> bother to distinguish between 1 and 4. This gives 
>> a simplified picture, which is adequate for many 
>> purposes, in which we happily ignore the 
>> type/token distinction (as we normally do in 
>> English) and where issuing a GET is a bit like 
>> asking an usher for A concert program, at which 
>> she then hands you a copy from her pile of 
>> identical copies, and you take it away and read 
>> it without bothering her further, and if anyone 
>> asks you what you are reading you say, THE 
>> program. (You could say that each copy is a 
>> 'representation' of the great concert program in 
>> the sky, or of all the other copies, or of the 
>> state of the printing platen at the moment the 
>> ink hit the paper, but there's not usually much 
>> point in being that picky about these 
>> distinctions.)
> 
> True, but if one is discussing the TAG's WebArch document ( at http://www.w3.org/TR/webarch/ ), it is essential to make this distinction, because the difference between a "representation" and an "information resource" is essential to the WebArch.
> 

It's even more essential when considering examples that are more 
complicated that the "identical copy" situation.  For instance, the 
example in the RDF Vocabularies Recipies where what you dereference is 
the URI of an RDF vocabulary, and you get different representations 
(RDF/XML or HTML) depending on what kind of representation you ask for.

>> . . .
>> Just to clarify another source of muddle, I would 
>> not call any of these things "representations" of 
>> any of the others. In my usage of the word 
>> "representation", there is no representation of 
>> anything involved in the entire architectural 
>> story of how an http GET is processed. Nothing 
>> represents anything here, because there are no 
>> semantic relationships involved. The various 
>> bitstrings are simply copies of one another, and 
>> the relationship of a document to its bitstring 
>> encoding is that of a rendering or encoding, 
>> rather than a representation: a token/type 
>> relationship. (The bitstring does not *describe* 
>> the document it encodes. If it did, it would have 
>> to describe it using a syntax, but bitstrings, 
>> pretty much by their very nature, do not have any 
>> syntax.)
> 
> I agree.  I don't like the term "representation" either, but I guess the TAG needed a term and that was the term they picked.
> 

It seems to me this is pretty clearly Roy Fielding's concept of 
"representation", and the choice was deliberate.

Anyway, I'm not sure *I* agree, and I think I need to drill down a 
little (tomorrow maybe).  For example, are there really no semantic 
relationships involved (or am I misunderstanding what you mean by 
"semantic relationship")?  Remember that these ideas need to (and, I 
think, do) capture more than just the scenario "copy the HTML file 
that's on the server to the client's machine and turn the browser loose 
on it", which is the literal bitstring copy case, and I think focusing 
only on the most obvious *information* resources may slant us toward 
that specific scenario.  If the URI denotes John (the person), and what 
you get back is a picture of John, isn't there a semantic relationship 
involved?  It may not be terribly explicit (certainly not to a machine), 
and it may not be direct either, but it seems like there is one. 
Someone at the server end placed a representation (the picture) there 
and set things up so that representation is returned when a URI that 
purportedly denotes John is dereferenced.  Admittedly only a 
representation is moved around, but so what?  Suppose that some RDF 
describing John is returned in addition to the picture.  Does that 
change the semantic relationship?

Also, it seems to me this is very much bound up with the distinction 
being made between information resources and other resources.  This 
distinction, and the different server return codes being associated with 
it, seem to create a binary (yes/no) answer to the question, "does the 
representation that has been returned convey all of the essential 
characteristics of the resource denoted by the URI you've dereferenced" 
(in the opinion of the person setting up the relationship between the 
URI and the representation that gets returned).  Clearly there's not a 
whole lot of room for nuance here (!), but there does seem to be at 
least some kind of semantic relationship.

>> . . . 
>> An RDF ontology, at any rate, is either an RDF 
>> graph or an RDF/XML XML document. Either way, it 
>> is not an HTTP endpoint or an abstraction of an 
>> HTTP endpoint. So it cannot be an information 
>> resource in David's sense, seems to me.
> 
> Yes, it can be if instances of it are intended to be served via HTTP.  My proposed definition[1] is very narrow in at least two ways: (1) it ignores "documents" that are never intended to be served (because they are not very relevant to the "information resource"/"representation" discussion); and (2) it is restricted to the HTTP protocol, because that's where the issue of resource identity (and the httpRange-14 issue) comes up.  
> 
> [1] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Apr/0053.html
> 

Well, I'd be looking for a definition to provide a little more 
explanation than that :-)  Of course the problem may be, as Samuel 
Johnson put it in the Preface to his Dictionary, "To explain, requires 
the use of terms less abstruse than that which is to be explained, and 
such terms cannot always be found."

--Frank

Received on Tuesday, 25 April 2006 01:43:22 UTC