Subject: Re: LISP and AI From: Erik Naggum <erik@naggum.no> Date: 2000/05/10 Newsgroups: comp.lang.lisp Message-ID: <3166989135334203@naggum.no> * David Thornley | In other words, that you want the ability to write a link that | refers to a position in the other document, rather than a predefined | anchor? Yes, that, too. The biblical chapters and verses arose for the purpose of the references. Legal documents have their structure from the need to refer to individual sentences and items in lists. | So, what you'd like also is an ability from document A to put a link | in an arbitrary place in document B that goes to an arbitrary place | in document C? Yes. | (Obviously, this would have to be limited to a particular viewing of | the documents; if it were possible to put arbitrary links in other | people's pages in general, all pages on the Web would have multiple | links to porn sites.) This is an important point. Which links are active on a given page is controlled by the set of linking documents you have selected. The "viewing" is controlled by the browser, which knows about _your_ linking preferences, glossaries, dictionaries, etc, and merges them with those contained in (or referenced) the document itself. | Is that an adequate description of what you are complaining about? No. I't s good start, however. | Or are there other things you'd want to be able to do? Again as an example, I want to say, in a formalized way, "That part of document A contradicts that part of document B" and put it in a collection of comments on various documents on the Net. When somebody picks up this collection of comments, they can visit the documents I have commented on in various ways and have an annotation box pop up in places where I had made such comments and go visit the other document to look at it. However, this is not _too_ exciting. The exciting part is when the links themselves can be referenced, aggregated, etc. That's when you _really_ need the ability to point to something and make it link to something else. | I've been having trouble following the list of deficiencies, and | would like to be sure I've got it. Think of it this way: If you are writing a novel, which would typically include dialog, you are not worrying about how to make irony come out right on your laser printer, because there's no point in making it visually distinct from any other text and there's no point in involving the printer unless you have a language to talk about the irony of a particular piece of text that could affect the printer's behavior. You would, however, worry about how to express the irony in your own language. The printer would simply render it in whatever way it usually renders text. When people get stuck in the HTML world, they naturally complain about the pointlessness of talking about irony because there's no browser that would render <irony>foo</irony> differently from anything else, and it would look just like any other text. If they _wanted_ the browser to render irony differently, they would simply write the low-level stuff that HTML defines to cause the browsers to change the rendering, but they would _still_ not think that _HTML_ supports irony. HTML supports the mechanisms that allows something else entirely to express irony through its rendering-friendly language. It is that something else that I'm interested in. In the case of your novel and the laser printer, it's capturing the author's intent in a language able to talk about its own usasge, such as English. In the case of HTML, it's whatever caused that particular "code" to be produced in the first place, ultimately _some_ authors' intent. Because HTML can do certain simple tricks, and because most people aren't aware of what they are doing, it is possible to conflate the expression with the intention, indeed common to do so among those who aren't and don't want to be educated. This doesn't remove the intent. It only means that some people will insist that if they can express it in HTML, there's no point in talking about the intent and other languages that would make it easier to talk about the intent. The fundamental deficiency in HTML is that it reduces hypertext and the intertwinedness of human communication to a question of how it is rendered and what happens when you click on it. By giving the world a language in which numerous important concepts can no longer be expressed, these concepts are removed from our world. When music was written down with notes, a lot of music that was very hard to write down with notes vanished, and music became note-friendly. When tasks are automated, the skills that went into the automation vanishes and only the skills required to keep the automated solution going remains. When children learn to speak particular languages, their ability to speak other languages deteriorates and vanishes. HTML is to the browser what PostScript is to the laser printer. Normal people don't worry about PostScript when they want to employ irony in a dialog. Normal people shouldn't worry about HTML when they want to make hypertext links. They should think of what their _real_ needs are, and trust me, those needs are _not_ covered as such by HTML, but they can still be _expressed_ in HTML such that a browser can render it to the reader, just like PostScript does not cover the needs of an author as such, but most everything an author wants to say can be _expressed_ in PostScript and come out right. (And that which cannot be expressed in PostScript will have a natural tendency to become unwanted unless people change to a new language.) That is to say, everything I want _may_ be implemented with a chain of proxy servers that add their particular thing to the incoming HTML, just as I could add filters that hacked PostScript to get special effects on the laser printer. The end result as it is given to the browser or laser printer is _still_ HTML or PostScript, respectively, but neither the HTML nor the PostScript were created to do what the proxy servers and filters have done _to_ them. It is not productive to argue that "it's just HTML! HTML can do it all!" when the software that produces the HTML is driven by so much more input than whatever generated the original HTML _or_ the browser, and which simply tries to teach the browser how to do things HTML _can't_ do on its own. Which means that whether it is done by a chain of proxy servers or a smarter browser that understands a _richer_ language than HTML is immaterial, but you still can't get a browser that only understands HTML to do any of this stuff without the proxy servers in between. For instance, CSS may be employed to change the rendering of an HTML document, and CSS may be provided by the user to override a document's rendering. The HTML may contain a reference to some CSS that instructs the browser on what to do, but that still doesn't give HTML the credit for the rendering. To put it in yet another way: What I want the browser to do, is accept input from a number of sources, merge them, and produce a synthetical document that reflects decisions that none of the sources individually can know about, because they rest with the reader. To achieve this without the necessary languages to describe relationships _between_ (other) documents is so cumbersome that it is effectively removed from the wish list to begin with. (Imagine setting up a chain of numerous proxy services for each of the documents you want to look at -- you can't even click on links, anymore, because you may want to select another linking document.) I really hope this helps. #:Erik