viewfinder: an object browser

ViewFinder: an object browser

Alessandro D’Atria, Amihai Motrob,* , Laura Tarantinoa

aDipartimento di Ingegneria Elettrica, Universita degli Studi di L’Aquila, 1-67040L’Aquila, ItalybDepartment of Information and Software Engineering, George Mason University, Fairfax, VA 22030-4444, USA

Received 30 June 1998; received in revised form 20 October 1998; accepted 17 November 1998

Abstract

ViewFinder is a graphical tool for browsing in databases that provides a flexible, yet intuitive environment for exploratory searches. Thedesign approach has been to provide maximumfunctionalityand generality without sacrificingsimplicity. The constructs of ViewFinder’sexternal model are essentially object-oriented: class and token objects, membership relationships between tokens and classes, generalizationrelationships between classes, inheritance, and so on. This external model is based on an internal model which resembles a semantic network.Such a network may be extracted from a variety of data models, including object-oriented, entity-relationship and extended relationalmodels. This architecture gives ViewFinder a large degree of model independence. The main construct of the external model are displays ofobjects (either classes or tokens), calledviews. Commands are available for efficient traversal of the database, displaying views of any class ortoken. To speed up repetitive searches, views may be synchronized: the user sets up several views, linked in a tree-like structure, so that whenthe information displayed in the root view is modified (e.g. scrolled by the user), the contents of the other views change automatically.Additional commands are available to search, order, aggregate and select the information displayed in a view, thus providing a simple queryfacility. q 1999 Elsevier Science B.V. All rights reserved.

Keywords:Graphical tool; Object browsing; Exploratory searches

1. Introduction

To improve their usability and responsiveness, most data-base systems offer their users a wide variety of interfaces,suitable for different levels of expertise and different typesof applications. A particular kind of interface which is nowcommonly available arebrowsers. Browsers are intendedfor performingexploratory searches, often bynaive users.Thus, they usually employ simple conceptual models andoffer simple, intuitive commands. Ideally, browsing shouldnot require familiarity with the particular database beingaccessed, or even preconceived retrieval targets. Browsingmay be used to gain insight into the contents and organiza-tion of the searched environment, to arrive at specific retrie-val targets, and even to satisfy such targets.

In this paper, we describe a new browsing interface todatabases, called ViewFinder. The design approach hasbeen to provide maximumfunctionalityandgeneralitywith-out sacrificingsimplicity. These three design principles areexplained below. A preliminary design of ViewFinder wasdescribed in Ref. [30].

Simplicity . As already mentioned, browsers must besimple to use. ViewFinder communicates with its usersmostly by graphical means (e.g. menus and icons) and itrequires very little typing. The ViewFinder model definesa small number of basic concepts and a small number ofoperations (altogether, the global menu has six options andthe browsing menu has nine options). Indeed, it is possibleto explore a database by using just two commands. There isemphasis on economy of style, and consistency and predict-ability of behavior; the authors believe that a graphicalinterface that employs a great number of different graphicalconstructs can become just as complex and intimidating touse as the textual interface it is supposed to replace.

Functionality . Most database browsers define searchprocesses that are indeed simple to perform, but simplicityis often achieved by providing low-level commands, andlimited functionalities. Consequently, browsing sessionstend to be quite inefficient, and may become tedious aftera while. ViewFinder incorporates several features thataddress these deficiencies. Additionally, where some brow-sers provide their users with graphical tools to browse in thedatabaseschemeand then construct simple queries, users ofViewFinder can browse in the databaseextensionas well.For example, it is possible to enter the name of a database

Information and Software Technology 41 (1999) 211–234

INFSOF 3982

0950-5849/99/$ - see front matterq 1999 Elsevier Science B.V. All rights reserved.PII: S0950-5849(98)00124-4

* Corresponding author. Tel.:11-703-993-1665.E-mail address:[email protected] (A. Motro)

value (or to ‘‘click’’ on this value if it appears somewhereon the screen) and receive a frameful of information on thisvalue.

Generality. By and large, the approach to browsing hasbeen ad hoc: browsing is often understood only in terms ofthe specific user interface being constructed. Additionally,most browsers are designed to be used only with databasesof a specific data model. The approach of ViewFinder ismore formal and more general. Rather than defining brows-ing in a given data model, ViewFinder defines a data model(with its associated operations) for browsing. The architec-ture of ViewFinder provides a large degree of model inde-pendence, which allows it to be used with databases of avariety of data models. This independence is achieved by atiered architecture. ViewFinder employs two differentmodels: theexternal modeldefines high level structuresand operations; these are the structures that are displayedto users and the operations with which users can manipulatethese structures. This external model is mapped to aninter-nal modelwhose structures are more primitive. These twogeneric models are realized in specific environments. At theuser’s end, the external model is interpreted with specificvisualization structures and operations and implementedwith a specific graphical windowing environment. At thedatabase end, the internal model is interfaced to a specificdatabase system; this database system can employ one ofseveral possible data models. By reprogramming the presen-tation of the external model and the database interface of theinternal model, the ViewFinder model can be implementedwith different graphical user interfaces and with differentdatabase systems.

The underlying internal model of ViewFinder may becharacterized as a semantic network, consisting of objectsconnected by binary relationships. Objects are merelynames. It is through their relationships with other objectsthat information about objects is expressed. For each object,a structure calledview is defined; this presents the relation-ships and objects that areadjacentto the given object in thenetwork. These structured displays of data are the maincomponent of the external model.

The information in each view is sorted into severalframes. For example, the view of the classEMPLOYEEwill show its superclasses (e.g.PERSON), its subclasses(e.g. MANAGER), its properties (e.g.SALARY), and itsmember tokens (e.g.JOHN). By pointing to particularobject names in a displayed view, users may request todisplay other views, in addition to, or in place of, viewscurrently displayed. For example, while viewing the classEMPLOYEE, users may request to view the classMANAGER or the tokenJOHN. Thus, users may navigatein the class hierarchy, and move freely between class andtoken objects.

To speed up repetitive searches, which otherwise couldbecome very tedious, views may besynchronized: the usersets up several views, linked in a tree-like structure, so thatwhen the information displayed in the root view is modified

(e.g. scrolled by the user), the contents of the other viewschange automatically. Additional commands are availableto search, order, aggregate and select the informationdisplayed in a view. Indeed, these commands amount to aflexible, yet simple,queryfacility.

Whereas the internal model of ViewFinder resembles asemantic network, its external model constructs are essen-tially object-oriented: class and token objects, membershiprelationships between tokens and classes, generalizationrelationships between classes, inheritance, and so on. Notethat the external model of ViewFinder is not a completeobject-oriented model, as this concept is commonly under-stood,1 because ViewFinder is not a complete databasemanagement system. Rather, the external model of View-Finder supports those elements of object-oriented modelsthat are relevant to browsing and presentation. Thisobject-oriented presentationcan be provided for specificobject-oriented models, as well as for other data modelsthat support generalization hierarchies and complex objects(e.g. various flavors of the entity-relationship or extendedrelational models). In each case the low-level semanticnetwork would beextractedfrom the given database.

In the remainder of this section, we provide a brief surveyof database browsing and relate it to ViewFinder. The orga-nization of the rest of this article follows closely the tiers inthe ViewFinder architecture. Sections 2 and 3 describe theinternal and external models. Section 4 describes in detailour implementation of the external model; the implementa-tion described is for the SunView windowing environment.Section 5 is devoted to the mapping between the internalmodel and other data models; the mapping between theinternal model andODMG, a generic object-oriented datamodel, is discussed in detail. Section 6 concludes with abrief summary and discussion of additional researchdirections.

1.1. Background

Most browsers assume a conceptual model that inter-leaves the data in anetworkof some kind, and browsingis done bynavigation: the user begins at an arbitrary point inthe network (perhaps a standard initial position), examinesthe data in that ‘‘neighborhood’’, and then issues a newcommand to proceed in a new direction.

An early example of this approach is the interfacedesigned and implemented by Cattell, at Xerox [7]. Theinterface is to an entity-relationship database [10], and itfeatures a set of directives for scanning a network of entitiesand relationships, and presenting each entity, together withits context, in a display calledframe. A similar interface waslater provided for the entity-relationship database manage-ment system Cypress [8].

Cattell’s model was further employed in the Living in aDatabase (LID) system [14]. But whereas Cattell’s system

A. D’Atri et al. / Information and Software Technology 41 (1999) 211–234212

1 For example, it does not have the equivalent ofencapsulation.

relied on textual interaction on a character-based display,the LID system featured graphical interaction on abitmapped display. Users of LID ‘‘live’’ inside an instanceof an Entity-Relationship database. At each point in timethey ‘‘reside’’ in a particular tuple, from which they canview the data tuples and schema structures that are asso-ciated with it.

BAROQUE [29] is a browsing interface to relationaldatabases.BAROQUE establishes a view of the relationaldatabase that resembles a semantic network (integratingboth schema and data), and provides several intuitivecommands for scanning it. When a user ‘‘visits’’ a particularnode in the network (a data value) the system constructs a‘‘frame’’ of information on this value, showing its relation-ships to other data values. The user can then pick a valuementioned in this frame and request to display its frameinstead. In effect, the user is traversing an edge in the networkto visit an adjacent node.BAROQUE was recently ported toa graphical environment of windows, menus and icons.

More recently, Cattell, Rogers and Learmont describe asystem that provides an entity-relationship view of rela-tional databases [25], and a graphical tool that, likeBARO-QUE, displays entities assembled from the underlyingrelational database [35]. The interface also provides limitedupdate capabilities, and it supports the display of pictures aswell as text.

Browsing is offered as the principal retrieval method forloosely-structured databases [27]. Such databases are heapsof facts that do not adhere to any conceptual design. Factsare named binary relationships between data values, so thedata may be regarded as a semantic network of values. Thisloosely-structured model of databases has been adopted byUSD [22], a system that provides database capabilities oftenrequired in scientific research. The main retrieval andbrowsing paradigm of its graphical user interface is thematching ofpatternsconstructed by users.

Browsers have been developed for various relationalsystems, for example,SDMS [21], INGRES [40] andDBASE-III [4]. These are primarily tools for scanning rela-tions (including relations that are results of formal queries),and therefore have only limited exploration capabilities.Browsing is confined to a single relation at a time, and itis not possible to browse across relation boundaries. If a userencounters a value while browsing, and wants to know moreabout it, he must determine first in which other relations thisvalue may appear (quite difficult), then formulate a formalquery, and resume browsing in the new relation.

OdeView is a graphical interface to Ode, an object-oriented database system and environment [3]. OdeViewprovides facilities for examining the class hierarchy, fornavigational browsing, for displaying parts of objects, andfor selecting objects that possess specific characteristics.One of OdeView’s most important features is synchronizedbrowsing. This feature in particular, and OdeView’snavigation model in general, were inspired byKIVIEW[30], the predecessor of ViewFinder.

In the network structure assumed by most browsers,adja-cencyreflects relationship. For example,JOHN is linked toMANUFACTURING because John works in the manufac-turing department, andMANUFACTURING is linked toDEPARTMENT because the former is an instance of thelatter. A different approach is taken by Pintado and Tsichrit-zis [34] who propose to place objects in a space, so that theirmutual proximity reflects theiraffinity (as computed fromsome measure). Users can then navigate among objects withthe help of a two dimensional ‘‘map’’ that visualizes thedistances between objects. By changing the measure, differ-ent maps can be derived for the same set of objects. Navi-gating from an object directly to ‘‘similar’’ objects is also afeature of theBAROQUE browser, discussed earlier. Whenviewing an object, a user may ask to display similar objects,where similarity is defined as having identical values for aset of properties specified by the user. Hence, similarityestablishes an alternative network of objects, in whichobjects are adjacent if they are similar.

A database browser should allow its users to navigatefreely in the databaseextension, e.g. its users should beable to examine data items and follow their relationshipsto other data items, or to name a data item and receiveinformation about it. The next three systems are in a some-what different class: they are essentiallyschema browsers,with built-in query facilities.

GUIDE [45] is a graphical user interface which is basedon an Entity-Relationship model extended withisa relation-ships.GUIDE‘s primary focus is to assist its users in theformulation of queries. Typically, a user identifies the rele-vant schema components, and the system constructs atextual query.GUIDE provides many facilities for panning,zooming, and hiding schema components, yet the layout ofthe database schema is essentially fixed (i.e. individualschema components cannot be repositioned relative toeach other).

SKI [24] is a user interface to the Sembase databasesystem, a system that implements a semantically rich datamodel. Sembase’s constructs include entity sets, single ormultivalued functional relationships, andisa relationships[23]. SKI provides powerful graphical tools for browsing inthe schema. Its schema layout is much more flexible thanGUIDE‘s, enabling users to focus on the parts of the schemathat are relevant to their retrieval goals. Simple querying isprovided by allowing users to define ad hoc subtypes andexplore their contents (the ‘‘answers’’) in scrollablewindows. However,SKI has no facilities for browsingthrough the data.

Closely related toSKI, with respect to functionality andexpressive power,SNAP [6] is a general purpose schemamanager which uses a coherent paradigm to support theschema design, schema browsing, and selection-typequeries.SNAP is based on the IFO data model [1], anobject-based semantic data model which provides featuresfor the representation of simple and complex objects, func-tional relationships, andisa relationships. As in SKI, users

A. D’Atri et al. / Information and Software Technology 41 (1999) 211–234 213

operate on the schema of the database, which is displayeddiagrammatically using different kinds of graphical shapes.For large database schemes,SNAP provides commands toreposition objects, hide and redisplay objects, pan and zoomover the schema, and reformatisa hierarchies and complexobject representations. Users can also specify selection-typequeries graphically. All answers returned by the systemhave the structure of non-first normal form relations, andare displayed as nested tables. Again,SNAP has no facilitiesfor browsing in the data.

Schema design, schema browsing, and query formulationare offered also byISIS [17], a graphical interface to asubset of the Semantic Data Model [19].ISIS providestwo alternative views on the schema, depending on whethera user wishes to focus on theisahierarchy or on the attributenetwork. The presentation is again diagrammatic. However,unlike the systems previously discussed, structured graphi-cal symbols are used to visualize complex objects; further-more, patterns assigned to classes allow representation ofsemantic links in iconic format. Browsing is mostly at theschema level, though a limited form of navigation can beaccomplished at the data level: scrollable windows list theinstances of classes, and individual instances can be selectedto be analyzed in more detail. However, the visualization ofthe entire state of an object is somewhat inconvenient,requiring users to follow the semantic connections one atthe time.

Database browsing has often been described ascomple-mentaryto database querying. A survey of the advantagesand limitations of these two retrieval methods is given inRef. [11], which also suggests several ways to bridge thesetwo methods. The automatic inference of formal queriesfrom information obtained in browsing sessions is thepurpose of the Query-by-Browsing system [13]. Users ofQuery-by-Browsing are presented with listings of databaserecords and mark them as relevant or irrelevant to theirretrieval objectives. The system then infers the patternunderlying the selections by means of an inductive learning-based algorithm.

Whereas the subject of database querying has beenapproached formally, the approach to database browsinghas been mostly informal. Query languages are oftenbased on formal languages (e.g. relational algebra andcalculus), and issues such as query language completenessor query language equivalence are often addressed. Incontrast, database browsing is usually defined by means ofa particular interface that has been constructed. A moretheoretical study of browsing is given in Ref. [12], whichproposes a formal environment for defining several brows-ing processes with increasing levels of complexity.

More generally, the subject of user interfaces to data-bases, and browsers in particular, has been recognizedrecently as an area of research and development withinthe field of databases that faces important challenges andthat deserves increased attention [32,39].

It should be noted that the applicability of browsing is not

limited to databases, and the method has been appliedsuccessfully in other environments. Browsers have beenconstructed for programming environments to support thedevelopment of software [5,16,18,20], and in electronicreference and hypertext systems [26,33,41,43].

These days, the term browsing is often identified withsearching the World Wide Web (WWW).2 To a large extent,the spectacular growth of the World Wide Web is a directresult of the application of the simple paradigm of hyper-textual browsing to already existing capabilities of the Inter-net. It is the interaction paradigm more than anything elsethat triggered the explosive growth of the Global Informa-tion Infrastructure (GII) [15]: a mouse click is all that usersneed to traverse links across the world. As the GII expands,dramatic changes take place in both the types of informationinvolved, and the kind of people who access the availableinformation (most of whom are bound to remain permanentnovices with respect to many of the diverse informationsources that they access) [31]. User interfaces requiringminimal technical sophistication and expertize are hencenecessary to support users and their tasks [39].

As a consequence of these new utilization constraints, thetwo-step loop upon which most interactive database accesstools have been based, i.e. alternating between query-specification and result-visualization, is being replaced bynovel approaches. These approaches are being adopted inWeb applications as well as in more traditional applications.For example, theTTT taxonomy [38] identifies seven inter-action tasks: overview, zoom, filter, details-on-demand,relate, history and extract. The browsing paradigm is receiv-ing a growing interest with respect to many of these tasks,and novel forms of browsing are being proposed; of thesystems that have recently been published we mention thePolyNav system for overviewing functions [44], theIVEEapplications for overview, zoom, filter and details-on-demand tasks [2], and by the TableExpander interface forzoom and detail-on-demand activities [36,37].

2. The internal model

In this section we define the underlying internal model ofViewFinder. This model is not apparent to the users ofViewFinder, but is necessary for defining the structuresand operations of the external model.

2.1. Objects, relationships and facts

The underlying internal model is a semantic network,consisting ofobjectsconnected bybinary relationships.Inmany aspects it is similar to the model behind loosely-struc-tured databases [27,28]. Such a network may be defined by a


2 The WWW is a very large collection of cross-referenced documentsthat are located on many different computers, which are connected via theInternet. Browsing in the WWW is an activity that involves the examinationof related documents by following the cross-reference links.

set of triplets (m,r,n), wherem andn are objects andr is arelationship. These triplets will be calledfacts; the first andthird objects of a fact will be called, respectively, thesourceand thetarget objects of the fact.

There are two kinds of objects:class objectsand tokenobjects. An object is either a class or a token. Examples ofclass objects areEMPLOYEE andDEPARTMENT; exam-ples of token objects areJOHN andMANUFACTURING.In addition to the classes that are specific to the application,there are severaltype classes: a class calledDATABASE,and a set of classes that correspond to the common datatypes, such asINTEGER and STRING. In the followingdefinitions the symbolsa, b, c denote any class,t denotesa type class,x, y, zdenote tokens,m, n denote objects (eithertokens or classes), andr denotes a relationship.

There are four kinds of facts:generalization facts,membershipfacts, intensionalfacts, andextensionalfacts.These different kinds of facts are described later, togetherwith nine requirements that must be satisfied by any set offacts.

2.2. Generalization and membership facts

A frequent relationship between classes isgeneralization:one class is more general than another class (the latter classis then aspecializationof the former). The generalizationrelationship will be denoteda . Examples of generalizationfacts are (EMPLOYEE a PERSON) and(DEPARTMENT a UNIT).

A frequent relationship between tokens and classes ismembership: a token is a member of a class. The member-ship relationship will be denoted[ . Examples of member-ship facts are (JOHN [ EMPLOYEE) and(MANUFACTURING [ DEPARTMENT).

We require that generalization and membership satisfyfive requirements:

1. Root of generalization hierarchy: for every databaseclass,a, other thanDATABASE, (a a DATABASE) is ageneralization fact, and for every database classa, whichis not a type class, there exists a single type classt, otherthan DATABASE, such that (a a t) is a generalizationfact.2. Required membership for tokens: for every tokenx,there exists a classa, which is not a type class and amembership fact (x [ a). If (x [ a) and (x [ b) anda ± b, then there exists a typet, such that (a a t) and(b a t).3. Irreflexivity of generalizations: if (a a b) is a general-ization fact, thena ± b.4. Transitivity of generalizations: if (a a b) and (b a c)are generalization facts, then (a a c) is also a general-ization fact.5. Inheritance of membership over generalizations (x [ a)is a membership fact and (a a b) is a generalization fact,then (x [ b) is also a membership fact.

The transitivity requirement models the accepted real-world semantics of this relationship. For example, ifPERSON is a generalization of EMPLOYEE, andEMPLOYEE is a generalization ofMANAGER, thenPERSON is also a generalization ofEMPLOYEE. Together,transitivity and irreflexivity guaranteeacyclicity, sothat thegeneralization relationship imposes ahierarchy on theclasses of the database.3 The first requirement guaranteesthat this hierarchy is connected and has a single root class,calledDATABASE.4 Immediately below the root there is alevel of classes that correspond to types. Each type class isthen the root of a separate generalization hierarchy. Typesare used to restrict operations on each object to those thathave been defined for its type. The second requirementstates that every token should be a member of at least onenon-type class, but a token may not be a member of classesof different types. Finally, the inheritance requirement guar-antees that the set of member objects of each class iscontained in the set of member objects of every moregeneral class.

2.3. Intensional and extensional facts

An intensionalfact associates two non-type classes with arelationship other thana ; for example, (PERSON,AGE,-YEARS). An extensionalfact associates two tokens; forexample (JOHN,AGE,32). The semantics of an intensionalfact is that any extensional fact with source and targettokens that are members of its source and target classes,respectively, is admissible. Thus, an intensional fact definesa domainof extensional facts.

Given a fact (m,r,n), which is either intensional or exten-sional, the pair (r,n) will be referred to as apropertyof m.Thus, the classPERSON has the (intensional) property(AGE,YEARS), and the tokenJOHN has the (extensional)property (AGE,32).

Extensional facts must belong to the domain of at leastone intensional fact; that is, for each extensional fact theremust be an intensional fact and two membership facts thatassociate the tokens of the extensional fact with the respec-tive classes of the intensional fact. Formally:

6. Required membership for extensional facts: if (x,r,y) isan extensional fact, then there exist non-type classesaand b, membership facts (x [ a) and (y [ b), and anintensional fact (a,r,b).

Intensional facts may possess two characteristics. Someintensional facts are designated asmandatory: there must bean extensional fact that associateseachof the members ofthe source class with a member of the target class. Someintensional facts are designated assingle-valued: for eachmember of the source class there may be at most one


3 Because transitivity and irreflexivity imply antisymmetry,a is a strictpartial order.

4 In practice, the name of this root class would be different for eachdatabase.

extensional fact that associates it with a member of thetarget class. Formally:

7. Instantiation of extensional facts for mandatory inten-sional facts: if (a,r,b) is a mandatory intensional fact, thenfor every membership fact (x [ a) there exist a member-ship fact (y [ b) and an extensional fact (x,r,y).8. Instantiation of extensional facts for single-valuedintensional facts: if (a,r,b) is a single-valued intensionalfact, then for each membership fact (x [ a) there exists atmost one pair of membership fact (y [ b) and extensionalfact (x,r,y).

An important characterization of intensional properties isthat they are inherited over generalizations. Formally:

9. Inheritance of intensional properties over generaliza-tions: if (a,r,b) is an intensional fact and (c a a) is ageneralization fact, then (c,r,b) is also an intensionalfact. Similarly, if (a,r,b) is an intensional fact and (c ab) is a generalization fact, then (a,r,c) is also an inten-sional fact.

As an example, consider these three generalization rela-tionships:MANAGER a EMPLOYEE, TEMPORARY aEMPLOYEE, andPRIVATE-OFFICE a OFFICE-SPACE.The inheritance rule guarantees that if office space is avail-able to employees, then it is available to managers; and ifemployees may have office spaces, then they may haveprivate offices as well.

These definitions lead to various conclusions. When anintensional property is propagated to the subclass of thesource, itpreservesthe characteristics of being mandatoryor single-valued. For example, if office space is available toevery employee, then it is available to every manager; and ifemployees may not have more than one office space, thenthis restriction also applies to managers. When an inten-sional property is propagated to the subclass of the target,it preserves the characteristic of being single-valued, but notnecessarily the characteristic of being mandatory. For exam-ple, if employees may not have more than one office space,then they may not have more than one private office; butwhen employees are guaranteed office spaces, they are notguaranteed private offices.

When an intensional property is propagated to thesubclass of the source, it mayacquire the characteristicsof being mandatory or single-valued. For example, officespace may be available to employees, and guaranteed formanagers; and several office spaces may be available toemployees in general, but only a single office space totemporaries. When an intensional property is propagatedto the subclass of the target, it could acquire the character-istic of being single-valued, but never the characteristic ofbeing mandatory. For example, multiple office spaces maybe available to employees, but at most one private office;however, if office space is not guaranteed to everyemployee, then private office could not be guaranteed.

Rules 4–7 and 9 are illustrated graphically in Fig. 1. Thefollowing graphical conventions are used: class objects areindicated with squares, token objects with circles. Relation-ships are indicated with arrows directed from the sourceobject to the target object. Mandatory relationships are indi-cated with thick arrows, all other relationships with thinarrows. Each of these rules was phrased as an implication,stating that if certain facts exist, then other facts are implied:existing facts are indicated with solid relationship arrows,implied facts with dashed relationship arrows.

2.4. Immediate and distant objects and properties

Rules 4, 5 and 9 (the transitivity of generalizations, theinheritance of membership over generalizations, and theinheritance of intensional properties over generalizations)may be regarded asclosureproperties of the generalizationrelationship. In these cases, it is useful to distinguishbetweenimmediateanddistantrelationships.

A classa, is animmediate generalizationof a class,b if(b a a) and there is no classc, such that (b a c) and (c a a).For example,EMPLOYEE is an immediate generalizationof MANAGER, if it is a generalization ofMANAGER, butnot a generalization of any other class which is more generalthanMANAGER.

A tokenx, is animmediate instanceof a classa, if (x [ a)and there is no classb, such that (b a a) and (x [ b). Forexample,JOHN is an immediate member ofEMPLOYEE, if


Fig. 1. Graphical representation of rules in which facts are implied by otherfacts.

it is a member ofEMPLOYEE, but not a member of anyclass which is more specific thatEMPLOYEE.

A property (r,b) is animmediate intensional propertyof aclassa, if (a,r,b) is an intensional fact and there is no classc,such that (a a c) and (c,r,b) is also an intensional fact, andthere is no classd such that (b a d) and (a,r,d) is also anintensional fact. For example, (WORK-FOR,DEPART-MENT) is an immediate intensional property ofEMPLOYEE, if it is an intensional property ofEMPLOYEE, but not an intensional property of any classwhich is more general thanEMPLOYEE, andEMPLOYEEdoes not have an intensional property with relationshipWORK-FOR and a target class which is more generalthanDEPARTMENT.

Since the characteristics of intensional properties may beacquired after propagation, we need to define separately theimmediate intensional properties which are mandatory orsingle-valued.

A property (r,b) is an immediate mandatory intensionalproperty of a classa, if (a,r,b) is a mandatory intensionalfact and there is no classc, such that (a a c) and (c,r,b) isalso a mandatory intensional fact. For example, (SALAR-Y,AMOUNT) is an immediate mandatory property ofEMPLOYEE, if it is a mandatory property ofEMPLOYEE,but not a mandatory property of any class which is moregeneral thanEMPLOYEE. A property (r,b) is animmediatesingle-valued intensional propertyof a classa, if (a,r,b) is asingle-valued intensional fact and there is no classc suchthat (a a c) and (c,r,b) is also a single-valued intensionalfact, and there is no classd such that (b a d) and (a,r,d) isalso a single-valued intensional fact. For example, (OFFI-CE,PRIVATE-OFFICE) is an immediate single-valuedproperty of MANAGER, if it is a single-valued propertyof MANAGER, but not a single-valued property of any

class which is more general thanMANAGER, andMANAGER does not have a single-valued property withrelationship OFFICE and a target class which is moregeneral thanPRIVATE-OFFICE.

Objects and properties that are related to a given object,but are not immediate, will be referred to asdistant.

Finally, a database is a set of generalization facts,membership facts, intensional facts (some of which aremandatory and/or single-valued) and extensional facts,over a set of tokens, a set of classes and a set of relation-ships, that satisfy the nine requirements described earlier.

3. The external model

Theexternal model(the user model) defines higher levelstructures and operations. These are the structures that aredisplayed to users and the operations with which users canmanipulate these structures.

3.1. Views, frames and windows

For every database object, we define a structure calledview. This structure is assembled from facts in which thisobject participates, and it has several independent compo-nents calledframes. The definition of views is different forclass objects and token objects.

Let a be a class object. The view ofa is defined as fourframes:

1. Members:the tokens that are immediate members ofa.2. Superclasses:the classes that are immediate generaliza-

tions ofa.3. Subclasses: the classes that are immediate specifications

of a.4. Properties: the immediate intensional properties ofa

(properties that are mandatory or single-valued aremarked as such).

Note that the members of the class in view are thoseshown in themembersframe, as well as the members ofany subclass. Similarly, the subclasses of the class in vieware those shown in thesubclassesframe, as well as theirsubclasses; and the superclasses are those shown in thesuperclassesframe, as well as their superclasses. Similarly,the intensional properties of the class in view are thoseshown in thepropertiesframe, as well as the intensionalproperties of any superclass, and the intensional properties


Table 1EMPLOYEE

Members Superclasses Subclasses Properties m s

ADAM PERSON INACTIVE WORK-FOR DEPARTMENT U U

BETTY MANAGER POSITION TITLE U U

FRANK TECHNICAL SALARY AMOUNT U U

MARY TEMPORARY OFFICE ROOM U

TOM SECRETARY EMPLOYEE

Table 2JOHN

Classes Properties

EMPLOYEE WORK-FOR MANUFACTURINGPARENT POSITION SUPERVISOR

SALARY 46 000OFFICE MB475AGE 32CHILD JEFFREYCHILD JULIE

obtained from the intensional properties shown by substitut-ing subclasses in the target.

For example, Table 1 shows a possible view of a classEMPLOYEE (m means mandatory ands means single-valued).

Let x be a token object. The view ofx is defined as twoframes:

1. Classes: the classes of whichx is immediate member.2. Properties: the extensional properties ofx.

For example, Table 2 shows a possible view of a tokenJOHN.

Note that different real-world objects should be modeledby database objects with different names, or else informa-tion about different real-world objects would be combinedinto a single view. Using the same name for different real-world objects may cause other modeling problems as well.For example, consider the intensional facts (CITY,POPU-LATION,CITIZENS) and (COUNTY,POPULATION,CITI-ZENS). If the objectFAIRFAX is chosen to designate boththe city of Fairfax and the county of Fairfax, then it wouldbe impossible to associate the two extensional facts thatstate the actual populations of the city and the county ofFairfax with their corresponding intensional facts (also, thesingle-valuedness of these intensional facts would beviolated).

Finally, awindowis a display structure for presenting thecontents of a frame. A window presents only a fixed intervalof elements of the frame; a specific position in this interval(e.g. the first, middle or last position) is established as thedistinguished position.A frame may be presented in severalindependent windows simultaneously. Each windowdisplays a ‘‘version’’ of the frame, which may be subjectedto useful manipulations, such as ordering and selection.These and other manipulations are described next.

3.2. Basic view operations

The basic operations that may be applied to views are:display, scroll, search, order, aggregate, selection andclosure.5

The most elementary browsing operation is todisplayaframe of an object in a window (to ‘‘open’’ a window). Theparticular object must be specified by the user, either bytyping its name or, more often, by selecting it from somewindow which is already open. When an object is thusspecified, the system selects a default frame and presentsit in a window. The user can then replace the contents of thiswindow with any other frame of the same object, or he canopen another window with any other frame of the sameobject.

The process of repeatedly opening new windows on

objects that are referenced in current windows (and closingsome windows as well) corresponds tonavigation in theunderlying semantic network. When a nodem of thenetwork is visited, a portion of its immediate neighborhoodis displayed in a window. Opening a new window on anobjectn, which is referenced in a window onm, correspondsto crossing an edge fromm to visit its adjacent noden.

The number of elements displayed in each window islimited by the size of the window. The user may controlthe frame interval that is currently being displayed, either bythe sequential process ofscrolling the frame in the window,or by the direct process ofsearchinga particular elementand displaying it in the distinguished position.

The defaultorder of the elements (tokens, classes orproperties) is implied by the order in which they havebeen arranged in the database, but each frame may be reor-dered by the user. Frames of classes (thesuperclassesandsubclassesframes in the view of a class, and theclassesframe in the view of a token) may be ordered lexicographi-cally by the name of the class. Frames of properties (theintensional propertiesin the view of a class, and theexten-sional propertiesin the view of a token) may be orderedlexicographically by the name of the relationship. If severalproperties have the same relationship, they are ordered bythe target object. In the case of intensional properties, thetargets are classes and a lexicographical order is used; in thecase of extensional properties, the targets are tokens, and theorder is determined by the type class to which these tokensbelong (e.g. numerical for the classNUMBER, lexicogra-phical for the classSTRING). Frames of tokens (themembersframe in the view of a class) may be ordered byan order which is determined by the type class to which thetokens belong.

In addition, frames of tokens may also be ordered withrespect to the target token of any single-valued property ofthat class.6 For example, the members ofPERSON may beordered byAGE. This kind of order is extensible in twoways. By using aggregate functions, multi-valued propertiesmay be used as well. For example, the members ofPERSONmay be ordered by the total number of occurrences of theproperty (CHILD,x). Also, orders on several properties maybe combined in sequence to resolve the ordering ofmembers that have the same value by the previous orders.For example, the members ofEMPLOYEE can be orderedby POSITION andLEVEL (within a position).

Each of these orders may be specified as either ascendingor descending. Note that the same frame may be displayedin multiple windows, each using a different order.

Several standardaggregatefunctions may be computedon the elements of a frame. Acountfunction that computesthe total number of elements is defined for all frames,maxi-mumandminimumfunctions that compute, respectively, theelement with the lowest and highest value (with respect to


5 Although we shall refer to an operation as being applied to a window ora frame, it is always applied to a copy of a frame which is associated with aparticular window.

6 If the property is not mandatory, the elements for which this property isnot defined are grouped at the end and marked appropriately.

the prevailing order) are available for frames of tokens orclasses, andsum and average functions that compute,respectively, the sum andaverageof all the elements areavailable for the members frame of classes that aresubclasses of the classNUMBER.

Frames of tokens also allow users to apply the numericalfunctions (i.e.maximum, minimum, sum,and average) toany numerical property of the class.7 For example, whenviewing the membersframe in the view of PERSON,users may request the averageAGE.

The set of elements of a frame may be restricted tempora-rily to a selected subset, and future operations on this framewill ignore all other elements. There are two basicselectionmethods. In the first method, which is available for allframes, the userenumeratesthe subset, either by specifyingindividual elements, or by specifying the endpoints of inter-vals of elements. In the second method, which is availableonly for membersframes, the user specifies apropertyand acondition,selecting all the tokens whose values for the prop-erty satisfies the condition. A variation of this method doesnot require a condition, and selects all the tokens for whichthis property is defined. Evidently, this feature resembles asimple querying tool. The effect of selection can becancelled.

As defined, the various frames include only immediateobjects and properties. At times, it may be desirable to viewdistant objects and properties as well. Aclosureoperation isavailable for augmenting the contents of the window withdistant objects and properties. The effect of closure can becancelled.

3.3. Synchronization

In the process of browsing, the different windows, onceopened, are independent: the information displayed in anywindow may be modified without any effect on the

information displayed in the other windows.Synchroniza-tion allows users to set up several windows, connected in atree-like structure, so that when the information displayed inany window of this tree is modified (by scrolling or search-ing), the contents of its descendent windows changeautomatically.

Let W1 be an open window, displaying the object namep1

in its distinguished position. Assume that the user opens asecond windowW2, by selectingp1 in W1. ThenW1 andW2

are calledparent and child windows, respectively.8 Theoperationsync(Wl,W2) establishes a synchronization linkbetween the child window and its parent window:W2 willalways display a frame of the object appearing in the distin-guished position ofW1.

Such synchronization links may be repeated to form atree of windows (note that the children of a window arealways synchronized with thesameobject in the parentwindow). When the information in one of these windowsis modified, changes will be made to all itsdescendentwindows.

Synchronization is terminated with the operationbreak(W), where W is an open window. This operationbreaks the synchronization betweenW and its parent.Synchronization is broken automatically when the parentwindow is closed or is changed to display another frame,or when the child window is closed.

The precise effect of synchronization depends on thespecifics of the child windowW2. When synchronizationis establishedW2 has specificwindow attributes.As muchas possible, these attributes should be maintained whenW2

is refreshed to display new objects. When the same attri-butes cannot be maintained, a policy should establish thenew attributes. There are five such window attributes:frame(the specific frame which appears in the window),closure(whether the window shows the closured set of items or onlythe immediate items),ordering (the ordering of the frame),interval (the specific interval of the frame which isdisplayed in the window), andselection(the selection criter-ion applied to the frame).

The policy for determining the attributes of a refreshedwindow could be quite complex. Consider, for example, theinterval attribute. A window ofmemberswill be refreshed toshow the interval occupying the same relative position in thenew frame; e.g. if the original frame has 200 objects, withobjects 41 through 60 displayed in the window, and the newframe has only 100 objects, the refreshed window will nowdisplay objects 16 through 35. A window ofpropertieswillbe refreshed to show the same property in its distinguishedposition. If this property does not exist for the new object,the next property in the present ordering would be shown;unless this window itself has a child window synchronizedwith it, in which case this window will be scrolled until its


Fig. 2. Three synchronized windows.

7 An intensional property whose target class is a subclass ofNUMBER.This property need not be mandatory or single-valued.

8 WhenW2 is used for opening another windowW3 on the same object,W1 would still be the parent ofW3.

distinguished position is empty (and its child window willdisplay the windowNULL).

We illustrate the use of synchronization with a descrip-tion of a browsing session that involves three windows.

First the user opens a window with the subclasses frameof EMPLOYEE and scrolls it until the objectMANAGERappears in the distinguished position. Next, the user opens awindow with the members frame ofMANAGER, andscrolls it until the objectHARRY appears in the distin-guished position. Finally, the user opens the propertiesframe of HARRY and scrolls it until the property (OFFI-CE,AV678) appears.

The user now synchronizes the third window with theobject HARRY in the second window, and the secondwindow with the objectMANAGER in the first window.Fig. 2 illustrates the resulting situation.

Having established these displays, the user now browsesin the list of managers by scrolling the second window.While browsing, the third window changes automaticallyto display information on each manager (in particular, theoffice of the manager).

When finished, the user returns to the first window andscrolls the list of subclasses, replacingMANAGER withTECHNICAL. The second window changes automaticallyto display information on this class, and the third windowchanges automatically to display information on a particularmember of this class. The user now returns to the secondwindow, to browse in the list of members of the technicalstaff.

Note that if there are no members of the technical staff,the second window that is used to drive the third windowwill be empty. In this case the third window (and possiblyother descendent windows) will display the windowNULL.If TECHNICAL is later replaced byTEMPORARY in thefirst window, and there are temporary employees, the thirdwindow will change to display the properties of a particularmember of this class.

4. The user interface

The pilot implementation of ViewFinder implements theexternal model described in Section 3 in a multi-windowgraphical environment, and in this section we describe thisspecific user interface in detail.9 A multi-window graphicalenvironment provides the most natural and effective inter-face, but other user interfaces are possible as well; forexample, a simple textual interface in which the systemoutputs all data and menus to a simple terminal, and usersinput their choices by typing. The present implementation ofViewFinder is based on a ‘‘kernel’’ system that permits easyconstruction of multiple user interfaces.

4.1. The conventions of ViewFinder

ViewFinder is implemented as a SunView [42] applica-tion program. Since conceptual simplicity is a fundamentalrequirement of ViewFinder, it employs a relatively smallsubset of the rich set of communication primitives supportedby SunView. For the most part, these primitives arecommon to all windowing systems. The basic primitivesused in ViewFinder are listed below (the terminology isslightly different from that of SunView).

• Cursor: a screen indicator, whose position is controlledby a movement of a mouse. The action of depressing amouse button will be referred to aspointing (at the itemor area where the cursor is located).

• Button: a small labeled box. The action as pointing at abutton will be referred to asdepressingthe button.

• Display window: a framed rectangular area of thescreen, with a horizontal header at its top, and a verticalscroll-bar at its left. The header shows the label of thedisplay window; the scroll-bar enables users to controlthe contents of the display window with the aid of themouse. For brevity, we shall often refer to displaywindows simply as windows.10

• Menu: a framed list of choice items. Menus pop up whenthe user points at predetermined areas of the screen (forexample, the header of a window) and disappear whenthe mouse button is released. When the user points at amenu item, it is emphasized, and if the button is releasedover an emphasized item, this item isselected.A menuitem may show an arrow at its right hand side: if the userpoints at the arrow, then another menu pops up (a ‘‘pull-right menu’’) the user can thus ‘‘walk’’ through menus,until a final selection is made.

• Communication box: a framed rectangular area of thescreen, used for exchanging information between theuser and the system. Examples are the following:

Selection box:a box with an array of buttons. It pops upin situations when the user must select an option. It disap-pears after a selection is made.Message box:a box with a ViewFinder message and abutton labeled ‘‘close’’. It pops up to display the result ofa computation or an error message. It disappears when thebutton is depressed.Confirmation box: a box with two buttons labeled‘‘confirm’’ and ‘‘cancel’’. It pops up when the user initi-ates certain actions whose effect is relatively substantial.The buttons are used to confirm or cancel the initiatedaction. After either button is depressed the boxdisappears.


9 This user interface is a complete implementation of the external model;yet one could conceive a more powerful graphical implementation.

10 Recall thatwindow isalso a user-model term, referring to a particularversion of a frame in the view of an object. This should cause no confusion,as the context would allow the inference of the proper interpretation of theterm. Indeed, the interpretations can usually be identified, as framewindows will always be presented in display windows.

Input box: a box with a prompting message. It pops upwhen keyboard input must be obtained from the user. Itdisappears when the user terminates the input by depres-sing the ‘‘return’’ key.Structured box: a box that incorporates several of theabove four kinds of communication boxes.

When the system is requested to open a view of an object(a token or a class), it selects one of the frames of this viewand displays the initial interval of elements in a window ofstandard size. The first position of the displayed interval isthe distinguished position.Every window is assigned aunique identification number. The window has a headerlabeledobject_name.frame_nameandwindow_id (parent_-window_id).11 A scroll bar along the left border allows userscontrol over the portion of the frame that is displayed in thewindow.

The frame which is opened by default is determined byestablishing an intuitive order among the various frames,and opening the first non-empty frame. For class objects,the order issubclasses, members, properties, superclasses;for token objects it is:properties, classes.Recall that Rule 1of the internal model guaranteed that each class has at leastone superclass, and Rule 2 guaranteed that each tokenbelongs to at least one non-type class. Thus, the default

frame is guaranteed to be non-empty. The system thenfills the window with the initial interval of the frame. Theelements are arranged vertically, with object names asbuttons and relationship names as text.

By depressing these buttons, the user requests the systemto display the corresponding objects in new windows. Thewindow in which a button is depressed becomes theparentof the new window.12 By pointing at the background and atthe header areas of each window, the user may bring upmenus for performing additional operations. These menusare described in the next two subsections.

4.2. Global commands

When ViewFinder is invoked, a single window appears,covering the entire screen. This window is displayedthroughout the entire session, and it encompasses all activ-ity. A row of buttons at the top of this window offers sixglobal commands.The result of depressing these buttons isdescribed next.

4.2.1. DatabaseWhen database is depressed, a selection box appears,


Fig. 3. Starting a ViewFinder session.

11 The definition of a parent window will be provided shortly.

12 An alternative method, in which the user types in directly the name ofthe new object, is described in the next subsection. In this case the newwindow does not have a parent.

with a column of buttons labeled with the available data-bases. By depressing a button, the user opens that database(the database currently open, if any, is closed). The name ofthis database is also the name of the root class of its general-ization hierarchy, and itssubclassesframe is opened in awindow. In this specific case only, the list does not showthe subclasses (which are type classes, such asSTRINGor NUMBER), but their subclasses. This default frameresembles a ‘‘directory’’ of this database.

Fig. 3 shows the ViewFinder screen at the beginning of asession. After issuing thedatabase command from theglobal menu, the user selected thePERSONNEL database,and thesubclassesframe of the root classPERSONNEL isdisplayed in a window.

4.2.2. View, restoreWhen view is depressed, an input box appears, and the

user is prompted for the name of an object, which is thendisplayed in a window. Such ‘‘open by name’’ is an alter-native to the usual ‘‘open by pointing’’, and is useful whenthe user wishes to view an object which is not referencedanywhere on the screen.

The commandrestore causes a selection box to appearwith a column of buttons labeled with the names of thewindows most recently closed. By depressing a button, theuser redisplays that window, exactly as it was when closed.

This command is used together with theclosecommand, tobe described later.13

4.2.3. Refresh, help, quitThe commandrefresh synchronizes all windows with

their parent windows. This command is used together withthe synccommand, to be described later.

The commandhelp causes a selection box to appear, witha column of buttons labeled with the basic operations.Depressing any of these buttons causes a message box toappear, with specific information on this operation.

The commandquit terminates the ViewFinder session.Confirmation is required.

4.3. Browsing commands

When the user points to the background of a windowwhich displays a frame in the view of an object, the princi-pal menu of ViewFinder appears. The nine commands inthis menu implement the functionalities described inSection 3.

4.3.1. Open, close, replaceThe commandopenopens another window for displaying


Fig. 4. Opening new windows and replacing windows with other windows.

13 By closing and restoring windows, users can work around the limitimposed by SunView on the number of open windows.

another frame (possibly the same frame) of this object. Thenew window will have the same parent as the currentwindow. A pull-right menu lists the possible choices:super-classes, subclasses, membersand properties for a classobject, andclassesandproperties for a token object.

The commandclosecloses the current window. Recallthat this window can be restored later by using the globalcommandrestore.

The commandreplace replaces the frame currentlydisplayed in this window with another frame of this object.A pull-right menu lists the possible options:superclasses,subclasses, membersandproperties for a class object, andclassesandproperties for a token object.

Assuming the situation shown in Fig. 3, consider thefollowing actions. First, the objectPERSON is selectedfrom the PERSONNEL window, thus opening a secondwindow with thesubclassesframe ofPERSON. Then, theobjectEMPLOYEE is selected from thePERSON window,thus opening a third window with thesubclassesframe ofEMPLOYEE. Next, theopencommand is issued to open afourth window with themembersframe ofEMPLOYEE.14

Finally, thereplacecommand is issued, and the user is nowconsidering the options for the frame that will replacemembers(Fig. 4).

4.3.2. SearchThe commandsearchscrolls the contents of the window

to a specified item. A pull-right menu appears with fouroptions:forward, backward, next andprevious. If eitherforward or backward is selected, an input box appears,prompting the user for a string of characters. The windowis then scrolled either forward or backward, until the firstelement (object or property) that matches this string occu-pies the distinguished position. If no occurrences of thisstring are found, the window is not scrolled, and a messageis displayed in a box. If eithernext or previous is selected,the search is repeated for the previous search string, in eitherforward or backward direction. Search strings may includethe wildcard character ‘‘*’’, which matches any substring.

Assume that, while viewing themembersframe ofEMPLOYEE, the user issues thesearchcommand and itsforward option, and types the stringJOHN into the inputbox. Themembersframe is scrolled forward until the firstoccurrence of this string is encountered. The user issuessearch again, and is now considering the different searchoptions (Fig. 5).

4.3.3. OrderThe commandorder modifies the ordering of the

contents of the window. A frame-dependent pull-rightmenu offers the available options. For frames of tokensthe menu lists the optionsnew and refine; each of these


Fig. 5. Searching a value.

14 Note that only immediate members ofEMPLOYEE are listed; i.e.those who are not members of any of its four subclasses.

options has its own pull-right menu with the optionsby-property and by-name; and each of these options has itsown pull-right menu with the optionsascending anddescending. Thus, the user selects one of eightcombinations.

The optionnew is for establishing a new order for theframe, while the optionrefine is for establishing a second-ary order to resolve the order between elements that havethe same position according to the prevailing order. Theoption by-name orders the members according to an orderthat is implied by the type. The optionby-property ordersthe members by the values they possess for some property.In the latter case, a selection box appears listing the closureof the properties of this class, and the user is asked to selecta property. If the user selects a multi-valued property, asecond selection box appears listing various aggregate func-tions (see later) that are applicable to the type of the prop-erty, and the user is asked to select a function. The tokenswill be ordered by the aggregate of the values they possessfor this property. The optionsascendingand descendingdetermine whether the items are listed from lowest to high-est, or conversely. If the frame is ordered by a propertywhich is not mandatory, the tokens that do not possessthis property are marked and positioned at the end, and asuitable message appears.

For frames of classes or properties, the pull-right menulists only the optionsascendingor descending. Classes are

always ordered lexicographically; properties are orderedlexicographically by the relationship; properties that havethe same relationship are ordered according to the targetobject (if the targets are classes, the order is lexicographic;if the targets are tokens, the order is determined by the type).

Assume that, while viewing themembersframe ofEMPLOYEE, the user issues theorder command and theoptionsnew, ascendingandby-property . When presentedwith a selection box with the properties ofEMPLOYEE, theuser selectsSECRETARY which is multi-valued, and wasthen presented with a selection box of possible aggregatefunctions (Fig. 6). Selectingcount will cause the employeesto be reordered by the number of their secretaries.

4.3.4. AggregateThe aggregatecommand computes functions on the set

of items in the current frame and displays the results in amessage box. For frames of tokens, a pull-right menu liststhe optionsby-name and by-property. The option by-nameis for computing aggregates of the tokens themselves,while the optionby-property is for computing aggregatesof some property of the tokens. In the latter case, a selectionbox appears listing the properties of this class, and the useris asked to select a property (it need not be mandatory orsingle-valued). For either option, a selection box appearslisting the available aggregate functions:count, maximumandminimum for tokens or properties of all types, and, in


Fig. 6. Ordering by the total number of the number of the occurrence of a property.


Fig. 7. Computing an aggregate.

Fig. 8. Selecting by enumeration.

addition,sum andaveragefor tokens or properties of thetype NUMBER. For frames of classes or properties only aselection box appears, listing the functionscount, maxi-mum andminimum .

Results of aggregate functions are displayed in a messagebox. When the functionmaximum or minimum , by someproperty, is applied to a frame of tokens, the message boxincludes also the tokens that possess the minimal or maxi-mal value.

Assume that, while viewing themembersframe ofEMPLOYEE, the user wishes to find the total number ofemployees. The user issues the commandaggregatewith itsoptionby-name,and is then presented with a selection boxof possible aggregate functions. Selectingcount, the user ispresented with a message box showing the total number ofemployees (Fig. 7).

4.3.5. SelectThe commandselectrestricts the items of a frame to a

selected subset. A frame-dependent pull-right menu offersup to eight options. For frames of tokens it lists theoptions by-enumeration, by-existence, by-condition,select, show-all, restore, undoand quit . For all otherframes, it offers the same options, exceptby-existenceandby-condition.

The options by-enumeration, by-existence and

by-condition are for marking items to be selected. Whenselectis selected all items are initially marked.

When by-enumeration is selected, a selection boxappears with these buttons:to-top, single, to-bottom andquit, with single being the default selection. In this mode,depressing any marked button in the frame unmarks thattoken, and depressing any unmarked token marks it. If themode is changed toto-top or to-bottom, depressing amarked (unmarked) button in the token frame unmarks(marks) all tokens between the token and the first or thelast token. When the user has finished marking, he pressesquit, to return to the mainselectmenu.

Assume that, while viewing the members frame ofEMPLOYEE, the user wishes to restrict the list to certainemployees. The user issues the commandselect with itsoptionby-enumeration.Fig. 8 shows the marking process:elements with ‘‘*’’ in their button have already beenmarked.

When by-existenceis selected, a selection box appearslisting the non-mandatory properties, and aquit button.When a property button is depressed, all the tokens thatpossess a value for this property are marked. The optionquit returns the user to the mainselectmenu.

Whenby-condition is selected, a structured box appearswith four boxes. One selection box lists all the properties. Asecond selection box lists numerical comparators (�, ±, ,,., # and$), logical connectors (and, or andnot), opening


Fig. 9. Selecting by condition.

and closing parenthesis, and two buttons labeledclear-condition andquit. The other two boxes are an input boxand a message box. The user constructs the selection condi-tion by depressing property buttons, comparators, connec-tors and parentheses. After depressing a comparator, theuser must enter a value in the input box. The message boxdisplays the selection condition as it is being constructed.The construction process may be restarted by depressingclear-condition. Quit returns the user to the mainselectmenu.

Assume that, while viewing themembersframe ofEMPLOYEE, the user wishes to restrict the list to employ-ees with salary over 45 000. Fig. 9 shows the process ofconstructing the selection formula.

These three marking processes can be combined, provid-ing a flexible tool for selecting the items to be retained andthe items to be removed. The other options of this menuperform the actual selection. The commandselectremovesall the unmarked items from the window. The commandshow-all reverses the effect ofselect: all unmarked itemsare returned to the window. Marking and selectioncommands may be interleaved to provide a process of incre-mental filtering. The commandundo allows users to cancelthe effect of the most recent selection: if performed imme-diately afterselect,it restores the situation after the next-to-last selection; otherwise, it restores the situation after thelast selection. The commandrestore shows all the items of

the frame and marks them, allowing users to start a newselection process. Thequit command terminates the selec-tion session: the present window is retained and markingsdisappear. Subsequent selection sessions will resume thesituation just before thequit command was entered. Awindow that has been subjected to selection will have theword SELECT appended to its header label; e.g.EMPLOY-EE.MEMBERS.SELECT.

4.3.6. ClosureThe commandclosureaugments the window with distant

classes, members or properties. A pull-right menu offers twooptions: all and immediate. Selecting all augments theframe with all distant classes, members or properties, asappropriate. Selectingimmediatecancels the closure opera-tion.15 A window that has been subjected to closure willhave the wordALL appended to its header label; e.g.EMPLOYEE.PROPERTIES.ALL.

Assume that, while viewing the properties frame ofEMPLOYEE, the user issues aclosure command andselects the optionall. The frame is then augmented withall intensional properties ofEMPLOYEE, for example,(AGE,YEARS) or (CHILD,DEPENDENT) (Fig. 10).


Fig. 10. Augmenting a frame with distant properties.

15 Whenclosure is applied to a frame that has been subjected toselect,the frame is augmented with the closure elements of the entire frame, notonly those of the selected frame.


Fig. 11. Setting up a synchronized tree of windows.

Fig. 12. The same tree of windows after the root had been scrolled.

4.3.7. SyncThe commandsync synchronizes the window with its

parent window. The command requires that the window is achild of a still-open parent window (i.e. recall that a childwindow iscreated bypointing to the object in the distinguishedposition of another window, the parent window). A pull-rightmenuoffers three options:auto-refresh, demand-refreshandbreak. The first two options regulate the refresh policy of thiswindow. With automatic refresh, the windowwill be refreshedwhenever the contents of the parent window is changed. Withdemand refresh, the window will only be refreshed when theuser depresses the globalrefresh button. This way, the usercan scroll the parent window, without affecting the childwindow, until he has located the desired element. The optionbreakbreaks the synchronization between this window and itsparent window.

As discussed in Section 3.3, when a child window isrefreshed during synchronization, it should preserve theattributes of the former window; i.e. show the same frame,display a ‘‘similar’’ interval within that frame, and maintainits closuring, ordering and selection choices. Presently, onlylimited inheritance is maintained.

An example of synchronization is shown in Fig. 11 and Fig.12. First, the user opens members frame ofDEPARTMENTand scrolls it untilMANUFACTURING occupies the top(distinguished) position. Then, the user opens the propertiesframe of MANUFACTURING and scrolls it until theMANAGER property occupies the top position. Finally, theuser opens two windows onHARRY showing its propertiesand classes. Fig. 11 shows the present situation. The user nowissues thesynccommand with itsdemand-refreshoption inthe last three windows. The third and fourth windows are nowsynchronized with the second window, which is synchronizedwith the first window. When the list of departments in the rootwindow is scrolled, the properties of the ‘‘next’’ department,and the properties and classes of its manager will be displayedin the three descendent windows. Fig. 12 shows the situationafter the root window has been scrolled up one line.

4.4. Layout commands

When the user points to a window header, the standardSunView menu pops up with six commands to control thelayout of the current window:close, move, resize, expose,hide andquit .

Note thatcloseandquit both close the window, but theformer encapsulates it in an icon that may later be reopened.Recall that windows can also be closed with theclosecommand from the browsing menu, and can later be restoredwith the global commandrestore. Note also that thecommandresizemay affect the number of items displayedin the window.

5. Interfacing ViewFinder with different data models

Because its internal model has low-level structures,

ViewFinder can be interfaced easily to different data models,including various object-oriented models, various Entity-Relationship models, and various extensions of the relationalmodel that feature a generalization hierarchy and nested attri-butes. In each model, the ViewFinder network (i.e. the tripletfacts) must be extracted from the given database.

Interfacing ViewFinder to an existing database manage-ment system requires mapping the structures of its internalmodel to the structures of the data model employed by thatparticular system. The complexity of this mapping depends,of course, on the underlying data model (an example of amapping is described later). Once the structures have beenmapped, the retrieval of ViewFinder triplet facts is accom-plished by aDBMS-specific software module that uses thequery tools provided by the underlyingDBMS, mainly data-base queries and data dictionary queries. The present imple-mentation works only with databases that actually conformto the internal model of ViewFinder (i.e. the present systemmust be given a file of triplet facts).

Note that it should not be necessary to store the semanticnetworks extracted from databases. Thus, interfacing does notrequire converting entire databases to ViewFinder’s internalformat. As users browse in a database, the section of thenetwork in the ‘‘neighborhood’’ being browsed is extractedfrom the actual database with a relatively small set of queries.A similar approach was taken by the relational browserBAROQUE [29], where a ‘‘real-time’’ response was achievedwith the aid of various indices. This process provides manyopportunities for optimization: for example, how to anticipatefuture browsing directions and pre-construct sections of thenetwork, while the user is busy observing the present data; orhow to determine which sections of the network recentlyconstructed should be ‘‘cached’’, in case they will be neededin the near future. This topic is currently being studied.

This section focuses on the interface between ViewFinderand external databases. For reasons of space, the discussionmust be limited to a single data model, and we have chosenthe object-oriented data model. To keep the discussion inde-pendent of specific object-oriented database systems, itseems appropriate that we consider theODMG93 standard[9], which is being developed by the members of the ObjectDatabase Management Group.16 Again, for reasons ofspace, we shall focus only on the main concepts of theODMG Object Model.

5.1. The ODMG model

An ODMG database is a collection of persistent denota-ble objects, categorized bytypes. Denotable objects areeither mutable(objects)or immutable(literals). All deno-table objects have identity: the identity of a literal is typi-cally the bit pattern that encodes its value; the identity of an


16 The ODMG voting member companies and most of the reviewercompanies are committed to support this standard, which is thereforeexpected to become the de facto standard for the object-oriented industry.

object is termedobject identifier(OID). Objects may havenames; a name must refer to a single object, but an objectmay have several names.

Objects of a given type must have commoncharacteris-tics: a common behavior and a common range of states.Behavior is defined by a set ofoperations that may beexecuted on objects of the given type. Thestateof objectsis defined by thevaluesthey carry for a set ofproperties.Properties are further classified intoattributesand binaryrelationships,where the former take literals as values, andthe latter definetraversal pathsbetween types.

A type has oneinterfaceand one or moreimplementa-tions.The interface defines the external interface supportedby instances of the type (i.e. properties and operations). Animplementation defines the actualdata structuresfor repre-senting the instances of the type, and themethodsthat oper-ate on these data structures.

A type is itself an object and, as such, may haveproperties, including supertypes, extent (i.e. theinstances of this type) andkeys.A subtype: (1) inheritsall the attributes, relationships and operations of itssupertypes; (2) may add additional properties andoperations; and (3) may refine inherited properties andoperations. Multiple inheritance is allowed. An instanceof a subtype is also an instance of each of itssupertypes.

These concepts are illustrated in Fig. 13 which showsan interface definition for a typeEMPLOYEE. Theinterface is defined in ODL, the object definitionlanguage of theODMG Object Model. The exampleincludes a structured literal (the attributeADDRESS)and a collection-valued property (the relationshipHAS_SECRETARIES).

5.2. The ViewFinder representation of an ODMG database

ViewFinder represents anODMG database with a set of

facts that can be browsed to explore the generalization hier-archy and to view the properties of type and instanceODMG objects. There is no support for object behavior,since the function of a browser is to search the contents ofdatabases.17 The correspondence between variousODMGstructures and their ViewFinder counterparts will bedescribed by a mappingm.

5.2.1. Object namesA ViewFinder object must have exactly one name

(indeed, objectsare names), whereas anODMG objectmay be referred to by several names. A namedODMGobject is represented in ViewFinder by one of itsODMGnames; an unnamed object is assigned a name.

5.2.2. Generalization factsThere is a simple one-to-one correspondence between the

types of anODMG database and the classes of its View-Finder representation. TheODMG distinction betweenliteral types and nonliteral types induces a partition of theViewFinder classes intoliteral classes and nonliteralclasses.

For every literal typet (either built-in or defined by aninterval, an enumeration or a structure),m(t), its ViewFindercounterpart, is a subclass of one of the ViewFinder typeclasses; e.g.INTEGER, STRING, DATE, BOOLEAN, andREAL. Specifically:

m(INTEGER) a INTEGER,m(FLOAT) a REAL,m(BOOLEAN) a BOOLEAN,m(DATE) a DATE,m(t) a STRING, for t [ { CHARACTER,CHARAC-TER_STRING,BIT_STRING,TIME,TIMESTAMP},


Fig. 13. ODL definition for a type EMPLOYEE.

17 Nevertheless, it is possible to extend the external model with amethodframeto display information about the methods associated with objects.

m(t) a m(T), if t is an interval of values of typeT,m(t) a STRING, if t is an enumeration or a structure.

The latter choice is motivated by the fact that, since inViewFinder objects are names, the type classes are used tocategorize the object names.

For every nonliteral typet, m(t) is a (nonliteral) class withthe same name ast. The supertypes oft induce generaliza-tion facts withm(t) as the source. If the only supertype oft isthe root of theODMG type hierarchy, then ViewFinderincludes the generalization fact (m(t), a ,STRING); other-wise, if t has the supertypesT1,T2,…, Tn, then ViewFinderincludes the generalization facts (m(t), a ,m(Ti)), i � 1,…,n.

For example, theODMG typeEMPLOYEE induces thesegeneralization facts:

(m(EMPLOYEE), a ,m(PERSON)),(m(ADDRESS), a ,STRING).

5.2.3. Intensional factsThe only literal classes that can appear as the source of

intensional facts are classes representing structures. Thestructuret � kslot1,slot2,…,slotnl, wheresloti is defined askslot_namei:[collection_specifier] Til,18 is represented inViewFinder with the intensional and mandatory facts(m(t),slot_namei,m(Ti)), i � 1,…,n (if the slot contains acollection specifier, the intensional fact is multivalued).

For example, the structure typeADDRESS induces theseintensional facts:

(m(ADDRESS),NUMBER,m(INTEGER)), mandatoryand single-valued,(m(ADDRESS),STREET,m(STRING)), mandatory andsingle-valued,(m(ADDRESS),CITY,m(STRING)), mandatory andsingle-valued.

The interface body of a nonliteral typet determines theset of intensional facts havingm(t) as the source. There is aone-to-one correspondence between the characteristics(attributes and relationships) of anODMG nonliteral typet and the ViewFinder properties ofm(t). A characteristicsignature in the interface body oft, defined as:

characteristic_specifier [Collection_specifier] target_type name19

is represented in ViewFinder with the intensional fact(m(t),name,m(target_type)). The property ofm(t) is manda-tory if the corresponding characteristic is a key (or belongsto a compound key) and multi-valued if the correspondingcharacteristic signature contains a collection specifier.

The distinction between attributes and relationships issomewhat blurred, and is retained only by the nature of

the target classm(target_type), which is a literal class forproperties representing attributes and a nonliteral class forproperties representing relationships.

The characteristics ofEMPLOYEE induce these inten-sional facts:

(m(EMPLOYEE),COMPANY_ID),m(STRING)),mandatory and single-valued,(m(EMPLOYEE),SALARY,m(INTEGER)), single-valued,(m(EMPLOYEE),ADDRESS,m(ADDRESS)), single-valued,(m(EMPLOYEE),HAS_SECRETARIES,m(EM-PLOYEE)), multi-valued.

5.2.4. Membership factsThe ViewFinder representationm(t) of a literal typet is

implicitly instantiated and its member frame cannot bebrowsed, with the exception of enumeration types whoseinstances are explicitly declared. There is a one-to-onecorrespondence between the values of an enumerationtand the members ofm(t): the enumeration t �{ vl,v2,…,vn} is represented in ViewFinder with the member-ship facts (m(vi), [ ,m(t)), i � 1,…,n.

For a nonliteral typet, the membership facts withm(t) asthe target are determined by the instance objects belongingto the extent oft. There is a one-to-one correspondencebetween the instances oft and the members ofm(t):extent(t) � { o1,o2,…,on} is represented in ViewFinderwith the membership facts (m(oi) [ m(t)), i � 1,…,n.

5.2.5. Extensional factsThe state of anyODMG instance object consists of

instances of the characteristics (attributes and relationships)defined by its type. The object characteristics define abstractstates: they appear within the interface definition of anobject type rather than in the implementation. An objectstate can be treated as a list of pairs(characteristic_name,-value), where the value may be an individual object or acollection of objects, depending on whether the character-istic is single-valued or collection-valued. The correspon-dence between the state ofo and the extensional factshavingm(o) as the source is defined in the following way:

• Each single-valued characteristic instance of an objectois represented in ViewFinder with an extensional fact(m(o),characteristic_name,m(value)).

• Each collection-valued characteristic instance ofo isrepresented in ViewFinder with the extensional facts(m(o),characteristic_name,m(vi)) for vi [ value.

6. Conclusion and directions for further research

ViewFinder is a graphical tool for browsing and queryingdatabases. Its design emphasizes simplicity of operation,


18 The collection specifier is optional and is one of {Set,Bag,List,Array},andTi is a literal type.

19 The characteristic_specifier isattribute or relationship.

advanced functionalities, and generality (with respect to thedatabases with which it can be used). ViewFinder was fullyimplemented as a prototype. It is written in the C language,and it runs on a Sun Workstation in the Unix operatingsystem environment. The external model uses the SunViewwindow management system. Presently, the database is inthe format of the internal model.

Work on ViewFinder is still continuing. At the user’s end,we are interested in improving the current implementationof the external model, to achieve a more attractive graphicaluser interface. At the database end, we are interested ininterfacing ViewFinder to external database systems andwe are investigating implementation techniques that assuregood performance. In this section we describe two addi-tional thrusts of research: extending ViewFinder withfeatures for assembling browsing results, and extendingViewFinder to allow users to modify the database.

6.1. Displaying views of virtual objects

Presently, ViewFinder allows users to explore a databaseby repeatedly displaying views of existing database objects,usually by pointing at their references in views presentlydisplayed. Work is underway on extensions to ViewFinderthat will allow users to construct views that do not corre-spond to existing database objects. Specifically, users willbe provided with a new set of commands for creatingvirtualobjects from actual database objects, and displaying theirviews.

To our knowledge, existing database browsing tools donot provide structures and operations for constructingresults of browsing sessions. Consequently, users whoencounter many items of interest in a search process, maysimply have to copy them onto a note pad. In analogy withrelational databases, where formal queries operate on actualdatabase relations to create relations which are answers tothese queries, the new commands will operate on databaseviews (objects) to create views (objects) that are results ofbrowsing sessions.

Virtual objects are always classes. When created (in thebeginning of a browsing session) virtual classes are mostgeneral and have no members. During the session they aremanipulated to include objects of interest, and their positionon the generalization hierarchy changes correspondingly toreflect their new ‘‘contents’’. At the end of the session theycontain the ‘‘output’’ of the session. The dynamic change inthe ‘‘class’’ of a virtual class agrees with the uncertaintythat characterizes browsing.

As an informal example, consider a database that includesthe following generalization hierarchy: the classesMALE,FEMALE and EMPLOYEE are specializations ofPERSON, and the classesMANAGER and TECHNICALare specializations ofEMPLOYEE. Assume that we arebrowsing in this database to determine who should get asalary raise. Initially, we create a new virtual class calledRAISE. Next, we insert intoRAISE the classesMANAGER

and TECHNICAL in their entirety. Then, we retain inRAISE only the members of the classFEMALE, and werestrictRAISE to include only employees in the manufac-turing department. Finally, we insertTOM into RAISE andwe deleteBETTY from RAISE. Altogether, the members ofthe virtual classRAISE are the female employees in themanufacturing department that are either managers ormembers of the technical staff, but excluding Betty andincluding Tom.

It is possible to represent the definition of a virtual class inthe form of a new kind of facts, to be calleddefinition facts,which would be displayed in a new (fifth) frame of thevirtual class.20 Browsing can then be extended to allowusers to browse also in definitions. Since definitions areoften used to formalize higher level concepts, such defini-tions, like inference rules, may be regarded as a form ofknowledge.Altogether, ViewFinder would be integratingaccess todata(i.e. token objects),schema(i.e. class objectsand their hierarchies) andknowledge(i.e. definitions ofvirtual classes).

6.2. Extending ViewFinder to handle databasemodifications

While presently ViewFinder is a tool for database retrie-val (e.g. browsing, querying), it may be extended to allowalso database modification. Modifications may include thecreationof new objects (either classes or tokens), thedele-tion of existing objects, and thealteration of existingobjects.

Modifications will be defined at the level of the externalmodel. That is, users will alter the information displayed inviews, or will use menu commands to create and destroyobjects. These changes will be checked for consistency withthe rules governing the internal model, and will then betranslated into modifications of the underlying semanticnetwork (i.e. insertion, deletion or alteration of triplet facts).

When ViewFinder is interfaced with other data models, itwould be necessary to propagate the modifications to theactual database. Issues of update propagation are currentlybeing studied.

Acknowledgements

The work of D’Atri and Tarantino was supported in partby the Commission of the European Communities under theprojectsESPRIT 1117 (KIWI), ESPRIT 2424 (KIWIS) andAIM 2024 (MILORD). The work of Motro was supported inpart by NSF grants, nos. IRI8609912 and IRI9007106. Theimplementation of ViewFinder was done by FabrizioProsperi Porta (preliminary version) and Walter Tross(current version). The authors wish to thank them for theirvaluable suggestions and comments.


20 Actual classes would have empty definition frames.

References

[1] S. Abiteboul, R. Hull, IFO: a formal semantic database model, ACMTransactions on Database Systems 12 (4) (1987) 525–565.

[2] C. Ahlberg, B. Shneiderman, Visual information seeking: tightcoupling of dynamic query filters with starfield displays, in: R.Baecker, J. Grudin, W. Buxton, S. Greenberg (Eds.), Readings inHuman-Computer Interaction: Towards the Year 2000, 2nd ed.,Morgan Kaufmann, San Francisco, CA, 1995, pp. 450–456.

[3] R. Agrawal, N.H. Gehani, J. Srinivasan, OdeView: the graphicalinterface to Ode, in: Proceedings of ACM-SIGMOD InternationalConference on Management of Data, Atlantic City, New Jersey,May 23–25, 1990, pp. 34–43.

[4] DBASE-III Reference Manual, Ashton–Tate, Culver City, CA, 1984.[5] J.L. Bell, Reuse and browsing: survey of program developers, in: D.

Tsichritzis (Ed.), Object Frameworks, Centre Universitaire d’Infor-matique, Universite´ de Gene`ve, 1992.

[6] D. Bryce, R. Hull, SNAP: a graphics-based schema manager, in:Proceedings of the IEEE Computer Society Second InternationalConference on Data Engineering, Los Angeles, California, February5–7, 1986, pp. 151–164.

[7] R.G.G. Cattell, An entity-based database interface, in: Proceedings ofACM-SIGMOD International Conference on Management of Data,Santa Monica, California, May 14–16, 1980, pp. 144–150.

[8] R.G.G. Cattell, Design and implementation of a relationship-entity-datum data model, Technical report CSL-83-4, Xerox Corporation,Palo Alto Research Center, Palo Alto, California, May 1983.

[9] R.G.G. Cattell (Ed.), The Object Database Standard: ODMG93(Release 1.1), Morgan Kaufmann, San Francisco, California, 1994.

[10] P.P. Chen. The entity-relationship model: toward a unified view ofdata, ACM Transactions on Database Systems 1 (l) (1976) 9–36.

[11] A. D’Atri, L. Tarantino, From browsing to querying, Data Engineer-ing 12 (2) (1989) 46–53.

[12] A. D’Atri, L. Tarantino, A browsing theory and its application todatabase navigation, in: J. Paradaens, L. Tenembaum (Eds.),Advances in Database Systems, Implementations and Applications,CISM Courses and Lectures No. 347, Springer, Berlin, 1994, pp.161–180.

[13] A. Dix, A. Patrick, Query by browsin, in: P. Sawyer (Ed.), Interfacesto Databases Systems, Lancaster 1994, Workshops in Computing,Springer, Berlin, 1994, pp. 236–248.

[14] D Fogg, Lessons from a ‘‘living in a database’’ graphical query inter-face, in: Proceedings of ACM-SIGMOD International Conference onManagement of Data, Boston, Massachusetts, June 18–21, 1984, pp.100–106.

[15] N. Gershon, J.R. Brown, Computer graphics and visualization in theGlobal Information Infrastructure, IEEE Computer Graphics andApplications 16 (2) (1996) 60–75.

[16] A. Goldberg, D. Robson, A metaphor for user interface design, in:Proceedings of the 13th Hawaii International Conference on SystemScience, Honolulu, Hawaii, January 3–4, 1980, pp. 148–157.

[17] K.J. Goldman, S.A. Goldman, P.C. Kanellakis, S.B. Zdonik. Isis:interface for a semantic information system, in: Proceedings of theACM-SIGMOD Conference on the Management of Data, 1985, pp.328–342.

[18] I. Goldstein, D. Bobrow, Browsing in a programming environment,in: Proceedings of the 14th Hawaii International Conference onSystem Science, Honolulu, Hawaii, January 8–9, 1981.

[19] M. Hammer, D. McLeod, Database description with SDM: a semanticdatabase model, ACM Transactions on Database Systems 6 (3) (1981)351–386.

[20] R. Helm, Y. Maarek, Integrating information retrieval and domainspecific approaches for browsing and retrieval in object-oriented classlibraries, in: Proceedings of OOPSLA ‘91, Phoenix, 1991, pp. 47–61.

[21] C. Herot, Spatial management of data, ACM Transactions on Data-base Systems 5 (4) (1980) 493–513.

[22] R. Johnson, M. Goldner, M. Lee, K. McKay, R. Schectman, J.Woodruff, USD — a database management system for scientificresearch, in: Proceedings of ACM-SIGMOD International Con-ference on Management of Data, San Diego, California, June 2–5,1992.

[23] R. King, D. McLeod, An approach to database design and evolution,in: M. Brodie, J. Mylopoulos, J. Schmidt (Eds.), On ConceptualModeling, 1984, pp. 313–327.

[24] R. King, S. Melville, SKI: a semantic knowledgeable interface, in:Proceedings of the 10th International Conference on Very Large DataBases, Singapore, August 27–31, 1984, pp. 30–33.

[25] T. Learmont, R.G.G. Cattell, An object-oriented interface to a rela-tional database, Technical report, Information Management Group,Sun Microsystems, 1987.

[26] G.A. Miller, Dictionaries of the mind, in: Proceedings of 23rd AnnualMeeting of the Association for Computational Linguistics, Chicago,Illinois, July 8–12, 1985, pp. 305–314.

[27] A. Motro, Browsing in a loosely structured database, in: Proceedingsof ACM-SIGMOD International Conference on Management of Data,Boston, Massachusetts, June 18–21, 1984, pp. 197–207.

[28] A. Motro, Assuring retrievability from unstructured databasesthrough contexts, in: Proceedings of the IEEE Computer SocietySecond International Conference on Data Engineering, Los Angeles,California, February 5–7, 1986, pp. 426–433.

[29] A. Motro, BAROQUE: a browser for relational databases, ACMTransactions on Office Information Systems 4 (2) (1986) 164–181.

[30] A. Motro, A. D’Atri, L. Tarantino, The design of KIVIEW: an object-oriented browser, in: Proceedings of the Second International Confer-ence on Expert Database Systems, Tysons Corner, Virginia, April25–27, 1988, pp. 17–31.

[31] B. Myers, J. Hollan, I. Cruz, Strategic directions in human computerinteraction, ACM Computing Surveys 28 (4) (1996) 794–809.

[32] E. Neuhold, M. Stonebraker (Eds.), Future directions in dbmsresearch, Technical report TR-88-001, International ComputerScience Institute, May 1988.

[33] J. Nielsen, The art of navigating through hypertext, Communicationof the ACM 33 (3) (1990) 296–310.

[34] X. Pintado, D. Tsichritzis, An affinity browser, in: D. Tsichritzis (Ed.),Active Object Environments, Centre Universitaire d’Informatique,Universitede Gene`ve, 1988.

[35] T.R. Rogers, R.G.G. Cattell, Object-oriented database user interfaces,Technical report, Information Management Group, Sun Microsys-tems, 1987.

[36] G. Santucci, L. Tarantino, To table or not to table: a hypertabularanswer, ACM Sigmod Record 25 (4) (1996) 40–44.

[37] G. Santucci, L. Tarantino, A hypertabular visualizer for query results,in: Proceedings of VL-97, the 1997 International Conference onVisual Languages, Capri, Italy, September, 1997, pp. 189–196.

[38] B. Shneiderman, Information exploration: search and visualization,in: Designing the User Interface, 3rd ed., chap. 15, Addison–Wesley,Reading, MA, 1997.

[39] A. Silberschatz, M. Stonebraker, J. Ullman, Database systems:achievements and opportunities, Communications of the ACM 34(10) (1991) 110–120.

[40] M. Stonebraker, J. Kalash, TIMBER: a sophisticated database brow-ser, in: Proceedings of the Eighth International Conference on VeryLarge Data Bases, Mexico City, Mexico, September 8–10, 1982, pp.1–10.

[41] P.D. Stotts, R. Furuta, Petri-net-based hypertext: document structurewith browsing semantics, ACM Transactions on Information Systems7 (l) (1989) 3–29.

[42] Sun View Programmer’s Guide, Revision A, Part Number 800-134-510, Sun Microsystems, Mountain View, CA, 1986.

[43] S.A. Weyer, A.H. Borning, A prototype electronic encyclopedia,ACM Transactions on Office Information Systems 3 (l) (1985)63–88.

[44] K. Wittenburg, W. Ali-Ahmad, D. LaLiberte, T. Lanning, Rapid-fire


previews for information navigation, in: T. Catarci, M.F. Costabile,G. Santucci, L. Tarantino (Eds.), Proceedings of AVI-98, the WorkingConference on Advanced Visual Interfaces, L’Aquila, Italy, May 24–27, ACM Press, 1998, pp. 76–82.

[45] H.K.T. Wong, I. Kuo,GUIDE: a graphical user interface for databaseexploration, in: Proceedings of the Eighth International Conferenceon Very Large Data Bases, Mexico City, Mexico, September 8–10,1982, pp. 22–32.


viewfinder: an object browser

Documents