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.

We are now distinguishing between an endpoint and 
an implementation of an endpoint?? This is 
getting out of hand. So the running code is an 
implementation of a logical endpoint which is the 
real information resource. Presumably I could 
implement the same logical endpoint somewhere 
else on the network, right? (If not, where is the 
utility in distinguishing them?) Would its URI 
still identify it - the logical endpoint - at 
that other place on the network? Or would it in 
fact identify the implementation? Etc. ..

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

Ah, thanks for that correction. By (3) I meant a 
sequence of characters, rather than a stream of 
data. This is a more abstract notion. The 'same' 
document in sense (3) might be realized 
simultaneously by several streams of data. I 
meant (3) in the sense that there is only one 
novel called "Moby Dick", all of the physical 
incarnations of which are tokens of it, so that 
the various bitstrings and bitstreams (2, 4 and 
5) are all tokens or renderings of (3). Sorry if 
the reference to XHTML was misleading.

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

Quite.

>, 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.

Exactly.

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

Yes. But of course it is not identical to 4 since 
it resides at a different place.

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

You get different things; I would say, you get 
different documents. (They contain different 
characters, which is usually a good sign.) In 
what sense they are representations, and of what, 
remains to be clarified. I doesn't seem plausible 
to me to say that some HTML and some RDF could 
possibly both be representations of a single 
thing, except in a very inexact sense that they 
might both be 'about' the same 'topic': but what 
is a piece of RDF really 'about' ? That notion 
isn't in the RDF spec anywhere.

>>>. . .
>>>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")?

Not in the architectural issues and in what Roy 
Fielding seems to mean by 'representation', no. 
Most (all?) of the problems in WebArch seem to me 
to arise from taking an architectural discussion 
and trying to apply it to semantics. This is 
about as wrong-headed as trying to use ideas and 
terminology from chemistry to do economics.

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

But as far as the architecture goes, this is 
about all that needs to be said: plus of course 
all the architectural stuff about caching, supply 
versus demand side transactions, and so on: all 
the architectural stuff from Roy's thesis et. 
seq. I don't mean to imply that all this network 
architecture isn't important, only that it is 
about one topic, and semantics is about a 
different topic. As far as the architecture is 
concerned, the relationships among messages are 
all to do with rendering the state of a server 
accurately at the other end of a transfer. The 
semantics of those messages, if they have any, is 
irrelevant.

>  If the URI denotes John (the person), and what 
>you get back is a picture of John, isn't there a 
>semantic relationship involved?

Yes, but because you introduced a semantic term. 
You said the URI *denotes* John (and that the 
picture was *of* him, which arguably is also a 
semantic notion, though not one that is 
extensively analyzed yet, afaik.) How can that be 
relevant to communication architecture? Symbols 
don't travel more slowly if they have different 
denotations. The architecture doesn't even know 
that this image is of John, or that this URI 
denotes John; not does it need to know that. Its 
business is to deal with transmitting encodings 
and symbols, not with denotations. What URIs 
denote has absolutely no bearing on anything 
architectural, and what URIs 'identify' in the 
WebArch sense has no bearing on what they denote, 
unless we specify that it should: which, recent 
history suggests, we should do only with extreme 
care, and after studying the consequences 
carefully.

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

I agree. But these senses of 'represent' - 
denoting, being a picture of - are not Fielding's 
sense of 'represent'. In fact, the two senses 
bear almost no useful connection to one another. 
The TAG tries to talk about architecture and 
about semantics as though they were a single 
topic, and they are NOT a single topic. That is 
why things have gotten so utterly confused.

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

It involves a different semantic relationship. To 
talk about this coherently requires that we be 
clear about which kind of semantic relationship 
we mean, and what we mean by 'representation'. I 
know the TAG wants to keep things as simple as 
possible, and I respect that desire, but the fact 
is that this whole topic just is damn 
complicated, and the relevant work has not in 
fact been done. It is irresponsible of the TAG to 
be delivering semantic pronouncements about 
matters that have not yet even been fully 
studied, and regarding which there is no body of 
experience to appeal to. Semantics was 
complicated enough to be challenging when we only 
had traditional media to consider, and the most 
that anyone ever needed to think about was the 
type/token distinction, and maybe speech acts as 
an absolute fringe case. Now we have many more 
distinctions (documents, characters, glyphs, 
codepoints, datastreams, endpoints, logical 
endpoints, implementations of logical endpoints, 
RDF graphs vs. RDF/XML, 
text/hypertext/markup,...) many of which violate 
long-cherished distinctions in semantic analysis 
(for example, much of the language used in 
discussing marked-up text violates the 
use/mention distinction). There is a lot of hard 
work to do to try to properly understand how 
semantic ideas can be applied to these new uses 
of notations, and the challenges of the semantic 
web. This work hasn't been done yet, and it will 
require all of us, semanticians and network 
architects, to try to understand what one another 
are saying, and not impose poorly-thought-out 
decisions which do not have a rational basis. 
Decisions like the TAG made on http-14, and this 
half-formed notion of an 'information resource', 
seem to be based on nothing better than shallow 
misunderstandings arising from a confusion of 
terminology. (The very idea that http has a 
'range' in the semantic sense is itself not 
obvious, and I think in fact is mistaken.)

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

Well, no, I think that this virtually rules out 
any kind of semantic relationship, since I know 
of no way to analyze 'represents' semantically 
which would provide for ALL the essential 
characteristics of the represented to be captured 
by the representation. (It depends, of course, on 
what one means by the weasel words, in this case 
"essential".) Certainly a description cannot do 
this, except in cases not of wide interest (in 
mathematics, for example, where notions like 
'abelian group' are defined so that they can be 
fully characterized by finite descriptions; 
notice that they have to be Platonic ideals in 
order for this to be possible.) In fact, one 
definition of a 'natural kind' (most of the 
entities that one wishes to talk about) is that 
they cannot be fully described, so that all 
descriptions of them must be partial, and there 
is always more that could be said. An image of 
anything cannot usually be said to convey all the 
essential characteristics of the thing depicted; 
unless, again, we drastically limit the notion of 
'essential' to a particular function or task - 
say, to identify a face uniquely, as on photo 
identification document. It seems to be inherent 
in the very idea of a representation that, in 
Korzbyski's phrase, the map is not the territory. 
In fact, the only cases in which one thing A can 
be said to convey all the essential 
characteristics of another B is when these 
"essential characteristics" are entirely 
concerned with the form or shape of B, and that A 
is a sufficiently exact copy of this form or 
shape of B that it can stand in its stead. So, a 
binary encoding of a text, or a book printed on 
paper, or more generally any physical token of 
any type, would count. In other words, in fact, 
if the thing 'represented' is itself some kind of 
notation, and the 'representation' is a copy or 
rendering of it, sufficiently exact as to make it 
possible to parse it in the same way. Such a 
close rendering or encoding of one thing as 
another is not usually (outside the TAG) referred 
to as a 'representation', and is not usually the 
topic of a semantic analysis. (There are some 
edge cases that one might argue about, 
admittedly. Does a musical score convey all the 
essential characteristics of a piece of music? 
What about a MIDI file? What about labanotation? 
Hmm.)

>>>. . . 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."

Well, yes, but in this case, there is an entire 
field devoted to talking about these matters. Not 
only do the TAG apparently not know anything 
about this field, they mis-use its terminology 
without explanation.

Pat

>
>--Frank


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Tuesday, 25 April 2006 18:00:29 UTC