[Indigo]<Squirrel>Doc>Nuts.memo!1

Abstract:An experimental user interface paradigm is proposed, designed to be uniform across Cedar programs, using DOCs and the database system as a basis for an integrated environment. The interface is object-based, oriented towards families of facilities rather than specific "tools". It unifies the various applications underneath via a common database representation of objects, and on top via a common DOC representation of objects and operations thereon.

This memo is about "integration" in Cedar: providing facilities that plug together and provide some consistency in their interaction with the user and programmer. To date the component subprojects of Cedar, particularly user facilities and the database system, have limited the degree of integration they provide in order to avoid excessive dependencies between subprojects and to allow experimentation with a variety of different user interface paradigms. The time has come to experiment with more integration; the following is a proposal in that direction.

If you’re convinced integration of Cedar components is the greatest thing since sliced bread, skip to Section 2. Otherwise, let me point out a few things.

1.A uniform user interface [above-integration]. Similar operations in different tools should appear similar to the user. For example, one should be able to move text from one window to another, point at objects anywhere on the screen in response to a query from a particular program, and be able to recognize the layout of a particular tool’s window (commands, data, parameters) quickly.

2.Compatibility across tools [below-integration]. Applications must be able to run at the same time in the same run-time environment, and the output of one program should be compatible with the input of another. Unix pipes are a step in the latter direction. Database systems provide a much bigger step: a common high-level representation of data structures across programs.

1.An easier understanding of the system. This is important to a new user or one who hasn’t time to maintain expertise. It also has some importance to expert users, since they have less to remember and can devote more attention to content over form.

2.Easier construction of new systems. Plug-compatible parts means that composing new systems, either temporary (e.g., to answer a single query) or permanent (e.g., a new tool), can be done much more productively.

Several points about information integration are well expressed in Jim Mitchell’s recent memos on programming environments and on charter goals of CSL ([juniper]<CSL-Notebook>Entries> 80CSLN-00??.press, [juniper]<CSL-Notebook>Entries> 80CSLN-0035.press). Outside of our lab, integration of components is of particular concern with office products. Star represents progress in the direction of above-integration, but has a way to go in below-integration.

The most basic primitive in the Cedar database system is an entity. In this memo "Cedar database system" refers to that system with some extensions we will discuss in the last section. The most basic primitive in the Cedar user facilities is a DOC. The basic primitive unifying entities and DOCs we will call a nut. A nut is a DOC viewing an entity stored in the database. A nut might view a program module entity, a memo entity, or a person entity.

In addition to entities, which represent real or abstract objects, the Cedar database provides two other basic primitives, values and relationships. A value is a string or a number; these do not represent objects per se, but perhaps some measurement or property of an object. The database system guarantees uniqueness for entities but not for values; more precisely the definition and only useful property of an entity is a unique immutable referent. A relationship is a connection between one or more entities and values; it represents some correspondence between them. An example of an entity is the person "John Doe". An example of a value is "23." An example of a relationship is an "age" relationship connecting "John Doe" and "23."

Entities, values, and relationships have types. An entity might be of type program, memo, or person. A value might be of type string or number. A relationship might be of type author, member, or phone-number. We will find it desirable to allow a hierarchy of types. For example, entities of type "article", "book", and "memo" are all special cases of type "document". Any document may participate in an "author" relation, but the more specific types may participate in other relations, e.g. a book may participate in a "chapter" relation.

A database management system’s scheme for describing data is called a data model. The scheme proposed here, in terms of entities, values, and relationships, is one such scheme. The relational model is another; our scheme is a marriage of several data models. The best documentation currently available is [ivy]<CedarDocs>database> EVRModel.bravo, approximating the model we are using, and DMSurvey.bravo, which provides some background. We are not describing the underlying data model in its totality here. It will not be necessary for the purposes of our proposal to introduce hierarchies of value types or relationship types. We will not describe the database access primitives. We will not describe views, which are sets of relationships that are not stored but computed. The reader should be aware that a view mechanism does exist to make different applications independent of the data representation.

The logical primitives of the data model (entities, values, relationships) for data representation are only part of the common language a database system must provide. In addition to a data model, we require a data schema, a description of the actual types of data and allowable relationships for some particular database. When multiple applications are involved, this common definition involves coordination and integration of applications. Although different views of a database can be provided, the common basis is as important as the physical data structures themselves to the database’s function of below-integration.

Figure 1 shows how we might display the three parts of a nut. In this case, the nut is of type Memo. We’ve chosen to give memos numbers for names, a number which must be unique among all entities of type Memo. The label on a nut’s window specifies the type and name of the entity viewed. The three subwindows of the nut show items 3, 2, and 1 above in that order.

Note in particular the second subwindow, showing this entity’s relationships to other entities and values. The "From" line, for example, represents a binary relationship between a Memo and a Person. When displaying any memo, the name of the person who authored the memo is shown in this way. Similarly, when displaying any person a list of the memos he or she authored are displayed. In either case, selecting the name of the related entity in the second subwindow causes a new nut to be displayed viewing the selected entity.

Memos and Persons are entities. Relationships may also connect entities and values, for example giving the date or subject of a message. Values, being simple strings or numbers, have no nut representing them. The system allows editing a value when it is selected, but no other special action is taken.

It is part of the client’s database design to make decisions to make particular types of item, say "subjects" of a message, be entities rather than values. This decision reflects the kind of use intended of such an item: whether we want to think of a finite set of uniquely named subjects, or treat subjects as strings which may be matched but need no unique identity.

Note that the display of a Memo nut is specialized to its type: e.g., the operations on a Program nut would be different, and the way in which we display its relationships and body would also be different. We will discuss this specialization later; for now assume there is a specialized DOC and associated procedures for each nut type.

A number of applications have already been built in the Cedar Database Management System, although to date only a limited range of data have been represented. In Figure 2 we extrapolate to a set of entity types adequate for a wide variety of applications. In Figure 3 some types of relationships between these entity types are shown.

Perusing the figures, one can see how various applications might represent their information. A whitepages application, for example, might use the phone and address relations for Person and Organization entities. An electronic mail application might use the mailed and member relations with Person, Memo, MemoSet, and DistributionList entities. A personal notebook application might store relationships between Ideas, Articles, Projects, and so on. A programming environment application might also deal with a wide variety of entity types: Persons, Documents, MesaComponents, and their subtypes.

For the sake of clarity, only modest extensions to the Laurel scheme of things have been made for the example. The same message may belong to multiple MemoSets ("mail files"). Subsets and supersets of both DistributionLists and MemoSets are part of the scheme. Laurel views exactly two memos and one MemoSet at a time; we view any number of these or other entities here.

Once we have diverged from the Laurel scheme, of course, a host of more powerful schemes may come to mind. As the type hierarchy in Figure 2 suggested, we might treat memos as simply a special type of document. The user may view, mail, respond to, and categorize documents more general than messages. This brings us into the domain of the CSL Notebook, on-line annotated bibliographies, personal databases, and libraries. The single database across all applications, the message system being only one, opens up more possibilities. Direct references to projects or parts of programs can be included in messages; these can be viewed by the receiver via simple selection. The phone number of a message’s author is available; the user might phone the sender in a single command (ref Etherphone project). A single protection mechanism and set of protection groups suffices to control access to messages, distribution lists, programs, and documents, contrasted to a separate program and database per application.

Most importantly, all the facilities provided by the Cedar database system are available regardless of application domain. Thus a general query language or report generator can be used whether you’re interested in program variables, addresses, or literature references. Instead of learning a different program per function, the same user interface paradigm applies to distribution lists, programs, and documents.

Figure 5 <Figure 5 not yet completed> shows some nuts we might use in a simple Mesa programming environment. The entity types include program modules, definitions modules, and configuration modules in addition to related entity types such as persons (who create, modify, or use programs) and documents (that define the user or client interface to programs or describe their implementation). Because the database contains all the import and export relationships between programs and interfaces, and all the containment relationships between programs and configurations, the Make command on a configuration can do compilations and binds for simple configurations entirely via database access. This is an over-simplification, the system modeller will require more information and the cooperation of a number of system utilities. But the uniform paradigm provided by the database basis makes this cooperation much easier.

We store additional information about modules in the database: the names of the types, procedures, and variables they define. These are shown simply as text values in Figure 5. As the sophistication of Cedar tools progress, we probably want to define entities at this finer level of granularity. This redefinition changes the MesaComponent and its subtypes in Figure 2 to:

The goal of the "Nuts" proposal is an integrated set of facilities as opposed to monolithic tools. The difference is that facilities overlap. They overlap in the types of data they need, the actual data they access, the user interface paradigm they share, and the database operations they require.

The disadvantage of facilities over tools is the loss of flexibility and perhaps of performance in using a standardized shared display and data representation. The advantages are labor-saving in building new facilities and easier operation by the user. The labor for monolithic tools is probably still appropriate for some applications, but the experiment in integrating a wide variety of applications is definitely worth the effort.

1.Defining Nuts.mesa, an interface between a central application-independent "information manager" and application-dependent programs that manage DOCs for particular types of entities. The information manager, actually a generalization of the Palm browser, is named Squirrel. (The various application-dependent DOC managers might be named after different kinds of nut trees: Walnut, Almond, Acorn). Squirrel invokes a different DOC manager depending on the type of nut the user wishes to view or operate upon.

2.Extending the Cedar database system to the functionality required for this proposal. This includes some work already underway by Eric as well as some more extensions, e.g. the ability to store procedures in the database system.

4.Laying out a feasible implementation for Squirrel. Squirrel must provide some default behavior for entity types not yet having an application--dependent DOC manager. A mechanism for linking up the latter at run-time to Squirrel via the Nuts interface needs to be worked out, and it needs to work in the current Cedar environment. I propose to compile all the DOC managers with the same (rarely changing) Nuts.bcd, store the DOC manager bcds in the database system, and NEW them into the running environment the first time a nut of a specific type is encountered. Mildly radical.