sparce: superimposed pluggable architecture for...

SPARCE: Superimposed Pluggable Architecture for Contexts and Excerpts

Sudarshan Murthy, David MaierDepartment of CSE, OGI School of Science & Engineering at OHSU

{smurthy, maier}@cse.ogi.edu

May 5, 2003

AbstractPeople often impose new interpretations onto existing information. In the process, they work with

information in two layers: A base layer, where the original information resides, and a superimposed layer, where only the new interpretations reside. Referring to base information in this manner reduces redundancy and preserves context. Superimposed information management (managing layered information) preserves these layers of information. It facilitates superimposed applications in which people can interact with heterogeneous information sources.

Superimposed application developers like to interact with base layers using a common interface regardless of base-layer types or access protocols. Also, users like to perform operations such as navigation and querying with any base layer. Unfortunately, base layers differ in their support for these operations. Appropriate architectural abstractions placed between these layers can ease communication between the two layers and make up for some of the deficiencies of base layers. They can also allow independent evolution of components in these layers.

An architecture called SLIM (Superimposed Layer Information Management) has already been defined to demarcate and revisit information inside base layers. However, some superimposed applications need to do more; they also need to access content and context of information inside base layers. We have defined a successor to SLIM, called SPARCE (Superimposed Pluggable Architecture for Contexts and Excerpts), for this purpose. In this paper, we describe the goals, design and implementation of SPARCE. We also present results of evaluating SPARCE.

Keywords: Information modeling, superimposed information, software architecture, hypertext, compound documents, excerpts, context, SLIM, SPARCE.

1. Motivation and IntroductionThe United States Department of Agriculture, Forest Service (USFS) routinely makes decisions to

solve (or prevent) problems concerning forests. The public may appeal any USFS decision [6]. The appeal process begins when an appellant sends in an appeal letter. An appeal letter raises issues with a USFS decision and the decision-making process. It frequently cites documents such as the Decision Notice (DN) and Environmental Assessment (EA). A USFS Editor processes all appeal letters pertaining to a decision and prepares an appeal packet for a reviewing officer. An appeal packet contains all documents a reviewing officer might need to recommend a decision about issues raised in appeal letters. The RID letter (RID stands for Records, Information, Documentation) is one of the documents in an appeal packet. This letter lists the issues raised in appeal letters and a summary response for each issue. An Editor synthesizes a RID letter using information in documents such as the DN, EA, and specialists’ reports. In this letter, the editor presents information from other documents in a variety of forms such as excerpts, summaries, and commentaries. In addition, the editor documents the location and identity of the information sources used in synthesizing the letter.

Composing a RID letter requires an editor to maintain large working sets. Since it is not unusual for an editor to be charged with preparing appeal packets for several decisions simultaneously, the editor may need to maintain several threads of organization. Though using documents in electronic form can be helpful, such use does not necessarily alleviate all problems. For example, the editor still needs to


document the identity and location of information. In using electronic documents, the editor has to cope with multiple document windows open at once. Also, locating information in large documents can be tedious (using traditional search utilities available in applications).

We hypothesize that the USFS appeal process (and similar processes in other domains) can benefit from superimposed information management. Superimposed information is information placed over existing sources (called base layers). Word-processor documents, spreadsheets, presentations, databases, and web pages are examples of base layers. Delcambre and others [8] have described the Superimposed Layer Information Management architecture (SLIM) to manage superimposed information. SLIM facilitates addressing of information inside base layers, but it does not facilitate retrieval of content or context from base layers. Some superimposed applications (such as those that might be developed to assist in preparation of RID letters) need such information.

We have defined the Superimposed Pluggable Architecture for Contexts and Excerpts (SPARCE) to allow access to content and context information in base layers. We have built two applications—RIDPad and Schematics Browser—to exercise this new architecture. RIDPad is intended to assist a USFS editor to collect and organize material to prepare RID letters. The Schematics Browser allows USFS personnel to view past appeal decisions as instances of entities and relationships in a structured data model. In this paper, we describe the goals for SPARCE, its design and implementation, and the two SPARCE applications. We also present results of architecture evaluation.

The rest of this paper is organized as follows: Section 2 gives an overview of superimposed information and SLIM. Section 3 demonstrates the need for excerpts and contexts. In Section 4 we describe the goals, design, and an implementation of SPARCE. In Section 5 we describe two SPARCE applications and present results of evaluating SPARCE. We present related work, future work, and a summary in Sections 6, 7, and 8 respectively.

2. Superimposed Information and ApplicationsMaier and Delcambre [11] define superimposed information as “data placed over existing information

sources to help organize, access, connect and reuse information elements in those sources.” They call existing information sources base layers, and data placed over the base layers the superimposed layer. Figure 1 shows these two layers of information. An application that manipulates base information is called a base application; an application that manipulates superimposed information is called a superimposed application.

Maier and Delcambre note that superimposed information has been used since before the advent of computers (for example, concordances and commentaries), but that there is a new need to reexamine this concept in the electronic setting. Improved addressability and accessibility of base layers, and increased digitization of information are some reasons for the renewed interest.

The rest of this section briefly describes an earlier architecture and application for superimposed information management. Complete details are available in the work of Delcambre, Maier, and others [7, 8, 11].

2.1 SLIM and SLIMPadDelcambre and others [8] have defined an architecture called Superimposed Layer Information

Management (SLIM) for management of superimposed information and applications that use it. SLIM defines an abstraction called a mark to represent an occurrence of information inside base layer. Figure 1 shows how a superimposed layer uses marks to address base information. This figure is adapted from a description of SLIM [8].

Marks provide a uniform interface to address base information, regardless of base-layer type or access protocol. Several mark implementations, typically one per base-layer type, exist in SLIM. A mark implementation decides the addressing scheme appropriate to the base layer it supports. For example, a mark for a

of 14


selection in a spreadsheet might contain the row and column numbers for the first and last cell in the selection, whereas a mark for a selection in an XML document might contain an XLink.

Figure 1: Marks in SLIM architecture. Figure 2: SLIM reference model.

Superimposed applications may represent superimposed information in any model, regardless of the base-layer types they interact with. They only need to store IDs of marks, which they can exchange for mark objects (from a Mark Management module as we will see shortly). Superimposed applications work seamlessly with any base-layer type due to the uniform interface supported by all marks.

Figure 2 shows a reference model for SLIM as a UML Conceptual Diagram. The Mark Management module (subsystem) is responsible for creating and storing marks, retrieving marks (given a mark ID), and for navigating back to the base layer. The Superimposed Information Management module provides storage service to superimposed applications. Use of this module is optional. The Clipboard is used for inter-process communication (at mark creation time).

SLIMPad is a superimposed application that employs SLIM. It allows users to create marks in a variety of base layers and paste them as scraps in a SLIMPad document. Scraps are superimposed information elements associated with a mark ID and a label. Users can also create bundles, which are named groups of scraps and other bundles. Figure 3 shows a SLIMPad document. The rectangles within the workspace denote bundles. The first label inside a bundle (left, top corner of the bundle) is its name. Other contents of the workspace are scraps. A user can activate (double click) a scrap to return to the corresponding base layer. Figure 3: A SLIMPad document.

2.2 Limitations of SLIMMark management in SLIM consists of mark creation, retrieval, and resolution (navigation)

operations. These operations are necessary, but not sufficient for superimposed applications such as those we envision for the USFS appeal process. As we will show in Sections 3 and 4, users sometimes like to see contents and context of a mark (such as the containing paragraph and section heading), from within a superimposed application. SLIM does not support these operations.

The SLIM implementation also has some packaging and deployment limitations. For example, the mark management module must run within the process of any superimposed application. As a result, several instances of the mark management module may be loaded at once (one for each instance of a superimposed application) even though one instance would suffice.

Some usability issues also exist in SLIM implementation. For example, the mark creation process is modal. That is, a user must create a scrap immediately after creating a mark in a base layer. This limitation is mainly due to the way SLIM uses the shared Clipboard service. The USFS editors we have

of 14

interacted with would like to create multiple marks in a base layer, without having to use them immediately. Our representative users have also asked for new facilities (such as reusing marks) in superimposed applications. Providing some of these facilities requires new architecture and application capabilities.

3. Excerpts and ContextsAn Excerpt is the content of a marked base-layer element. An excerpt can be of various types. For

example it may be plain text, formatted text, or an image. An excerpt of one type could be transformed into other types. For example, formatted text in a word processor could also be seen as plain text, or as a graphical image. Context is information concerning a base-layer element. Presentation information such as font name and color are examples of context. Information such as the containing paragraph and section heading are also examples of context. Because we use the same mechanism to support both excerpts and contexts, we will often use the term “context” to refer to both kinds of information about a mark.

3.1 Need for excerpts and contextsA USFS editor excerpts contents from base layers in the process of preparing a RID letter. In addition,

the editor sometimes examines features related to excerpts. For example, the editor may want to determine the heading of the section an excerpt is in or examine the information (such as previous or next sentence) surrounding an excerpt in the base layer. USFS editors would like to see both excerpts and contexts from within a superimposed application.

Fulfilling some user needs might require superimposed applications to access context information that a user might not explicitly access. We demonstrate such needs using an example. We have noted some variations in how editors use excerpts in RID letters. An editor sometimes reproduces excerpts exactly as they are in base layers. At other times, the editor retains only parts of the original formatting, or no formatting at all. Compliance with documentation guidelines, consistency, and personal preferences are some of the factors that influence the choice. The need to display an excerpt (formatted exactly or partly as in its base layer), requires a superimposed application to examine the excerpt’s context.

Consider the fragment of a web page as displayed by a web browser shown in Figure 4(a). The highlighted portion of the fragment is the marked region. Figure 4(b) shows three possible HTML markups corresponding to the marked region. The first markup specifies the font name and size, the second markup specifies only the font size, and the third markup does not specify any font characteristic. Font characteristics not specified are inherited from an enclosing element (transitively) in the second and third markups. If no enclosing element specifies the necessary font characteristic, the web browser uses a default value, possibly from an application setting. That is, a superimposed application might need to examine markup all the way up to the start of the web page, or even examine an application setting to display the marked region.

Cheatgrass, Bromus tectorum, grows near many caves in this project area.

Cheatgrass, Bromus tectorum, grows near many caves in this project area.

Cheatgrass, Bromus tectorum, grows near many caves in this project area.

(a) Web-page fragment. (b) Three possible HTML markups for the marked region.

Figure 4: A fragment of a web page and some possible markups.

of 14


3.2 Architectural considerations in supporting excerpts and contexts We observe that several kinds of context are possible for a mark. The following is a representative list

of context kinds along with examples for each kind. We also note that the context of a mark may include elements of many kinds.

Content: Text, graphics. Presentation: Font name, color. Placement: Line number, section. Sub-structure: Rows, sentences. Topology: Next sentence, next paragraph. Container: Containing paragraph, document. Application: Options, preferences.

Contexts can vary across base-layer types. For example, the context of a mark to a region on a painting (in a graphics-format base layer) includes background color and foreground color, but it does not include font name. However, the context of a mark to a selection in a web page includes all these three elements. Contexts can also vary between marks of the same base-layer type. For example, an MS Word mark to text situated inside a table may have a “column heading,” but a Word mark to text not situated in a table does not include that kind of context. Lastly, the context of a mark itself may change with time. For example, the context of a mark to a figure inside a document includes a “caption” only as long as a caption is attached to that figure.

Thus, architecture to manage excerpts and contexts must support a variety of excerpt types, variety of contexts among and within base-layer types, and the variable context of a mark. In addition, we predict that superimposed application developers prefer a uniform interface to context of any base-layer element. We predict this preference from our experience in architecture design in general, and that of our colleagues (specifically with mark management in SLIM).

4. SPARCEWe have designed and implemented the Superimposed Pluggable Architecture for Contexts and

Excerpts (SPARCE) to facilitate mark and context management. The desirable qualities1 of SPARCE are:

Functionality: Manage marks, contexts, and excerpts. Reusability: Many superimposed applications must be able to use the same SPARCE implementation.

More than one superimposed application must be able to run simultaneously on the same computer, and be able to interact with multiple base layers.

Modifiability: We must be able to improve SPARCE and its applications independently with minimal affect on each other.

Extensibility: We must be able to support new base-layer types and context elements without affecting existing applications.

Usability: The implementation must use familiar metaphors, and follow relevant development and user-interface conventions. It must also aid usability of applications developed.

Package flexibility: We must be able to customize deployment units (process packaging) to meet application and user needs.

Testability: The implementation must aid verification and validation of itself, and that of its applications.

The reference model for SPARCE is derived from the model for SLIM (shown in Figure 2). Figure 5 shows the SPARCE reference model as a UML Conceptual Diagram. The Context Management module is the major addition to the model. Superimposed applications depend on this module to obtain the

1 An overview of qualities of software architectures is available in the work of Bass and others [Bass 1998].

of 14


context of a mark. This module depends on Mark Management module to locate information inside base layers. It then interacts with base layers to determine contexts.

The Clipboard module is similar to the Clipboard in operating systems such as Macintosh and MS Windows. An implementation might just reuse the available Clipboard object or emulate a clipboard using a shared data structure. SPARCE differs subtly from SLIM in its use of the Clipboard. SLIM does not utilize a base application’s ability to copy information to the Clipboard, but SPARCE does. This change improves usability in some cases (as illustrated in Section 4.1).

Figure 5: SPARCE reference model. Figure 6: Two mark creation scenarios.

The Superimposed Application, Mark Management, and Superimposed Information Management modules function just as they do in SLIM. SPARCE reuses the Superimposed Information Management module of SLIM to provide storage service to superimposed applications. Consequently, we do not describe that module in this paper. In the remainder of this section, we describe the design of other modules of SPARCE and their implementation.

4.1 Mark managementThe Mark Management module supports three operations for marks: creation, retrieval, and resolution.

Mark creation is the operation of generating a new mark corresponding to a selection in a base layer and storing the mark in a repository. The retrieval operation returns a mark from the mark repository. Resolution is the operation of navigating to a location inside the base layer. Mark creation is the most complex of these operations due to a variety of creation means and base application constraints. Consequently, we dedicate the rest of this sub-section to that operation.

The mark creation process consists of two steps: generating the address of base information (and other auxiliary information), and using the information generated to create a mark object in the mark repository. The information generated in the first step is called mark fodder. The address contained in mark fodder depends on the addressing mechanism needed to support the base-layer type. For example, the fodder for a mark to information inside a PDF document contains the starting and ending word indexes; the fodder for a mark to a selection in a spreadsheet contains the row and column numbers for the first and last cell in the selection.

There are many possible scenarios for creation of marks, but we describe only two due to space constraints. Figure 6 depicts the two scenarios in a UML Use Case Diagram. The boxes in the figure denote system boundaries. The broken arrows denote object flows. In both the scenarios depicted, a user starts mark creation in a base application and completes it in a superimposed application. The superimposed application in which the user completes mark creation retrieves the mark fodder from the Clipboard, and passes it to the Mark Management module. The Mark Manager creates a mark object from the fodder. It assigns a unique ID to the mark object and stores it in the mark repository.

The Copy use case in Figure 6 demonstrates an ideal scenario. Ideally, a user should be able to select base information in a preferred base application, copy it to the Clipboard, and complete mark creation in a superimposed application. This scenario is ideal because it does not require the user to learn any new application, tool, or process to create marks. However, supporting this scenario requires cooperative base

of 14


applications: base applications must either copy sufficient information to the Clipboard (to generate mark fodder), or they should allow other applications to hook into the copy process. Microsoft Word and Excel [13] are examples of such cooperative applications.

Some base applications do not facilitate tapping into Clipboard operations, but they might provide mechanisms (such as plug-ins or add-ins) to extend their environments. A special mark creation tool can be inserted in to the user interface of such an application. The user operates this special tool to copy mark fodder to the Clipboard, and then completes mark creation in a superimposed application (as in the first scenario). The Mark use case in Figure 6 demonstrates this scenario. Early versions of Adobe Acrobat and Netscape Navigator are examples of base applications in this category.

4.2 Context managementSPARCE uses a set of classes and interfaces for context management. Figure 7 shows them in a UML

class diagram. Table 1 provides a brief description of the classes and interfaces.

SPARCE supports context retrieval for three classes of objects: marks, containers, and applications. SPARCE uses the classes Mark, Container, and Application respectively to model these elements. A Container is an abstraction for a base document (or a portion of that document). An Application is an abstraction for a base application. SPARCE also defines the interface Context-Aware Object to any base-layer element that supports context. The classes Mark, Container, and Application implement this interface.

As we mention in Section 3.2, architecture for contexts must accommodate the variety of contexts both across and within base layers. Also, the context of any base-layer element must be accessible through a common interface. SPARCE fulfils these requirements by treating context as a property set (a collection of name-value pairs). In SPARCE, context is the entire set of properties of a base-layer element and a context element is any one property. For example, the text excerpt and font name of a mark are context elements. SPARCE uses the class Context to model a property set and the class Context Element to model a property. Figure 7: Classes and interfaces for context management.

The class SPARCE Manager is at the root of SPARCE. It maintains a repository of marks. Superimposed applications use this class to create new marks from mark fodder, and to retrieve existing marks. This class can also provide information about containers and applications where marks are made.

The interface Context Agent helps SPARCE achieve its extensibility goal. A class that implements this interface takes a context-aware object and returns its context. That is, SPARCE does not access base-layer elements or their contexts directly. It uses external agents to do so on its behalf. However, SPARCE is responsible for associating a context-aware object with an appropriate context agent. SPARCE obtains the name of the class that will be the context agent for a mark from the fodder used to create the mark. The same agent is used to retrieve context for the mark’s container and application2. SPARCE instantiates the

2 Sharing the same agent can reduce development time because the code needed to retrieve context of a mark, its container, and its application tend to be similar.

of 14


context agent class by name whenever a superimposed application accesses the context of a context-aware object.

Class/Interface Description

Mark A mark to base-layer information.

Container The base document (or a portion of document) in which a mark is made.

Application The base application in which a mark is made.

Context-Aware Object (interface)

Interface to any base-layer element that is able to provide its context. The classes Mark, Container, and Application implement this interface.

Context The context of a context-aware object. It is a collection of context elements.

Context Element A single piece of context information about a context-aware object.

Context Agent (interface) Interface to any base-layer. An implementation will retrieve context from a context-aware object. There is usually one implementation per base-layer type.

SPARCE Manager Creates, stores, and retrieves marks; associates context-aware objects with appropriate context agents.

Word Agent The context agent for MS Word.

PDF Agent The context agent for Adobe Acrobat.

Table 1: Classes and interfaces for context management.

4.3 ImplementationWe have implemented SPARCE for Microsoft Windows operating systems. The implementation

currently includes support for the following base applications: MS Word, MS Excel, and Adobe Acrobat (PDF files). The agents for these base applications support the following kinds of context: content, presentation, containment, placement, sub-structure, topology, document, and application.

We used the following tools to implement SPARCE and support the base applications mentioned above: MS Visual Studio 6 (C++ and Visual Basic), MS XML Parser 4.0, MS Office XP, and Adobe Acrobat 5 SDK. We used ActiveX technology [12] to implement the classes in Figure 7.

In addition to implementing the classes shown in Figure 7, we have also implemented the following reusable view facilities. All these facilities, except the Clipboard Viewer, are superimposed applications.

Context Browser: A window that displays the current context of a context-aware object. Context Viewer: A window that displays the value of one context element of a context-aware object. Clipboard Viewer: A window that lists mark fodders (available on the Clipboard) that could be used

to create new marks. With this facility, users can start many instances of the mark creation process in base layers, and complete those instances later in one or more superimposed applications (as described in Section 4.1).

Property Pages: Tabbed windows to display properties of existing context-aware objects. Selection Dialogs: Dialog windows to select existing context-aware objects. For example, a dialog

can be used to select a mark already in the marks repository for reuse in a superimposed application.

Package Type Package Type

Mark and context management ActiveX EXE Context Browser and Viewers ActiveX DLL

Mark fodder generation and Clipboard monitoring ActiveX EXE Adobe Acrobat plug-in Regular DLL

Clipboard Viewer ActiveX DLL MS Office and PDF context agents ActiveX DLL

Clipboard access helpers Regular DLL MS Office add-in ActiveX DLL

Table 2: SPARCE packages.

of 14


The implementation resulted in eight physical packages (deployment units or process packages). Table 2 lists the packages and their types. ActiveX EXE servers run out of process, whereas ActiveX DLL servers and regular DLLs both run within a process. We note that the packaging shown in Table 2 might need to be changed based on deployment and application needs. We mention some packaging considerations in Section 5.3.

4.4 Supporting new base-layer types and contextsThe SPARCE implementation includes the infrastructure needed to interact with any base-layer type.

Enabling support for a new base-layer type is as easy as following the five steps shown below.

1. Study the base layer to understand support for marking. This study should include understanding the addressing scheme for the base layer.

2. Decide which mark creation scenarios to support.3. Implement mark fodder generation. Mark fodder generation is done when mark fodder is copied to

the Clipboard. 4. Decide what context elements to support.5. Implement a context agent for the base layer. The context agent must be packaged in an ActiveX

server and registered with the operating system for the current SPARCE implementation.

We have also implemented some testing aids. A context agent that does nothing is included so that the development process can be incremental. We recommend using this agent until Step 3 is completed successfully. This proxy agent can be later replaced with the agent developed in Step 5. We have also included a superimposed application (presented in Section 5.1) that can be used to test support for new base-layer types. This application can display properties and contexts of any context-aware object.

Changing the context elements supported for a base-layer type only requires changing the property set population in its context agent. We note that adding support for new base-layer types or changing context elements supported does not require any change (or recompilation) to the SPARCE implementation or superimposed applications. However, the context agent will need compilation.

5. EvaluationWe have evaluated SPARCE by implementing it and by building superimposed applications to use

that implementation. We have also added support for a few popular base-layer types. Table 3 shows the procedure we followed to evaluate SPARCE. The table also shows the qualities each step was aimed at evaluating. The qualities desirable in SPARCE are described in Section 4.

We have already described the implementation of SPARCE in Section 4.3. In the remainder of this section we describe the superimposed applications we have developed and the results of evaluation of SPARCE.

Evaluation Step Qualities Evaluated

Implement SPARCE, support one base-layer type (MS Word) Functionality, usability

Implement one superimposed application (RIDPad) Functionality, usability

Support new base-layer types and new context elements (MS Excel, Adobe Acrobat)

Modifiability, reusability, extensibility

Implement viewers Functionality, usability, reusability, testability

Implement second superimposed application (Schematics Browser) Functionality, reusability

Change deployment scenarios Package flexibility

Table 3: Evaluation procedure.

of 14


5.1 RIDPadRIDPad is a superimposed application for the USFS appeal process (described in Section 1). A USFS

editor can use this application to collect and organize information needed to prepare a RID letter. A RIDPad instance is a collection of items and groups. An item is a superimposed information element associated with a mark. It has a name and a description. The name is user-defined and the description is the text excerpt from the associated mark. A group is a convenient collection of items and other groups. RIDPad uses a simple information model to store mark IDs and text excerpts.

Figure 8(a) shows a RIDPad instance with information concerning the “Road 18 Caves” decision (taken in the Pacific Northwest Region of USFS). The instance shown has eight items in four groups. The group titled “Environmental Assessment” contains two groups. The information in the instance shown comes from three distinct base documents in two different base applications. (The item labeled “Comparison of Issues” contains an MS Excel mark; all other items contain MS Word marks.) All items were created using base-layer support included in the implementation of SPARCE.

(a) A RIDPad instance (b) A mark resolved to its base layer. (c) Context of a mark.

Figure 8: A RIDPad instance, a base layer, and the Context Browser.

RIDPad affords many operations for items and groups. A user can create new items and groups, and move items between groups. The user can also rename, resize, and change visual characteristics such as color and font for items and groups. With the mark associated with an item, the user can examine its properties and browse its context from within RIDPad. The user can navigate to the base layer if necessary. When examining context, the user can copy a context element’s value to the Clipboard and paste it into other applications. For example, a USFS editor can copy information to a RID letter being composed in a word processor. (We are in the process of developing an application to build RID letters based on RIDPad instances.) Figure 8(b) shows the base layer opened for the mark associated with the item titled “FONSI.” The highlighted region corresponds to the mark. Figure 8(c) shows the context browser for the same mark. On the right, the browser shows the text of the mark with full formatting. The hierarchy of the mark’s context is displayed to the left.

5.2 Schematics BrowserAppeal letters from different appellants in the USFS appeal process tend to share features. They all

contain appellant names and addresses, refer to a DN, and raise issues. Such similarities suggest a schema for appeal letters. A superimposed schematic is a schema superimposed over base information in a model similar to the Entity-Relation model [4]. The Schematics Browser is a superimposed application developed by our colleague Shawn Bowers to demonstrate the use of superimposed schematics. We altered this application to use SPARCE to access base layers. We also enhanced this application so a user can view contexts of base-layer elements.

of 14


The Schematics Browser lists superimposed schematics and allows a user to browse an instance of a selected schematic. (At present this application does not support creation of new schematic instances.) Entities and attributes in a schematic instance may be distributed over any number of base layers. Marks can be associated with entities and attributes. The Browser stores mark IDs and other information related to schematic instances in a relational database.

Figure 9 shows an instance of a USFS appeal decision (decision on issues raised in appeals) schematic opened in the Schematics Browser. The numbered circles in the figure are annotations used to describe the figure and not part of the interface itself. Window 1 lists instances of the appeal decision schematic. Window 2 displays the schematic instance selected in Window 1. Window 3 displays details of an entity instance.

Figure 9: Schematics Browser.

The “1997 Ranch House Timber Sale” appeal decision schematic instance is shown in Window 2. Although a single schematic instance is displayed in this window (and we are able to browse information as if it comes from a single source), we note that the information currently displayed in Window 3 comes from three distinct base documents. The Issue entity is currently selected in Window 2 and the details of the first Issue entity is displayed in Window 3. The attribute desc in Window 3 is the description of the issue. It has a mark associated with it (indicated by a line under the attribute name). When an entity or an attribute has a mark associated, a user can either visit the base layer or choose to see the context from within the Browser.

5.3 ResultsWe have both qualitative and quantitative results of evaluation of SPARCE. We first present the

qualitative results which show that SPARCE has the desirable qualities we listed in Section 4. We then present some quantitative results that provide a measure of time to develop superimposed applications and support new base-layer types.

Functionality and reusability: The SPARCE implementation allows superimposed applications to access base-layer elements and their contexts across a variety of base-layer types. We have implemented two superimposed applications using the SPARCE implementation. We did not make any changes in the SPARCE implementation specifically for either of these applications. We have been able to run both superimposed applications simultaneously on the same computer.

Modifiability and extensibility: We have been able to modify the SPARCE implementation, the two applications, and the various context agents independently of each other. Upon modification, we have only recompiled the source code for the package modified. That is, we have been able to evolve components of SPARCE and its applications independently. We have added support for new base-layer types and context elements without affecting existing applications or the SPARCE implementation. We have successfully followed the process outlined in Section 4.4 to support new base-layer types.

Usability: The mark creation process requires users to perform only operations that are familiar and natural to them. Also, the mark creation process is similar across base-layer types. The process is non-modal, and it allows users to create many marks in base layers before using them. The Context Browser and Viewers use simple and familiar user-interface elements. The same is true for the Clipboard Viewer. We predict that a user familiar with one superimposed application will not need much learning to use other superimposed applications (if the display services are reused). Ease of development of superimposed applications is also a measure of usability of the architecture implementation. We have

of 14

1

2

3


observed that operations with marks and contexts are usually done with a few lines of code (between three and eight lines of code in MS Visual Basic).

Package flexibility: Any of the ActiveX servers listed in Table 2 (Section 4.3) can be implemented as an in-process or an out-of-process server. We have verified that reconfiguring packages in this manner does not affect the functionality of SPARCE or its applications. However, we caution that it is important to clearly understand the effect of making such changes. For example, speed of performance is better when operations are performed within a process. However, operations performed outside a process provide resilience to both processes involved (one process aborting does not affect the other). Instantiating a class on a remote computer implicitly requires an out-of-process server. Lastly, the patterns of usage and the technology used to implement the services should be considered in packaging.

Testability: The reusable view facilities (listed in Section 4.3) serve as testing aids for superimposed application developers and users. The do-nothing context agent (explained in Section 4.4) and RIDPad are both testing aids when adding support for new base-layer types. We have not described the testability of the SPARCE implementation itself in this paper due to space constraints.

We have some statistics that give a feeling for the time to develop superimposed applications and to add support for new base-layer types. We developed the RIDPad application in approximately 30 hours. We altered the existing Schematics Browser in approximately six hours to use SPARCE. We added support for MS Word and Excel in about 7 hours combined. We added support for Adobe Acrobat in about 12 hours (of which six hours were spent in exploring alternatives and understanding the Acrobat SDK).

We realize our evaluation process is mostly qualitative. As a result, our results and conclusions have an air of subjectivity. Nevertheless, our observations of the behavior of the SPARCE implementation and its applications show that we have successfully met our goals. With SPARCE, we feel that superimposed application developers will be able to focus mostly on their application needs. We feel similarly about adding support for new base-layer types.

6. Related workVisions of imposing new interpretations onto existing information existed decades ago. Vannevar

Bush hypothesized that due to advancements (after 1945) in the field of photocells, microfilms, and photography, researchers would be able to easily record their observations [5]. He also hypothesized that being able to record easily would increase the volume of scientific records and that there must be an efficient means of consulting them. He posited Memex, an imaginary device to store and consult information efficiently. Memex offers the following features to organize information: browsing, navigation, annotations, indexing, associations, and sharing.

T.H. Nelson proposed a file structure called the Evolutionary List File (ELF) to meet requirements of a system he was developing for personal filing and manuscript assembly [14]. He termed the file structure evolutionary because it needed to support evolving contents and arrangements. He also determined that list structures were needed to support categories of information.

Hypertext is a system of laying out information for non-linear media [14]. In hypertext, a user creates networks of information by establishing relationships (links) among different pieces of information (nodes). The World Wide Web is an example hypertext system. NoteCards, Intermedia, and Dexter [9, 16, 10] are hypertext systems closely related to SPARCE.

A compound document is a document composed using information from disparate sources. It allows a user to create one document in which data from many applications can be composed and manipulated, often without leaving the document. OpenDoc and OLE 2 [2, 12] are compound document systems closely related to SPARCE. Weck has built a user interface around a compound document editor (based on a system called Oberon), but that work is applicable only in the domain of symbolic computation [15].

of 14


Hypertext systems, compound document systems, and superimposed information management systems are all attempts to (intentionally or not) realize the visions of Bush and Nelson. However, these systems differ significantly in how they realize those visions. Hypertext systems and compound document systems are useful to layout information for non-linear media and linear media respectively. However, SPARCE can be used to build applications to layout information for either kind of media. Hypertext systems have historically been application-oriented, while compound document systems have historically been architecture-oriented. SPARCE is similar to compound document systems in that it too provides architectural support to build superimposed applications. Domain-specific applications are easier to build with architectural support. Hypertext systems do not manage contexts, and compound document systems manage only content context. SPARCE can manage many kinds of context.

NoteCards Intermedia Dexter OpenDoc OLE 2 SPARCE

Base type 2 (text, graphics) 3 (text, graphics, timelines) Any Any Any Any

Base location Proprietary File system Proprietary Any Any Any

Base granularity Document Sub-document Both Both Both Both

Link cardinality 2 2 Any 2 2 2

Link traversal Directed Undirected Configurable Directed Directed Directed

Dependency Lisp MacDraw None CORBA COM None

Operating system Any Macintosh Any Any MS Windows Any

Context kinds None None None Content Content Many

Table 4: Comparison of SPARCE with related systems.

Table 4 compares SPARCE with the related systems mentioned earlier in this section. From the table it is clear that SPARCE combines the strengths of hypertext systems and compound document systems. Like compound document systems, SPARCE can address either whole base layers or just parts. Like Dexter, SPARCE is independent of any programming language or operating system.

7. Future workOur work so far on SPARCE has demonstrated the feasibility of using architectural support to manage

marks and contexts for use by superimposed applications. There is a lot of future work possible in improving, validating and applying SPARCE. The following is a list of possible future directions:

Validate implementation with assistance from representative users. Benchmark SPARCE against alternative approaches. Evaluate alternatives for context caching. Explore approaches to sharing and distributing superimposed information. Explore modeling constructs for superimposed information. For example, sets and lists. Develop support for base-layer types such as databases, emails, and multimedia. Consider application to other domains. For example, medical information management. Explore additional operations on marks and contexts. For example, mark containment comparisons

and queries over contexts. Explore means to manage changing base layers (contents and location).

8. SummaryWe have demonstrated the need for contexts and excerpts. We have presented SPARCE, architecture

to support contexts and excerpts in superimposed applications. We have demonstrated, using example applications, how different superimposed applications reuse the same architecture implementation. We have also shown that new types of base layers and contexts can be supported without affecting existing

of 14

superimposed applications. We have highlighted the differences between SPARCE and other related systems. We have also mentioned possible future directions for our work.

9. AcknowledgementsWe thank Professor Lois Delcambre, the SLIM team in the Database and Object Technology group,

and all reviewers. We thank John Davis for helping us understand the USFS appeal process and for providing sample appeal packets. We thank Shawn Bowers for sharing the Schematics Browser’s source code. This work was supported in part by the National Science Foundation Grant IIS-0086002.

10. References[1] Adobe Systems Incorporated. Acrobat Software Development Kit. Available online <http://partners.adobe.com/asn/developer/> Accessed 2003; Apr. 27.

[2] The OpenDoc Technical Summary. 1994. In: Apple World Wide Developers Conference Technologies CD; April; 1994; San Jose; CA.

[3] Bass L, Clements P, Kazman R. 1998. Software Architecture in Practice; Addison-Wesley; 1998.

[4] Bowers S, Delcambre L, Maier D. 2002. Superimposed Schematics: Introducing E-R Structure for In-Situ Information Selections. In: Proceedings of ER 2002; Pages 90–104; Springer LNCS 2503; 2002.

[5] Bush V. 1945. As We May Think. In: The Atlantic Monthly; 1945; July.

[6] Appeal of Regional Guides and National Forest Land and Resource Management Plans. 2000. Code of Federal Regulations, Title 36, Chapter 2, Part 217; U.S. National Archives and Records Administration; 2000; July 01.

[7] Delcambre L, Maier D. 1999. Models for Superimposed Information. In: Proceedings of ER Workshops 1999; Pages 264-280; 1999; November 15-18; Paris, France; Springer; 1999; ISBN 3-540-66653-2.

[8] Delcambre L, Maier D, Bowers S, Weaver M, Deng L, Gorman P, Ash J, Lavelle M, Lyman J. 2001. Bundles in Captivity: An Application of Superimposed Information. In: Proceedings of ICDE 2001; Pages 111-120; 2001; April 2-6; Heidelberg, Germany; IEEE Computer Society; 2001; ISBN 0-7695-1001-9.

[9] Halasz F.G, Moran T.P, Trigg R.H. 1987. NoteCards in a Nutshell. In: Proceedings of the ACM CHI+GI Conference; 1987; Pages 45-52; ACM Press; New York, NY.

[10] Halasz F.G, Schwartz F. 1994. The Dexter Hypertext Reference Model. In: Communications of the ACM; Volume 37; Issue 2; 1994; February; Pages 30-39; ACM Press; New York, NY.

[11] Maier D, Delcambre L. 1999. Superimposed Information for the Internet. In: Informal Proceedings of WebDB ’99; Pages 1-9; 1999; June 3-4; Philadelphia, Pennsylvania.

[12] Microsoft Corporation. 1995. The Component Object Model Specification; 1995; Oct. 24.

[13] Microsoft Corporation. Microsoft Office Development Resources. Available online <http://msdn.microsoft.com/> Accessed 2003; Apr. 27.

[14] Nelson T.H. 1965. A File Structure for The Complex, The Changing and the Indeterminate. In: Proceedings of ACM 20th National Conference; 1965; Aug. 24-26; Cleveland, OH; Pages 84-100.

[15] Weck W. 1996. Document-Centered Presentation of Computing Software: Compound Documents are Better Workspaces. In: Proceedings of the Fourth International Symposium on Design and Implementation of Symbolic Computation Systems; Karlshue, Germany; Springer LNCS 1128.

[16] Yankelovich N, Haan B.J, Meyrowitz N.K, Drucker S.M. 1988. Intermedia: The Concept and the Construction of a Seamless Information Environment. In: IEEE Computer 21; 1; 1988; January; Pages 81-83, 90-96; IEEE.

of 14