Using Structured Types to Incorporate Knowledge in Hypertext

Jocelyne NANARD, Marc NANARD

Department of Knowledge Acquisition and Representation

Laboratoire d’lnformatique, de Robotique et de Microélectronique de Montpellier

University of Montpellier

860 Rue de Saint Priest, 34090 Montpellier, France

Email: nanard@crim.ft

Canonical PDF source: https://dl.acm.org/doi/pdf/10.1145/122974.123006

122974.123006.pdf1.02 MB

ABSTRACT

It has been shown that the famous problem of user disorientation in hypertext is not due to the concept of hypertext itself but rather generally results from the lack of a conceptual model for hypertext application. Unfortunately, in most hypertext systems, the weakness of structure specification mechanisms discourages the development and use of such a model since it is difficult to reinforce hypertext structure and to really incorporate knowledge. A lot of works provide intelligent mechanisms to help navigation but either they use external knowledge or automatically synthesize links from information included in nodes which thereby have no sufficient conceptual value.

The present paper focuses on an object-oriented hypertext model (implemented in the MacWeb system) using structured types to incorporate knowledge in hypertext. Concepts and their relationships as well as their instances and their own relationships may be represented. Such a model makes the capture of knowledge at source easier thus allowing a more conceptual navigation, Furthermore, active behaviors may be associated, as methods, to types. This provides a powerful mechanism to help develop structured hypertext as well as task centered applications, by taking advantage of knowledge representation.

KEYWORDS

Structured types, knowledge representation, object-oriented, hypertext model, document synthesis.

1. INTRODUCTION

For a while, navigation problems have been the in vogue topics about hypertext. Bernstein has shown in [Bern90] how a poor organization of the hypertext structure may cause disorientation and he has suggested solutions for preventing this. In fact, this problem is not inherent in the hypertext concept, but is due to the weakness of structure specification mechanisms in most of the first hypertext systems. This is why reinforcing hypertext structure and providing means to incorporate knowledge are of importance.

Of course, a lot of works attempted to provide the user with intelligent mechanisms to help navigation [Crof89, Fris89, Clit89, Thom89]. They use external additional knowledge either for modeling the user, the domain or the system or for describing relationships between concepts (such as in Visar with CYC [Lena90]). This knowledge is used for guiding information retrieval.

Furthermore, in most classical hypertext, knowledge associated to information present in the hypertext is not elicited because inclusion and reference link types are not powerful enough to express the logical structure of a hypertext. Systems using richer types are very often application-dependent [Conk88] and no general model for managing both information and knowledge in a hypertext has been proposed. Even KMS which early suggested the use of hypertext for handling knowledge only enforces a hierarchical structure [Aksc88]. Reference links are used to escape it.

This paper presents a general hypertext model taking advantage of typed nodes and typed links and of explicit rich relationships between types for building and using knowledge representation in hypertext. Thus, concepts and their relationships as well as their instances and their own relationships may be represented. Furthermore, active behaviors may be associated to types. This model makes possible the mapping of an object-oriented structure on the hypertext. Such a model facilitates an intelligent navigation. Moreover it can be helpful for developing specific hypertext applications integrated with some computer-aided tasks (such as document preparation and management with CAD applications).

This general model is implemented in MacWeb [Nana89], a hypertext system running on Apple Macintosh and developed at University of Montpellier (France). The system is used both for educational purpose and for research applications. It provides a very flexible and extensible type management mechanism making possible to represent knowledge useful to structure any hypertext application.

The first part of the paper focuses on the interest of capturing knowledge on information stored in the hypertext at design time and to incorporate it owing to a rich hypertext structure model. Then the MacWeb hypertext model we developed for managing knowledge in a hypertext is described. An application which takes advantage of knowledge to synthesize technical documents adapted to the user’s task, illustrates the model relevance.

2. HYPERTEXT AND KNOWLEDGE

The word knowledge first is associated to artificial intelligence. For instance, intelligent hypertext applications often use a preprocessor which handles rule-based knowledge for improving man-machine interactions. But this is not the only kind of knowledge on a hypertext, neither the only application nor the only way to handle it. Hypertext models themselves can deal with both information and knowledge. When an author creates a hypertext, he has a mental model of it. Some aspects of this mental model can be stored in the hypertext as information and some others as knowledge. Directly collecting this knowledge at source is more efficient than trying to later elicit it from the available information.

2.1 Information and Knowledge

Since information and knowledge are general words, we need to precise their meaning in this paper. In computer science, the word knowledge stands for elicited relationships between objects making possible automatic reasoning or, at least, efficient logical computation, whereas information is more user-oriented and suggests ‘anything that a human being can be interested in’. For instance, documents contain information but little or no computable knowledge whereas Sowa graphs [Sowa84] represent knowledge, but little or no information.

Hypertext can handle both information and knowledge, information in the contents of nodes and knowledge in the structure. Greater is the expressive power of the link management system, more knowledge can be embodied into the hypertext and thus more pertinent computation can be done to improve information access or synthesize specific views [Nana88]. The <Portrait> of <Mona Lisa>, by its own, is only an information. Its link of type <Painted by> to the node of type <Famous person> named <Leonardo da Vinci> and its link <Location> to the <Public Collection> <Musée du Louvre> represent some knowledge (see figure 1), which can be used later at a more conceptual level, for instance for retrieving <Location>s where are <portrait>s <painted by> <Italian Painters> <living in> the <16th Century>.

In this paper, we only focus on this kind of knowledge and show its advantages, but, of course, we don’t neglect the interest of external rule-based knowledge for handling intelligent applications.

2.2 How to capture knowledge associated to hypertext

An author may either organize existing data as a hypertext or explicitly create a hypertext from scratch. Thereby, two approaches for eliciting knowledge associated to a hypertext are possible. In the first case, extracting pertinent knowledge from data is rather difficult. In the second case, it is possible and suitable to explicit the author’s intentions and, on the way, to capture knowledge on the hypertext at source.

‘...At the beginning were texts. Then came Hypertext, and men had to turn text into hypertext...’ That was a troublesome process, since texts have been designed with their own rhetoric structure which was oriented towards sequential reading [Yank85].

As reported in [Bern90], hypertext structure may be automatically built from linear documents either by using a conceptual markup or by discovering specific structures based on observation of signal words or phrases occurrences. Automatic indexing techniques [Salt88] may also be used. Structured hypertext maybe produced by taking advantage of more formal techniques based on pair grammars [Stot90].

Whereas these techniques quickly spread out, and are useful to transform existing linear texts in hypertext, they rarely capture all the author’s initial intentions. The produced structure results only from a late and specific interpretation of documents. Relations between parts are most often captured at a lexical level but the global semantics assigned by the initial author to some parts of text is lost. Today, text analysis methods are not efficient enough for recovering the meaning of a paragraph and its actual purpose in the rhetoric structure. Most hypertext only propose structural links and reference links: it is far easier to exhibit a reference relationship between two nodes than to explicit the exact semantics of this reference relationship. When texts exist before the hypertext structure, the resulting hypertext store information more than knowledge. This is why it is so important to capture knowledge at source.

When a hypertext is developed from scratch, the author structures it according to the intended rhetoric effects [Bern90, Stre89] and to the domain semantics. The node contents are elaborated with respect to the planned structure. An expert author, using a user-friendly system, directly works and thinks in terms of hypertext and no more in terms of linear documents. At node or link creation time, the author’s intention which is the reason of node existence and of its relationships with other nodes, is available and can be caught. Later, it would be lost.

Indeed, evidence has been presented in the hypertext literature that it is very difficult for authors to articulate the specific relationships between chunks of information. our experience on building hypertext, for instance for educational domain or for managing our writing process, has shown the importance of having means for capturing structures as they emerge. The same remark has been stressed by Jordan: a lot of structuring mechanisms available in IDE [Jord89] result from similar experience with Notecards [Hala88] which already provided types.

Thereby, it is interesting and suitable that the hypertext system provides means to capture at source the author’s explicit intentions and that the hypertext structure makes possible to store them. This knowledge will be helpful to the author himself in the design process as well as to hypertext users. Moreover, it is suitable that the system may have an intelligent look at the structure for guiding or even constraining the author in building hypertext. Improving structural regularities in the hypertext maybe done by providing mechanisms for building semantic hypertext templates.

There is an evident similarity of situation to structured documents manipulation approaches, where, after a period of weakly structured documents, systems such as Scribe, LaTeX and Grif [Quin86] made easier and easier for the user to express the documents logical structure as and when they are created. The interest of SGML logical structure specification features for handling knowledge on documents is obvious. Similarly, now is the time for hypertext to step towards richer structures.

2.3 Examples of knowledge available at source

Some examples of applications where knowledge may be captured at source are now mentioned. In most of them however, knowledge is still poor and poorly used, but it is just the early times.

During the writing process, an author may create typed nodes and typed links for expressing its intents. For instance gIbis [Conk88] proposes a set of predefine types and a mechanism for building new types based on a cognitive study of the task. Even in simplest applications, types are helpful: when preparing a lecture with MacWeb [Nana 89], which is described in next section, I use for instance <additional explanations>, <demonstrations>, <examples>, <anecdotes> <analogies>... link types for structuring the hypertext.

In some applications, the structure is strongly constrained for semantic reasons and can even be supported by a preexisting structure. CASE applications with integrated documentation are such examples [Bige88] [Verc90]. Similarly, in design activities such as scientific discovery, knowledge on the context in which objects are produced may be encapsulated into types. These types make it possible to synthesize specific active views of these set of related objects to manage them [Nana88]. Furthermore, even in non hypertext-based applications, the Post-it™ metaphor produces hypertext-like organizations [Nana90]. It is helpful to add some type management to this basic mechanism for handling these chunks of information and providing the user with an efficient tool so that the chunk set can be used as a hypertext handling both information and knowledge. For instance in a CAD station, the user can stick information chunks on application-specific objects. This set of chunks can be regarded as a hypertext. Knowledge associated to chunks is represented both by the relationships between initial objects and by relationships between chunks and objects (e.g. the illustration, which shows the location of this part in a machine, the comment of this illustration, the warnings...).

As a conclusion for this section, we may say wherever knowledge is available, it is helpful to capture it since it is far more difficult to elicit it later. This capture needs to be done without significant overhead for the author. Today, no one would criticize the overhead due to the management of documents logical structure in model-directed documents production systems such as Grif since this overhead is balanced by the helpful guiding made possible by the structure. Generic and flexible type structures and mechanisms for taking advantage of such structures are suitable in hypertext and the benefits they provide can greatly balance the overhead due to their management.

These benefits concern on the one hand the help, the control and the constraints the system can provide the author with for reinforcing regularities in the hypertext application structure and on the other hand the improvement of the information retrieval functions used in the application.

2.4 Types management and knowledge representation

The method presented in this paper which consists in using structured types to represent knowledge does not intend to provide a complete knowledge representation model. Its main interest is its direct compatibility with the classic links, nodes model. It is a first step towards including knowledge in hypertext and it may greatly improve access’ to information. Thus, the suggested technique just takes advantage of the hypertext structure for encapsulating knowledge since hypertext are based on chunks and links, links types and chunks types are the natural support for knowledge representation,

Types make possible to represent concepts. For instance in the previous example, <Leonard da Vinci> is a chunk name, <Famous person> is its chunk type. <Famous person> is a concept. It does not represent an explicit set of chunks like groups of chunks can do. It characterizes what kind of properties any <Famous person> does share. Abstract attributes are attached to concepts. For instance, a <Famous person> has a <biography>, in which their <famous actions> are referred to, they live at a given period, in some country and so on. These attributes are other concepts or relationships between concepts.

This set of relationships between types constitutes a generic structure which can be used for guiding hypertext design and later for computations (queries or reasoning). But in classical hypertext models, some relationships such as inheritance are not explicitly represented as links. Now, the need for structuring mechanisms is coming to light. Some systems like MacWeb or IDE [Jord89] provide sub-structures cloning facilities for managing conceptual relationships. Hyperbase [Schü90] for its own, relies on the relational data base model.

Object-oriented models are well known for their efficiency for knowledge representation. An <Italian painter> is a concept which is more specific than <Painter> which is more specific than <Artist> and than <Famous person>. Thus, an <Italian painter> inherits of the properties which are defined for <Artist>s. Building an object-oriented model on types in a hypertext with multiple inheritance makes possible to efficiently handle knowledge without significant overhead for the system as well as for its user. The next section presents how we have implemented such a model in MacWeb based on a simple hypertext model.

3. MACWEB, A HYPERTEXT SYSTEM HANDLING KNOWLEDGE

MacWeb has been designed to be a test bed for studying and teaching hypertext and for developing classical hypertext applications based on browsing as well as knowledge based applications or document production applications. This led to separate the general provided features at two levels:

a flexible object oriented network model able to encapsulate knowledge as well as to assume the classical information storage. This model is implemented by the MacWeb kernel.

a unique scripting mechanism which takes advantage of the rich model of representation to develop specific applications. This mechanism is implemented as the WebTalk interpreter.

Both levels are accessible through a fully integrated and direct manipulation interface. They provide general and flexible mechanisms allowing to specify specific application-dependent behaviors.

3.1 MacWeb basic hypertext model

Similarly to Notecards [Hala88], MacWeb kernel manages a network of typed chunks (nodes) called a web. Relationships between chunks (or chunk parts defined as anchors) are expressed by typed links. Chunk types and link types may be freely defined. Complex relationships can be established between types owing to an object-oriented approach. This provides an independent abstraction mechanism for expressing semantics. Thereby, advantage can be taken of the relationships between types when exploring or updating the network or when automatically producing documents from information and knowledge stored in the web.

The kernel provides all the web management facilities and basic operations on types, but is not concerned at all with semantics of types which is encapsulated in their relationships. The basic model extension to take into account semantics of types relies on an interesting bootstrapping property of object-oriented approaches: classes are objects too. Therefore, types can be represented by chunks too. This makes possible to use the same basic mechanisms both for representing typed relationships between chunks and for describing semantics of link and chunk types. These two hypertext structures are bound through type names.

Consequently, the user manipulates the representational abstractions in the same environment as s/he works with the hypertext network.

The basic components of the hypertext structure model are now detailed. The use of the model itself for encoding types semantics is explained in section 3.2.

The main characteristic of the basic model is a resolute absence of constraints. All constraints are shifted onto the description of types semantics thus being only application dependent. MacWeb primitive objects are Webs, Chunks, Links, Anchors, Chunktypes and Linktypes.

3.1.1 Web

Both information and knowledge are manipulated as a network of typed chunks connected by typed links. We call it a web for suggesting that there is no predefined constraint on its structure. This web may have any structure of graph as in Intermedia [Yank88].

3.1.2 Chunks

Chunks are the web nodes. They are always typed and can be used for knowledge representation within a structure or for information storage. A chunk is a directly addressable and editable piece of information available in the system at the network level. Chunks may be of any volume. But when they are small, it is possible to bind them a more accurate semantic as mentioned in [Trig86]. A chunk has a set of entering links, a set of outgoing links and an optional external ChunkName which is a user defined string.

3.1.3 Chunktypes

Every chunk has a logical type. This type is identified at user level by an external ChunkTypeName. Type creation and updating is completely free: MacWeb kernel provides means for allowing type changes and does not set for its own any constraints to be verified for such an operation. When created, a type is not bound to any specific semantics. At this level, using types only leads to partition the chunks set. All constraints are shifted onto type semantics description specified through their types relationships and their associated scripts, thus allowing a very great flexibility.

3.1.4 Links and linktypes

Links express binary relationships between two anchors. Each link has an associated linktype which denotes the relationship represented by the link. A linktype is known at user level by an external LinkTypeName. Links are directional they have a source anchor in a source chunk and a destination anchor in a destination chunk. This decomposition makes the kernel responsible for linking chunks, and the chunks editors responsible for managing the anchors according to the object class (textual, graphics...) of chunks. Stepping along links is possible either forwards or backwards both in browsing or in expressing queries.

3.1.5 Anchors

Due to the object-oriented approach, the editing method of the chunk content is responsible for managing anchors and for maintaining their consistency during edition. Thus only a standard ‘look and feel’ is shared by the editors.

Anchors are logical and not geometrical. Unlike Hypercard buttons and similarly to Intermedia, they are not geometrically defined as an area within a window, but explicitly and logically bound to a portion of text or of picture. MacWeb does not enforce any standard visual representation for anchors, such as buttons icons. A change of cursor shape is the standard feedback when entering an anchor. It is the author’s responsibility to choose a stronger feedback such as a typographic enhancement to emphasize the hypertext visual structure.

Anchors may be defined, observed and updated at will. Since several anchors may overlap, the browsing mechanism always displays a pop-up menu which proposes the targets accessible from the selected point. Each item of this menu is compound of a LinkTypeName followed by the ChunkName of the destination chunk.

3.2 The type specification mechanism

As shown in first section, a hypertext model must be able to represent knowledge as well as information. Knowledge management capabilities are available in MacWeb hypertext model through types specification but no semantic structure is enforced: the user may configure and use types at his will. But MacWeb provides means to specify an object-oriented structure for types: each type may behave as a class. Inheritance relationships may be defined between types. Furthermore, methods can be attached to types by means of scripts. Specifying the type structure is done by using the hypertext metaphor thus taking advantage of a natural and consistent diwt manipulation interface.

3.2.1 The object-oriented structure of types

An originality of MacWeb is the use of a web structure to specify complex relationships between types. It corresponds to apply the well-known Chicken-Egg metaphor to object-oriented programming: classes are objects.

The relationships between types are described in a Web of types as links between nodes which stand for the chunktypes and the linktypes used in the web of the basic hypertext model (called from now the main web).

Any kind of structure might be defined, but the primitive Inherits relationship is provided as a primitive linktype in order to strongly suggest to build an object-oriented model for a type structure! Assigning methods to types, overriding inherited methods, managing multiple inheritance between types and avoiding cycles in class definition are basic features handled by the MacWeb kernel.

Figure 1. A web of types. A very simple but typical example is used to illustrate MacWeb ability to handle knowledge. The WebView is very convenient for observing or graphically defining classes according to an object-oriented model. MacWeb handles multiple inheritance (a <Painter and Scientist> <inherits> from both <painter> and <scientist>). The specific behavior attached to the linktype <Linktype> is specified by the WebTalkScript named <Check Compatibility> which is evaluated on each newLink operation for any type of links since it is bound to the highest type in the link hierarchy. Whereas the kernel does not, by its own, enforce any type structure, it makes possible any kind of strategy to be specified and automatically run, owing to the script binding mechanism. Note that the web of types is not truly separated from the main web. The <Painter and Scientist> <Leonardo da Vinci> and his <picture> <Mona Lisa> are instances of the specified classes and are elements of the main web.

When a structure of types is explicitly specified, it is mapped onto the web through the identity between the external name of a type and the external name of a chunk belonging to the web of types.

Two chunktypes and a linktype are predefine for building the web of types: they are respectively named <Chunktype>, <Linktype> and <Inherits>. These predefine types cannot be deleted nor renamed. They are used as follows:

Creating an instance of chunk named ‘x’ and of type <Chunktype> creates as a side effect the chunktype named ‘x’.

Creating an instance of chunk of type <Linktype> named ‘x’ creates as a side effect the linktype named ‘x’.

Establishing a link of type <Inherits> from a chunk of type <Chunktype> (resp. <Linktype>) named ‘a’ to a chunk of type <Chunktype> (resp. <Linktype>) named ‘b’ means that the type named ‘a’ inherits all the properties of the type named ‘b’ which are not explicitly defined for ‘a’.

A chunk of type <Linktype> or <Chunktype> may have several <Inherits> outgoing links. Multiple inheritance is possible and the selection between equivalent attributes on different paths is arbitrated by the ordering of the link list.

A link of type <Inherits> can only be established between chunks having types which both inherit from the type <Chunktype> or both inherit from the type <linktype>.

When a chunk has a type which inherits from the type <Chunktype>, this type can only be changed to another type which inherits from the type <Chunktype>; the same rule applies to <Linktype>.

The web of types is the network of chunks whose types inherit from the type <Chunktype> or from the type <Linktype> with their connecting links. This notion of web of types is purely formal and induces no real separation between a web of types and a main web. Practically, the web of types only is a sub-network of the web itself and can be handled with the same interface than any part of the web. Figure 1 illustrates how some knowledge can be represented through type structures.

3.2.2 Attaching methods to types

Methods can be attached to types (considered as classes) and to chunks1 (considered as instances). They are used for specifying their semantics (and their behavior). Defining a method for a type ‘t’ is simply done as follows: a chunk whose chunktype inherits from the predefine chunktype <WebTalkScript> is linked to the chunk which defines the type ‘t’. WebT alkScripts may be also associated to main web chunks. A WebT alkScript is specified in the algorithmic language WebTalk. It can be interpreted by the WebTalk Interpreter, either on explicit request issued by the user, or on an implicit request generated by the kernel. WebTalkScripts can be used for various purposes, as illustrated later. Methods defined as WebTalkScripts may be inherited along the type structure. Two kinds of methods may be defined according to the linktype of the link connecting the WebTalkScripts to chunks:

Footnote 1. he difference is that when the method is directly attached to a chunk, the connecting link can have explicit anchors in the chunk. These anchors can behave as buttons for triggering the interpretation of the associated WebTalkScript. If the method only belongs to a type, it only appears in the Interaction menu since no explicit anchor is defined for it in the selected chunk.

Methods which are triggered by explicit user requests: in this case, the WebTalkScript is connected by a link of a user-defined type which denotes what kind of function is assumed by the method specified in the WebTalkScript.

Methods which are implicitly triggered by the kernel on specific actions: in this case, the linktype of the link connecting the WebTalkScript specifies on which action the interpretation of the WebTalkScript is achieved. For this purpose, some predefine linktypes are available and handled by the kernel. These linktypes are: <On NewLink>, <On CutLink>, <On NewChunk>, <On CutChunk>, <On Open>, <On Browse> ...

When a chunk is selected in the main web, methods available in the inheritance of its chunktype are accessible in the Interaction menu. Whenever MacWeb kernel achieves any operation such as a chunk or link creation or deletion, it checks before validating the operation if the inheritance of the type of the concerned object has a script attached with a linktype corresponding to this kind of operation. For instance, when adding a new link to a given chunk, if the chunk itself or one of the ancestors of the type of this chunk has a WebTalkScript attached by a <OnNewLink> link, then this script is interpreted. This WebTalkScript can do any checking, explanation to the user, and so on... It has to return a boolean for validating or invalidating the operation. Of course, if no script is found, the action is validated.

Simulating dynamic links is given as an example for illustrating this technique. Some systems distinguish between static links and dynamic links. MacWeb basic model only provides static links, but WebTalkScripts attached to a chunk make possible to handle dynamic links. The linktype <On Browse> is used for triggering the evaluation of a WebTalkScript while browsing. When the user steps through such a link, instead of calling the chunk’s editor for opening it, the kernel calls the interpreter. This interpretation does what is specified in the corresponding method, for instance it can select information according to a contextual query and organize it as a document. This behaves exactly as the traversal of dynamic links and can display virtual documents whose content has keen collected from several chunks according to queries (see section 4).

3.2.3 The WebTalk language

WebTalk is a general purpose language for specifying WebTalkScripts. It has been originally designed to specify generic models of interactive documents named Conceptual Documents which may be used as user centered interfaces between the web and the user [Nana88]. There is no place for a complete description of WebTalk. More details can be found in [Nana89]. Only a few points are reminded.

These generic models specify four aspects of documents: their content, their logical structure, their presentation, their behavior on user actions.

The logical structure of generated documents is filled with information which either is statically defined in the model as strings or results from the interpretation of queries which extract information from the web. These queries take into account the knowledge embedded in the web by the types and their relationships. (see Annex).

The elements of the document logical structure are interactive objects. Their behavior is specified as interaction methods. Thus the language has been provided with the facility to send commands to MacWeb kernel for carrying back the effects of user interaction into the web. Furthermore, WebTalk provides control structures such as iteration, alternative, procedures and recursion allowing to efficiently describe complex processing. Of course, each of these aspects can be used alone, either for writing independent queries, or for specifying the processing to be done on some actions and thereby is well suited for specifying WebTalkScripts. Conceptual documents are a special kind of WebTalkScripts.

4. EXAMPLE: A COMPUTER-AIDED DOCUMENTATION PREPARATION APPLICA TION

In order to illustrate the advantage of incorporating knowledge within a hypertext a very simple computer-aided documentation preparation application is now described. In this example, knowledge is used to collect information in the web and to organize it as documents: the web contains information and knowledge on repairing cars. The user may browse these information like in a classical hypertext, but interactions have keen provided for presenting more compact and task-oriented information.

The class <Operation> has a method specified in the WebTalkScript named <For a Novice>. Its source code is given in annex. When a given <Operation>2 is selected, its <For a Novice> method becomes available in the Interaction menu. This WebTalkScript contains a generic document specification which specifies how to describe in a detailed manner (<for a novice>) the complete sequence of actions for achieving the concerned operation. Evaluating this method synthesizes a document (see figure 2). In this way, and with no more effort, as many situation-adapted documents as there are instances of the <Operation> class in the web can be produced.

Footnote 2. A chunk whose type inherits from ‘operation’.

On the screen, there is no visual distinction between the directly displayed content of a chunk and a document synthesized as the result of a WebTalkScript evaluation. The user (author or reader) may interact with either and any updating is carried back to the web. Browsing is, of course, possible from both.

Figure 2. Taking advantage of knowledge for producing situation-adapted technical documentation. As a debugging or checking facility, MacWeb can display synchronously the generated document and its model: the WebTalkscript is displayed in another window and markers encompass the portion of source code originating the selected part in the document. Information about this selected part of the document is displayed at the top of the document window: its path in the document logical structure, and the name of the chunk which would be updated if the user edits this selected part.

5. CONCLUSION

This paper has shown how knowledge may be easily represented within hypertext by using typed links and typed chunks and by defining relationships between types. Such a knowledge representation model is in the same trend as recent works in object-oriented database [Bella90]. Using the hypertext metaphor for defining types relationships and behavior leads to a flexible and extensible object-oriented hypertext model.

Taking advantage of this knowledge-based model makes it possible to develop applications which, for instance, capture knowledge at source, need conceptual navigation or direct access to information according to criteria or else synthesize documents as views of information available in the hypertext.

Unlike the Dexter model [Hala89] or the Lange’s model [Lang89] which only provides a weak typing mechanism through attributes associated to links, nodes, and so on, the hypertext model of Macweb explicits the structure of types and expresses it by the web structure itself. This is required for explicitly representing and using knowledge. The model enforces in MacWeb a strict separation between the kernel which is an application independent hypertext engine and any specific structure of types which is application-dependent. Furthermore, complex behaviors may be specified for hypertext objects by binding scripts to types as methods. The mapping of an object-oriented structure onto a hypertext makes easier the design of task-driven applications.

MacWeb kernel, by its own, does not enforce any strategy for type organization. The object-oriented structure of types and the binding of active behavior to types makes it possible to specify hypertext structuring strategies as and when they emerge. These strategies may encapsulate any level of control by taking advantage of type properties.

Application dependent control may be expressed in a declarative manner owing to the automatic triggering of methods attached to types on specific actions on the web and according to type inheritance.

This model has proved its usefulness in MacWeb and the kernel is now being ported to Unix. A large scale application is currently under development for integrating a document production sub-system into an existing CAD system running on Sun. Elements of documentation and application objects are organized as an hypertext structure as and when information and knowledge are produced during the design process. Specific documents can be synthesized when needed.

6. REFERENCES

[Aksc88] Akscyn R.M., McCracken D.L., Yoder E. A., “KMS: a distributed hypermedia system for managing knowledge in organizations”, CACM, 31(7), 1988, pp. 820-835.

[Bella90] Bellahsene Z., Massiot O., “Towards a knowledge model”, Proceedings DEXA90, Int. Conf. on Databases and EXpert systems Applications, Vienne (Autriche), Août 1990.

[Bern90] Bernstein M., “Hypertext and technical writing”, Proceedings ECHT’90 Course, Versailles (France), Nov. 1990.

[Bige88] Bigelow J., “Hypertext and CASE”, IEEE Software, March 1988, pp. 23- 27.

[Camp88] Campbell B, Goodman J.M., “HAM: a general purpose Hypertext Abstract Machine”, CACM, 31(7), 1988, pp. 856-861.

[Clit89] Clitherow P., Riecken D., Muller M., “Visar: a system for inference and navigation of hypertext”, Hypertext ’89 Proceedings, ACM Press, Baltimore, 1989, pp. 293-305.

[Conk88] Conklin J., Begeman M., “gIbis a hypertext tool for exploratory policy discussion, ACM Transaction on Office Information Systems, Vol. 6, n° 4, Oct. 1988, pp. 303-331.

[Crof89] Croft W. B., Turtle H., “A retrieval model for incorporating hypertext links”, Hypertext ’89 Proceedings, ACM Press, Baltimore, 1989, pp. 213-224.

[Fris89] Frisse M.E., “Searching for information in a hypertext medical hand-book”, CACM, 31(7), 1998, PP.880-886.

[Hala88] Halasz F., “Reflexions on NoteCards: seven issues for the next generation of hypermedia systems”, CACM, 31(7), July 1988, pp. 836-852.

[Hala89] Halasz F., Schwartz M., “The Dexter hypertext reference model”, Workshop on hypertext standardization, 1989, pp. 95-133.

[Jord89] Jordan D., Russell D., Jensen A.M. S., Rogers R.A., “Facilitating the development of representations in hypertext with IDE”, Hypertext’89 Proceedings, ACM Press, Baltimore, 1989, pp. 93-104.

[Lang89] Lange D.B., “A formal model of hypertext”, Workshop on hypertext standardization, 1989, pp. 145-165.

[Lena90] Lenat D.B., Guha R.V., “Building large knowledge based systems: representation and inference in the CYC Project”, Reading, Addison Wesley, 1990.

[Nana88] Nanard J,, Nanard M., Richy H., “Conceptual documents: a mechanism for specifying active views in hypertext”, Proceedings of ACM Conference on Document Processing Systems, ACM Press, Santa Fe (NM), Dec. 1988, pp. 37-42.

[Nana89] Nanard M., Nanard J., “MacWeb, un outil pour 61aborer des documents”, Proceedings of WOODMAN89 (Workshop on Object-Oriented Document Manipulation), Rennes (France), Mai 1989, in BIGRE n° 63-64, Mai 1989, ISSN 0221-5225, pp. 18-29.

[Nana90] Nanard M., Nanard J., Pingand P., “An object-oriented kernel for dynamical software integration”, Proceedings of the IEEE Conference on Systems Integration, Morristown (NJ), 23-26 April 1990.

[Quin86] Quint V., Vatton I., “Grif: An interactive system for structured document manipulation”, J.C. van Vliet ed., Cambridge University Press, 1986, pp. 200-213.

[Salt88] Salton G., “Automatic text indexing using complex identifiers”, Proceedings of ACM Conference on Document Processing Systems, ACM Press, Santa Fe (NM), Dec. 1988.

[Schü90] Schütt H. A., Streitz N. A., “Hyperbase: a hypermedia engine”, Proceedings ECHT’90 Conference, Versailles (France), Nov. 1990, pp. 95-108.

[Sowa84] Sowa J. F., “Conceptual structures”, Addison Wesley, 1984.

[Stot89] Stotts P .D., Furuta R., “Hierarchy , composition, scripting language and translators”, Proceedings ECHT’90 Conference, Versailles (France), Nov. 1990, pp. 180-193.

[Strei89] Streitz N.A., Hanneman J., Thuring M., “From ideas and arguments to hyperdocuments: traveling through activity spaces”, Hypertext’89 Proceedings, ACM Press, Baltimore, 1989, pp. 343-364.

[Thom89] Thompson R.H., Croft W.B., “Support for browsing in an intelligent text retrieval system”, Int. J. Man-Machine Studies 30, 1989, pp. 639-668.

[Trig86] Trigg R.H., Weiser M., “Textnet: a network-based approach to text handling”, ACM Transaction on Office Information Systems, 4(1), 1986, pp. 1-23.

[Verc90] Vercoustre A.M., “Structured editing—Hypertext approach: cooperation and complementarily”, EP90, R. Furuta ed., Cambridge University Press, 1990, pp. 65-78.

[Yank85] Yankelovich N., Meyrowitz N., van Dam A., “Reading and writing the electronic book, Computer, 18(10), 1985.

[Yank88] Yankelovich N., Haan B.J., Meyrowitz N., Drucher S.M., “Intermedia the concept and the construction of a seamless information environment”, IEEE Computer, 21 (1), 1988, pp. 81-96.

Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission.

[Source: Jocelyne Nanard and Marc Nanard. 1991. Using Structured Types to Incorporate Knowledge in Hypertext. In Proceedings of the Third Annual ACM Conference on Hypertext (San Antonio, Texas, USA) (HYPERTEXT ’91). Association for Computing Machinery, New York, NY, USA, 329–343. https://doi.org/10.1145/122974.123006.]