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