Michael Bieber
Electronic Enterprise Engineering Initiative,
New Jersey Center for Multimedia Research, and
Computer and Information Science Department
New Jersey Institute of Technology
University Heights, Newark, NJ 07102 USA
bieber@njit.edu; http://megahertz.njit.edu/~bieber
Analyzing an application specifically in terms of its intra- and inter-relationships can lead application analysts to better understand its complexity and richness, as well as better provide the kind of access and metaknowledge users desire. A relationship analysis should supplement the standard analysis that analysts perform when designing new applications. Analysts also can perform a relationship analysis to design a layer of supplemental functionality for existing applications. This paper describes the Relationship Navigation Analysis Approach for the initial analysis phase of Web systems design.
Developers of analytical applications often struggle with the need to present complicated information in a way users can best understand it. This involves insightful visualization techniques and user interface design. This is difficult, and for some applications it simply is not enough for all users, especially students, novices and those unfamiliar with the internal details of the application domain (such as a non- technical manager who must make decisions based on an analyst's work).
Even for applications with straightforward information displays, users may still have questions about what a particular item means or how it was determined. Over and beyond its primary purpose of presenting, gathering or manipulating information, logically each page within a Web application might be considered a potential starting point for information exploration. The ability to explore aspects of a piece of information in more detail could help users resolve doubts about or simply better understand both that item, as well as the analysis or display of which it is a part. Users may wish to dig deeper around data values and symbols they see, labels on graphs or user input forms, options in pop- up lists, information users enter as input (before actually submitting it), or even on the menu commands and other controls they can invoke.
Furthermore, users often have different mental models of an application (and its underlying domain) than an application analyst or software engineer. Even when analysts work closely with users, the end result might not be equally intuitive for all users or serve each user's individual tasks equally well. A user may wish to access a particular display, function or piece of information which he or she believes is immediately relevant to the task at hand, but which the system does not make accessible from the current screen or its immediate vicinity.
Analyzing an application specifically in terms of its intra- and inter-relationships can lead application analysts to better understand its complexity and richness, as well as better provide the kind of access and metaknowledge users desire. A relationship analysis should supplement the standard analysis that analysts perform when designing new applications. Analysts also can perform a relationship analysis to design a layer of supplemental functionality for existing applications.
This paper presents the Relationship Navigation Analysis (RNA) Approach for the initial analysis phase of systems design. We describe the five steps of the RNA, concentrating on the general relationship types one finds in applications. We begin in the next section by discussing relationship management and hypermedia.
The field of relationship analysis and management also is known as hypertext or hypermedia [Is93, BI95]. (Nominally, hypertext concerns relationships only within textual displays, though most researchers and practitioners use the terms interchangeably.) Hypermedia enables people. Hypermedia, as a concept, encourages authors to structure information as an associative network of "nodes" and interrelating "links". This structure should reflect the relationships inherent in an application's domain, actual structure, and surrounding metaknowledge. (Relationships generally are implemented as links. World Wide Web applications usually present nodes in a window or a frame, and place anchors to links within these nodes. Selecting an anchor displays the information at the other end of the relationship. Multiple links may be offered in a pop-up list or side frame.) Presenting information in this networked structure frees authors and designers from the linear, sequential structure that characterizes most printed documents. Presenting information as an associative network enables users (information readers) to access information in the order most appropriate. The concept of hypermedia promotes options and choice. In a larger sense, hypermedia increases comprehension through the enriched context that comes from sophisticated navigation support and supplemental information [THH95, RB97].
But how does this apply to applications that are not primarily authoring tools or document-based? Hypermedia considers any application system in terms of the relationships among its elements and processes, focusing on how users gain access to them. Hypermedia navigation techniques, by providing direct access to these intra- and inter- relationships, can give users a greater feeling of control within an application, and a greater understanding of its domain, components and results.
The traditional design methodologies of functional decomposition and data flow analysis help us consider a system in terms of its processes and how information passes through them. An object-oriented viewpoint considers the system in terms of its components and component hierarchies, and the operations applicable to each. A relationship analysis focuses on understanding each of an application's elements, components and processes through its interrelationships and available metaknowledge. We believe that a relationship or hypermedia analysis should play a part in the design of every application with user interaction, and hypermedia access should supplement many application feature sets.
As an aside, we note that hypermedia is not a new concept. While many users first experience hypermedia through the World Wide Web, hypermedia research has been ongoing since the early 1960s when Doug Engelbart developed NLS, a multi-user distributed hypertext system [EE68]. Since then, the hypermedia research community has been developing a wealth of features, systems, guidelines, frameworks and theory focusing on structuring, presenting and accessing interrelated information.
The World Wide Web has a limited implementation of hypermedia [BVA97]. Most Web browsers handle a single link emanating from an anchor, a single type of link, single-step forward link traversal, single-step backtracking, hot list (bookmark) annotation, and a history list. Other hypermedia systems allow multiple links per anchor (selecting an anchor brings the user a list of links) and multiple link types, with each link clearly labeled as to its type, e.g., explanation, contradiction, hands-on exercise, etc. (One may have to rank, filter or layer links if their magnitude overwhelms the user.) While most links seen on the Web are created manually (or converted over with a word processing document), large systems and those that generate content dynamically will have to generate the links automatically, often on-the- fly [SL89, Bi92, BK95]. This especially is the case for several of the relationship types we shall specify below. In fact, we designed the entire Relationship-Navigation Analysis technique specifically for these dynamic systems. Several approaches, tools and engines exist to assist developers in implementing such links [BK95, GW97].
In what follows we present and discuss the five steps of the Relationship-Navigation Analysis technique.
Relationship-Navigation Analysis (RNA) has 5 steps:
(1) stakeholder analysis
(2) element analysis
(3) relationship and metaknowledge analysis
(4) navigation analysis
(5) relationship and metaknowledge implementation analysis
RNA has two major purposes. On its own, a relationship analysis will help the system analyst form a deeper comprehension of the application. This occurs primarily in steps 1-4. The analyst then must decide which of these relationships actually to implement. Some may provide only marginal benefit. Others may be very costly or difficult to implement. These decisions take place in the last step.
While quite useful in its current form, we intend to develop the RNA technique further by producing specific guidelines for each step and by reducing the range of options that the analyst must consider within steps 2 and 3 of the analysis. These refinements should make the analysis more systematic and easier to conduct, while allowing it to remain necessarily open-ended.
The purpose of the stakeholder analysis is to identify the application's audience. Knowing who will be interested in an application helps the analyst broadly determine the entire range of important elements and relationships, and then to focus on these specifically. Especially those applications with public Web access have a much broader range of stakeholders than many imagine.
Many analysts, in fact, find this the most enlightening part of the RNA. For example, in a recent analysis of a virtual university, the analysts started out with the implicit assumption that current students would be the only users of the system. They were only considering putting course syllabi, assignments, professor contact information, and the like on-line. The stakeholder analysis very quickly found stakeholders such as potential students, parents of potential students, the university's accreditation board, companies looking for consultants, researchers looking for fellow students, and even professors gathering information about their own and others' classes.
For a complex decision analysis package, stakeholders included not only the analysts who would use the application, but managers who had to act on the analyses, new employees who had to learn about a domain, those who funded the department using the analysis package (to understand why certain strategies were followed and others rejected) and the organization's legal department which had to defend the department's decisions in lawsuits several years after decisions were implemented [KPB90, Bi92].
Of course, designers may decide not to serve all the potential users, but they should decide this explicitly. If some of these unintended users might come across the system anyway, then the designers should include some orientation information for them clearly identifying the system's scope and kindly direct them to more appropriate systems.
Often-ignored stakeholders include the actual system developers (who have to debug problems and authors who construct information within the application (e.g., an analyst building a new model based on existing models). For research prototypes, research colleagues and grant providers constitute important audiences that often are interested in internal or conceptual features that few users might need to notice explicitly.
In addition to identifying stakeholders, the analyst also identify and understand the tasks each type of user might want to perform within the system. These will help the analyst focus on specific areas during the following RNA steps.
We strongly encourage analysts to consult the stakeholders found in this step to assist in performing, or at least to confirm and extend the results of the following four steps.
Here the analysts lists all the potential elements of interest in the application. At one level these include all types of items displayed in any on-line display (information screens, forms, documents, and any other type of display), as well as the screens, forms and documents themselves. The easiest way to start is to examine each screen (or mock-up) and identify each value and label it contains.
A more complete analysis could also include all subsystems within the application; all processes users conduct within the application; all internal processes within the application; and all operations that could be invoked. Each may be accessible to a stakeholder, who might benefit from exploring their relationships and metaknowledge. As part of our future research we will be coming up with guidelines for determining which of these are most useful to identify.
Note that the analyst should identify kinds or classes of elements, not individual instances. The relationship types we discuss in step 3 all are for specific types of elements. In the educational domain these include "syllabus" and "professor", as opposed to individual syllabi and professors. In the decision analysis domain these include "model" and "data value" as opposed to specific models or data values.
Relationship analysis concerns inter-relationships, intra- relationships and metaknowledge. The analyst should consider each element of interest identified in the prior step in terms of each of the following general kinds of relationships, for each group of stakeholders. Certain relationships will be useful to only certain stakeholders.
Relationships can lead to information inside and outside the application. Analysts should not feel constrained by real-world considerations of availability or implementation cost and effort. In this step they should exercise their creativity as fully as possible. Only in step 5 should they consider how to implement the relationships and metaknowledge found.
In a way, this step is more a brainstorming exercise than a rigorous analysis. The relationships specified below are the general kinds (classes or categories) of relationships one finds in different computational applications. Various hypermedia researchers have come up with different link (or relationship) taxonomies [Oi96, TW86, WR95] which contain specific link types for particular applications or domains. These could fall across several of our general link categories. Note too that we have compiled the above set of general link categories based on personal experience in developing and using applications. It is not complete. Neither have we tried to normalize it; a particular semantic link type might fall in more than one category. Nevertheless, analysts have found the current set very useful in thinking about providing relationship support to applications. As part of our future research we plan to come up with a more complete and theoretically robust taxonomy of link categories. Although we have found other general taxonomies [DeR89, Pa91, RT90] inadequate for our domain of generic application support, we might incorporate and use them as a starting point.
Schema relationships represent (and when implemented provide direct access to) the kind of domain-specific relationships one finds in an application design document or a database entity-relationship diagram or schema. Within a decision support system (DSS) or model management system, one may associate models that operate within the same domain. One also may infer associations among models that share global variables or other components. Within an enterprise support system (ESS), schema relationships include the intra-organizational relationships found in an organization chart.
Process relationships represent processes or tasks that people do. In a work flow support system or ESS, process relationships represent the interconnections among workgroups, departments and software applications handling different aspects of a product or service. Process relationships give access to the next step in a work flow or procedure, subtask in a project management system, or document in a series.
Operation relationships represent an application's executable commands, such as those one would find in it's menus or action buttons (e.g., submit). Logically operation relationships connect an object to the result of operating upon it. In a DSS for example, an execution link connects a decision model and data scenario with their computed analysis result. An explanation link connects that analysis result with an explanation of its calculation.
Structural relationships connect related objects based on the application's domain independent internal structure common to all instances of the application system. In every DSS these include links among a decision model's equations, its variables, and individual data values instantiating the variables. In every project management system, subtasks are related structurally to their parent tasks, to the portion of the timeline that they affect, and to documents produced within them. In every geographic information system (GIS), the elements of a map and their underlying data are related structurally. In every programming language editor, program variables are related structurally to all statements that contain them. Subroutines are related structurally to the statements that call them. In every spreadsheet, formulas are related structurally to the cells and functions they include.
Descriptive relationships connect an item of interest to definitions, longer descriptions, an object's purpose and other descriptive information.
Attribute and Parameter relationships connect an item of interest to its attributes and parameters and other background information. In a DSS, a data value's system parameters include its size, data type and security classification. Its domain parameters include its attributes. Background information includes its source and owner and purpose. Descriptive information also encompasses definitions, longer descriptions and background information.
Occurrence relationships connect all views and other manifestations of a given item. In a CASE tool, for example, these would connect each occurrence of an item in the requirements document, design documents, program code, documentation and system output. In a GIS, one should be able to see every occurrence of a data value or geographic object in all maps, data listings and analysis reports. Occurrence relationships would also link different versions of the same document or datum.
Statistical or dependency relationships give access to any items that statistically occur under similar conditions or appear to depend upon others (perhaps determined through a cluster or knowledge discovery analysis).
Similarity relationships connect all items that share some degree of similarity. In a CASE environment, for example, similarity relationships could connect all subroutines that use (some or all of) the same set of variables, albeit for different purposes. In a CAD system, similarity relationships could connect all components that share (some or all of) the same set of building block components, but use them differently. In a mathematical modeling DSS, similarity relationships could identify all mathematical models that contain (mostly or entirely) the same equations, perhaps with different local variable names.
Collaborative relationships structure collaboration among people. For example, in a brainstorming system, participants may have to enter a comment before they can see others' comments, or each might work on a task that later should be merged. In a group decision analysis system, these may show how different group members weight a particular decision factor or event.
Ordering relationships put items in some kind of sequence. The most straightforward ordering relationships can be found by asking the question: "if I had a previous and a next button for this element of interest, where would each lead?" Determining this may depend on user preferences or on temporal information (e.g., ordering by precedence).
Contingent or ad hoc relationships represent all relationships declared by the user in addition to those above. While all the aforementioned relationships could be generated automatically based on the application or system structure, ad hoc links allow the user to declare anything not inferable or automatable. They thus are contingent on synthesizing abilities and knowledge the user has but the computer does not. Contingent relationships range from comments on single items to user-declared links among items. Both document authors (e.g., analysts) and, security permitting, document readers (e.g., other group members, management, customers and the general public) may be able to annotate items within an application.
Bieber and Vitali [BV97] shows how several of these general relationship types can supplement an on-line sales invoice. [Bi97] shows how they can supplement a mathematical modeling decision support system.
Once we identify the relationships, we can think of how the user might access them. The most straightforward implementation would make each relationship a link, and then provide simple traversal (users selecting an anchor and link, and the system displaying the link destination). But certain relationship types lend themselves to more sophisticated navigation. The concept of hypermedia includes many other navigation features based on relationships or links. These include guided tours and trails, overviews and structural query. In this step of RNA, the analyst should decide which navigation features might best serve stakeholders' needs.
Overviews [La90, THH95, UY89] allow users to see the relationships among a group of nodes or documents. Overviews often are presented graphically, with each node as square and links as lines connecting them. Clicking on a node usually displays that node in a separate window. Overviews are especially appropriate for displaying schema, process, ordering and occurrence relationships.
The beauty of the Web paradigm is that users control their own navigation, deciding the most appropriate document to view at any given time. This sometimes also is the Web's curse: users unfamiliar with a site can find it hard to find what they seek, can be overwhelmed by the number of links available and sometimes lose track of where they are. (The hypermedia research community calls these problems "disorientation" and "cognitive overload" [Co87, THH95].) Good user interface design can alleviate them in part. Overviews can also help to keep users oriented. Guided tours and trails provide another technique.
Guided tours [MI89; GMP96, FSM97] and trails [TW86] are "recommended paths" through a Web site. In a DSS, for example, an analyst could set up one recommended path for a new analyst that explains the domain in detail, another path for a high-level manager wishing an overview of a domain, and a third path through documents concerning budget decisions for the budget oversight committee. The analyst could prepare an annotated guided tour to explain a completed analysis or other process. Guided tours only include previous and next links on the tour itself, restricting the user to nodes or documents on the tour. Nodes on trails include all links, thereby allowing the user to either follow the trail's previous and next links, or detour away from the trail via these other links.
Guided tours and trails also are appropriate for displaying schema, process, ordering and occurrence relationships, when the system can specify an order of the individual items within each relationship and the user would want to visit one at a time.
Structural query [Ha88, LYY96, BV97] allows the user to query a Web site based on its structure instead of its content. For example, one might wish to see all documents with links or annotations placed by the legal department, all documents linked to the current one, all documents with schema links to a particular item of interest. Structural query often is similar to occurrence relationships; for example, in an analytical DSS one might ask to see all the models that have the same assumption (all mathematical models with an assumption link to the same assumption).
[BK95, BVA97, Ma96, Ni90, Ni95] discuss these and several other navigation features in more detail.
Clearly step 3 can generate a lot of relationships and step 4 can generate a lot of possible navigational opportunities. In this step, the analyst must decide which actually to implement. This step is not the actual implementation, simply the logical decision of which relationships to implement. Analysts should consider the costs and benefits (actual and marginal) of both implementing and displaying each. We separate this step from steps 3 and 4 so the analyst can exercise all of his or her creative talents there without constraint by real world considerations.
Hypermedia design methodologies present one of the most important developments in the hypermedia field [BI95, BI96; FGI95]. Hypermedia design involves more than applying well-understood system analysis and design or software engineering techniques to hypermedia. Hypermedia functionality requires new kinds of relationship management and navigation support. Hypermedia design methods provide a systematic approach to relationship management and navigation support, which in turn, should enable consistent, large-scale, robust hypermedia implementations. RNA does not compete with any of the existing hypermedia design techniques or methodologies. RNA assists primarily in the requirements gathering phase which one would conduct before using the other methodologies. RNA helps the analyst understand the application domain well enough to conduct a full design using the other methodologies. Similarly, analysts could use RNA in conjunction with non-hypermedia design techniques.
Our future work with RNA concerns developing guidelines for each of the five steps and for applying each of the relationship types and navigation techniques. We want to prune the number of possibilities in steps 2 and 3, figuring out which relationship types are most likely to be useful on which general kinds of elements of interest or to which general kind of stakeholder. Furthermore, we intend to develop an exact procedure for coordinating RNA with other software engineering and hypermedia analysis techniques, as discussed in the previous paragraph.
But in the end, we hope that our most enduring contribution is successfully convincing developers of Web applications (both new and transported from other computer environments) to take full advantage of linking in their applications. Time and time again designers have told us that RNA has shown them links they never imagined in their own applications. Identifying these is the necessary first step towards implementation. Implemented thoughtfully, the Web's linking and navigation facilities can go a long way to reducing the complexity of applications for users.
Born from the need to figure out what to make into links when adding automated hypermedia support to analytical applications, the Relationship-Navigation Analysis has gone though several iterations, primarily in tutorials at the HICSS97 and AusWeb'97 conferences. We are most grateful to the tutorial participants who helped refine this analysis. We also are indebted to Mohan Pattabiraman, Qiang Lu, Sonal Panchal and Praveen Ramanathan who have applied various versions of RNA to real applications at New Jersey Institute of Technology, and to the application developers and owners, including Athanassios Bladikas, Haresh Gopal, Carmen Marici, Lou Pignataro, Lazar Spasovic, Chi Tang and Dave Ullman.
We gratefully acknowledge funding for this research by the NASA JOVE faculty fellowship program, by the New Jersey Center for Multimedia Research, by the National Center for Transportation and Industrial Productivity at the New Jersey Institute of Technology (NJIT), by the New Jersey Department of Transportation, by the New Jersey Commission of Science and Technology, as well as grants from the Sloane Foundation and the AT&T Foundation, and the NJIT SBR program.
[Be95] BENNETT, K. Legacy systems: coping with success. IEEE Software, January 1995, 19-23.
[Bi92] BIEBER, M. Automating hypermedia for decision support. Hypermedia 4, No. 2 (1992) 83-110.
[Bi97] BIEBER, M., Supplementing Applications with Hypermedia, Technical Report, CIS Department, New Jersey Institute of Technology, 1997.
[BI95] BIEBER, M. AND ISAKOWITZ, T. (eds.) Designing Hypermedia Applications. Special issue of the Communications of the ACM 38(8), 1995.
[BI96] BIEBER, M. AND ISAKOWITZ, T. Introduction to the special issue: hypermedia in information systems and organizations. Journal of Organizational Computing and Electronic Commerce 6(3), 1996, iii-vii.
[BK95] BIEBER, M. AND KACMAR, C. Designing hypertext support for computational applications. Communications of the ACM 38(8), 1995, 99-107.
[BV97] BIEBER, M. and VITALI, F. (1997). Toward support for hypermedia on the World Wide Web. IEEE Computer 30(1), 1997, 62-70.
[BVA97] BIEBER, M., VITALI, F., ASHMAN, H., BALASUBRAMANIAN V., and OINAS- KUKKONEN, H. Fourth generation hypermedia: some missing links for the World Wide Web. International Journal of Human Computer Studies 47, 1997, 31-65.
[Co87] CONKLIN, E. J. Hypertext: a survey and introduction. IEEE Computer 20(9), 1987, 17-41.
[DeR89] DEROSE, S. Expanding the notion of links. Hypertext '89 Proceedings, Pittsburgh, PA, November 1989, 249-257.
[EE68] ENGLEBART, D. AND ENGLISH, W. A Research Center for Augmenting Human Intellect. Proceedings of the Fall Joint Computer Conference 33. (Arlington, VA 1968), 395-410.
[FGI95] FRAiSSE, S., GARZOTTO, F., ISAKOWITZ, T., NANARD, J. AND NANARD, M. (eds.), International Workshop on Hypermedia Design'95 Proceedings, Montpellier (June 1-2, 1995).
[FSM97] FURUTA, R., SHIPMAN, F. III, MARSHALL, C., BRENNER, D. AND HSIEH, H. Hypertext Paths and the World-Wide Web: Experiences with Walden's Paths. Hypertext'97 Proceedings (Southampton, April 1997), 167-176.
[GMP96] GARZOTTO, F., MAINETTI, L. AND PAOLINI, P. Navigation patterns in hypermedia data bases. Journal of Organizational Computing and Electronic Commerce 6(3), 1996, 211-237.
[GW97] GRONBAEK, K. AND WIIL, U. Towards a reference architecture for open hypermedia. Proceedings of the Third Workshop on Open Hypermedia Systems, WIIL, U. (ED.) CIT Scientific Report #SR-97-01, 1997, The Danish National Centre for IT Research, Forskerparken, Gustav Wieds Vej 10, 8000 Aarhus C, Denmark.
[Ha88] HALASZ, F. Reflections on NoteCards: seven issues for the next generation of hypermedia systems. Communications of the ACM 31(7), 1988, 836- 855.
[Is93] ISAKOWITZ, T. Hypermedia in information systems and organizations: a research agenda. Proceedings of Twenty-Sixth Annual Hawaii International Conference on System Science (HICSS) (Maui, Jan. 1993), Volume III, 361-369.
[KPB90] KIMBROUGH, S., PRITCHETT, C., BIEBER, M. AND BHARGAVA, H. The Coast Guard's KSS project. Interfaces 20, No. 6 (1990) 5-16.
[La90] LANDOW, G. Popular fallacies about hypertext. in Jonassen, D. and Mandl, H. (eds.) Designing hypermedia for learning, Series F. Computer and Systems Sciences 67, Springer-Verlag, 1990, 39-59.
[LYY96] LEE, Y. K., YOO, S-J., YOON, K. AND BERRA, P. Querying structured hyperdocuments. Proceedings of the Twenty-Ninth Annual Hawaii International Conference on System Sciences (Wailea, Maui; January 1996), IEEE Press, Washington, D.C., Volume II, pages 155-164.
[Ma96] MAURER, H., HyperWave: The Next Generation Web Solution, Addison Wesley, London, 1996.
[MI89] MARSHALL, C. AND IRISH, P. Guided tours and on-line presentations: how authors make existing hypertext intelligible for readers. Hypertext '89 Proceedings (Pittsburgh, Nov. 1989) 15-42.
[Ni90] NIELSEN, J. The art of navigating through hypertext. Communications of the ACM 33(3), March 1990, 296-310.
[Ni95] NIELSEN, J. Multimedia and hypertext: the Internet and beyond. AP Professional, 1995.
[Oi96] OINAS-KUKKONEN, H. Debate Browser - an argumentation tool for MetaEdit+ Environment. Proceedings of the Seventh European Workshop on Next Generation of CASE Tools (NGCT '96), Crete, Greece, 1996, 77- 86.
[Pa91] PARUNAK, H. Ordering the information graph. in Hypertext/hypermedia handbook, Berk, Emily and Joseph Devlin (eds.), Intertext Publications/McGraw-Hill Publishing Co., Inc., New York, 1991, 299-325.
[RB97] RANA, A. AND BIEBER, M. Towards a collaborative hypermedia education framework. Proceedings of Thirtieth Annual Hawaii International Conference on System Science (HICSS) (Maui, Jan. 1997), II 610-619.
[RT90] RAO, U. AND TUROFF, M., Hypertext functionality: a theoretical framework. International Journal of Human-Computer Interaction 2(4), 1990, 333-358.
[SL89] SCHNASE, J. AND LEGGETT, J. Computational Hypertext in Biological Modelling, in Hypertext '89 Proceedings. (Pittsburgh, PA, November 1989) 181-198.
[THH95] THURING, M., HANNEMANN, J. AND HAAKE, J. Hypermedia and cognition: designing for comprehension. Communications of the ACM 38(8), 1995, 57-69.
[TW86] TRIGG, R. AND WEISER, M. TextNet: A network-based approach to text handling. ACM Transactions on Office Information Systems 4, No. 1 (1986) 1-23.
[UY89] UTTING, K. AND YANKELOVICH, N. Context and orientation in hypermedia networks. ACM Transactions on Information Systems 7, No. 1 (1989) 58-84.
[WR95] WANG, W. AND RADA, R. experiences with semantic net based hypermedia. International Journal of Human-Computer Studies, 43, 419- 439, 1995.