The first kind is the more traditional non-interactive document, which
consists of media that will be displayed without deep modification during
normal use. The order in which the material is perceived might change,
fonts might change, pagination might change, color space might be
distorted; but there is an immobile core of content. Texts, images, moving
images, sounds, and potentially textures, tastes and other records of
sensory experience fall into this category.
This is the type of document Brian is having trouble keeping alive. These
documents can typically be transferred into alternate formats, but often
with a loss of design integrity.
The second type of document is a more recent arrival. This is a deeply
interactive document, such as a CD-ROM, video game, highly JAVA-ised web
page, interactive or generative music work, or, for the worst possible
case, a virtual world. In this case the interactivity is core to the
content. The specification of the interactivity is only intelligible in a
reconstruction of the hardware and software environment in which it was
written.
(If the time domain is not important to a particular interactive document,
then the hardware environment becomes less vital and more abstract; only
then does the strategy pure software emulation become sufficient- but the
time domain is likely to become more and more important. An example of a
design where the time domain is not critical is a command line interface.)
There will probably be no end to the exploration of new hardware/software
environments in which interactive designs can be expressed. This is a new
art form in its own right, that is generating its own loving momentum- it
is unstoppable. So it would not be wise to plan on the appearance of a
stable, ultimate standard metaformat for interactivity.
The recent email exchange about practices to keep documents alive has
generated some ideas that are better suited to the first kind of document
than the second. For instance, the idea of choosing the most standard
available format for representation only makes sense if the choice is not
central to the content being represented. This is true of text and
bitmaps. But it not true of interactive works.
A case in point. I've designed many virtual worlds in the software made by
my old company VPL, as did a lot of other people. Since that software
hasn't been supported for quite a while, many of us have tried to transfer
our v-worlds to other software packages. The v-worlds in question are
significantly complex, such as a brain surgery planner. The transfer
process turns out to be impossible. The VPL software had a particular way
of organizing interactivity that has thus far proven to be too hard to
emulate on other systems.
This is just one example. The management of old software is in general a
huge multi-billion dollar problem. We used to call it a "crisis" in the
biz, but stopped using that alarmist term because of its implied optimism;
a crisis has a resolution, but the software maintenance problem appears to
be with us for the long term.
In much the same way that it is unlikely that scientists will ever come to
the final conclusion of the process of empirical inquiry, attaining perfect
knowledge of the universe, it is also unlikely that complex, deeply
interactive systems will ever be documented to the point of perfect
completion by "metadata".
"Unlikely" does not mean "impossible". Many computer scientists have
attempted to find a general solution to the problem. I've spent years on
it myself. I think of it as the Everest of computer science.
The recent exchanges about long term document life perhaps apply a little
better to the first type of document. My thought on artificial perpetual
use perhaps applies better to the second type.
It is impossible to keep a hardware/software environment constant for
extended periods of time. With each incremental change must come
corresponding incremental changes to interactive works that run in the
environment. A dormant document might be revived in a world in which it is
no longer intelligible.
So the thought is to have constant automated exercise of the global archive
of interactive works. The result would be a continuous, verified match of
works to their environments. In some cases the environment would be kept
more stable than it otherwise would have been. This is what Apple does
with the Macintosh- testing a large number of applications on each
incremental change to the hardware and software. In other cases, the
interactive works could be maintained to keep working in a changing
environment, though of course that will damage their archival authenticity.
And perhaps we will get good enough at computer science to have some of the
maintenance take place automatically.
Another approach is to archive the interactive hardware/software
environments. It's easy to underestimate the difficulty of doing this.
It's expensive- you have to buy the machines at their peak value and devote
floor space to them. Even worse, you'd have to keep copies of every
hardware/software COMBINATION in working order but without changing a
single detail.
I've been trying to do this on a small scale with my own works. The
Stanford library has asked me to reproduce an early 80's VPL system that
ran a visual programming demo that did not run on later systems. I have
tried for two years to find the right combination of weird early glove,
weird early SGI, etc. - thus far without success.
At any rate, the perpetual use paradigm might be the only way to keep type
2, highly interactive documents alive. I thought about this originally
after considering the impressive persistence of the Hebrew Torah, which is
copied constantly, not merely on an as-needed basis.
All the best,
Jaron