The Proceedings of the 1989 NanoCon Northwest regional nanotechnology conference, with K. Eric Drexler as Guest of Honor.

Return to NanoCon Top
Return to NanoCon Proceedings Table of Contents
Return to Jim's Molecular Nanotechology Home Page

NANOCON PROCEEDINGS page 6

IV. HYPERTEXT PUBLISHING

Introduction by Mike Thomas

This afternoon's agenda will focus on hypertext. I've been asked several times "Why hypertext in a conference on nanotechnology?" I'm going to let Eric explain. Basically we're going to talk about a technology that is already in place and how we are going to exploit it to support some of the activities in nanotechnology.

A. Eric Drexler: Hypertext and Nanotechnology

I'd like to make a few comments on why people who are interested in nanotechnology and future technology in general should also be very interested in hypertext. If we as a society are going to understand future possibilities in technology, it is very important that we have better means of communicating and debating complex ideas.

For example, let's say that you are somebody who goes around giving talks on something kind of crazy sounding like nanotechnology. What you find is that you write paper after paper and give talk after talk, and you give talks to many technical audiences on the subject. You find that various questions come up, and often the same questions come up again and again. You give different variations on the answers, sometimes better, sometimes less good. An audience can listen to a little bit of information that you give in a brief presentation, they can listen to a handful of questions and responses, and from that try to see whether this makes any sense. But there is no way that this process can accumulate over time. I can't come to an audience like this and metaphorically bring a bag full of previous questions and answers and say "Here is the full range of questions that technically competent people have come up with on this broad range of points, and here are the answers, and here is what other people think is the quality of these answers, and say "Look! This particular area seems to have withstood criticism; this particular area seems to be shaky because of such and such."

In paper media, if you read something, there is no easy way to find out what other people think about it. Science Citation Index helps in a slow, clumsy way. To evaluate complex ideas, one would really like to see what someone has said, see the most effective criticisms that have been made, see the responses to those criticisms, and to have all this happen in the context of a literature where supporting evidence, instead of being re-stated, can simply be incorporated by citation.

That is what hypertext publishing will give us. I believe that it will be a medium where good ideas will tend to rise to the surface more rapidly because bad ideas will be criticized effectively out of existence. I believe that it can be a powerful force for improving society's ability to understand complex technologies, and to debate complex policy alternatives for dealing with those technologies, and come to more sensible decisions more rapidly. It will give us a better chance of understanding where we are going, and of dealing with these issues, which I think is a matter of life or death.

Editor's Note: For a more complete discussion of these issues, see:
We now have the replacement for Mark Miller - the one who was responsible for making Mark Miller stay home and work instead of coming here to speak with us.

B. Marc Stiegler: The Xanadu Project

There are rumors that we are not feeding the programmers at Xanadu except when they deliver fully debugged code. Those rumors are only partly true.

1. The Hypermedia Shopping Plaza

I do my presentations out of my hypermedia shopping plaza [Editor's Note: Marc used a program developed in HyperCard® to illustrate these ideas]. You can walk around the shopping plaza. You can go into the toy store and buy copies of "Manhole" and David's Sling. "Manhole" is the first really good piece of hypermedia art, and David's Sling is the first hypermedia novel. There are also some unusual stores, such as the "Problems & Answers" store. We can go into the library and roam through the card catalogue, back and forth through all the world's knowledge.

We can't build the hypermedia shopping plaza today. This is only a demo. When I do my hypertext demo, I go through the resources of the plaza and use it to cure a disease [see "Hypermedia and the singularity" by Marc Stiegler, Analog, January, 1989, pp. 52-71.]. All the information to cure this disease existed in the world, but it took three years to find all the pieces. It takes 30 minutes to do with hypertext.

For this audience, which knows something about hypertext from reading Engines of Creation, I thought I would show you the recently added new building--the Xanadu headquarters building. Xanadu has divided the problem of building hypermedia information systems into two parts.

2. The Xanadu Information Server

Our primary focus is building the back end. We will ship with our product one example front end that we refer to as "The Exemplar", which will supply a certain amount of generic hypermedia information manipulation capability. It won't be specifically designed for building the point and counterpoint refutation systems that Eric describes in EOC, but it will be better for doing such refutation systems than anything that exists in the world today.

The information server will share some characteristics with conventional database management systems. One thing that all such systems must do is protect the integrity of the data in the face of catastrophes, such as loss of power, operating systems crashes, etc. One peculiarity of such an information server is that some user is working 24 hours a day so that the system can never be shut down for repairs. The normal shut down mode is a catastrophic failure in the hardware or the operating system. Another characteristic is that it must be able to support multiple, concurrent users. It must also be able to grant various permissions and accesses to different data.

The hypermedia server is also very different from a conventional database management system. The major difference is that a hypermedia server gives information management for unstructured, multimedia information the way that conventional databases manage highly structured records. We can support all types of digital information - text, pictures, sound, and digitized video. We treat the data as large blocks of bits. It is up to the presentation application to present those bits to the user in an intelligible manner.

Xanadu was originally envisioned by Ted Nelson 20 years ago to be the basis of a hypertext publishing system, wherein people from all over the world could pour knowledge in and get knowledge out. To support that large a user community, you have to be able to guarantee that no matter how large the information pool grows, you will still have rapid access. For the last 19 years the people at Xanadu have been working on the algorithms to guarantee that. We now have some mathematical proof that various kinds of access are logarithm-bound so that rapid access can be guaranteed no matter how large the information pool grows. This characteristic is very valuable even for people who have much smaller information pools. The information pool always gets more valuable as it gets larger and richer. Thus, it would be very disappointing if performance sharply degraded someday just as the pool was getting large enough to be the most valuable thing in your entire corporation. That won't happen to you if you use Xanadu!

3. Links in Xanadu

We also support very fine-grained and very large-grained links. For example, you can attach a link to an object as small as a single byte, or as large as the first 25 volumes of the Handbook of Nano-Assemblers, which we all hope will be a very large handbook one day. The fine-grained linking ability is very fundamental to doing the refutation systems that Eric talks about. The next time you get into a heated discussion with somebody, note carefully the size of the objects that you are arguing about. Frequently you are arguing about a sentence, a phrase, or a particular word. Thus you need a fine-grained link to effectively attach a refutation.

Another capability that we supply is that all of our links are bi-directional. If any of you have used HyperCard® or Owl's Guide® you know that most systems that are commercially available use single direction links. This difference is important when you're trying to traverse a very large information pool. One particular example, using the mini-max algorithm, comes out of my personal experience working on my master's thesis. I was studying learning using the game of Reversi, and I was able to go back, using a series of backwards links, from discussions on using the mini-max algorithm on Reversi to discussions on how it was used in chess to the original invention of the algorithm. As people write, they build backwards links through what they reference. Unfortunately, from the mini-max document, you can't see links made to it, only links to things that it references. With bi-directional links, the guy working on Reversi can go back to mini-max and find a forward link to find out about alpha-beta forward-tapered pruning mini-max, which is the version of the algorithm that is very useful for Reversi.

We also supply the ability to attach sensors to regions of the information pool. When someone makes a change inside one of those regions, then the server will automatically send you an alert that somebody has been monkeying around in that region, which you are responsible for. You are not then dependent upon someone sending you electronic mail about the fact that he just attached a new refutation to your most cherished work. If this a fatal refutation, and it will be available to anyone who reads your document thereafter, you want to be alerted so that you can counter-refute.

We also supply "version control" and "historical trace", even for multi-media documents. Version control is something that the computer science community has avoided supplying for years. It is hard to do, and as long you are dealing with stand-alone systems, the individual user will maintain a limited amount of version control in his head. That approach instantaneously breaks down if you have three people working on a document together. For example, an engineer designs a circuit, then someone else uses that circuit as a basis for a new circuit. A new user could use Xanadu to review the development of the circuit and see all the changes that had been made.

If you think about the collaborative endeavors that you have undertaken, and if you have tried to use collaborative software, I think you will find that these capabilities are needed for any kind of collaborative endeavor. If you can't get a fine-grained link, then you can't attach a refutation to the specific point that you wish to refute. If can't get a link at all, you won't be able to find related documents because they are buried in directories hither and yon. If you don't have sensors that signal you when things are changed in areas that you care about, then you lose control. If you don't have version control, then you lose control again. We believe that Xanadu forms the underpinning of really successful collaborative software that will be seen in the next couple of years.

4. First Xanadu Configuration

The first configuration that we will be supporting for the hypermedia information server will be in the Sun® computer family. We will be building our Exemplar front end for both IBM® PC's and Macintoshes®. You will be able to access the information server either across Ethernets® or across telephone lines from your Macintoshes or PC's. There will also be an unknown number of third parties who will be releasing special purpose applications at the time we release the package. There may be from zero to several hundred third party front ends. After we have Xanadu available on Sun computers, we will start to port it to every platform on the planet. You will need at least a MacII or a 386-PC for the back end if you plan to serve more than one person with information. Shortly after shipping the basic Xanadu information pool, we will make available as an option a back-end to back-end protocol so that multiple information pools on multiple computer platforms will be able to exchange information. This should come out very quickly next year.

The one thing that we have committed to (the reason Mark Miller and everyone else is locked up) is shipping a product sometime this year. We expect to start beta testing of the back end for third parties sometime this spring, and we hope to have the Exemplar along with a relatively solid back end available in late summer or fall for beta test site end users.

5. Applications of Xanadu

I would like to briefly mention two of the applications that I think should be especially interesting to this group. Xanadu will make possible truly effective electronic mail systems for the first time in history. My experience has been that what happens with electronic mail is that you start accumulating very long lists of messages, so that it becomes very difficult to find some fact that you know you received many months ago. Thus you end up re-doing the research rather than trying to search your mail. If your mail was in a hypermedia pool, and the linking techniques were very easy, then you can link everything together.

I can't help thinking that one place that this might have made a difference is in the launch of the space shuttle. Making a decision to launch the shuttle has to trade off the short term risk of having the shuttle blow up against the long term risk of having your project cancelled. Somewhere out there in the long list of memoranda that the NASA people have sent back and forth, there is surely a long list of memoranda about safety, one about O-rings, about weather. Had the guys who were worried about the launch decision been able to quickly whip through all of these messages and found the 3 messages that linked these things together, and presented this to the guys in charge of the launch decision, might it have made a difference? This is an example of something that you could do with Xanadu immediately.

Another example is of something that would take a few years to pull off. We will need a lot of public pressure to pull this particular example off. How many people saw the Bush-Dukakis debates? In the second debate there was a very interesting interaction, wherein Bush made an assertion that even Dukakis had voted a certain way once. Dukakis said "Absolutely not!"

Obviously somebody was stretching the truth really hard. I was quite sad because I figured that my chances of finding the truth were very, very small. Maybe somewhere some journalist would write an article and talk about Dukakis's actual voting record, but my chances of seeing that article and linking the result back to this particular video clip were very slim. Now mankind had a very fortunate accident because the next journalist to ask a question had happened to have memorized Dukakis's voting record. One sad thing about this incident is that most people don't remember the incident or what she said, but at the moment, if we had held that debate on a hypermedia information pool, then every journalist who had a comment to make about this inter-change could have put a little icon on the screen, and anyone who was interested could have punched a button and found the analysis, and even looked at the actual minutes from the governors' caucus in question. Suppose this broadcast had been held inside a hypermedia information pool, and suppose the candidates had known that whatever they said, anybody in the country would be able to link the video clip to the proof, the voting record. Might that not have changed what they said in the first place?

These are some of the things that we are hoping for with Xanadu.

AUDIENCE: In my opinion, information integrity is going to be a very critical issue. What have you designed into...

M. STIEGLER: We are taking a number of approaches to solve different problems. An example is that we are building a piece of software that we refer to as the "unusually reliable disk interface." It supplies more protection than is usual against normal operating system problems like writing two directories. One possibility is that we may when we start shipping hold an annual contest wherein every person who finds a way in which a Xanadu back end fails, gets a reward. We are aware that reliability is a very big issue since we will be asking people to put everything that they have into Xanadu. Currently computer manufacturers are asking you to put everything into their filing system under their operating system. If that doesn't scare you, then you don't understand computers very well.

Editor's Note: For more on the Xanadu project see:

C. Louis Roberts: A Hypermedia Image Access System

Introduction by Mike Thomas

Undoubtedly this is going to be very exciting stuff in the years to come, but the reality is that these systems are just getting started and there's a lot of different versions of software out there trying to support these techniques, and there's a lot of trouble putting systems like this together. I'd like to introduce Louis Roberts from Boeing, who has been building such a system for a while, and he is going to tell us about what they have built and discuss some of the issues that they resolved along the way.

Author's Abstract:
Hypermedia Image Access System: Scope, Strategy and Lessons Learned
G. Louis Roberts. Boeing Computer Services, Seattle, WA 98124.

Overview of a hypertext system developed to assist Boeing Commercial Airplane (Operations Technology) in automation of image access to a library of 40-50,000 visuals. Why the system is needed, why our organization was chosen for the implementation, the scope and functionality of the system, and the lessons learned during implementation.
L. ROBERTS: I started as a biochemist and sneaked out of biochemistry and into the back-door of computer sciences. Who knew that Boeing needed someone like that?

This presentation is not to be construed as an endorsement by the Boeing company of any particular product, group of products, or technologies. They made me say that, and I'm glad!

1. Overview of the System

We're going to be talking about a system that was created to address a particular technical need. I'm a senior analyst with the Boeing Company. My organization is Information Retrieval Technology. Our charter is to implement both text and graphics databases across the Boeing family of companies, and we are just now getting into hypertext, hypermedia technologies. The customer for this effort is the manufacturing and development group of the commercial airplane company. They had 40,000 photographs of various manufacturing procedures. How do you find anything in such a huge file? The scope of the project is to convert all 40,000 photos into an electronic form, to add category information to them, and to interconnect at least three Boeing sites over existing Ethernet. We are going to establish Macintosh work-stations linked to an optical disk drive via boxes to a Vax. The Vax will have something called the Photo Navigator, developed using HyperCard, that will contain many stacks, each with a few photographs. The user's work-station will be a Mac or a MacII linked to a video monitor, which will have the images stored in analog form on a videodisk (digital takes too much room). The HyperCard application will bring up the video image and show it on the color monitor, and possibly allow the user to print the image right at the workstation, if the resolution is satisfactory.

2. How the System is Used

[Editor's Note: Some of the views of what the user would see at various stages while using this system are available in the appendix.]

When the user first enters the system, he is shown two main activity "loops." The main activity is to build an order list of photos that the user needs. If he can't find what he needs, he is shunted to an exception loop that details an administrative procedure for requesting a new photograph to be made. In addition, a "describe" button brings up a scrolling panel that tells everything about the contents of this first screen. This panel discusses each of the icons on the screen in turn, and as each icon is described, it flashes.

At any time, the user can click on any icon. One example is the "Category Selector." After choosing the appropriate category out of about 1000 categories included, double clicking on that category will instantly link the user to that category of photos. If the desired category is not present among the categories offered, single clicking within the field of category choices will bring up a box into which you may enter text (describing the category that the user wants). The program will then search the files for that text. If it is not found, the user is shunted to the exception loop to request a photograph to be made. If a stack is found wherein that data might lie, a display gives categories, dates, remarks, and an image of a photo.

In some cases, access to a photograph is restricted. The user is warned that these categories require a special signature to show a "need to know."

A "Find" button explains how the retrieval works. It shows how to click within fields or to get into the "slide show" mode and browse through a large number of pictures. Entering criteria into the "Remarks" text box provides an opportunity to refine the photo selection. If the image, in this example a type of tape laminator, is found, it is displayed as a 72 dots-per-inch, black-and-white image on the computer screen. This image is a crude representation of the original color photograph, but was nevertheless an improvement on the black-and-white photocopies that the engineers had previously been using to judge which photographs they wanted to look at.

The application supports several browse modes: find the next tape laminator image; do a slide show of all images of the tape laminator; show all of the images within this particular category regardless of whether they have anything to do with the tape laminator. At any time, the user can use the "Order" button to activate a menu to order the original photograph as a color slide, transparency, etc. Again, he may be notified that he needs his supervisor's approval.

The next step gives the user the option to return to the search system and get another photograph, or to print his order list. The creation of the order list is the only step that involves observable delay. All of the panel-to-panel photograph retrieval operations are quick (3-5 seconds), even with a slow Bernoulli box.

3. Other applications

Within our company is something called the DC Office Morning report, which is basically a "clipping service" in which a staff reads everything that might be of significance to the company, capsulizes it, and distributes it to selected management. To address that audience, we developed an application that is more like hypertext, with no graphics component. Double clicking on a word will thread to the next occurrence of that word within the application. There are 2081 cards and about 2.5 megabytes of text in this particular application.

Another demonstration I have done is for the Government Industry Data Exchange Program. Text and graphics are both included. A button entitled "Picture" appears when there is a picture linked to a particular piece of text. This example is about "Red Plague", which is the condition in which silver-plated, copper electrical wire grows copper oxide in response to atmospheric conditions. Again, double-click, backward-forward navigation is supported.

4. Lessons Learned

· Surprisingly something that was intended as a single-user workstation productivity tool, and written by one guy, was found to address the networked information retrieval needs of a company as large as Boeing, and in a very complex computing environment. Despite some deficits in HyperCard® and in other hypermedia tools currently available, the functionality has been adequate to the task so far.

·The networking capability has been good, but text retrieval needs improvement. We are investigating running our own externals to allow better capability than is present in HyperCard, and to allow linking to more powerful computers.

5. Discussion

AUDIENCE: You mentioned that the two versions of HyperCard® are just barely adequate. Have you heard anything about SuperCard®?

L. ROBERTS: We're on the list!

AUDIENCE: Another question. At an office products show in Portland last week I saw the Canon color laser printer, and I was wondering if something like that could be hooked in to give color laser prints.

L. ROBERTS: The color printer that we were looking at was basically a color video printer for $1200-1400.

QUESTIONER: The Canon printer is $40,000, but the prints are cheap.

AUDIENCE: How much human time did it take to create a filing system for 40,000 photographs?

L. ROBERTS: About 4 man-months. A lot of that is coordination and gathering requirements. The users were focused tightly on "How can we improve our paper system?" It required a cognitive leap to get them to consider an electronic system. The requirements were not that easy to flush out.

AUDIENCE: Is HyperCard® a tool for creating user interfaces?

L. ROBERTS: I believe that that is one of the areas where HyperCard® is functionally very strong.

AUDIENCE: Would you do it the same way again?

L. ROBERTS: Basically, yes. I might wait until Supercard® was actually shipping because it has significantly more power. Also, it's important to get the users involved as early as possible.

AUDIENCE: Do you see a problem in how the system behaves as the number of users grows? Also, what are the limiting factors the way the system is currently implemented.

L. ROBERTS: The limitations of the prototype are primarily that configuration control over these data files is a pain. If you store them on a server somewhere, you're locked into low resolution and long transmission times over the network. If you store them at the work station on a laser disk, you've got real good resolution and vanishingly small transmission time, but you've got a large configuration control problem of shipping out, mastering, and distributing the laser disks for the images. We don't yet have optical fiber in place to quickly send large pieces of data, nor do we have the kind of sophisticated data compression methodologies to make small bit-packages out of large graphic objects.

The up-scaling problem that we will encounter here is collision between user A and user B wanting to get at the same photograph. Right now we rely on happenstance -- that there are far more photos than users, and that the different users tend to have different interests. The up-scaling of HyperCard® itself isn't really a problem because each work-station has its own copy of HyperCard and is addressing the data over the network.


Next page of the NanoCon Proceedings
Previous page of the NanoCon Proceedings
Return to NanoCon Proceedings Table of Contents
Return to Jim's Molecular Nanotechology Home Page
Return to Web Site Design and Authoring Services

Comments and correspondence? Send email to Jim Lewis:
nanojbl@halcyon.com
NanoCon Proceedings © Copyright 1989, by NANOCON
This page is part of Jim's Molecular Nanotechnology Web, copyright ©1996 James B. Lewis Enterprises. All rights reserved.
Last updated 26June96.
The URL of this document is: http://www.halcyon.com/nanojbl/NanoConProc/nanocon6.html