Cart
[Home] [By Thread] [By Date] [Recent Entries]
Semantics are in the mind of the author, and they are in the mind of the recipient. They are never in data, no matter how encoded. Moreover, the only realities that matter are the ones in our heads, because those are the only ones upon which we can act. Communication is possible only because we believe it is possible. We believe it happens only because we have believed it long enough to accumulate sufficient context with our correspondents to confirm us in our belief. It's a matter of preponderance of evidence. Disappointments -- i.e., communications failures -- are inevitable. If a commercial airplane is intended to land at Logan Airport, and then fails to do so, we may be sure that the finger of blame for that failure will eventually be pointed more or less accurately, even if the task of pointing it requires stupendous effort. In order to minimize the effort involved, many systems are already in place, each of which is designed to allow some set of responsibilities to be assigned and accepted, thereby to make each step in the process of flying to Logan auditable. I think your question, Roger, is not about air travel, but rather about human communications in the general case, and I think there's a better way to ask it: "When communication is known to have failed, how do we minimize the effort involved in assigning blame for the failure in such a way as to prevent future failure(s)?" Parenthetically, I feel I must mention, at least in this xml-dev context, the fact that same question was uppermost the minds of those who insisted, many years ago, that every SGML document must have a DTD. That was no misfeature. It allowed the finger of blame to be more easily pointed, at least when communications failed on account of a discrepancy between actual document structure and expected document structure. With respect to structure, at least, all of the following questions became inarguably answerable: * Did the transmission conform? * Did the recipient's process work correctly? * Should the transmitter have known better than to transmit? * Should the recipient have known better than to accept the transmission? What I want to say has little to do with the overall structure of a data transmission. But it *does* have to do with pointing the finger of blame for communications failures. And the very same question is still exactly the right question: "When communication is known to have failed, how do we minimize the effort involved in assigning blame for the failure in such a way as to prevent future failure(s)?" In other words, how can we constrain or compel the *construction* of transmissions (not necessarily their *structure*, but certainly their *construction*) and how can we constrain or compel the *interpretation* of transmissions thus constructed? I think the answer must have to do with the sharing of context. And I still believe that topic mapping (see disclaimer and reference below) is a good way to establish and interchange a "preponderance of evidence" such that construction and interpretation can be sufficiently constrained and compelled to reduce the number and severity of communications failures, and to tweak those compulsions and constraints in response to experience, thus to establish and maintain a *community* that *communicates* reliably. Disclaimer and Reference: My definition of "topic mapping" has little or nothing to do with any of the popularizations of that term. It's a simple idea, but XML mavens may have too much baggage to get there in one step. This link: http://www.coolheads.com/SRNPUBS/groveProgenitorOfTMs.txt may be better for you, because it traces the historical development of the idea from the perspective of the original Topic Maps standard, which could not be understood in the absence of a fair appreciation of the GROVE paradigm. (It's a matter of record that it was *not* widely understood.) Perhaps the key point is that it's necessary to make an explicit distinction between a syntactic construct, on the one hand, and its semantic, on the other. Reliable semantic interchange -- i.e., communication -- is always extremely difficult, but in the absence of the discipline of making such a distinction, reliable semantic interchange is unlikely if not downright impossible. Even thinking about a topic map document means holding two perspectives on it firmly in your mind simultaneously: a graph of subjects of conversation, and an interchangeable rhetoric for that graph, which is a corresponding graph of syntactic (and/or object or virtual object) structures. This takes some rather unsettling self-training, perhaps because our brains are designed to ignore the latter and "pay no attention to the man behind the curtain." The man behind the curtain is the rhetorician in the room, and, like the Wizard of Oz, even *he* doesn't know how it works. On 11/29/2013 10:09 AM, Costello, Roger L. wrote: > Hi Folks, > > > > This hex string is the EBCDIC encoding of the uppercase letter A: > > > > C1 > > > > This hex string is the ASCII encoding of the uppercase letter A: > > > > 41 > > > > Suppose we create a tool that converts EBCDIC text to ASCII text. The > main aspect of the conversion is that the input has a property called > semantics – its “meaning” – which must be preserved by the process. For > example, the conversion must preserve this semantics: “uppercase letter A.” > > > > Next, consider this XML which expresses the location of Boston’s Logan > airport, using an ICAO code: > > > > <Airport> > > <ICAO>KBOS</ICAO> > > </Airport> > > > > This XML expresses the location of Boston’s Logan airport, using > latitude/longitude: > > > > <Airport> > > <Latitude>42.3631° N</Latitude> > > <Longitude>71.0064° W</Longitude> > > </Airport> > > > > Suppose we create a tool that converts ICAO locations to > latitude/longitude locations. The main aspect of the conversion is that > the input has a property called semantics – its “meaning” – which must > be preserved by the process. For example, the conversion must preserve > this semantics: “location of Boston’s Logan airport.” > > > > But wait! Haven’t we stated that XML doesn’t have semantics? If XML > doesn’t have semantics, how can a conversion process preserve semantics? > > > > I’m confused. > > > > Question: An XML instance document has semantics: > > > > (a) Yes > > (b) No > > > > /Roger > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
