Hypertext from the Data Point of View: Paths and Links in the Perseus Project more

W~ 503 HYr Eun 005. The Cambridge Series On Electronic Publishing Managing Editor: P. HAMMERSLEY HYPERTEXT: CONCEPTS, APPLICA TIONS SYSTEMS AND 1 c IIJ The prupose of this new series is to publish books in the exciting and topical field of electronic printing and publishing. The series will attempt to cover all aspects of electronic publishing including: Proceedings of the First European Conference on Hypertext, INRIA, France, November 1990 Edited by N. Streitz, GMD-lPSl, Germany A. Rizk, lNRlA-Rocquencourt and J. Andre, lNRlA-lRISA, Rennes • Matters relating to hardware, software and standards concerned with transferring authors' words and images to the printed page; • Screen-based documents - hypertext and its implications for authors and readers; • Document delivery - electronic methods of reader access to publications, full-text database publishing, CD-ROM delivery systems and the impact for libraries; • Human factor~ relating, for example, to document structures for readability, editing aids, expert-system based interfaces and type and page design, ' While there will be some overlap with other areas of computer science (such as information retrieval, HCl and computer graphics), the series will conc~ntrate pnmanly on books concerned with publishing and so should provi e a scholarly and specific survey of developments in'this subject area. Ttl 1 es WIll range from advanced textbooks to multi-author works. . Already published. EP88, Document Manipulation and Tor h . yp g ap y; J.C: van Vliet (ed). StruCturedDocuments' J And ' Raster Ima in d.' .: re, R. Furuta & V. Qumt (eds). g g an Dlgltal Typography 89; J. Andre & R. Hersch (eds). Tlurlfl"I1f,1JI 1J.mnily.f~ UlprlJll_ .. a .s_~FIIf-a rJotu,.;-..., ...... ",urtn ..... I"'Hi>JId<~ <iIoa -.-.~ H.""vm"'Jw. 1514. CAMBRIDGE Cambridge New York UNIVERSITY PRESS Port Chester Melbourne Sydney Wf 50:; HYI Eur 005 I • II , Published by the Press Syndicate of the University of Cambridge The Piu Building, Trumpmgton Street, Cambridge CB2 I RP 40 West 20th Street, New York, NY 10011, USA 10 Stamford Road, Oakleigh, Melbourne 3166, Austral ia Table of contents © Cambridge University Press 1990 First published 1990 Printed in Great Britain at the University Press, Cam bridge ECHT'90 conference '" , , , . , . , . , , . , , . , . , . , . ' . , . ' , ' , , , , . ' .... , ... , .. viii Librar»of Congress cataloguing in publication data available British Library catai " ogulllg III publication A. R1ZK and N. STREITZ Preface "" , .. " , ix , data available Keynote address P.BROWN Assessing the quality of hypertext documents , .. , , ,. 1 ISBN 0 521405173 Toolkits for hypermedia applications M. SHERMAN, J. HANSEN, M. McINERNY, and T. NEUENDORFFER W Building hypertext on a multimedia toolkit: an overview of Andrew Toolkit hypermedia facilities ........ ", ...... "", .... ,.,.,." ... ",. J. PuTIRESS and N, M. GUIMARAES 13 The toolkit approach to hypermedia , ... R. OGAWA, H. HARADA, and A. KAMEKO .. , 25 Scenario-based hypermedia: A model and a system ,.,.,.,., , . , , , , . , , , , , 38 Formal models and query languages F. AFRATIand CO. KOUTRAS A hypertext model supporting query mechanisms, . , .. , , ,_. , , ... , ... , , , , 52 C BEERIand Y. KORNA lZKY A logical query language for hypertext systems ,.'", O. LUCARELLA .. , ... , .. '. _. , . , ., 67 A model for hypertext-based information retrieval .. . , 81 Databases, indices and normative knowledge H. SCHurr and N. STREITZ HyperBase: A hypermedia engine based on a relational data-base management system P.O. . , . . . . . . . . . . . . . .. ,., .. , , ,. 95 BRUZA Hyperindices: A novel aid for searching in hypermedia, ..... _.. , ., ... , 109 Hypertextfrom the data point of view 325 Hypertext from the Data Point of View: Paths and Links in the Perseus Project Elli MYLONASand Sebastian HEATH Department of the Classics 319 Boylston Hall Harvard University Cambridge, MA 02138 the project is to produce a new kind of structured library, in which it is easier for both researchers and students to move about and to find the information they need. Given the diversity of the data, of its destined uses, and of the relationships among the parts of the data, the form of a hypertext was found to be the most appropriate form. The first release of Perseus- will contain about 100 Mb of digital data, and about 15000 NTSC video color images. It will be released as a combination of CD ROM and videodisc. The CD ROM will contain all textual information, and black and white images; the videodisc will contain the still and moving color images. Perseus runs on the Macintosh in HyperCardr To accommodate limited budgets, reduced versions will be available for users who have only a CD or only a videodisc player. It is important to note that the Perseus Project has been conceived and is being carried out by classicists and archaeologists. We are confronting a variety of problems on the technical and on the scholarly side. We must at the same time translate traditional paper information into a useful and intelligent electronic form and create the system through which it will be used. Since it is impossible to design and implement a large software system at the same time as creating and structuring a large amount of data, we decided to minimize software creation as much as possible. We want to create a system that is powerful enough to be useful, but that will at the same time be available as soon as possible to our intended audience: academic departments, libraries and student resource areas in schools and universities. These constraints have obviously had a great influence on the hardware and software decisions for the project. ABSTRACf: The Perseus Project is building a system for studying Classical Greece, incorporating into it several different types of source material. In order to minimize system development time, and to make it accessible to the users of the system faster, it is being developed on Macintosh computers. using HyperCard. This paper describes two navigational methods that have been created in Perseus: generalized linking, and paths. They were chosen because they could provide the most flexibility and the most functionality. Their implementation is briefly described, as well. KEYWURDS: linking, navigation, paths, Perseus Project 1 Introduction Classical Greek civilization is a topic with relevance to many different disciplines, which can be approached from numerous, differing, standpoints. The same data, which comprises textual and visual sources, can provide different information to the philologist, the historian, the art historian and the anthropologist, to name a few. As these disciplines have to cope with more material, their practitioners tend to become more specialized, and to work within a more circumscribed area. At the same time, it is obvious that these related disciplines stand only to gain from synthesizing their data and their expertise. The Perseus Project I is in the process of creating a database of textual and visual material on Classical Greece in electronic form. The information we are collecting will include Greek texts and English translations, images of archaeological objects and sites, their textual descriptions, and secondary material such as a dictionary and and an encyclopedia. The defming principle of IThe Project is based al 2 Desirable Features Since the Perseus Project has decided to minimize in-house software development, we had to choose carefully those features that were most necessary to make our data useful, and were also within our means. Our first decision was to keep our data independent from our delivery system. All Perseus data exists ill a richer archival format than HyperCard can manage," so that it may be ported Harvard University, with collaborators at Bowdoin College, Pomona 2perseus 1990b will be released for testing in June 1990, and the first public release is planned for D3ecember 1990. There will be a yearly version after that for at least 4 years. . I Macmtosh and Apple Copyright by Apple Computer, Inc. These decisions 987, when the project received its first major funding from the Annenberg/CPB were all made tn Project. College, and St. Olaf College, among others. It is funded primarily by the Annenberg/CPB Project, and by Apple Computer, Inc, Prof- Gregory Crane of Harvard University is the project director. are fi 4rexts I .all structured using SGML all black and white images are entered as PostScript iles, and , . co or images are stored as color sltdes. 326 E. My/onas & S. Heath Hypertextfrom the data point of view 327 to more powerful software and hardware. If, however, our system is to provide any new functionality beyond a simple translation of paper data and methods to electronic form, it has to allow easy navigation among the different kinds of information it contains. For example, a readers who is reading an historical essay on early Athens should be able to effortlessly follow a link to a primary source discussing the law-giver Solon. Likewise, a student who is studying a plan of Olympia should be able to see images of the site, and read the descriptions that are in the ancient travelogue of Pausanias. Furthermore, these links must be latent in the database. Unlike many systems," where the information is added incrementally as new links are created, Perseus is starting out with a large database of extant materials." It would be impossible to create all the necessary links by hand. To save overhead, the same mechanism should be applicable both to handmade links and those automatically generated by the system. Since we have chosen to distribute a read-only database in a low-end system, Perseus cannot support a sophisticated network of user-created links on the lntermedia or the KMS model. We can be sure, however, that all the users of Perseus, whether they be instructors, students or scholars, will want to be able to leave their mark on the system. They will want to take notes, create guided tours and lessons for students and peers, and write essays and papers in Perseus. It is necessary to provide a simple device that will allow all these activities, and that will work in conjunction with a CD ROM. The Perseus path editor is our solution to this problem. Paths can be enhanced by a note-taking facility, which allows for extended commentary on the part of the reader, and that could be integrated into the guided tours. It is readily available, and can handle character sets and images relatively well 3 Hardware and Software For a number of reasons we decided that the best computer for our purposes would be the Macintosh. It is already common in many universities, it has good graphics capabilities and handles non-Roman character sets well. Our delivery system, HyperCard, has many of the same advantages as the Macintosh. and it is also free to buyers of new Macintoshes. In addition, it has an extensible scripting language. In 1987, the only other low-end hypertext system available was Guide, which did not support graphics very well, and was not yet extensible.f At that time we had some experience with Xerox Notecards, which might have been able to sol ve many of the problems that we still face, but we decidedagainst it because of its cost and unavailability." As it comes out of the box, HyperCard was and remains the least hypertextual of the many systems that fall into that category. However, HyperTalk gives it great potential as a development environment. Using it we can prototype the data structures and functionalities of our system easily. HyperCard also supports the multimedia capabilities that we need to display video images, and it works on read only media. Finally, we are reasonably assuredof its continuing ex istence and support from Apple. There are, however, many shortcomings to HyperCard. While there is no need to provide a comprehensive list of these, some have directly affected our abilityto create a large useable, database that can be navigated and manipulated in a "hypertextual" manner. Specifically HyperCard has no abstract link object. While it is possible to procedurally move from one card to another by executing a HyperTalk handler, and thereby provide the functionality of a link, there is no built in method to specify a link independently of the code that executes it. The endpoints of a procedural link remain unknown until it is located and executed. Links that exist as independent data objects can be treated as a database, and filtered,selectively retrieved and edited all together. HyperCard's visual interface also makes it difficult to separate the infonnation that makes up a link from the interface for initiating that link. The starting point of a link is usually the physical location of the button that holds a ~yperTalk handler that, upon invocation, will take the user to another card. herefore, a link IS accessible only when the user can see the button that Will perform the link. This joining of the interface and implementation of links makesthem hard to maintain; changing a link requires actually editing the button WhIchis the link endpoint. It also means that the linking mechanism is not ~ . 5George Landow of the Brown University English and Art History Departments and IRIS, pointed out that il is better to refer 10 me "readers," of a hypertext than to the "users." This is especially true for literary and scholarly hypertexts like Context 32 and Perseus. (Computing in the Humanities Users' Group meeting, Brown University. 1988). 6ln'ennedia, g-mlS, KMS, Notecards or Neptune are examples of such systems. 7For another attempt '0 handle similar problems see Frisse et al. [1989]. .. E:. all D ow forsopb' R e o'e[l989] Yen now, CD Word, which is built in Guide on the PC, had to add significant exrensrons t d linking between pieces of text. For a description 0 f t hiIS sys t e m ,.see li . .' IS reate to - and ~In 1985, Gregory Crane received a Xerox University Grant, and together with Jeffrey Wills enneth Morrell, produced some materials for studying classical texts. Morrell[1987]. 328 E. Mylonas & S. Heath Hypertextfrom the data point of view 329 generally available as an underlying system function. The Perseus Project has a standing policy of maintaining data separately from a particular front end application. We consider links to be a form of data that should also be kept outside of HypetCard, Buttons which contain the link information inside them do not allow us to do this. HyperCard also lacks an adequate mechanism for creating retraceable paths through the database. Using the "go back" command in an attempt to retrace one's steps does not necessarily allow the reader to revisit locations in the order she had encountered them. On the contrary, back tracking frequently re ult in an endless loop that hops between two cards. In addition, it is not possible for the reader to control which cards are added to the "go back" path, or to annotate them. Finally, the trail mechanisms that are built into HyperCard do not allow for the creation of permanent trails-all information is discarded on exiting the application. ." "0" Q to provide the reader with the ability to move from one document to any other withoutfirst going through a table of contents or a hierarchical browser. Due to the large quantity of data in Perseus, it is not possible to create by hand all the possible links that a reader might want to follow. to Perseus therefore relies heavilyon links whose endpoints are specified by keys found in the data, such as place names and textual reference information. Although a degree of hand craftedlinking is available to the editors of Perseus, the major linking technique isbasedon lookups in a wide variety of indices to the Perseus data. Just as Perseus has a standing policy of storing data in machine and applicationindependent formats, we feel that it is important to implement linking in such a way that it were not wholly dependent upon HyperTalk. We therefore decided to make as much of the the Iinking process as possible external to HyperTalk. This will also enable us to port our linking mechanism to another platfonn more easily. One important component of portability is the ability to refer to documents by a canonical name and not be bound by the file naming conventionsof any particular operating system. Our linking mechanism, then, has to automatically map between canonical references and Macintosh file names. Table I: Document types in Perseus Document Type Atlas BUilding Catalog CoinCatalog ImageCatalog PrimaryText SecondaryText Site VaseCatalog Type Code atlas arch it com vindex primary secondary site vase Canonical atlas title catalog title catalog title catalog title author, work author, work site name catalog title Name Internal Structure site site catalog # archive # language, reference catalog # catalog # ;. 300 "l Figure I: Generating Links in Perseus 4 Generalized Linking The feature that ill differentiate the data in Perseus from its paper analogue I the ability to move between different typeS of related data We want - An essential requirement for any generalized linking scheme is the ability ----;-----'" .. 'On IOnere are severa t diffrerent linking Implementations In current hypertext systems. M any reIy Sophist" 1 leated, hand made link objects. The best examples of tbis is lntermedia and Noteeards. 330 E. Mylonas & S. Heath Hypertextfrom the data point of view 331 to specify the end points of a link. Accordingly the Perseus Project has designed a highly flexible naming protocol that uniquely identifies all documents in Perseus and which allows references to specific points within those documents. It consists of three parts: the type of document being referred to, the name of the specific document, and a variable number of fields that can indicate the exact endpoint of a link. In Table I 'Document Type' and 'Type Code' list the currently identified document types and give the code for each type. 'Canonical Name' provides space for naming individual documents of a given type and 'Internal Structure' gives the format of references into each document type. The string "primary, aeschylus, agamemnon, translat ion, 776" specifies line 776 of the translation of Aeschylus' Agamemnon. The string "at las, perseus atlas, olympia" indicates that Olympia should be located in the Perseus Atlas of Greece. Note that each type of document can have its own grammar for specifying link endpoints within it. This flexibility increases the likelihood that Perseus will be able to accommodate different types of documents, with varied internal hierarchies, as endpoints of links. In the above protocol it takes a variable number of items to name a document uniquely. The Atlas is always named by a single item, namely "atlas." It always take three items, however, to name a primary text uniquely. Since the unique name of each type of document is always comprised of a fixed number of items, it is possible to separate the name of a document from the internal reference by knowing the type of document to which a link refers. We have compiled a database of all the documents that appear in Perseus and have named them using the 'type code' and 'canonical name' fields of the above protocol. It is this database that allows us to map between a canonical name and the name of the specific file that holds that document in the current implementation of Perseus. The canonical name is the first field of each record in the named object database. The second field is the current location of that document in Perseus. Table 2 shows the record for Aeschylus' Agamemnon would be: Table 2: Record Structure of the Named Object Database Perseus arne primary,aeschylus,agamemnon Current Location in Perseus stack aesch ag" lJ Looking up the string "primary.aeschylus.agamemnon" returns the string "stack 'aesch ag'''. This is a valid HyperCard location to which it is possibleto go. The Perseus linking mechanism that uses this database is broken down into three parts. First, the endpoint of the link is specified. Second, the named databaseis searched to ascertain the current location of the desired document and thatfile is opened. Third, the actual link endpoint is located within the target document. The goal of defining these three stages is to isolate the linking code intoindividual modules. The first and third stages of this linking process currently involve substantialHyperTalk programming. The HyperCard user interface is heavily dependentupon such building blocks as buttons, fields and pop-up menus. As notedabove, we want the same underlying mechanism to support user-specified linksand those built-in links provided by the editors of Perseus. The basic role of the interface is to generate a canonical name which the second stage of the linkingmechanism can use to move to the target document That name can be detenninedeither by clicking on a button that generates a predetermined name, forexample, an Atlas button, or by explicitly typing in a canonical name, such as thename of an ancient text, and invoking a general link button. From the user's Point-of-viewthere is a fundamental difference between specifying one's own endpoint to a link and following a link already made available by the creators of Perseus. However, this difference need only affect the user interface. Both types of linkscan use the same underlying mechanism for moving between two points. . The third stage, finding a specific point in a document, can have radically dIfferent implementations depending upon the type of document at the link endpoml. If that document is a primary text, then completing the link may entail fmdmg a specific line and highlighting it. If an Atlas is the endpoint, then complet' th e link means plotting a place name on a map and per h aps . . mg ~~ . . . g Ightmg It for the reader. Obviously these are two very different tasks that requITend"d i I .' . IVI ua HyperTalk handlers. In order to separate out this third stage It as w necess3ty to make every stack in Perseus able to handle incoming links. The A~~ . bour examp I' can display a place name on ItS maps, but knows not h'mg e, a ut selecting text. This "object oriented" approach simplifies the maintenance ofPerseuscode bv i . ..' Yisolating the document specific parts of hnk han dli mg. The presence of the database of named documents makes the translation • • " 332 E. Mylonas & S. Heath Hypertextfromthe data point of view 333 between canonical names and specific files very simple. As stated above, this database i searched and returns the location of the document. This location is then opened and the third stage of the mechanism is invoked. Actually pecifying the end point of a link is as simple as combining the name of a document with an appropriate internal reference. Figure I shows two different way in which to do this: by means of a predefined link, or by using a general link generation button. In the lower left hand comer of the site plan of then i a button who e icon i a map of Greece. This button indicates a pri ileged link to the Perseus Atlas. It contains a handler which simply con renate the title of thi card "athens" with the string" atlas, perseus atlas" to form the valid link string "atlas.perseus atlas.athens," A reader who presses this button will then be taken to the Atlas and see Athens highlighted on a map of Greece. In the lower center of screen is a pop-up with the "primary te r" item selected. In the adjacent field the user has typed "aeschylus,persians". electing "primary text' will cause the string "primary," to be prepended to the Iring "aeschylus, persians" to form the link string "primary, ae h lu . persian ." Either one of these strings can be passed to a shared set of handlers th t a tually moves to the target stack. Perseus. It also provides a mechanism by which Perseus. users can quickly move between different documents that comprise the Aaamemnon'sDeath f !'!ill+ my notes kgolid -.. ~ ccnspic ¥ Aehm.s n:;.. ..... Mf>9~""on o. ~ "9 , 372 :Q f- I1IjcenaE' b; Thi1IHl\t p).~in th. "f.mllml\on .. t..n Cl~.m..~r" .mufn rrOm th. h(lll,l'•• 't.l" h."h\C kmt-d h,. huttt.nd_ The pr ess of decoding and following a link is broken down into three step". First. the name of the document being linked to is identified. Then that name i earched for in the database of named objects and that location is a essed. Each ta k ha a handler called "incoming" which can take a link tring and find the document pecific internal reference. Upon arrival in a stack !hi handler is called with the link string as its argument. If that link string does not contain any internal reference, as is the case in table I. then "incoming" default to the beginning of the document The database containing named objects and their HyperCard positions has the further advantage of being easy 10 maintain and easy Lo modify. It is stored plain en file and can ea ily be added to and recompiled. Another advantage of this method is that each object can al 0 have more than one name. N.ebookll """',F,ot,"" liN,. '''h l f Re:ermgt Footprints IIDelete pathl ------§] I +-@r+ <D ? trllI ¢!l ¢> '* I Figure 2: PerseusPath Card 5 User efinedNavigation-Paths D !leCes theirow 0 orgamze and annotate n needs. The notio f.. . metaphor f '. n 0 a path or guided tour has been " frequent or naVtgalion in h ~es<:ribinh ypertext systems: Vanncvar Bush used it when . g ow the Memex wo Id b d II ' ,mplementar u e use. 1here have been several different Ions of paths in h 12 types:the hi , ypertexl systems. They fall into two distinct .. tstory tratl whi h . \'Jsns,t3nd th a . ' c automallcally logs every location the reader e guided tour who h . , siored visit d and ' tc tS a predetennmed set of locations thaL can be be e Over and over' h 14 tweenthe tw . , In t e same order. The primary difference o IS that the fi st ' . ~~~~ __ -=r IS an arttfact of the movements of a reader Ii 11BU'hl1945J In a hypertellt syst h ' em t at contains sary to allow users t .' a large amount of diverse data. it is the information according to 1lIe three records "primary "primary sophocles, text, sophocles, oedipus tyrannos:' text, sophocles, oedipus rex" and "primary text, oedipus the king" can easily co-exi t in the database and po iti n. namely the stack" soph 0 ." This i a simple but effectl\c v.a) of dealing with the nlultiple name thaI have been given Lo many same point Lo the - four documen . TIll implementation of links navigational 1.001 has pro\ed II fill ill crtlltmg an eily maintained network of predertned links wIthin Zeltweger[l9&9] . llln'o_. glVesa survey of th' , 14 ~uledla has impl ,ese Implementations and the basic types of path. Rep emented history tr il resenled hy Note' a s as a contextual aid to the reader. cards lablelops. Trigg[1989] 334 E. Mylonas & S. Heath Hypertextfrom the data point of view 335 through the database, which serves as a reminder of where she has been. The second is a consciously selected trail that is meant to be followed again, either by the creator, or by someone else. Although both types of trail can be saved and studied later, only the second is really made with an eye to future use. We decided that a path tool would be a productive metaphor for Perseus, and that the guided tour kind of path would be the most versatile. 15 These paths can be used to record where a reader has been, but may also be used in an expository manner, to prepare sets of locations in the database for other readers to visit. To complement Perseus Paths,we added an annotation facility, called "Notebooks." 16 Readers of the system not only want to save locations of interest, but also to comment on on them and their significance. They also want to make notes on their Own work. These Notebooks are HyperCard stacks that can be added to a path that also includes pre-existing Perseus material. Used together, paths and notebooks provide a facility that can be used as a hypertextual essay writing tool. 17 A Path is an ordered list of locations in Perseus. These are presented and stored on a card called the path card (see fig. 2). Each location on the Path is represented by an icon called a "footprint." A footprint on a Path points to either a whole card, or some selectable piece of information on a card, such as a span of text, This use of a separate location for the guided tour information allows an external database to reference the read only materials in Perseus. Each footprint icon on a Path card indicates the kind of data that the it points to, thus primary text is marked by a little scroll, art by means of a little vase, and maps by a map. t8 When a reader has created a Path, she may add brief annotations to each footprint on the Path Card, and also edit the path, rearranging and renaming the footprints. A reader can have one or more Path and Notebook stacks that are drive or floppy disk. Paths and stored on her own magnetic media-hard 15The paths available in the StcrySpace program provided a us with a good model for the functionality we wanted. although the implementation is different. Bolter et al.[ 1987] 16N ole taxing f aCI rues are extremely cornmon in HyperCard systems. The best example is -'.' '1" Notebooksare, al the moment, implemented completely in HypcrTalk. Paths are available from every card within Perseus. When a reader is in Perseus,she can choose to follow a Path by selecting from a list of those paths currently available. Clicking on the "path next" arrow that appears on each Perseuscard will move her to the next footprint. As she is moving through Perseusfrom footprint to footprint, any brief annotations that have been added to a footprint appear on the current card. The reader may leave the Path at any time,for example, by following a link, and then she may continue to walk the Pathwhere she left off by pressing the "path next" arrow again. A Notebook is simplya Perseus stack that does not reside on the CD ROM, but whose location isknownto the system, and that has blank space for writing on it. Like any other Perseuscard, a Notebook card may be added to a Path. It is possible to go to the currentcard in the Notebook with one click, from any card, using generalized links, Like the generalized links described above, the code that handles Paths is alsomodular, and able to handle many different types of specific path location in thesame way. Because they evolved separately, the two features do not yet use the same handlers and name database. However, this improvement is a top priority for the next version of Perseus. The way Paths actually work is as follows, When a reader adds a footprint to a Path, a string is created which contains information about the originating stack and card, and any other mfonnationthat is necessary to pinpoint an exact location such as a span of text Thisstring is generated by two separate functions: the stack and card information comefrom a general path handler that is on all stacks, and the stack specific mfonnationcomes from a local handler, This information is then sent to the Path card,where it is stored, and not used again until it is necessary to go the location ~~lcated by the footprint. At that time, a general handler can move back to the gmatmgcard and stack, and where a local handler controls any further details SUch indicating the selected text. As with generalized linking, this "object as onented" approach allows one set of shared path handlers to control path ~~~l ' eaves stac k-specific details up to the local environment. probably Ille Jefferson Project Notebooks. These used to be available through Kinko's Software Exchange. and are in use at the University of Southern California. 17Eatly vers ions of these tools were used in sections taught by ElJi Mylonas and others for Gregory Crone's "Classical Greek Literature and Fifth Century Athens' at Harvard. As students became more comfortable with the system, their writing tended 10 become less linearly conventional. (Spring 19 9). . I ~lier v~ions of the system had footprint icons. Which, we fell. did not convey enough information. The IConS were changed, bur the name "footprint" was retained. since it fits well within the path metaphor. 6 Conclusion , This paper has discussed some of the system features we have Implementedto create a database that will be useful to researchers, teachers and ~tudentsof Classical Greece, within the constraints of a low end software and ardwarepl tf a orm. We have concentrated our software development effort on 336 E. Mylonas & S. Heath creating tools that will be versatile and easy to manage. We feel that we have been successful in that we have created a moderately powerful linking and userdefined navigation system which has proven useful to us in our development effort, and to our first test users, who have been able to move around the database productively. At the same time we are trying to work within HyperCard, we are also careful to make sure that we are not trapped within it. Data and linking mechanisms are designed to be independent of the delivery y .tem, except for unavoidable system specific features. We also feel that the problems that we have encountered and tried to solve for Perseus are endemic to hypertext databases that are created from extant and diverse materials, and that the decisions we have made are applicable to hypertext database design at all levels. How should Hypermedia Authoring Systems forComputer Aided Instruction Look Like? Panelproposer: Peter A. GLOOR, Laboratory for Computer Science MIT, Cambridge MA 02139, USA Panelists: Michael KIBBY, Scottish HC! Center, University of Strathclyde, UK R. Ray MCALEESE, Heriot Watt University, Riccarton, Edinburgh, UK Max MUHLHAUSER, Institute for Telematics, Universitat Kaiserslautern, BRD Gerald . NELSON, Department of Agricultural Economics, University of Illinois, C Urbana-Champaign, USA Daniel RUSSEL, Xerox PARC, Palo Alto, USA 7 Bibliography Bush[I945) Vannever Bush, "A:; We May Think." Atlantic Monthly, 176. Bolter er aI. [1987J. Jay D. Bolter and Michael Joyce, "Hypertext and Creative Writing" in Hypmal '87 Proceedings. November 13·15,1987, Chapel Hill,NC, pp.41-50. Conklin e: aI.[1988]. Jeff Conklin and M. L. Begeman, "g-mIS: A Hypertext Tool for Exploratory Policy Discussion." ACM Transactions on Office InformaJkm Systems vol, 6, no. 4. pp.303· 331. DeRose [1989]. Sleven 1. DeRose, CD Word Tutorial. Dill as: Dallas Theological Seminary, 1989. Prisse et el. (1989). Mark Frisse and Steve B. Cousins, Information Retrieval from Hypertext: Update on the Dynamic Medical Handbook Project" in Hypertext '89 Proceedings. November 5 -8, Piltsburgh. PA. New York: ACM. pp. 199-212. Marshall er a1.[1989]. Catherine Marshall and Peggy Irish, "Guided Tours and On-line Presentations: How Authors Make Existing Hypertext Intelligible for Readers." in Hypertext '89 Proceedings. November 5-81989, Piusbwgb, PA., pp. 15-26. Morrell[1987] Kenneth Morrell, "From Books to Workstations: Problems in developing a computer based curriculum in the Humanities", Proceedings of ICDBHSS, 7/1/87. Slatin[I988J John Slatin, "Hypertext and the Teaching of Writing" in Text. Conl ext, and HyperText (E. Barret. ed.). MIT Press, Cambridge, MA, 1'1'. 111-129. Trigg11988] Randy Trigg, "Guided Tours and Tabletops: Tools for Communicating in a Hypertext Environment,' ACM Transactions of Office InformaJion Systems vol.. 6, no. 4, pp.398-414. Yankelovich et al. [1988] Nicole Yankelovich, Bern Haan, Norm Meyrowitz and Steve Drucker, "lnterrnediai The Concept and Construction of a Seamless Information Envircnmetu." IEEE Computer vol. 21 no. I, pp. 81-96. Zellweger [1989) Polle Zellweger. "Scripted Documents: A Hypermedia Path Mechanism," in flYfJerrexr '89 Proceedings. November 5-8, 1989. Piusburgh, PA. pp. 1-14. IntrOduction and Overview PelerA. Gloor (panel proposer) By the discussion among proponents and users of various hypermedia systems I hope to Clarify the requirements which are needed for a hypermedia authoring syst . em In order to be able to produce usable hypermedia learning programs, Evaluationcriteria for (hypermedia) CAl programs as e.g. the following points are well known: availability of "learning by discovery" • availability of a "learning environment" POSsibility the student to expand the learning environment himself. for individualization of learning (e. g. concerning learning speed, learning contents, learning sequence etc.) real multiuser capabilities as: