A Cooperative Hypertext Interface to Relational Databases

Thierry Barsalou, M.D., and Gio Wiederhold, Ph.D.

Section on Medical InformaticsMSOB X-215, Stanford University School of Medicine

Stanford, CA 94305-5479

Abstract

Biomedical information systems demand cooperative interfaces thatmaximize the flow of information between machine and user. Withinthe framework of the PENGUIN project-an object-oriented architec-ture for expert database systems-, we describe the use of hypertexttools for designing sophisticated interfaces to the relational-databasecomponent of PENGUIN. The interface designer employs HyperCardto construct a visual representation of the underlying database thatrequires the user to recognize rather than to recall the appropriatecommand name. We show that the resulting direct-manipulation styleof interaction facilitates greatly information retrieval and presentation.

1. IntroductionCombining database and expert-system technologies into expertdatabase systems is art emerging research area. Expert database sys-tems can be seen as mediators-"software modules which exploit en-coded knowledge about some sets or subsets of data to create infor-mation" [12]. Designers of such systems that are targeted at healthprofessionals must face the challenge of developing high-grade user in-terfaces. Indeed, wide acceptance and use of any computer programpresuppose a good interface that maximizes the flow of information be-tween machine and user. The design task is not easy; other workersin the field [4] have noted that it can consume up to two-thirds of aproject's development time.

In this paper, we describe our use of hypertext concepts to meet thatchallenge. More specifically, we present cooperative HyperCard inter-faces to relational databases within the framework of the PENGUINproject-an object-based architecture for expert database systems. Co-operation is a critical element of all applications that are designed toconvey information to the user interactively [7]. Cooperation bridgesthe gap between the application's computationally convenient represen-tation of the world and the user's information needs. Applying cooper-ative principles can alleviate the interface problems of presentation ofinformation, understanding of the domain and of the application, andmodes of interaction. In Section 2, we describe briefly the PENGUINproject. In Section 3, we review the foundations of hypertext systems,we define PENGUIN's guidelines for designing hypertext interfaces, andwe describe our development environment. In Section 4, we present indetail PENGUIN's HyperCard interfaces to relational databases, beforeconcluding in Section 5.

2. The PENGUIN ProjectThe PENGUIN project investigates the hypothesis that an object-oriented approach can serve as a unifying framework for developingexpert database systems (EDSs) [1]. From our viewpoint, EDSs should(1) enhance DBMSs with structuring and manipulation tools that pro-vide the user with an appropriate level of abstraction; (2) allow ESsto access and handle efficiently information stored in databases, and totake advantage of database techniques for dealing with persistency.

Objects offer undoubtedly the appropriate level of abstraction forEDSs. Storing information in the form of complex objects, however,can seriously inhibit sharing and flexibility, since persistent objects bindapplication-dependent knowledge to the data [11]. A desirable compro-mise is to exploit existing database technology by defining an object-based layer on top of a relational database management system. Thisapproach does not require storing objects explicitly in the database, butrather calls for generating and manipulating temporary object instancesby binding data from base relations to predefined object templates.With PENGUIN, we therefore introduce a tripartite architecture forEDSs, where the object layer mediates between a relational-databaselayer and a knowledge-based layer.

To facilitate the mapping between the database and the object layerand to provide domain-independence, we employ a structural modelof the database to augment the relational model [13]. The structuralmodel introduces connections to describe relationships between pairs ofrelations; those connections capture knowledge about constraints anddependencies among the database's relations.

PENGUIN exploits the structural model's knowledge of thedatabase along two dimensions. First, structural semantics improvestraditional relational transactions in several ways [3]. For instance, wecan add the concepts of aggregation, categorization, and generalizationto the relational model-all concepts that facilitate information brows-ing and presentation. Second, the semantics contained in the structuralmodel drives the object layer and enables us to define and manipulateobjects of arbitrary complexity, the components of which are stored inrelational format.

A layered architecture with coupling of existing systems explicitlyprecludes physical integration. We require, however, conceptual in-tegration, in that the layers, even though they are separate entities,should present a consistent interface to the users. Conceptual integra-tion means that we can interact with the system at any given layerwithout incurring the overhead of the layers above that one. An im-portant part of our work has therefore to deal with user-interface issues.

3. Hypertext Interfaces for PENGUIN

Our research hypothesis is that a hypertext approach can facilitate thedesign of cooperative user interfaces for EDSs. In the remainder of thispaper, we motivate the use of hypertext, we present the principles thatPENGUIN adheres to, and we describe the hypertext interface that wehave developed for PENGUIN's relational-database layer.

3.1 Hypertext

Hypertext is an approach to information management in which datais stored in a network of nodes connected by links. Nodes can containtext, graphics, audio, video, or other forms of data; as such, they repre-sent small pieces of information. Most of the power of hypertext comesfrom the associative access provided by the links. Links can be uni-or bidirectional, and are used for navigating from node to node in thenetwork. Collectively, the links then define the organizational structureof the hypertext document. The ability to cross-reference chunks of in-formation explains why hypertext is also known as nonlinear reading

3830195-4210/89/0000/0383$01.00 © 1989 SCAMC, Inc.

and writing [9]. Furthermore, many hypertext systems provide addi-tional tools to facilitate browsing through the network and editing of adocument. (See [5] for a comprehensive survey of hypertext.)

Apple's HyperCard program [6] for the Macintosh personal com-puter defines and manipulates stacks. Stacks are collections of records,or cards, grouped by type, or background; fields and buttons can be de-fined for either an individual card or a background. Text is stored infields, whereas graphics and bitmaps are placed directly in cards andbackgrounds. Those five entities defined by HyperCard-stack, back-ground, card, button, and field-are arranged into a message-passinghierarchy. Programming scripts, written in HyperCard's own program-ming language (HyperTalk), can be associated with any of the afore-mentioned entities to specify particular actions (for instance, what todo when clicking on a button). HyperTalk is Turing-complete, provid-ing all the necessary control structures, such as iterative and branchinginstructions. Moreover, HyperTalk gives the programmer access to allHyperCard interface-design functions; for example, it is possible withina HyperTalk script to define and control the appearance of buttons,fields, cards, and backgrounds.

Although hypertext addresses issues in data storage and manage-ment, and in knowledge representation, it emphasizes particularly thepresentational aspects of organizing poorly structured information. Hy-pertext systems rely on a high degree of interactivity, and heavilyexploit visual metaphors such as graphics and icons to move rapidlythrough a hypertext document. It is this last presentational aspectthat, we believe, is the major contribution of hypertext systems. Ap-plying hypertext concepts to interface design can therefore be very ben-eficial to the development of EDSs. We are exploring that avenue ofresearch within the framework of the PENGUIN system.

3.2 Design principles

We are using the HyperCard authoring tool to apply hypertext conceptsto interface design. The objective is to develop tailored, domain-specificinterfaces that take full advantage of a visual representation (through,for instance, icons, buttons, and graphics), and that exploit domainsemantics to facilitate information retrieval, browsing, and updating.PENGUIN conforms to consistent guidelines for designing intuitive in-terfaces.

The interface designer uses HyperCard's tools to construct a vi-sual representation, which the user manipulates directly, of the un-derlying database or knowledge base. Within the taxonomy of direct-manipulation interfaces [14], PENGUIN employs visual correlation tospecify objects and actions. Inasmuch as visual-correlation methodsrequire the user to recognize rather than to recall the appropriate com-mand name, they typically place a lesser burden on human memorythan command languages do.

The use of graphic techniques, such as bold and italicized typefaces,can maximize information content and highlight facts and events in away that is quickly understandable. Accordingly, we use HyperCard'stools to illuminate concepts and to focus the user's attention. Further,HyperCard's command language supports the interactive design andinvocation of critical elements in the user interface, such as scrollabletext fields, buttons, menus, and illustrations.

The user can select an existing hypertext interface and custom-tailor it easily for the task at hand. Most important, perhaps, she canrefine the interface without writing a line of code, by using the largepalette of tools that HyperCard assembles. In addition, as libraries ofinterfaces become available, we expect the need for such refinement tobe minimal.

This direct-manipulation style of interaction can dramatically im-prove the human-computer interface. As summarized by Marchioniniand Shneiderman, "instead of remembering commands or traversingmenus, the user sees a representation of the 'world of action.' Becausethe user points (with mouse, touchscreen, etc.) at given objects andactions, the impact of actions is immediately visible, thereby reducingerrors and speeding performance" [8].

3.3 Development environmentPENGUIN's architecture fits well into the client-server model; mul-tiple workstations can access a centralized, remote database serverthrough a variety of tailored hypertext interfaces. The databaseserver is a microVax-II computer from Digital Equipment Corporation(DEC). The DBMS package that we use is Rdb/VMS, DEC's relational-database product. Rdb/VMS provides access to databases through anSQL-like declarative query language and through high-level-languagesapplication programs. Any set of Rdb/VMS data-manipulation state-ments can be included in the program to perform the latter method ofaccess. More specifically, we employ the Rdb-Lisp interface to accessdatabases from programs written in Common Lisp [10]. The worksta-tions are Apple Macintosh personal computers. As mentioned previ-ously, HyperCard is the hypertext authoring tool for the Macintosh.Its programming language, HyperTalk, can be extended with externalcommands and functions (the so-called XCMDs and XFCNs) that arewritten in MPW Pascal.

The clients and the server communicate through a serial, syn-chronous protocol that we have designed. On the microVax, the serverprocess, written in Common Lisp, continuously polls its assigned se-rial port to check for messages sent by a client process. The mes-sages received are in fact Common Lisp expressions (that may includeRdb/VMS statements), which can then be directly evaluated by theCommon Lisp interpretor. There is one such process for each worksta-tion being serviced.

On the Macintosh, HyperTalk scripts extended with a set of custom-designed XCMDs handle serial communication with the server; thosescripts include the XCMDs to build and send messages, and to receiveanswers (for example, the result of a database query or an error mes-sage). The communication is synchronous in that all transactions areinitiated by the client; a client process expects a response from theserver for each message sent, and no other message can be transmitteduntil an answer for the previous message has been received. A time-outmechanism maintains synchronicity and prevents deadlocks that canresult from transmission errors.

4. HyperCard Interfaces to DatabasesWe draw all the examples in this section from an immunologic-researchapplication, which utilizes a database of such entities as monoclonalantibodies, antigens, and fluorochrome molecules [2]. PENGUIN im-poses only one set of related constraints on the design of HyperCardstacks that provide an interface to relational databases: Each Hyper-Card stack must correspond to a particular database, each backgroundof a stack must correspond to a database relation, each field of a back-ground must correspond to an attribute of a relation, and each cardof a background must correspond to a record of a relation. Figure 1illustrates this parallel between relational databases and HyperCardstacks.

The HyperCard interfaces exploit simultaneously and in synergy thebrowsing and direct-manipulation features of hypertext, the analytical-querying and concurrent-access features of relational DBMSs, and thedatabase semantic model introduced specifically by PENGUIN. Suchinterfaces provide a number of capabilities to remove the memory bur-den from the user and to facilitate the interaction at various stages ofa database session.

4.1 Exploration of the schemaAn application domain is a body of knowledge, consisting primarily ofentities and relationships. Domains vary widely in complexity (numberof entities and relationships), homogeneity (similarity of the entities andrelationships), and evolution (rate of growth and structural change ofthe entities and relationships) [8].

In relational DBMSs, the application domain is encoded in aschema. Unfortunately, users face numerous difficulties when they tryto comprehend the schema-that is, when they try to map the databasemodel to their own mental model of the application domain. Schemas

384

_X1gm-n,.

, .- .

Ca./ T.r , jj

Figure 1: The parallel structure of relational databases and HyperCardstacks in PENGUIN, where there is one stack for each database, one

background for each relation, one card for each tuple, and one field foreach attribute. Note that the mapping does not have to be strictlyone-to-one; instead, many stacks can interface with the same database.In addition, not all relations and attributes have to be representedwithin a stack, thus carrying the notion of a database view to thehypertext interface.

are generally complex, and have large numbers of relations that do notnecessarily correspond to domain entities (because of the requirementsof normalization theory). Moreover, although the relational model hasa regular and homogenlous structure, it blurs the semalntic distinctionbetween entities and relationships; relations are used to represent bothtypes of construct. Finally, at a more mundane level, the user mustremember and figure out many things-name and significance of rela-tions and attributes, format and unit of the attributes-before she can

use the database.To alleviate those problems, PENGUIN uses the structural model of

the database and offers visual tools to explore the application domainand to browse through the database schema. The user can access a

graphical layout of the schema, as shown in Figure 2. That layout isa network of relations and structural connections, thus making explicitthe relationships among entities and providing a general overview ofthe domain. The user can select items (either relations or connections)in the graphical layout, and can obtain additional information aboutthat item (for instance, the list of attributes for a relation or the typeand meaning of a connection).

In addition to exploring the schema at the onset of a session, the user

has a variety of tools that she can employ throughout a transaction.Explanations on any relation can be requested through the selectionof a HELP button. A pull-down menu lists, at all times, the set ofrelations that are defined in the current HyperCard stack. Moreover, as

illustrated in Figure 4, visual cues consistently indicate the function andtype of relational attributes and connections, highlighting, for example,the attributes making up the key of a relation.

4.2 Data retrieval and browsing

PENGUIN defines a hybrid interface system for retrieving information,combining the browsing capabilities of HyperCard for facile, undercon-strained exploration and the analytical-querying capabilities of DBMSsfor selective, multicriteria search. A key design issue has been to finda balance between those two strategies. PENGUIN's search systemconsists therefore of a declarative query language for downloading data

Figure 2: A graphical representation of the database schema. Theschema is displayed as a network of relations and structural connections;both relations and connections are mouse-sensitive objects. The user

can readily obtain more information about the domain by selecting any

one object.

from the server to the HyperCard stack, and of a combination of thatsame query language and of navigational access through dynamic linksfor searching locally in the stack.

Retrieval from the database Relational query languages suchas SQL provide powerful data-manipulation tools; yet, a complex, error-

prone syntax and a semantics that is sometimes ambiguous make thoselanguages inadequate for naive users. Instead, in PENGUIN, users

retrieve records from the database by manipulating a visual query

language. The basic idea is the following: For each background inthe stack, PENGUIN provides a corresponding search card, where alldatabase-retrieval operations are specified and performed. Figure 3presents such a search card for the ANTIBODY background of Figure 4,before and after a transaction with-the database server has been started.

The interaction style is a mixture of form fillin and direct manipu-lation. The user first enter search conditions in the form of declarativestatements for any number of the search card's fields. Using simplepoint-and-click interactions, she can then manipulate directly the query

(for example, changing the order of the Boolean connectives among thesearch conditions) before executing it. The visual query language acco-

modates single-relation queries as well as joins over multiple relations,Boolean operations, and a variety of pattern-matching operators-thusoffering a wide range of search options to query the database.

Let us first demonstrate a single-relation query. Figure 3 illustratesa query against the ANTIBODY relation. Once the query has been formu-lated declaratively, PENGUIN translates it into the correct CommonLisp expressions, which are then sent to the database server for exe-

cution. After execution, the server transmits back to PENGUIN thedatabase tuples that satisfy this query. For each tuple of the relationbeing queried, PENGUIN finally creates a new card in the correspond-ing background. Figure 4 displays such a card that presents one of thetuples satisfying the query of Figure 3(a).

Queries involving search on multiple relations simultaneously-joinqueries-are also handled in a simple and efficient way. The user selectsfirst the JOIN button shown in Figure 3(a) to indicate a join query.

PENGUIN employs a join editor to define which set of relations is beingsearched and how those relations are joined (see Figure 5). It relies on

the structural model to facilitate formulating the join expressions; thatis, the user needs only to state the pairs of relations to be joined, andnot the attributes involved in the join for each relation, as shown inFigure 5. PENGUIN exploits the structural connections to derive thelatter information automatically. Once the set of relations is known,the same visual query language as that for single-relation queries is usedto define search clauses over any number of the relations being joined.

385

D_m

'Reltos

_i.1,... ., #i. r .',: ^ .* i ..i.

,<... .

Ealkds.. J = . - ......... :,, . w 0 -.: t. . - .-,sb { ^ ;-.* ; X w . 6 . S

*_w ...... ....w . .Relation X

I A

. I I iFtt. E[ L [ 1.

+ ., , ., .. .,J

SELECTFROM Anti'body a

Antibody WHERE a.Clone_pYme STARTS WITH "Anti' ANDaFme-Specificity IS NULL ANDa3rightnew > 3 AND

.*. i.. lm(a.AntigenjSpecies - 'HUMAN' OR aAntigen,_Species CONTAINS 'ouse")(b)

Antigen NameAntigen Species HUMIAN*ouse Receiving: !(rdbsart-transaction :wait nil)

Receiving: !(setf rse *(a 'antibodies :cross NIL :with (or (andz >Fine spec1f_cltg_ _ __ (starting-with (A 'clone_name) "Anti") (arid (eq (A 'antigen_species)lHUIAN" ) (and (missing (A 'fine_specif icity)) (gt (A 'brightness) 3))))

.__________>3 (and (starting-vith (A 'clonejnae) 'Anti") (and (containing (Aa'ntigen._3pecies) 'ouse') (and (missing (A 'f ine_specificity)) (gt (Abrightness) 3)))))))Sending TReceiving: I(setf action '(setf xx (concatenate 'string xx (rdbSget (A'clone name)) *cr* (rdb$get (A 'antigen,_name)) *cr* (rdb$get (Aantigen_species)) *cr* (rdb$get (A 'fine_specificity)) *cr* (format nil';"D"(rdb$get (A 'brightness))) *cre)))

[~~]~C5j~j~IdbOJeIn COLlneerize Sending: Tl permeereln (!iiii.ticSte < Receiving: (catch 'theLoop (db$loop rse :do action :on-error

_________________d ___Join____________or__search errorActione))Sending: T(a) (c)

Figure 3: Using the search card for the ANTIBODY relation to query the database. (a) The search card contains the five ANTIBODY background's fields.The SEARCH STACK button allows the user to perform a search locally on the stack instead of remotely on the database (SEARCH RDB button). TheJOIN button, when selected, defines queries over multiple relations. The magnifying-glass button gives access to a query log of the current session.Finally, the cross-like button terminates the session with the server. To specify a query, the user enters a search clause for each attribute by clickingon the corresponding field and typing the clause, which can contain literals and operators ('&' for starting-with, '*' for contains, 'empty' foris-null, and '>'for greater-than). Multiple clauses for the same field are separated by a comma. (b) The same query in an SQL-like language.Note that the default logical arrangement of the ANDs and oRs connectors can be changed easily through the use of the LINEARIZE and OR SEARCHbuttons. (c) The set of Common Lisp expressions that are generated by PENGUIN for this query and executed by the server.

As for single-relation queries, the final step is to send the query to thedatabase server, which sends back the set of tuples satisfying the searchconditions.

Browsing through the stack PENGUIN supports variousways of navigating through the HyperCard stack, once data have beentransferred from the database. PENGUIN combines HyperCard's nav-igational access with the pattern-matching retrieval capabilities of aDBMS. We have extended HyperCard with a custom-designed searchengine. As a result, the same query language-described above-is usedconsistently to retrieve information from the database and to search theHyperCard stack. No matter what the target of a search (the databaseor the stack) is, the result of that search defines a set of cards (newlycreated if the target was the database; already present if the target wasthe stack). PENGUIN then enables the user to look at the result seteasily, as shown in Figure 4, by using two buttons to move back andforth in that set.

The semantics of the structural model plays a critical role in sup-porting navigation through the stack. The structural connections es-tablish dynamic links between cards of various backgrounds. By defi-nition, two backgrounds related by a structural connection share somecommon fields; for example, ANTIBODY and AB-COLOR PAIRS sharethe Clone Name field. A dynamic link between cards of those back-grounds therefore corresponds to common data values for the sharedfields. PENGUIN's browsing strategy follows from this characteristic.

As illustrated in Figure 4, a background contains a button for everyother background to which it is connected. In the context of a specificcard, the user can now find relevant cards in another related backgroundsimply by clicking on the appropriate button; PENGUIN determinesthe fields involved in the connection, builds the query using the card'sdata values for those fields, and retrieves all corresponding cards inthe second background. Note that more than one card will be foundonly if the connection being followed has a one-to-many cardinality. Inthat case, the same two-button mechanism as that used for scanning aquery's answer set is applied to loop through the cards.

4.3 Update of the database

PENGUIN supports all update operations-INSERT, DELETE, andMODIFY-in addition to the retrieval capabilities. The user can per-form update operations only by switching from READ mode to WRITE

mode. A different set of buttons for performing updates subsequentlyappears on each data card.

Insertions and deletions occur in batch mode, and require distincttransactions. New cards can be added to the stack at any time; thosenew tuples are not immediately inserted in the database. Instead, theuser has to request an insertion transaction to add to the databaseall the tuples created since the last insertion operation. Cards cre-ated between two insertion transactions can therefore be modified oreven deleted without consequence to the central database. Likewise,a deletion operation consists of two steps: (1) specification of a selec-tion expression, using the same query language as that employed fordata retrieval, and (2) request to delete all the database tuples thatsatisfy the selection expression. Unlike insertions and deletions, how-ever, modifications occur on one tuple at a time during a standardretrieval transaction, where each modified tuple has been loaded fromthe database in the course of that session.

Here again, PENGUIN uses the structural model to facilitate userinteraction with the database. More specifically, the algorithms formaintaining database consistency, which are described in [3], have beenintegrated into the HyperCard interface. A few examples of how thosealgorithms are applied follow:

* When a new card is created in an owned relation (such as inAB-COLOR PAIRS), the user can check that a matching tuple al-ready exists in the owner relation (such as in ANTIBODY). Thoseconsistency-checking operations are performed with a CHECK IN-SERTION button.

* As described previously, the user can navigate easily from onebackground to another in the context of a particular card. In alike manner but in WRITE mode, she can follow a connection tocreate cards that will inherit the data values of the initial cardfor that connection's fields.

* Deletion of one card may require deletion of other cards in con-nected backgrounds to preserve integrity of the data. PENGUINpropagates such deletions automatically without any user inter-vention.

Finally, during those update operations, PENGUIN provides con-currency control over the centralized database; multiple workstationscan thus access the same database through the HyperCard interface,

386

uploaded Antibody 3 ed

Clono lame _mtl [is

Antigen Name lagAntigen Species lim

Fine Specificity UNKNWll -

to Rntigen |to ttrbutesj

a b to*eL r narn .4a. eQjmuIWN1°"l,.piI",-0 ,i.Wf-

Figure 4: The background for the ANTIBODY relation and its naviga-tional capabilities. The READ button at the upper-right corner of thecard allows the user to toggle between read and write modes. Theeye-shaped button moves the user to the search card for this back-ground, where she can specify all search operations. The newly createdANTIBODY card is part of the answer set of the query of Figure 3. ThePREV IN SET and NEXT IN SET buttons allow the user to look at theother cards of the answer set. ANTIBODY is connected to the relationsANTIGEN, ATTRIBUTES, and AB-COLOR PAIRS, as shown by the corre-sponding buttons. By selecting To AB-COLOR PAIRS, the user candirectly retrieve all AB-COLOR PAIRS cards, such that Clone Name ="AntiIgG," without specifying any query expression.

and can protect the consistency of their respective transactions by set-ting and releasing locks on relations.

5. ConclusionDespite some limitations (for example, the interpreted nature of Hy-perTalk and the lack of a developer environment), there are severalbenefits to be reaped from applying HyperCard to the design of userinterfaces.

HyperCard offloads the interface design and separates that designfrom the management of information. Its flexibility makes HyperCardthe ideal tool for rapid prototyping and implementation of interfacesfor decision-support systems.

Our experience has indicated that a designer can prototype, de-bug, and refine different hypertext presentations in a single session.That ease of manipulation makes it possible to vary the packaging andpresentation of a specific system according to the requirements of thetarget audience. When HyperCard is used as the front end, the designof appropriate interfaces take up much less of the development cyclethan heretofore possible.

Finally, decoupling of the hypertext front end from the computa-tional engine greatly facilitates any extension of PENGUIN, inasmuchas the interfaces need not change. From the user's viewpoint, extensionsare completely transparent.

Acknowledgments. We thank Lyn Dupre for her editorial comments. This workwas supported by the National Library of Medicine under Grant RO1 LM04836, and

by DEC under the Quantum project. Additional computer faclities were providedby the SUMEX-AIM resource under NIH grant RR-00785.

References

[1] T. Barsalou. An object-based architecture for biomedical expertdatabase systems. In R.A. Greenes, editor, Proceedings of theTwelfth Symposium on Computer Applications in Medical Care,pages 572-578, Washington, D.C., November 1988. IEEE Com-puter Society Press.

45ORH:MPW:MUSources:RdbToM'c-Join on: And on:

fntlbodies colorscolors attributesattributes antigens

H1S1~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~4LEnta -ce Instance

|ANTIBODIES NOT-EQ RNTIGENS

Jonon RelatIonsANTIBODIES EU COLORS EQ

GREATERLESS

GREAT-OR-EU Ol ESS-011-E _

Figure 5: The editor to specify join expressions. The user enters pairsof relations to be joined by clicking on one of the relations in each of thetwo upper panels. The lower panel-JOIN ON RELATIONS-displays thejoin pairs already defined. In addition to manipulating natural joins,the user can call a pop-up menu (by clicking on the JOIN OPERATORbutton) to enter a nonnatural join.

[2] T. Barsalou, W.A. Moore, L.A. Herzenberg, and G. Wiederhold.A database system to facilitate the design of FACS experimentprotocols (abstract). Cytometry, page 97, August 1987.

[3] T. Barsalou and G. Wiederhold. Applying a semantic model to animmunology database. In W.W. Stead, editor, Proceedings of theEleventh Symposium on Computer Applications in Medical Care,pages 871-877, Washington, D.C., November 1987. IEEE Com-puter Society Press.

[4] D.G. Bobrow, S. Mittal, and M.J. Stefik. Expert systems: Perilsand promise. Communications of the ACM, 29(9):880-894, 1986.

[5] J. Conklin. Hypertext: An introduction and survey. IEEE Com-puter, 20(3):17-41, 1987.

[6] D. Goodman. The complete HyperCard handbook. Bantam Books,New York, NY, 1987.

[7] S.J. Kaplan. Cooperative responses from a portable natural lan-guage database query system. PhD thesis, Computer Science De-partment, University of Pennsylvania, Philadelphia, PA, 1979.

[8] G. Marchionini and B. Shneiderman. Finding facts vs. browsingknowledge in hypertext systems. IEEE Computer, 21(1):70-80,1988.

[9] T.H. Nelson. Getting it out of our system. In G. Schechter, ed-itor, Information retrieval: A critical review. Thompson Books,Washington, D.C., 1967.

[10] G.L. Steele Jr. Common Lisp: The language. Digital Press,Burlington, MA, 1984.

[11] G. Wiederhold. Views, objects and databases. IEEE Computer,19(12):37-44, December 1986.

[12] G. Wiederhold. The architecture of future information systems.Proceedings of the International Symposium on Database Systemsfor Advanced Applications, KISS and IPSJ, Seoul, Korea, 1989.

[13] G. Wiederhold and R. El Masri. The structural model for databasedesign. In Entity-relationship Approach to System Analysis andDesign, pages 237-257. North-Holland, 1980.

[14] C. G. Wolf and J. R. Rhyne. A taxonomic approach to understand-ing direct manipulation. Technical Report RC 13104 (#58210),IBM Thomas J. Watson Research Center, Yorktown Heights, NY,September 1987.

387