Scholarly Spaces 4 - Technical Requirements
[PREVIOUS] | [NEXT] | [FIRST]

IV. Technical Requirements

What characteristics should the infrastructure technologies have to best satisfy the scholarly practices and design principles which I have described?

IV.A. Distributed Computing

Let me recapitulate very broadly the evolution of mass usage from monadic computing to distributed computing in this past decade of the post-mainframe era. Up until very recently, Mac/PC developers have worked in a monadic computing model -- working with stand-alone machines, making minimal use of network services.[26] Mac labs currently in Meyer (and in dorms', Tresidder's clusters) represent the state of the art in stand-alone application-centric media work. This reflects the constraints of the technology as much as the lack of familiarity among this sector of the academic population with distributed computing.

We are moving toward environments in which we can deliver distributed media and services in forms which are meaningful to non-engineers. This corresponds to a sea-change in how we should view computation on the network: no longer need we think in terms of opening a file with an application on a particular machine in a particular operating system(OS).[27] Instead, we should be able to perform our cognitive gestures -- ie. making a citation, or executing a least-squares fit of selected data --- without having to explicitly designate a "file," "application," "operating system," or even computer. If the statistics code to do a nonlinear regression can't be found on your local PowerBook, it should be executed on a Sun or HP somewhere on SUNet -- you don't care where. MIT's X Windows users practiced a coarse form of distributed computing nearly ten years ago.[28] [29] We move the focus of design to the level of scholarly gestures. This analogous to designing clothes which people choose based on style or comfort and can wear without considering how many teeth/inch a zipper has.[30]

Networking/Distributed Systems Group's provides a version of MIT and CMU's location-independent computing paradigm. Unifying with DSG's AFS/DFS network file systems would save trouble in the long run, even if we suffer some birth pangs with the network. We avoid the administrative overhead of dealing with the Macintosh's relatively unsophisticated network tools. PC Novell is even more of a headache.[31] The first, and now paradigmatic approach to distributed computing is to deliver a baseline, or lowest common denominator of services across a set of blessed platforms, an approach followed by most systems administrator bureaucracies. This has many advantages, including robustness, predictable environments, and relatively low overhead. Among the many services provided in this model are: user authentication, user authorization; common, location-independent user space/views, quota management; common email backbone, MIME access; rationally planned improvements in data transportation and storage; efficient software distribution and licensing. (See VI.B.) For example, instead of CU-SeeMe and the unacceptably slow delivery rates of AppleShare networks, UNIX workstations can multicast video (MBone) on Ethernet with perceptibly better scaling behaviour.

We can begin to design more heterogeneous environments ("places" or spaces within the network) which are served by very high-level services (B, C below). Metaphorically, we can move from architectures of beehives or high-rises to much more variegated urban architectures. But variation, I should emphasize, does not imply or mandate anarchy.

However, much more scholarly use can be extracted from networked services than lowest common denominator (LCD) services such as security, email or distributed storage (see IV.B, below). Homogenizing to a Microsoft Word document metaphor, even augmented by hyperlinks, is another example of this LCD approach, which ultimately becomes a straightjacket. Another approach is to take the supremum across all available environments, taking advantage of different environments' peculiar strengths: eg. Macs for their rich set of personal productivity applications, SGI's for their 3D graphics and animation power, NeXTSTEP (NS) or Taligent for all the services demanded in the two paragraphs earlier (also IV.B), PDA's or whiteboards for capturing casual convesation, plus a rich programming framework in which we can rapidly develop new functions.

IV.B. What is required from the operating system[32]

The operating system must be at least NS quality. We need a set of workstations and environments in which a network multimedia presentation framework comes as a given. The base level should support or contain:

* multimedia, OS-independent distributed storage

* cascaded archiving facility[33]

* multimedia communication (email, bulletin board) at the system-level, uniformly available across all applications

* all standard Internet services[34]

Moreover, we need an OS which comes with services such as customizable full text search engines, filter services, object archiving in variant formats, data-links, 3D geometry (as opposed to graphics), built-in digital video support, and straightforward extensibility to new, currently un-integrated human-machine interfaces such as virtual reality (VR) or speech systems.

In a multi-platform, multi-OS world, the system must work transparently over a network of processors (like X, NS, Taligent, unlike Mac or Windows). More finely-grained, distributed OS' are on the horizon. We hope they'll slip underneath transparently, but only if we can migrate off of non-layered architectures (like current MacOS). Of course, one way to simplify the problem is to mandate only one OS for the whole university. For small institutions or highly-coherent institutions like Cal Historical Society or CCRMA, this is the best option, because one can standardize at a high level, but this is not realistic for a distributed institution such as Stanford.

IV.C. Scriptable development environments

No matter what systems are developed, so long as human interests change, systems will need to be modified on the spot to meet variable needs. Such modifications of system behavior are most flexibly done by humans writing scripts which are interpreted on the fly. Such scripts are best written in a language whose expressivity if not syntax is close to a subset of a human language (eg. algebra, English or a musical notation). In the scripting environment:

* the most public interface should be usable by power-authors, not just power-programmers

* script-authors should have access to entire OS toolbox

* authors should have tools for inter-operation with other authors' work

* privacy as well as memory security should be transparently provided.

IV.D. Interoperability at object level

Scholarly workspace builders will develop not monolithic applications like Word or PhotoShop, but tools like WebRunner or ScriptX objects (or Hypercard XCMD's) that cooperate by working on highly structured data (see below).

Such tools of course must present coherent user interfaces, and may appear as traditional application workspaces. This is far more challenging than most traditionally trained technologists realize. NS PixelMagician is an example where the UNIX toolkit pbmplus is packaged into what appears to be a sophisticated graphics application. Making the same set available under the NS Services turns such graphics transforms from specialist tools into utilities accessible to a wider set of authors, some of whom may not need to even explicitly invoke the tools. A set of services, each with its own network protocol, does not constitute a coherent user interface.

IV.E. Structured data vs. opaque data[35]

Wherever possible, we will maintain data in the richest form. As Larry Masinter (Xerox PARC) pointed out, intelligent agents, human or otherwise, can only be as smart as the structures used to encode data, so it is certainly true that data ought to be described in some rich way. (This includes everything from URL's to SGML to Mathematica notebook language.) Raw video or bitmaps are notoriously difficult to characterize by machine. But it will be more important to retain lossless convertibility. We can maintain degraded representations only as secondary copies for performance's sake.

Standards are being debated in every field for all sorts of structured data: spreadsheets, word file formats, image formats, etc. Taking our cue from a fundamental meta-principle in mathematics, the scholarly, non-technical communities may better spend their energies on discussing the right set of actions/transformations to apply to data, rather than debate at length which single format should be the mother of all formats.

It is not so important which rich structure is used, only that some rich structure is used. What's more important, I believe, is a rich space of transforms to map between data in one form to another without losing information meaningful to an intelligent agent. A general information-preserving translation framework[36] prepares simultaneously for archival preservation and for more fluid extraction of knowledge. Doug Lenat and fellow AI researchers propose to make sense of and retrieve media using propositional systems. This interesting alternative might be more useful ifone could easily fashion one's own propositional system in place of a canonical knowledge base.

In this section we have addressed the technological infrastructure that we would like to have in order to build richer or more seamless scholarly workspaces. Next, we turn to the concomitant human resources and organizational infrastructure.


[26] ASD has been making the transition from crafting courseware which worked on a stand-alone machine, good for only a particular lesson, to distributed media and distributed software for more intense scholarly work.

[27] OS will include, in addition to traditional basic operating system functions, substrate functions such as graphics and window management, persistent storage, and user interface abstractions (selection, action, event, etc.).

[28] Mathematica provides a much more refined environment for such location-independent computing, but in a narrower domain.

[29] Cf. S. Turkle's study of organizational-dynamic problems with the administrative approach taken by Project Athena in MIT: "Paradoxical Reactions and Powerful Ideas: Educational Computing in a Department of Physics," in Sociomedia, ed. Barrett.

[30] Of course engineering robustness is fundamentally important, and breakdowns occur, but we must minimize such "systems minutiae" in everyday work.

[31] Scaling, hardware/software compatibility and maintenance problems are so severe with DOS/Windows PC's that studies are emerging which show that "computerization" has usually not saved any money for the businesses which adopt computer technology. In the early days of business computing, the extra value added by technology was traditionally, and ironically, the close human support provided by the vendor (IBM).

[32] I use operating system loosely to include the windowing system, application frameworks, etc.

[33 How much is enough? We should enable and allow the traffic of highly-structured data which is ephemeral or personal. Examples include class-lecture videos which no-one asks to preserve. Other examples include complex telemetry data from a high-energy physics experiment, which may be delivered or processed using "public" network services, but stored on "private" (departmental) media.

[34] This presents a serious legacy problem. For example, even though the MMDD is prepared to attach to many commercial-strength RDBM's via its meta-database abstraction, MMDD clients must wait for the careful export of university bibliographic databases to a new, Z39.50-compliant server before they can attach to the sister data-sources.

[35] Opaque data is data that is stored without any higher-order semantic or structural tags. Digitized sound files and current digital video are opaque; TeX and scorefiles are structured.

[36] Such as those incorporated in Xerox's System 33 and the MMDD. In the special case of visual data and human agents, Pentland and colleagues in the Media Lab call such transforms semantics-preserving transforms.


[PREVIOUS] | [NEXT] | [FIRST]
xinwei@leland.stanford.edu - June 1995