Supporting User-defined Activity Spaces

Transcription

1 Supporting User-defined Activity Spaces Weigang Wang and Jörg Haake GMD - German National Research Center for Information Technology IPSI - Integrated Publication and Information Systems Institute Dolivostraße 15, D Darmstadt, Germany Tel: or fwwang, haakeg@darmstadt.gmd.de ABSTRACT Activity spaces are usually task-specific and only common to a group of people who work together in a certain application domain. It is desirable to enable users to define and modify activity spaces according to their needs. However, many users are unable to use a pre-defined activity space correctly or incapable of formally defining an activity space. This work tries to solve these problems 1) by developing a flexible hypertext meta-model which can represent activity space semantics, 2) developing an example-based definition tool for users to create task-specific activity spaces, 3) providing intelligent aid in using these activity spaces, and 4) providing a flexible space for adopting existing and emergent patterns. A system (COWFISH) with the above components has been implemented and tested at GMD-IPSI. Examples and initial applications have shown that using the system users can easily define the schemata of many activity spaces and hyperdocuments. They can also create new activity spaces with stepwise structure transformation and through reusing existing activity spaces. The system then uses the schema knowledge to maintain the semantic consistency of the activity space instances and to provide users with context-sensitive examples, choices, and explanations. KEYWORDS: activity space, hypertext model, semantic net, schema definition, schema integration, intelligent system, object-oriented system. INTRODUCTION Problem solving, such as writing a document, creating a design, or making a project plan, in general requires a notation for capturing knowledge that is created in the problem solving process. Such knowledge includes facts, interim solutions, and their non-linear relationships that can be conceived as an information space. Permission to make digital/hard copies of all or part of this material for personal or classroom use is granted without fee provided that the copies are not made or distributed for profit or commercial advantage, the copyright notice, the title of the publication and its date appear, and notice is given that copyright is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires specific permission and/or fee. Hypertext 97, Southampton UK c1997 ACM $3.50 Hypertext was from its beginning intended as a concept for representing and organizing non-linearly structured information spaces. Its basic means of structuring, namely nodes and links, can be used as a notation for knowledge capture and organization. It is important to note that any structure or organization that is useful for problem solving is specific to the task. It can be seen as a task-specific notation that is based on a certain methodology to be employed by the problem solver. In terms of the hypertext concept, this leads to the definition of task-specific hypertext object types and operations that are used to manipulate information spaces populated by instances of these object types according to the methodology. This reasoning was the background for introducing the activity space concept [25]. An activity space provides task-specific typed hypertext objects and operations that support problem solving in a certain domain (such as writing in SEPIA [25], creating a project plan etc.). As such, an activity space definition can be compared to a schema of a database system or a document type definition (DTD) in SGML [18] in that it determines the structures that can be instantiated in an activity space instance. The activity space instance provides support for creating information spaces consisting of instances of allowed object types, limiting its organization to allowed structures, and potentially offering taskspecific operations. Problem Analysis Activity spaces are usually task-specific and only common to a group of people who work together in a certain application domain. Usually, such activity spaces are pre-defined by tool designers. This relieves the users of pre-defined activity spaces from the burden of implementing their own tools. However, since activity spaces might change or emerge during cooperative work it is desirable to enable users to define and modify activity spaces according to their needs. However, many users are unable to use a pre-defined activity space correctly or incapable of formally defining an activity space. These two general problems can be split into more concrete subproblems: First, how can users learn to employ a pre-defined activity space according to the methodology intended by the activity 112

2 space designer(s)? That is, how can they learn what semantics are associated with the syntax and/or notation provided by the activity space? The problem of incorrect or inconsistent use becomes more critical if a group of people work together and need to coordinate their personal use of a shared workspace. In addition, three more subproblems are associated with the general problem of defining an activity space: Second, how to make methods and tools for the definition of activity spaces easier for end-users. This is especially important if there exist no adequate pre-defined activity space and when users already know what they want (i.e. they have a pattern for organizing their information space in mind)? Most existing tools for schema definition need either an understanding of certain formal languages or sophisticated professional skills. For this reason, schema definition is usually beyond the capability of most end-users. Third, what can users do if there is no adequate pre-defined activity space available and users have no clear idea on what pattern for organizing their information space they want? As experiences with hypertext systems allowing userdefined types (such as Aquanet [12]) show, users might have problems with defining appropriate structures to work with. Thus, one needs a high degree of flexibility to support the gradual transformation of informally structured information spaces (e.g., by layout) into more formal structures (e.g., by using typed objects). This process can be characterized as producing emergent structure, and in its final stage it can lead to the definition of a new activity space then matching the users task. Finally, what can users do if the problem at hand does not fit into the currently used activity space? This problem arises, for example, when at some point in the problem solving process the user recognizes that the current schema does not allow the expression of a certain piece of information. The user then has to find a better schema or organization that can deal with the exception and subsequently has to reorganize the current information space [19]. Another situation in which this kind of incompatibility arises is the case of reusing material that was organized in another activity space (that is, according to another schema). In this case, the user needs to merge information from different activity spaces into a possibly extended activity space whose definition might have been modified to capture the merged result. Related Work In the past, the first problem was usually delegated to tutorials or teaching the end users, and no specific support was provided by earlier hypertext systems. The second problems were addressed by supporting user-defined types, such as in MacWeb [17] and AAA [21], but they require the user to do so right at the beginning. The third problems were addressed directly by detecting structures with pattern recognition algorithms as, e.g., spatial pattern recognition in the VIKI system [14]. However, VIKI can mainly ease some user interaction (like structure selection, zoom) and cannot provide support for maintaining structural consistency. The forth problem has not been addressed by previous hypertext systems. It can be considered to be an example of schema integration in heterogeneous databases, but no general automatic solution has been found yet. Approach Our approach is to develop a flexible hypertext meta-model for activity spaces and based on this meta-model to provide three dedicated tools for each of the situations corresponding to the first three subproblems. The forth subproblem is collectively addressed by each of the tools. In order to support user-defined activity spaces (the second subproblem), we developed an example-based definition tool for defining activity spaces based on structures created by the user. Thus, the users do not need to learn any formal syntax for defining a new activity space. This approach also provides means to address the first problem of how to learn about a new activity space: in the activity space browser, the annotated example used for its definition can be used as online guidance for new users, and the type information can be used to provide intelligent context sensitive aid for users of the activity space instances. The third problem, namely that of supporting emergent structure, is addressed by developing a tool called the flexible space that allow users to develop a pattern gradually. The forth problem is addressed by allowing users to copy, modify and integrate existing activity space instances and/or schemata, no matter which of the three tools they are using. A system (COWFISH) consisting of above tools has been implemented. COWFISH stands for Cooperative Work in Flexible Information Systems using Hypermedia. It aims at creating a cooperative working environment that uses hypertext-based activity space as a metaphor for various collaborative tasks and working processes. In the following sections, we present the meta-model and tools in more detail. Section 2 introduces the flexible hypertext meta-model for defining activity spaces. Section 3 describes the above mentioned tools built on the model. Application examples of the tools are also presented. Section 3.1 presents the example-based activity space definition tool. Section 3.2 describes the intelligent aid provided by the activity space browser. Section 3.3 introduces the flexible space for supporting emergent structures. Section 4 describes the implementation and how the schema evolution and integration are handled. We finish with some conclusions, compare our approach to related work and present our plans for future work. 113

3 META-MODEL OF ACTIVITY SPACES A flexible hypertext system is a hypertext system which supports the co-existence and transformation of information structures in different degrees of formality, i.e., from very informal and unrestricted representations to very formal representations adhering to explicit rules prescribed by the system [7]. For hypertext systems, the degree of formality of information structures is often indicated by the degree of typing and constraints applied upon basic hypertext objects, e.g. from untyped, to typed with little constraints, to typed with strict constraints. The analysis of many tools that can be considered to offer activity space functionality, such as the SEPIA activity spaces [25] and a PERT/CPM (Program Evaluation Review Technique/Critical Path Method) system [28], reveals that they all use a labeled graph representation, which can be seen as a semantic network. Also they all have structural, relational, and computational semantics. The structural semantics are indicated by the graph type of a hypertext node-link structure. The relational semantics are reflected in the relationship among object types. The computational semantics are reflected in operations on the hypertext objects and conditional actions attached to those objects. Different activity spaces can be created by typing the hypertext objects and adjusting constraints in these three semantic dimensions. A semantic net is a knowledge representation scheme consisting of a directed graph in which conceptual units are represented as nodes, and relations between the units are represented as links. The graph becomes semantic when each node and link is assigned a meaning. The essential idea of semantic nets is that the graph-theoretic structure of relations can be used for inference as well as understanding [10]. Used as a logical model of hypertext, semantic nets can be classified into two types: independent and embedded [2]. In the independent case the nodes and links are tagged with concepts represented by terms. Each node of the semantic net contains a document chunk, but the links between nodes can be seen without necessarily seeing the document chunks. In the embedded case a document chunk is at the destination of a link. In traversing an embedded semantic net, users have to visit document chunks. Our approach to a flexible hypertext based meta-model of activity spaces is to integrate the structural, relational, and computational semantics into a unifying semantic net based hypertext model. This model is an extension of the objectoriented data model of the DOLPHIN system [24], which includes the following objects: Pages, which contain hypertext contents (Links, Nodes, and other media objects). A Page appears in a browser as a drawing area that presents the hypertext contents, Nodes, each of which contains a Page. A node (representation) appears on a Page as a labeled box. Links, which represent relationships between nodes. A link appears on a Page as a labeled line (with or without an arrow), and Other media objects, such as text, scribbles (handdrawings and geometric figures), and images (pixmap drawings). A node in the DOLPHIN model is actually an embedded link between Pages. A link in the DOLPHIN model is a visual indication of the relationship between nodes on the same page. The latter kind of links have no computational semantics for navigation. Semantic Typing The extended model unifies the independent and embedded types of semantic nets by classifying links into two categories: independent links and embedded links. Independent links are presented on a page as labeled arrow lines, which connect two nodes (labeled boxes) on the same page. Embedded links are presented on a page as labeled boxes (in the context of a page, they are seen as node representations). Links are also classified into organizational and referential categories [3]. This classification aims at providing highlevel structural constructs. By merging the above two classifications, links are classified as independent organizational links (organizational links for short), independent referential links (referential links for short), embedded organizational links (i.e., organizational nodes), and embedded referential links (i.e., referential nodes). To create an independent link between nodes in different content pages, one of the nodes needs first to be embedded in the page on which the link is to be created. An organizational node is used when its content is a logical part of its containing page. A node nesting structure with organizational nodes is based on a containment relationship. This relationship can be multi-hierarchical. New organizational nodes can be created freely on any page; but when an existing node (representation) is to be placed on a page (via a copy-paste operation) as an organizational node, the system will check if a cycle will happen, directly or transitively. If so, the node will be put there as a referential node. With this classification, any node is potentially a composite node [8], which may contain an organizational node nesting structure (a rooted directed acyclic graph (DAG)). A referential node is used when its content relates to the content of its containing page, but is not a logical part of the page. The system does not enforce any structural constraints on node nesting structure with referential nodes. They can form a nesting structure of any graph type. Organizational links are used for those relations which have structural constraints, such as a DAG constraint required for is a relation and part of relation. Referential links are used for cross-reference type relationships. They do not have struc- 114

4 tural constraints. Organizational links and organizational nodes form a backbone of the underlying semantic net. They provide a basis for composition mechanisms, and provide a structural clue for user navigation and automatic traversal of the net by a computer system. Within the above categories, links and nodes can be further classified into semantic types. In addition to nodes and links, pages and other media objects can also be semantically typed. For instance, Red Line and White Circle are two types of media objects with semantically meaningful names. A page type is determined by the set of object types (i.e. node, link, and other media object types) that are allowed in this page type. For example, a page type Chalkboard is defined by setting its color to black and setting light colors to all object types allowed in the page type. Constraints In order to maintain the consistency of the semantic net model, constraints are needed to govern the construction and manipulation of the net. Three kinds of constraints correspond to the above mentioned three kinds of semantics: structural constraints, relational constraints, and computational constraints. The structural constraints maintain the type of graph formed by organizational links and the type of graph formed by the organizational node nesting structures. The common graph types of structural constructs are linear path, tree and DAG. The relational constraints specify the allowed relationship between typed hypertext objects. The relational constraints on independent links are indicated by allowable typed links between typed nodes (a triple of <source node type, link type, destination node type>). The relational constraints on embedded links are indicated by the relationship between typed nodes and their typed content pages (a tuple of <node type, content page type>). The computational constraints specify the conditions and their corresponding operations on the nodes, links and substructures of a hypertext network. In an activity space model, task-specific operations can be defined for such operations. Examples of computational constraints are attribute value dependencies across a subnetwork, such as time dependency in a PERT network and token passing in a Petri-net [23]. Page Type as Document Type In this model, a hyperdocument (a document or an activity space) is defined as a rooted node nesting structure constituted by organizational nodes (i.e. a composite node). As described in the previous sections, in this model any node could be the root of a hyperdocument. The type of a document is determined by its root page type. A page is an interface metaphor for presenting a hyperdocument. It is not only a 2-dimensional display and drawing area for independent semantic nets (consisting of typed nodes and links), but also a space for embedded semantic nets (with typed nodes and their typed pages). In addition to nodes and links, other media types can be included on a page. On a page, the object types are indicated by their type names. The names for page types are globally unique, while the names for other object types (nodes, links, and media objects) contained on a page are unique within a page. This allows different constraints to be defined for different object types even if they have the same type names. In this model, untyped nodes and untyped links are actually two types of nodes and links without their type names displayed on the users interface. In a node nesting structure, page types can be defined recursively when nodes at different levels have the same linking semantics. TOOLS AND EXAMPLES OF THEIR USE Three tools have been implemented based on the above model to address our research problems. The user interface of the three tools is largely the same with a page displayed in the middle. On its left-hand side is an editing tool palette, and on its right-hand side is a palette for all allowed object types of the page. At the top is a title bar which gives the name of a tool, the title of the current page, and the type of the page. Under the title bar is a system logo, and a list of users currently working together (see Figure 1). In order to uniformly support a keyboard-mouse based user interface and a pen-based user interface, an object can be created in one of three different ways: selecting from a menu, drawing a gesture (drawing with a mouse or pen ), or selecting from the type palette. The gesture and palette methods are incorporated because they are more intuitive for creating graphical representations. In the following subsections, we present the three tools in more detail. In each of the subsections, first the principle and methodology behind a tool is presented, then a tool description is given, finally application examples are presented. The Example-based Activity Space Definition Tool In many situations a good example can make complicated things easier to understand. If a user has a clear idea about the kind of document type he or she wants, it should be easier for him or her to create a sample document in textual and graphical representations than to create an abstract expression of a document type in a formal language. Our approach is an example-based method: users create a simple but comprehensive sample hyperdocument, and the system extracts schema knowledge from it to define an activity space. Tool Description. When an example-based definition tool is activated, a blank page with a set of default object types is provided. These default object types are not included in the palette of the page. New object types can be created from the default types with either a menu operation or a creation gesture. Whenever an object of a new type is created, the new object type will be put into the palette. During the creation process, some basic attribute values will be assigned in dialog boxes. Other attributes will take default values and can 115

5 Figure 1: Planning Space. be reset when needed. When a node of a new type is created, the system will ask the user for its name, its category, its semantic type, and its page type (which can be a new one or an existing one selected from a dialog box). When a new page type is created, it will be available for users to select in subsequent node creation processes. The object creation operations activated through menu selections or creation gestures may widen constraints when new object types or new relations are introduced. The object creation operations activated from the palette apply constraints defined before. The objects of new types have to be created with either menu selections or creation gestures, because their types are not included in the type palette. The object creation activated from the palette has few dialogs to complete, because the type information has been already defined when the types are first created. Changes to an example page can affect all its instances when such a global effect is desired. For instance, adding a link of a new type in a page of the example document would make this link available in all the corresponding page instances. Example. Let s take the SEPIA planning space as an example to see how it can be defined with the tool. In the SEPIA planning space [25] there are two types of nodes: Issue and Position and four types of links: specialize, answer, suggest and contribute. An issue can be specialized into more concrete issues. A position answers an issue and may also suggest a new issue. The understanding of an issue may contribute to the understanding of another issue. Both Issue and Position type nodes are supposed to have flat contents without further nodes and links. To create an example with all of the above mentioned semantics, first a root node for this example document is created and its page type is named as Planning Space. Then in its content page four nodes and four links are created (see Figure 1). In order to express the linking semantics between nodes of the same type, more than one Issue type node is created. The first node of Issue type can be created with either the menu operation create node or a node creation gesture (drawing a box around the text for a node name). After the creation operation, the Issue node type is automatically put into the type palette. More nodes of issue type can then be pick-and-dropped from the palette to the current page. Similarly a link of a new type can be created either with the menu operation link to activated over a node or with a link creation gesture (drawing a line between two nodes). In the dialog raised in the node and link creation processes, the Issue and Position nodes are classified as organizational because their contents are logical parts of the planning space. The specialize link is classified as organizational because it has a structural constraint (acyclic). The contribute link is classified as referential because it has no structural constraints. Both Issue and Position type nodes have a page type of non-linking. This page type is defined by opening one of the four nodes and using menu operations to create some media objects (other than nodes and links), such as Text and Line, on the new page of the opened node. In order to help people understand the example, some anno- 116

6 Figure 2: Example of a Planning Space. tations are added on the page (e.g. the text node type connected via a line to the node type label in Figure 1). They are made for users of activity space instances to help them understand the semantics of the activity space (see next section). After the example is completed, instances of the planning space can be created either by assigning the Planning Space page type to a node in a node creation process. The look-and-feel of many hypertext documents, either typed or untyped ones, can be modeled with the tool. For instance, World-Wide-Web (WWW) documents can be modeled by first creating an untyped referential node, some text and graphic media objects on a page, and then defining the page type of the node recursively as the type of the page containing it. Similarly, KMS [1] documents can be modeled by creating one untyped referential node, one typed organizational node, and some media objects on a page. DOLPHIN documents can be modeled by creating two untyped nodes, one untyped link between the two nodes, and some media objects on a page. Intelligent Aid in Activity Spaces The annotated examples can help users understand the relationship among provided object types. The schema knowledge derived from the examples can be used by a computer to guide users of activity space instances. Whenever possible, constraints are turned into allowable choices in a given context, rather than allowing illegal actions to be attempted and then aborted. However, there are still situations when a violation can not be foreseen before an action is taken. For instance, an acyclic constraint can only be checked after an organizational link (or node) creation operation is submitted. In these situations a warning with explanations is given during automatic abortion of the operation. Tool Description. When an activity space browser is activated, it displays a blank page and a type palette with all pre-defined object types that are allowed to be used on the page (see the back window in Figure 2). When a new object is to be created with a menu selection or with a creation gesture, the allowed object types (if more than one) will be provided in a dialog box for users to choose (if there is only one, then the creation will be done without a dialog). A warning and explanation message will be given when no possible choice exists. When a new object is to be created from the type palette an explanation message will also be displayed if a structural or relational constraint is violated. The annotated example can be accessed by pressing a help button (see Figure 3, the help button is on the lower left corner, with a book icon and a question mark on it). When activated, a read-only browser presents the example page that corresponds to the page type of the current page displayed in the activity space browser. Users can then, if they want, navigate the node embedding structures of the example document. In the activity space browser, users can overwrite some attribute values that are not related to any of the three kinds of constraints, for instance, the attribute values for presentation styles or access rights, or switch back to their default values set during the definition of the type with the example-based definition tool. Examples. For instance, when a planning space browser is first launched, a blank page with a palette of all pre-defined 117

7 Figure 3: Automatic Preview of Choices. object types for its page type is presented on the user interface. Users can press a help button to see an example of the page. The example in the front browser is just the example document created with the example-based definition tool. In Figure 3, when a link is to be created with a creation gesture, the system provides two possible link types for users to choose from. Similarly, when the semantic net is to be expanded from a node with a menu operation expand, the system will provide choices of possible link and node type pairs for creating a node and a link in one step. The Flexible Space for Emergent Structures The flexible space supports the co-existence of a wide range of informal and formal information structures: from handwriting, drawings, text, untyped nodes and links, to typed nodes and links with or without constraints. The flexible space also supports transformation between these structures, for instance, from a text item to a heading of an untyped node, from an untyped node to a typed node, and from a node of one type to a node of another type. The flexible space takes a gradual evolutionary approach to create emergent structures. It allows users to draw from scratch with the possibility of reusing existing activity space instances. With the tool users can create objects of default types or copy objects of existing types first, and then change them with stepwise refinement until a desired pattern appears. This makes the tool simpler and faster with few dialogs for users to complete in each operation. When a good pattern emerges, users can ask the system to make it a schema. Tool Description. When a flexible space is first launched, the user interface displays a blank page with a blank palette. A default set of object types can be accessed with menu selections or gestures. The default node and link types in the flexible space are untyped nodes and links. Users can change them to typed ones with a retype menu operation activated upon them. After objects of new types are created, their graphical views can be seen on the current page and their types are added into the type palette. The object creation operations activated with a menu selection or a creation gesture may widen constraints. The object creation operations activated with the palette apply constraints. When a new node type is created, a default page type named as unpublished is attached to the node type, and this page type is not available for users to choose in subsequent node creation operations. Users can publish a page type for others to use by assigning it a unique name. After all page types in a document are published, the root page type of the document can be used to generate new activity space instances of this document type. Examples. Figure 4 shows the early stage when an emergent structure for project management is beginning to appear. At this stage, some less formal text items, graphics, untyped links and nodes are created for describing the activities and processes of a project. As shown in Figure 4, users are creating a new node from a text string End with a node creation gesture. At a later stage, nodes concerning tasks of the project are re-typed to task, and links concerning precedence dependencies between tasks are re-typed to precede by the users 118

8 Figure 4: Gradual Structure Transformation (1). using the retype menu operation. At this stage, an AON (activity on node) type project network diagram appeals, and users realize that it would be helpful if PERT/CPM semantics can be incorporated into the structure. With this emergent pattern as a specification and with the help of more experienced application system developers, the PERT/CPM computational semantics and their related attributes are added into the extensible method and attribute set of nodes and links. Users then can select and attach the computational semantics to the task nodes and precede links by using attaching computational semantics menu operation upon any one of task nodes and one of precede links. Finally, users realize that it would be helpful if project related information are also incorporated into the structure. Therefore, an exploration node type and an explore link type are defined for providing project related information. Figure 5 shows the emergent structure of a HyPERText space (hypertext with PERT semantics). In the HyPERText space, users can handle the creation and modification of the PERT network as easily as they handle other information needed for project management. When browsing the network, they can review a task description by displaying the content of a node; they can open a task node to see its sub-tasks; they can also trace links other than the precede links to see related information of a project (or projects). The critical path, the various time indications (such as those for duration and end date ), and the activity status (such as started and finished ) can be displayed and dynamically updated by the system on the user interface. With the computational semantics incorporated, the activity space goes beyond an ordinary typed hyperdocument to a useful interactive tool that can help people to get a job done. 1 IMPLEMENTATION The model and tools have been implemented with our COAST toolkit [20] in VisualWorks Smalltalk. In addition to normal class inheritance hierarchy, COAST can build a prototype inheritance hierarchy among the instances of a class. The activity space modeling made an extensive use of this mechanism. All hypertext modeling classes are subclasses of a prototype class, which has attributes of type, level, and prototype (a pointer to its prototype). A prototype is an initialized object that can be used as a template (type) for new objects [26]. New class instances, either prototypes (instances whose level attribute value is prototype ) or common instances (instances whose level attribute value is common ), only need to initialize those attributes whose values differ from the attribute values of their prototypes. The searching for an attribute value starts at a given level where the concerned instance is located in the prototype inheritance hierarchy and then goes to higher levels, until a valid value (not nil) is found. An instance at a lower level of the hierarchy may overwrite an inherited attribute value, or may switch back to its default inherited value by setting a nil value to it. Prototypes as Semantic Types In our implementation, objects of different media types are modeled as sub-classes of the abstract prototype class; while objects of different semantic types of the same media type are modeled as prototypes of the same class. A basic set of prototypes for each class is created with a primitive proto- 119

9 Figure 5: Gradual Structure Transformation (2). type editor by application system developers who understand the technical details of our object-oriented hypertext data model. In addition to common instances, the example-based definition tool and the flexible space create applicationspecific prototypes from existing prototypes. The activity space browser is provided to create common instances from chosen prototypes. It does not create any new prototypes. Prototype Inheritance for Constraints and Other Shared Behaviors In the example-based definition tool and the flexible space, some attributes are specified to be set at the nearest prototype level, so that their values can be shared by all common instances created from them. These attributes include 1) semantic type related attributes, such as type, 2) constraintrelated attributes, such as defaultpagetype for a node prototype, 3) presentation style-related attributes, such as color, and other attributes that need pre-defined default values such as accessrights. Constraints can be modified by adding or removing values in the constraint-related attribute value set and the presentation style can be changed globally by changing the corresponding style-related attribute values. This implements a kind of WYSIWYG style specification. In the activity space browser, all attributes (if allowed to be changed there) are specified to be set in common instances. Therefore, constraints defined in the prototypes will be enforced on all instances created with the activity space browser. Presentation styles can be changed in the activity space browser for a local effect, and can also be changed back to the default global style. Not all constraints can be represented and inherited through class hierarchies and prototype hierarchies. For instance, the DAG constraint checking is performed by traversing organizational links and organizational node embedding structures. Handling Schema Integration and Evolution A page prototype has an attribute allowedcomponenttypes whose value set contains all link, node, and media prototypes that are allowed to be used in the page instances defined by the page prototype. This set of prototypes is presented in the palette on the user interface. A page prototype has an attribute pointing to an example page from with which the page prototype is first defined with the example-based definition tool. With the flexible space and the example-based definition tool, when a set of objects is integrated from a page of one type into a page of another type with a copy operation, the prototypes of the set of objects will be copied and added into the value set of allowedcomponenttypes ; when two prototypes of the same class have the same type name, a dialog will be activated to decide whether to change one of the type names or to merge the two prototypes by merging their attribute values one after another. The copied common instances will be presented on the integrated page. If all the common instances of a prototype are removed from a page, then the prototype will be removed from the allowedcomponenttypes value set. The deletion of a prototype from the allowedcomponenttypes value set of a page prototype will not cause problems for its common instances that may exist in other page instances, because a prototype will not be finally removed from the system until the last common in- 120

10 stance of the prototype is removed. With the activity space browser, the object instance integration is only allowed between pages of the same type. Only the common instances are copied. All pre-defined prototypes and their attribute values will be kept intact, even if no common instances of an allowed prototype exist in a page. For new types of objects to be added to a page, the prototype of the page has to be modified first by editing its example page with the flexible space or the example-based definition tool. New classes of hypertext objects can be added into the class hierarchy by system developers. New basic prototypes can be added with the prototype editor. The example-based definition tool, the flexible space, and the activity space browser are implemented for end-users; while the prototype editor is designed for application system developers. CONCLUSIONS AND FUTURE WORK The COWFISH system is developed as a following up system of SEPIA. It builds on our experience with the SEPIA system and extends the SEPIA activity space concept into a meta-model of activity spaces for a wider range of tasks that can benefit from the flexibility and intuitive appeal of hypertext. Issue-based argumentive text, the focus of SEPIA, is now just an example of such applications. Some initial experiences have shown that using the system users can easily define the schemata of many activity spaces (such as the SEPIA activity spaces) and hyperdocuments (such as those in WWW and KMS as seening from their look-and-feel). Although we have not yet managed to do any controlled experiment with the prototype system, we believe that we have taken a promising approach to solve the identified problems on using and creating user-defined activity spaces. Because in general, writing a sample document with textual and graphical components is easier than making a description of a document type using formal languages or specifying it with lower level software tools. Also, a flexible space that supports an evolutionary approach to emergent structures can reduce the cognitive load in the activity space creation process. As shown in the given examples, COWFISH can use the schema knowledge to maintain the semantic consistency of the activity space instances and to provide users with context sensitive examples, choices, and explanations. Compared with many other systems, our approach is more comprehensive and has many new features. SEPIA [9, 25], gibis [4], and PHIDIAS [15] support pre-defined types created by system developers. Aquanet [13], OVAL [11], and MacWeb [16] use certain formal representations to allow knowledge structures to be defined by schema designers. The approach presented in this paper allows ordinary users to define document types simply by creating sample documents. DOLPHIN [7] supports the co-existence of and transformation among untyped informal and formal structures without constraints. This work extends it to support typed informal and formal structures with different degrees and combinations of constraints. HOS [22] uses textual analysis methods to support emergent structures. VIKI [14] can automatically detect emergent patterns in terms of the spatial configurations of visual symbols of typed objects (and/or collections). These emergent patterns are mainly for flexible information composition and user navigation. In COW- FISH, emergent patterns are created manually through gradual structure transformation and can be modified even when they are already used as schemata and have instances. Visual symbols can also be attached to objects for indicating their types. Related objects may be put or moved close to one another at the early stage when a pattern emerges, while at the late stage, if needed, more detailed relationship and constraints can be specified explicitly. Trellis uses a Petri-net for specifying hypertext navigational semantics [23] and for visual programing [5]. COWFISH tries to support the coexistence and transformation of hypertext objects with or without task-specific computational semantics. The reports on user experiences with typed nodes and links are mixed with conflicting results, many of which are not encouraging [14, 27]. One reason might be that in many systems users have gained little from the typed nodes and links in comparison to the effort they made to assign types to them. To use the typing knowledge for guiding the use and creation of typed information spaces is one way that may make the typing effort more rewarding. For activity spaces, a more important step is to incorporate task-specific computational semantics into hypertext object types, so as to make them useful tools that can do something for people to get their job done. Semantic types in most hypertext systems are used as visual aid in user interaction or as extra knowledge for system guided navigation. The ability to extensively exploit semantic typing for maintaining composition consistency, providing guidance for using and creating activity spaces, and especially, applying task-specific computational semantics is a distinct feature of COWFISH. In addition to provide the tools for users to create their own activity spaces, we are currently working on enlarging the set of ready-made task-specific activity spaces as basic building blocks for users to use or reuse. And we are also preparing more ready-made computational semantics for users to select and attach on hypertext objects. One of such computational semantics is workflow semantics [6] which can turn the task-specific activity spaces into a well-defined and wellcoordinated collaborative working process. There are still many open questions on activity space merging and transformation. Compared with structural and relational semantics, computational semantics is harder to incorporate, since this often requires some sort of programming skills. Next, we plan to further explore activity space merging and transformation, and to develop easier methods and tools for users to incorporate and assign task-specific computational semantics. We also plan to do some experimental studies on real users using the system. 121

11 ACKNOWLEDGEMENTS We would like to thank Ajit Bapat, Jörg Geißler, Anja Haake, David Hicks, Thomas Knopik, Yongwu Miao, Christian Schuckmann, Wolfgang Schuler, Norbert Streitz, and Daniel Tietze for their valuable comments and discussions. Special thanks are also due to Till Schümmer for implementing the prototype mechanism in the COAST toolkit. REFERENCES 1. R. Akscyn, D. McCracken, and E. Yoder. KMS: A distributed hypermedia system for managing knowledge in organizations. Communications of the ACM, 31, 7, pages , G. Collier. Thoth-II: Hypertext with explicit semantics. Hypertext 87, pages , J. Conklin. Hypertext: An introduction and survey. Computer, 20, 9, pages 17 41, September J. Conklin and M. Begeman. gibis: A hypertext tool for exploratory policy discussion. ACM Transactions on Office Information Systems, 6, 4, pages , R. Furuta and D. Stotts. Dynamic hyperdocuments: Authoring replaces programming. Special Issue on Hypermedia Design, Communication of the ACM, August D. Georgakopoulos, M. Hornick, and A. Sheth. An overview of workflow management: From process modeling to wrokflow automation infrastructure. Distributed and Parallel Databases, 3, pages , J. Haake, C. Neuwirth, and N. Streitz. Coexistence and transformation of informal and formal structures: Requirements for more flexible hypermedia systems. In Proceedings ACM European Conference on Hypertext Technology, pages 1 12, Edinburgh, F. Halasz and M. Schwartz. The dexter hypertext reference model. Communications of the ACM, 37, 2, pages 30 39, February T. Knopik and A. Bapat. The role of node and link types in open hypermedia systems. In Proceedings of the ECHT 94 Workshop on Open Hypermedia Systems, pages 33 36, Edinburgh, Scotland,, September F. W. Lehmann. Semantic networks. In F. W. Lehmann, editor, Semantic Networks in Artificial Intelligence, pages Pergamon Press Ltd, T. Malone, K. Lai, and C. Fry. Experiments with oval: A radically tailorable tool for cooperative work. In Proceedings of ACM CSCW 92, pages , Toronto, Canada, Oct Nov C Marshall and R Rogers. Two years before the mist: Experiences with aquanet. In Proceedings of the Fourth ACM Conference on Hypertext, Experiences, pages 53 62, C. C. Marshall, F. Halasz, R. A. Rogers, and W. C. Janssen, Jr. Aquanet: A hypertext tool to hold your knowledge in place. In Proceedings of ACM Hypertext 91, C. C. Marshall, F. Shipman, and J. Coombs. VIKI: Spatial hypertext supporting emergent structure. In Proceedings of the ECHT 94 European Conference on Hypermedia Technologies, Papers, pages 13 23, R. McCall, P. Bennett, P. D Oronzio, J. Ostwald, F. Shipman, and N. Wallace. PHIDIAS: Integrating CAD graphics into dynamic hypertext. In Proceedings of the ECHT 90 European Conference on Hypertext, Argumentation, Design and Knowledge Acquisition, pages , J. Nanard and M. Nanard. Using structured types to incorporate knowledge in hypertext. In Proceedings of ACM Hypertext 91, Hypertext Integrative Issues, pages , J. Nanard and M. Nanard. Should anchors be typed too? an experiment with macweb. In Proceedings of ACM Hypertext 93, Papers, pages 51 62, International Standards Organization. Information Processing Text and Office Systems Standard Generalized Markup Language (SGML). ISO 8879, Geneva, October D. M. Russell, M. J. Stefik, P. Pirolli, and S. K. Card. The cost structure of sensemaking. In Proceedings of ACM INTERCHI 93 Conference on Human Factors in Computing Systems, Conceptual Analysis of Users and Activity, pages , C. Schuckmann, J. Schümmer, L. Kirchner, and J. Haake. Designing object-oriented synchronours groupware with COAST. In Proceedings of ACM CSCW 96 Conference (to appear), Boston, W. Schuler and J. B. Smith. Author s argumentation assistant (AAA): A hypertext-based authoring tool for argumentative texts. In Proceedings of the ECHT 90 European Conference on Hypertext, Argumentation, Design and Knowledge Acquisition, pages , F. Shipman and R. McCall. Supporting knowledgebase evolution with incremental formalization. In Proceedings of CHI 94, pages , Boston, Mass., Apr

12 23. P. D. Stotts and R. Furuta. Petri-net based hypertext: Document structure with browsing semantics. ACM Transactions on Office Information Systems, 7, 1, pages 3 29, N. Streitz, J. Geißler, J. Haake, and J. Hol. DOL- PHIN: Integrated meeting support across local and remote desktop environments and liveboards. In Proceedings of ACM CSCW 94, pages , Chapel Hill, N.C., U.S.A, October N. Streitz, J. Haake, J. Hannemann, A. Lemke, W. Schuler, H. Schutt, and M. Thüring. SEPIA: A cooperative hypermedia authoring environment. In Proceedings of the Fourth ACM Conference on Hypertext, pages 11 22, E. Tyugu. Three new-generation software environments. Communications of the ACM, 34, 6, pages 46 59, W. Wang and R. Rada. Experiences with semantic netbased hypermedia. International Journal of Human- Computer Studies, 43, pages , J. D. Wiest and F. K. Levy. A Management Guide to PERT/CPM. Prentice-hall, New Jersey,