Subject: Re: LISP and AI
From: Erik Naggum <>
Date: 2000/05/10
Newsgroups: comp.lang.lisp
Message-ID: <>

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


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

  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.