H2PTM (1989) Hofmann
- Nous avons tout d’abord l’intention de donner une vue d’ensemble des différentes méthodes de navigation dans les systèmes d’informations. Nous allons discuter tout particulièrement quelques méthodes utilisées dans les systèmes d'hypertextes, telles que des cartes à grande échelle, des vues de l’oeil de poisson, des résumés et fonctions faisant appel à la mémoire pour les sentiers battus. A la suite de la description de la structure du logiciel de notre propre prototype nous procéderons à la présentation des méthodes browsing utilisées. La structure du logiciel est basée sur une configuration client/servuer. Le serveur contient un hypertexte global, commun à tous les utilisateur. Ce contexte est composé d’objets qui proviennent de l’hypertexte global, de même que d’informations individuelles. Alors que l’utilisation du système browsers de CONCORDE modifie petit-à-petit le propre contexte de l’utilisateur, browser signifie un accès progressif aux informations. Nous évitons parlà la vue d’ensemble globale, caractéristique des systèmes d’hypertextes, et qui est souvent la cause des effets perdus dans l’espace. En revanche nous offrons des fonctions qui décrivent un champ d’activités locales jusque dans ses moindres détails.
Motivation and Structure of Content
In recent months, the interest of researchers and developers of information systems has considerably grown in the area of hypertext. Hypertext is information distributed on so-called nodes. The nodes of the system can be related by links. Users may follow links to find related information; links can be typed or untyped; they may be uni- or bidirectional. Sometimes, if nodes have datatypes like bitmap, audio, or animation, the hypertext is called hypermedia  [Conklin 1987], [Hypertext 1987], [Hofmann, Cordes, Langendörfer 1989].
Various problems arise with the application of hypertext; the most important research areas are data modelling (adequate structures, complex objects, versions, restructuring), functionality (redo/undo, cooperative work, use of AI-methods, extensibility), and presentation (design and creation of hypertexts, views, user interfaces). For a discussion of these issues see e.g. [Brown 1988], [Halasz 1988], [vanDam88],
One central problem of all three main fields is the issue of navigation and queries in hypertext systems. Navigation and querying depend on the objects of the system (concerning the data model), is an important functionality, and presentation of the result of a query or of a navigation map strongly influences the interaction of system and user.
So, after a brief introduction to the various styles of querying and browsing in information systems (chapter 2), we will take a critical view of the tools of hypertext systems built for these purposes (chapter 3). Then we will introduce the concept of the hypertext system CONCORDE (chapter 4) and take a look on the solution developed for this system (chapter 5), followed by an example (chapter 6). We will close with an overview (chapter 7) and the references (chapter 8).
In order to retrieve data from database systems, office information systems, hypertext systems, retrieval systems, and expert systems, various methods are used. These methods depend on the kind of systems and the data inside the system.
Best known for relational database systems are query languages like SQL or QUEL. These languages are based on a calculus. They can be found in various systems, sometimes supported by a graphical user interface (see e.g. [Egenhofer, Frank 1988]). In some systems, Prolog and relational databases are brought together [Brodie, Jarke 1986], [Ceri, Gottlob, Wiederhold 1986].
Queries in retrieval systems or office information systems are commonly based on Boolean algebra [Salton, McGill 1983]. Keywords, an index, or a thesaurus are used to retrieve the documents these items relate to.
Also, the inference mechanisms of knowledge-based systems are based on a calculus. Their information is stored in extensional form in facts and rules. Often, users present the goal, which represents the "question”. The starting points of a solution, from which the goal can be reached, are the "answer” to this question. Other forms of "questions" are handled by an explanation module. In most cases, these modules present decision trees and the rules having fired.
A second type of query methods is not founded on a calculus but on the set of objects which have been retrieved in an earlier step. This class includes navigating CODASYL databases and browsers of multimedia systems, retrieval systems, and hypertext systems.
Here, active participation of the user is characteristic of the system. A set of tuples or documents is not the "final answer” anymore but a platform, from where interactive browsing may continue.
Sometimes, it will be an advantage to combine methods from these two classes of querying. [Marchionini, Shneiderman 1988] stress the fact that the finding of exactly defined objects may need indexing as well as browsing. [Tsichritzis, Christodoulakis, et al. 1983] describe a multimedia information system which uses conjunctions of values of data, text, voice, and image; further on, the matches of the query are scanned by a browser.
Data of hypertext systems can be structured in many unforeseen ways, not just in sequential or hierarchical order. So, browsing modules of these systems have at least to fulfill two different tasks: Firstly, they have to supply a filter to select elements from a set of objects. Secondly, they must be able to satisfy the user’s need to know where he or she is, and where he or she came from. We will now discuss some methods suggested for these browsers.
The most common method is to give an overview while showing a map of the hypertext network. Often, all links from objects to other objects are shown [Yankelovich, Meyrowitz, vanDam 1985], [Meyrowitz 1986], [Conklin 1987], [Halasz, Moran, Trigg 1987], [Foss 1988]. Even in small hypertexts , this overview will sometimes be confusing; the user will get the feeling of being "lost in space”. Therefore, [Utting, Yankelovich 1989, p.62] speak of this approach (showing only a global map) as an "effective demonstration of ’how not to do it’.”
To avoid showing the whole database, these systems usually show sectors of the map in a window. It may happen that links cross the window without their source or their destination being visible. The fact that the user may be bound to create the overview by him- or herself is smother potential drawback. It can be argued that any action a user him- or herself has to do in order to keep an overview of the hypertext leads to cognitive overhead [Conklin 1987]. Consequently, automatic support is needed.
[Fumas 1986] proposes a fish-eye view of data. The actual view of a database depends on the actual position in the database and an a-priori weight, which has to be defined for every data item. The actual view is calculated by combining both influences. The effect is that the region around the actual position is shown in more detail; objects farther away are only visible if their a-priori weight is high enough.
A similar proposition is made by [Komorowski, Greenes, Bear, Pattison-Gordon 1988], who present an object and its neighbourhood at different levels of abstraction. If the position changes at one level, new positions are automatically computed for all other existing levels (focus of interest).
[Pintado, Tsichritzis 1988] introduce an affinity browser. Objects are presented on a terminal depending on their affinity to each other. Objects presented close to each other are more related than more distant objects. Here, the distance of objects is computed by a measure. The presentation of these objects may change dramatically if the attributes of measurement are changed by the user.
[Foss 1988] criticizes the loss of information that results from simply showing links in a map. She suggests a summary to collect relationships between the content of an information system. Similar to expert systems, the summary contains an explanation to a user, how and, perhaps, why he or she has reached the actual item. Even the problems of this tool are similar to the explanation module of an expert system; if a summary is expected to contain more than just the names of the links and some comment being part of a link, then it has to have knowledge of the semantics of the links.
A particular kind of summary is introduced by [Tsichritzis, Christodoulakis, et al. 1983], where users can create annotations to documents using fasttalk (datatype ’’voice”).
[Foss 1988] further introduces a history mechanism, as do [Nielsen 1989] and [Utting, Yanke-lovich 1989]. Histories just mark the data a user has read or manipulated; if the user wants to go back to a special item, he or she only has to move backwards on items of the history list.
Miniatures are small realistic icons of stored data items, e.g. cards [Apple87] or documents [Tsichritzis, Christodoulakis, et al. 1983]. It is difficult to select a special data item from an offered set if the items are of great structural similarity.
Another way to guide some users (and restrict them, too) is to offer a path through the set of data. [Bush 1945] calls this trails; [Zellweger 1988] introduces a similar concept called active path. If the user is not bound to follow a path, the mechanism is similar to a "predefined history”.
Stotts and Furuta try a more formad approach to solve browsing problems. They use Petri nets as a generalised form of a directed graph. Hypertext "buttons” (i.e. links) are modelled by transitions, nodes by places. A marked Petri net as integral part of their hypertext definition describes the set ofall possible paths in a dedicated hypertext. The main advantage of using Petri nets is the facility to define browsing semantics by them. Parallel paths can be synchronised, the maximal number of windows needed for presentation can be computed, the reachability of nodes can be determined, and access control is possible by particular transitions of a Petri net [Stotts, Furuta 1989].
Most of these tools can be seen as an attempt to let the user know a semantical context, not just a locality. Sectors, predefined paths, fish-eye views, and affinity browsers show related objects more detailed or less distant to each other; summaries and history lists give an overview on recent activities of a user.
The Concept of CONCORDE
Purpose: CONCORDE is a hypertext system which on the one hand supports single users by offering local contexts, on the other hand creates a working space common for all users. This common working space is called global hypertext; here, application-dependent information is stored in small units typical for hypertext. These units relate to each other only by links of defined types; in the global hypertext user-specific relations are not allowed.
On the contrary, any local context allows individual creation and management of links and of complex objects. These objects are made of units of the global hypertext. Local contexts are the place for changing, updating, and deleting objects.
Basic Architecture: The concept of CONCORDE is based on a layered object-oriented approach [Cordes, Hofmann, Langendörfer, Buck-Emden 1989], [Cordes, Hofmann, Langendorfer 1989]. A presentation module represents the top layer; it allows the use of the tools of lower layers and presents the manipulated objects at the user interface. The next layer contains all the tools necessary to operate on a hypertext. A third layer is made of the logical management. In CONCORDE, we differentiate between a global hypertext and a local context to support a client-server-environment. In a server, the logical management administrates the globed hypertext; in clients, it manages the local context of a client. The bottom layer is represented by a storage module (see fig. 1).
Objects: We use an object-oriented approach to take advantage of encapsulation, inheritance, modularity, and polymorphism [Dittrich 1986], [Bancilhon 1988], [Tsichritzis 1988]. The global hypertext is built of basic objects called cards. As in NoteCards [Halasz, Moran, Trigg 1987] and in HyperCard [Apple87], we decided to model a basic information unit by the card metaphor. Cards are a symbol for a small flexible unit of information and can be easily presented on the terminal.
Cards tire objects made of a surrogate, an information part, system attributes (e.g. class, access rights, cardinality of links, cardinality of copies, icon, mode,...), application-dependent attributes (e.g. title, importance,...), and predefined links. There is no space for a detailed discussion of a card definition, but some remarks on attributes necessary to the browser have to be made.
Any card is instance of a class; a class hierarchy is defined dependent on the particular application. A creator of a card can determine access rights to a card; he or she can decide whether a card may be updated, deleted, or executed (if possible) by particular contexts. The right to read all cards stored in the global hypertext is guaranteed to all users! The links pointing to a card are counted as well as the links pointing from this card to others. Importance is defined by a user to mark cards central to his or her application. A card may have as many different importance values as different contexts exist. Further, cards have a title defined at their creation (may be empty).
Links of predefined types are the basic relations connecting one card to other cards. They are called predefined, because their types must not be chosen in an arbitrary manner. In the global hypertext, lints have just this kind of types offered by the system.
Typing links mainly means that all card classes whose instances serve as possible sources and destinations of links of a particular type are explicitly defined. In CONCORDE, predefined typing means more: a set of constraints is added to any link type. These constraints have to be fulfilled when a link is created. 
So, the system is able to interpret partitions of the hypertext. An example for a system using predefined typed (but uninterpreted) links is gIBIS [Conklin, Begeman 1988]. The issue of predefined link types is beyond scope of this paper; a forthcoming paper will discuss this and related issues in more detail.
The content of local contexts consists of checked-out copies of objects of the global hypertext with additional individual links. Also, we give the user the oppurtunity to define complex objects for him- or herself. Individual links can be typed at will. They will never be written into the global hypertext, therefore they can be used to keep personal information. They axe stored into the local database.
Editing the content of a card is only possible in a local context. While a context has a local storage (for the copies of the cards, the individual links, and for management information), the global hypertext is used as a global server to all the local contexts.
Tools: A set of tools works on local contexts and on the global hypertext. In local contexts, we offer various kinds of editors (a card editor for card instances, a class editor for card classes, a link editor for link types, an object editor to define complex objects). Further, a query module serves to get a set of cards stored in the global hypertext. A browser is used to present the cards to a user, to show links, and to allow working on particular objects. Using the browser a user incrementally changes his or her local context. Cards not present in the client are included on demand, updates are written to the global hypertext, and so on.
State of Project: While first concepts and discussions on CONCORDE began in 1988 (for example see [Hofmann, Langendörfer 1988]), we are now implementing the system We decided to implement a prototype system according to our limited resources of money and person power. Firstly, we build the global hypertext, just one local context, and the most important tools such as browser and query module. We use Smalltalk-80 on a SUN-3—workstation.
The Browser of CONCORDE
The interactivity of hypertext systems is a consequence of the structure of their information; users are able to relate facts by linking nodes at will, and the results of this linking are presented immediately. We will now describe how the browser of CONCORDE operates. Our goal is to keep the user always in context, which means to avoid his or her getting lost in space”. We will prevent this by not presenting cards which are only casually — at the moment of their presentation — local neighbours of the actual information item; the browser of CONCORDE will only show cards with a special relation to an actual item.
We will define these relations after a brief summary of what we will not do:
- a) We do not implement an unstructured overview map as e.g. in Intermedia [Yankelovich, Meyrowitz, vanDam 1985]. This does not mean that a user cannot get an overview on existing cards at all. But we free the user from placing every newly created card at a particular place in the browser; this way we free him or her from being responsible for the user interface of the browser. We restrict the way of getting overviews by using the class hierarchies of cards and links (see functions 1 to 4). [[#h2ptm biblio |]]
- b) Furthermore, we will not use the presentation form of miniatures. In many applications, especially in the office information area, very similar structured cards are created. In this case, miniatures are not much of a help.
- c) Up to now, we have not developed a function like a fish-eye view or a focus of interest. The most similar function of CONCORDE’S browser is the presentation of central cards (see function 9). A function presenting a fish-eye view could easily be implemented if necessary, based on the importance attribute of every card.
Now we list the operations the browser of CONCORDE supports; the list is followed by an explanation of each function. In an appendix, a more formal definition of the semantics of each function is given.
- Show the card class hierarchy;
- Show the link type hierarchy;
- Show all cards of a given class;
- Show all cards connected by a dedicated link type;
- Show all neighbours of an actual card;
- Show all links between an already defined set of cards;
- Show the transitive closure of a card with regard to a special link type;
- Oasis (marking a card);
- Centrad Cards;
- Look around;
- Follow a link;
- Specify cards to be a user-defined set.
Besides these functions, a user will be supplied with opportunities to change the module (explanation, print, edit, query etc.). Fig. 2 shows a typical presentation of the browser of CONCORDE. The central pane of the window is the browser window, the left part is made of two multi-functional panes, and the right part is a simple card editor showing the content of a selected card.
Before proceeding with a more detailed discussion of the functions, we have to define two terms: An actual card is the card which is the user’s focus of interest. Most browser functions relate to the actual card. A card becomes actual if it has been updated, or if explicitly triggered by a double click of the mouse at the icon representing this card. Actual cards are centered in the browser pane. There exists a pointer to the actual card which is never nil but, in some cases, to the beginning of a session in a newly created local context.
A highlighted card is a card visible in the browser pane and marked by a user with a single mouse click. This does not change the actual card! In Fig. 2, the central icon (text: ” vent .off”) represents the actual card, the icon directly below (”NO3_low”) is a highlighted card.
In the following, all functions are applicable on both the global hypertext and a local context except where especially noted.
1. Show the card class hierarchy: The card classes of the application form a hierarchy in our object-oriented approach. We will present this hierarchy by the form of a tree inside a window of the browser; the user may specify a node as "marked class”, and operate with function 3 on this class. Also, the user can specify a class; then this class and all its sub classes will be presented without showing the rest of the hierarchy.
2. Show the link type hierarchy: The hierarchy of types of the predefined links are presented graphically; individual link types can only be listed. This function is analogous to function 1 but handles link types, not card classes.
3. Show all cards of a given class: All instances of a ’’marked class” are shown. Inside the global hypertext, this function cannot be used.
4. Show all cards connected by a dedicated link type: After specifying a link type (e.g. by function 2), all cards connected with links of this type are listed. Inside the global hypertext, the application of this function is impossible.Since the application of functions 3 and 4 may have a large set of cards as result, their presentation depends on the cardinality of this set. While equal or less than twenty cards are presented graphically, more items are shown as a namelist. The user has to specify one card of this list to read it.
5. Show all neighbours of an actual card: The actual card is presented together with all neighbouring cards. Neighbours are defined as those cards, which are source or desti-nation of a link connected with the actual card. All links are presented with their type identity; presentation of additional information (e.g. description of the meaning of the link) is possible.We present all the links which connect presented cards. This distinguishes CONCORDE’S function from the "local map” function of the Intermedia browser which only presents the links pointing to the document of interest [Utting, Yankelovich 1989]. Further, we show links to cards at the moment not copied to the local context as short arrows which do not point to any icon. By selecting such a link (see function 12) the destination card of that link is copied to the local context. As a result, the hypertext local to the user changes incrementally. An extension of showing just direct neighbours is the presentation of an expanded neighbourhood. Here, all cards that are not more than two links away from the actual card are presented. The browser of fig. 2 shows such an expanded neighbourhood.
6. Show all links between an already defined set of cards: Here it is assumed that a set of cards has already been defined and that this set is presented in the browser. Also, this function has two different forms. In its first form, only the links are presented where source and destination are in the defined set of cards. By this function, the user is able to control whether suspected dependencies between specified cards exist or not. Actual card becomes the card listed first. The second form presents all links and their destination, but only if the source of those links is a member of the specified set. This is useful for trying to get an overview on related topics to a read card set. The second form is default.
7. Show the transitive closure of a card with regard to a special link type: To apply this function, the user has to select a card (becoming actual card) and one of its links. Then the transitive closure of this card with regard to the link type of the specified link instance is presented to the user. Applying this function is especially useful, when the semantics of the link type axe transitive. Inside the global hypertext, the application of this function is restricted. The construction of the transitive closure SK is as follows. Let be C∝ the actual card, Cj, Ck, card instances, and lt link instance of a link type L:
8. Oasis (Marking a card): Often the situation arises that a user needs one or more particular cards (and, perhaps, their neighbourhood) to work with. At the same time, he or she sometimes has to follow links which lead away from this ” working set”. By defining the dedicated cards as oases, the cards are marked and added to a collection of marked cards. The user has the opportunity to mark card instances presented in the browser or editor by a simple operation (e.g. clicking a mouse on the icon symbolising the card, and then selecting the ”oasis function”). Then he or she can return to one element of this set of specified cards. They serve as an anchor or oasis to a user after he or she has freely explored the hypertext. So, the user creates a collection with following operations to apply to: add a card to the set of oases; delete a card from the set; list all oases; set maximum number of markers to N; show maximum number of oases; save oasis set. The last operation ensures the existence of a defined set of markers beyond the end of a session. Actual or highlighted cards can be added to the set of markers. In fig. 2, the user has not marked any card as an oasis.
9. Central Cards: This function enables the user to look at cards with many connections.These cards may be good starting points for farther navigation. Cards which fulfill one of the following predicates are called central cards. The default predicate tests whether the number of links starting from a card is greater or equal a given value. The predicate is applied to the particular card attribute. All cards fulfilling the predicate are presented. Other predicates offered are testing whether the total number of links of a card (starting from the card and reaching the card) is greater or equal a given value, or testing, whether the value of the importance attribute is greater than a given value. Actual card will be the first in the list of matches, unless the user selects one of the presented cards as actual.
10. Track: The objective of a track is to give a history of a session to the user. A track is defined as an uninterrupted chain of actual cards. By default, at the beginning of a session the track is empty. Following operations may be applied to a track:
- Show track: the cards are presented in form of a list (see fig. 2, left part, lower pane). The user can choose one of the presented objects as new actual card.
- Back track: the user returns to already read cards; Here, it can be difficult to handle already deleted cards included in the track. One solution could be to offer a user the version of the card, when it was the actual card. This would be inconsistent compared to the other cards which axe presented in their actual state. So, we axe implementing a deletion mechanism, which ”cleans” the track of deleted cards. In one version of this function, every card selected of the track becomes the new actual card, consequently next member of the track. In a second version, every step back leads to a deletion of the last entry of the list.
- Next track: while operating on the track and having tracked back, the user can reach his or her last actual card in simple sequential steps along the track.
- Save track: this results in keeping all objects of a track saved. The last saved track of a session will be default track of the following session at the same local context.
- Cancel track: a sequence of objects can be deleted of the track. Default is the deletion of the whole track, for this operation is supposed to be applied on saved tracks not useful for the following session.
- Restrict track: the user has to define a value to the track, which serves as maximum limit to the objects kept in the track. If the value is reached, every new card becoming member of the track forces the deletion of the first card of the track (first in - first out).
The distinction between oases and a track is not only made by the automatical inclusion of cards to a track while oases have to be declared deliberately. It is also possible to mark only highlighted objects. But it is not possible to find a card in the track which was not an actual card.
11. Look around: We assume that a set of cards has been defined or is already presented by the browser. Then the content of any visible card can be presented to a user in the right pane of the browser window. The card to be inspected is selected by highlighting it. This serves as read-only function. Before the content of a highlighted card can be changed, the card has to be actualised. In fig. 2, the content of the highlighted card is presented in the edit window. This means the "look around’—function has been applicated on card ”NO3 low”.
12. Follow a link: A link of the actual card is selected. The destination object of this link will be the next actual card.
13. Specify cards to be a user-defined set: Cards visible in the browser may be specified by the user to build a user- defined set. This function may be applied only in local contexts. User-defined sets can be empty or can include various cards. These sets may be handled like cards after being defined. They are represented inside CONCORDE by structuring cards (similar to gIBIS' aggregates [Conklin, Begeman 1988]). Sets may be temporary, e.g. all user-selected cards form a set. This set only exists until another function is applied to this set. Some remarks have to be made on the presentation. At the moment, the browser’s presentation does not differentiate between uni- and bidirectional links. The direction of links is shown inside the edit window (see fig. 2). If there more than one link from a card to another one exists, only one edge is presented.
The presentation of a set of cards of any browser function is computed by an algorithm similar to the one described in [Pintado, Tsichritzis 1988]. This algorithm’s results are — in an aesthetical sense — not always optimal; as an example look at the browser pane of fig. 2. As [Brandenburg 1988] remarks, the drawing of nice graphs is NP-complete. Beside the actual solution, we axe trying to improve a heuristic approach whose performance at the moment is still too slow.
Example of the Application of Browser Functions
This chapter demonstrates — as a completion to chapter 5 — the results of using the browser functions. Our example is based on an abstract set of cards (called A to K). This simplification allows us to neglect link directions, names of cards, location (global, local), explanation of specific contents etc. Further, we can present the card set as necessary for a well recognisable visualisation.
Assume a user is working on the following set of cards:
At the moment we begin our observation, the actual card is A. Application of showing the neighbourhood (function 5) has a presentation like fig. 4 as a result. Application of an expanded neighbourhood results as shown in fig. 5. Notice that in a local map as e.g. in [Utting, Yankelovich 1989] the link from E to F would be omitted. Now, the user defines A, C, G, H, I and J as a set (function 13) by selecting them. At this set, the first version of function 6 is applied. The result is shown in fig. 6.
The user marks card A as an oasis (function. 8). Then, she follows linlcs (function 12) from A over C, B, H to E. While doing this, the default function selected by the user has been the neighbourhood function. Having card E as actual card, this leads to a presentation as shown in fig. 7.
Fig. 8 shows the result of an application of building the transitive closure (function 7) regarding the link type symbolised by a straight line (-). Notice that cards J and K do not belong to the transitive closure although they are connected by a link of this type.
Still the oasis list has only one entry (card A), while the history list has entries A, C, B, H, E. The user moves back the history list deleting the last entry (version of function 10); now the history has the entries A, C, B, H.
The user is interested in all cards having more links than her actual card H (more than 3). Fig. 9 shows the result of function 9. At last, she jumps back to her oasis (card A), and begins updating it.
In this paper, we presented a prototype of a hypertext system called CONCORDE, and took an intensive look at the browser of this system. We introduced a graphical browsing facility with special features, which differentiate this browser from the typical browsers giving one an unstructured overview map. We did this in order to avoid the ”lost in space”-problem of many hypertext systems. We are therefore implementing functions showing only semantical related information. These functions are: showing card class and link type hierarchies, showing neighbours of a card, showing the transitive closure, showing links between a defined set of cards, specifying markers, showing central caxds, manipulating tracks, looking into cards’ content, following links, and specifying user-defined sets of cards. In this way, the browser presents just context-sensitive card sets, dependent on the actual (or highlighted) card and the selected operation.
In chapter 2 and 3, we looked at approaches for searching in information systems, especially
at methods used in hypertext systems. After that, we introduced our own approach. Now, we should look an additional differences to related systems to complete the classification of CONCORDE.
CONCORDE is a system, which allows building a personal environment, called local context. Its basic objects are small information units called cards. While many other systems like NoteCards or HyperCard also use this metaphor, cards of the global hypertext of CONCORDE are objects with the links being part of the source-cards. This underlines the semantics of a link being integrated in a card.
Further, we differentiate between personal local contexts and a common global hypertext. The global hypertext is a server for all local contexts. So, the global hypertext supplies the user with link types dedicated to an application. Furthermore, it is able to control parts of the hypertext by constraints of these predefined links. Local contexts allow the hiding of personal information from the global hypertext by defining individual links and complex objects. Therefore, tools for local contexts are different from tools of the global hypertext. While in local contexts the explanation module serves more as a conventional help system, in the global hypertext the module will be similar to one of a knowledge-based system interpreting the predefined links. Editors work in local contexts; in the global context, the query module helps to define sets of cards to be imported into local contexts. Only the browser functions operate nearly identically in both local contexts and global hypertext.
[Apple87] ↑ Apple Computer, Inc., HyperCard User Manual, 1987
[Brodie, Jarke 1986] ↑ M.L.Brodie et M.Jarke, On Integrating Logic Programming and Databases; in: Proc. lJt International Workshop on Expert Database Systems, Kiawah Island (SC), October 1986, pp.197-207
[Brown 1988] ↑ P.J.Brown, Hypertext: The Way Forward; in: Proc. Int. Conf. on Electronic Publishing, Document Manipulation, and Typography, Nizza, April 1988, appeared in: J.C. van Vliet (ed.), Document Manipulation and Typography, Cambridge University Press, Cambridge, 1988, pp.183-191
[Ceri, Gottlob, Wiederhold 1986] ↑ S.Ceri, G.Gottlob et G.Wiederhold, Interfacing Relational Databases and Prolog Efficiently; in: Proc. 1** International Workshop on Expert Database Systems, Kiawah Island (SC), October 1986, pp.141-153
[Cordes, Hofmann, Langendorfer 1989] ↑ R.Cordes, M.Hofmann et H.Langendörfer, Layered Object-oriented Techniques Supporting Hypermedia and Multimedia Applications ; in: Proc. WOODMAN’89, Rennes, May 1989, pp.286-296
[Cordes, Hofmann, Langendörfer, Buck-Emden 1989] ↑ R.Cordes, M.Hofmann, H.Langendörfer et R.Buck-Emden, The Use of Decomposition in an Object-oriented Approach to Present and Represent Multimedia Documents; in: Proc. HICSS-22, Hawaii, Multimedia Software Track, January 1989, pp.820-828
[Halasz 1988] ↑ F.G.Halasz, Reflections on NoteCards: Seven Issues for the Next Generation of Hypermedia Systems; in: CACM, Vol.31, No.7, July 1988, pp.836-852; auch in: Proc. Workshop Hypertext’87, University of North Carolina, Chapel Hill, 1987
[Hofmann, Langendörfer 1989] ↑ M.Hofmann et H.Langendörfer, Concept of an Information System Creating a Local Working Context by Individual Hypertext Links; in: Proc. GI-Conference "Interactive Interfaces for Information Systems”, November 1989 (in German)
[Hypertext 1987] ↑ Proceedings of Workshop Hypertext’87, University of North Carolina, Chapel Hill, 1987
[Komorowski, Greenes, Barr, Pattison-Gordon 1988] ↑ H.J.Komorowski, R.A.Greenes, C.Barr et E.Pattison-Gordon, Browsing and Authoring Tools for a Unified Medical Language System; in : Proc. RIAO’88, M.I.T. Cambridge (MA), March 1988, pp.624-641
[Meyrowitz 1986] ↑ N.Meyrowitz, Intermedia: The Architecture and Construction of an Object-Oriented Hypermedia System and Applications Framework; in: Proc. OOPSLA’86, Special Issue of SIGPLAN Notices, September 1986, pp.186—201
[Zellweger 1988] ↑ P.T.Zellweger, Active Paths Through Multimedia Documents; in: Proc. Int.Conf. on Electronic Publishing, Document Manipulation, and Typography, Nizza, April 1988, published in: J.C. van Vliet (ed.), Document Manipulation and Typography, Cambridge University Press, Cambridge, 1988, pp.19—34
- Postal address: Bültenweg 74-75, D-3300 Braunschweig, Fed. Rep. Germany; Tel.: [+49] 531 391 3249; UUCP: ..mcvax!unido!infbs!hofmann; Bitnet: hofmann@dbsinf6.BITNET
- We will use the term hypertext throughout this paper, even if we do not restrict the datatypes of our system to text.
- CONnected Card-ORienteD Entities
- [Foss 1988] already calls a hypertext consisting of ca. 500 nodes medium-sized!
- A «simple example of such a constraint could be: if a link of type "father-of" points from card A to card B, a link of type "son-of" must point from B to A.