One-way connections between classes

When a user first encounters ACEDB, one of the features that attracts the most attention is the way the interface responds to mouse clicks. For example, in a window displaying information about a genetically mapped locus, a click on a strain name opens a new window displaying detailed information about the strain. Nearly all windows and graphical displays contain mouse-sensitive hotspots which can be browsed in a casual, non-directed way. Although the user may be unaware of it, each click traverses a link between objects in the same or different classes.

From the curator's point of view, links offer important advantages. They make it possible to break data into separate and manageable, yet related, chunks. Without this option data would have to be pooled into a single category. DNA sequences, researcher names and addresses, and raw recombination data would all be represented in one monolithic view. The result would be difficult to maintain and impractical to use.

Sometimes it is helpful to think of interconnections as representing "associations" rather than something more formal. When designing a model, try to anticipate the associations that will be familiar to your users. For example, "formally" a gene does not "have" a sequence, yet many people associate them and would expect to see sequences connected to members of a Gene class. Of course "formally" a gene doesn't "have" publications either; this just underscores the point that useful associations have more to do with human perspective than textbook biology. If an association is useful, work it in; if it is not meaningful, don't (e.g., a link between alleles and journal names). The goal is to present users with an environment they will find comfortable and familiar.

How links are made

Mouse-responsive hotspots work because different parts of the database have been connected to each other by links in the underlying models. The software for traversing the links via mouseclicks is already in place and is activated automatically whenever real data fills in the links that the curator has added to the design.

A link is signaled in the models whenever a field is represented by class name. The ?TShirt model contains several links. For example there is

          Store UNIQUE ?Store

Here the label "Store" is to be followed by a unique item which is the name of a member of the class called ?Store (remember, the leading "?" means the item is the name of a class). It is a coincidence that the label and the linked class have the same spelling. The label could just as well be

          Ookleplex UNIQUE ?Store

but that does not perform the labelling function very well. The UNIQUE qualifier is not required for this link and could be removed if desired. However, it makes sense that a particular t-shirt would be purchased at a single store.

Perhaps the model for ?Store looks like this:

?Store Address Street Text
               City Text
               State Text
               Zip Text
       Phone Text

Suppose the database is up and running and knows about the ?TShirt and ?Store models already. We read in the following data:

TShirt : sam55
Store : "Tom's DryGoods"

Store : "Tom's DryGoods"
City : "Salt Lake City"
State : "UT"

This accomplishes several things. The database creates a member of ?TShirt called "sam55" and fills in the field following the "Store" label; at the same time a ?Store object called "Tom's DryGoods" is created with "City" and "State" fields filled in. The objects appear in the selection list for their respective classes, where they can be double-clicked and examined.

A user viewing sam55 in a text window will now see "Tom's DryGoods" (in boldface, indicating an active link) following the "Store" label. Double clicking "Tom's DryGoods" will highlight the link and traverse it to the Store class. A new window will open, displaying the details associated with this particular member of ?Store. The store window could also have been obtained by clicking directly on "Tom's DryGoods" in the Store class selection list. The two windows are shown below:

Again we emphasize that the software responds to the mouse click because

1. the connection is specified in the model, AND
2. there is something to connect to, namely "Tom's DryGoods".

Notice that the link is one-way; that is, the user can traverse from the TShirt to the Store, but not the other way around. Two-way links will be introduced in another section.

Show me the whole t-shirt model again.

Back to Table of Contents