- From: Pat Hayes <phayes@ihmc.us>
- Date: Tue, 25 Apr 2006 13:00:08 -0500
- To: Frank Manola <fmanola@acm.org>
- Cc: "Booth, David (HP Software - Boston)" <dbooth@hp.com>, public-swbp-wg@w3.org
>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