Proposed Extensions for ACEDB Query Builder

John L. McCarthy jlmccarthy at lbl.gov
Tue Mar 22 14:22:37 EST 1994


Proposed Extensions for ACEDB Query Builder

We'd like your suggestions on proposed Query Builder extensions to make it
clearer and permit certain types of queries it currently does not do:

I. "Follow" to another class via a tag in the current class; and

II. "Next" where there are multiple data fields with a single tag.


REVIEW OF CURRENT QUERY BUILDER INTERFACE

The current query builder has boxes to  fill in as shown below.  
Here pipes and underscores are used to simulate boxes, % to indicate an
editable area selectable by mouse, and @ to represent downward pointing
triangles which can be clicked to bring up a list window for permissible
values that can be mouse selected for entry in that particular box.  (you
must display this in a monospace font to line up things correctly in their
respective boxes).

Query Builder:(Click right mouse button on the shaded boxes for choices)
                +---------------+
Find and select |%%%%%%%%%%%%% @| items
                +---------------+
       +----------------+ +----------+ +--------+ +-----------+
 where |%%%%%%%%%%%%%% @| |%%%%%%%% @| |%%%%%% @| |%%%%%%%%% @|
       +----------------+ +----------+ +--------+ +-----------+

The first box is used to specify class, while the four on the next line are
used to specify tag, operator, value and conjunction, respectively.

Values displayed in the list for <TAG> are determined
by the CLASS selected on the first line.

If a conjunction other than the default "END" is specified, Query Builder
automatically creates another "where" line to be filled in.
There can be as many additional where lines as the user wishes.


PROPOSED REVISIONS

We propose to revise the current Query Builder as follows:

A. change wording of first line to indicate triangles for choices;

B. delete "and select" before first box and add "class" after it;

C. add type of information below each box to help user understanding;

D. in conjunctions list, substitute default "to get keyset." for END;

E. add "and next field" to the conjunctions list;

F. add "and follow" at the end of the conjunctions list;

G. use different wording under tag box for "next" and "follow".


The net result would look something like as follows:

Query Builder:   (click triangle in any box for choices)
     +-------------------------+
Find |%%%%%%%%%%%%%%%%%%%%%%% @| class items
     +-------------------------+
       +----------------+ +----------+ +--------+ +-----------+
 where |%%%%%%%%%%%%%% @| |%%%%%%%% @| |%%%%%% @| |%%%%%%%%% @|
       +----------------+ +----------+ +--------+ +-----------+
        <tag>              <operator>   <value>   <conjunction>

(A) proposes to drop pop-up menus as an alternate mechanism for getting
lists of allowable values.  There is a limitation of the widget currently
being used for popup menus that prevents scrolling beyond the top or bottom
of the window; so users cannot get at the bottom of very long lists.  Until
this shortcoming is overcome, it seems best to have a single mechanism --
namely the triangles that bring up separately scrollable windows (which
must be dismissed before proceeding).

(B) is a relatively minor change in wording to clarify what is being done. 
[Suggestions for improvement welcome!]
The first (default) item on the class list would be changed to "ANY".

(C) is intended to help clarify what goes in what box, and to differentiate
what happens in lines after "and next field" or "and follow class" (see
below).

(D,E,F) The expanded list of conjunctions is proposed as follows:
   to get keyset.
   and
   or
   exclusive or
   and next field
   and follow class

1. The first list change is the simple default that terminates a query.
The proposal is to change it from "END" to " "to get keyset."  
Although "END" is shorter, it is less intuitive. 

2. The second change is to add a choice "and next field," the result of
which would be to bring up an additional "where" line in which the user
could specify some constraint on the second data field following the tag
(and which would get translated into a "next" ACEDB query phrase). In this
case, the label under the first box would change to "<data field> and the
choices available for that box would be limited to the data fields
following the first one in the model (indicated by putting the data type
following the tag in that box -- e.g., "Float").

3. The third conjunction list change is to add "and follow class."  If a
user chooses "and follow class", the Query Builder will automatically
create another "where" line to be filled in, as it does for other
conjunctions like "and" or "or."  In this case, however, the label under
the first box would change to "<tag ?Class>.  The list that appears if the
user clicks the triangle in that TAG box is a subset of those tags in the
current class whose values are names of other ?Classes.  The default
operator would remain "exists" (as in the original line). 

Users can further restrict such "Follow" queries by filling in other
operators and values to restrict the values of connected class objects thus
chosen, or by choosing another conjunction and going on to another line in
which they can specify restrictions on any tag in the connected class
specified by the tag in the line following "and follow class."
They can also go on to a third connected class by specifying another "and
follow class" in the conjunction box.


EXAMPLES

A simple query might look like this (CAPS FOR VALUES FILLED IN):

Find PAPER class items
 where YEAR     >        1990    to get keyset.
       <tag> <operator> <value>  <conjunction>

A query on a tag that had multiple fields might look like this:
Find Locus class items
 where gMap    exists             and next field
       <tag> <operator> <value> <conjunction>
 where FLOAT            >        12      and
       <data field> <operator> <value> <conjunction>
 where FLOAT           <          20     to get keyset
       <data field> <operator> <value> <conjunction>

NOTE: evaluation remains on same data field if "and" is conjunction.

An indirect (Follow) query might look as follows:

Find GENE items
 where ITEM NAME      CONTAINS   ADH    and follow class
       <tag>        <operator> <value> <conjunction>
 where CLONE ?Clone   EXISTS            and follow class
      <tag ?Class>  <operator> <value> <conjunction>
 where SEQUENCE ?Sequence  EXISTS             and
      <tag ?Class>        <operator> <value> <conjunction>
 where DNA            CONTAINS  AATTGG  to get keyset
      <tag>         <operator> <value> <conjunction>


I hope this example is more understandable (and legal) than my last one.
The idea here is that we (1) find genes that contain the string ADH; (2)
proceed to find any clones (a different class) connected to those genes
where the clones have sequence information; and (3) get a keyset of clones
from those where the DNA sequence contains the substring AATTGG.  [Jean: is
this ok?]

Note that follow can occur after multiple specification of constraints and
could even lead back through a class that was used for other purposes
earlier in a prior line of the query. 


"SMART" DEFAULTS

David Matthews has suggested that we consider inserting other default
values in the initial Query Builder boxes, depending on context.  

Currently, QB can only be invoked from the main window, and it comes up
with "ANY CLASS" in the class box, "ANY TAG" in the tag box, and "contains"
in the operator box.  One alternative would be to put the name of the class
of the currently selected class (top left default) in the first box.  If we
knew other information (from another window? e.g., tree text display), we
could put the currently selected tag in the box after "where" on the next
line and could even fill in the other boxes with "equals", and "<value>" if
a data field is selected.  I'm not sure how easy it is to get such
information from a window other than the currently active (main) window. 
Another alternative might be to make the Query Builder invokable from the
Tree Display, but that would add to the length of that already long menu.


DISCUSSION

The logic of our basic proposal seems OK, and the ACEDB query language
already supports it. The problem is that the wording may not be
sufficiently clear to help new users understand what is happening.

Adding explanatory text below the boxes does add clutter and uses up more
vertical real estate, but my hope is that it may help clarify what is going
on -- especially for "and next field" and "and follow class."

I would very much appreciate any advice about how we might better clarify
things via further changes in wording, layout, or whatever.

We would also appreciate comments & suggestions about "Smart Defaults."

-- 

+=====================================================================+
|  John L. McCarthy.               . | Internet:..JLMcCarthy at lbl.gov  |
|  Computer Science R&D  MS 50B-3238 | Bitnet: ...JLMCCARTHY at LBL      |
|  Lawrence Berkeley Laboratory     .| telephone: (510) 486-5307      |
|  1 Cyclotron Road                . |                                |
|  BERKELEY, CA 94720, U.S.A.      . | FAX:       (510) 486-4004      |
+=====================================================================+




More information about the Acedb mailing list