4. The Fragments Panel:

Manipulating and Viewing Fragments

Once fragment records are brought into the system, one may manipulate the resulting database of fragments in FAKtory's Fragments panel. This is one of FAKtory's three primary working panels, the other two being the Layout Edit and Finishing panels. Note that these three panels are generally the only ones seen or used by end-users.

The central portion of the large Fragments panel is a display area containing a vertically scrolled display of all the fragments in the database. By default this is just a tabular display of the labels of the fragments in alphabetical order. Ordinarily this would not be terribly useful, although the data set is generally small enough (several hundred to several thousand records), that scrolling through it looking for a particular fragment is quite viable (and we observe it being done). But there is much more. One can select any subset of the fields to be displayed. The display area automatically produces an appropriately tabularized display. If one asks for the sequence field to be displayed, an additional horizontal scroll bar appears, allowing one to scroll through the entirety of this rather lengthy field. Thus one can get a snapshot of any cross-section of the data and scroll through it. The Fragments panel further permits one to sort the display on the basis of any field, resolving ties on the basis of a second selectable field, and so on. Technically speaking, one may lexicographically sort the display on any ordered subset of the fields. Thus if one wanted to quickly see the records produced by technician Joe during the month of February, one simply asks to sort first on the Technician field and secondarily on the Date field, and asks for the these two fields plus any others to be displayed. Simply scrolling through the display one can quickly arrive at the contiguous segment of the display containing the records of interest. If one wishes to see a nicely organized display of all the information of a given record, including the pipeline processing information described below, one merely double clicks on an entry in the display area and a window containing the information pops to the screen.

While one can quite intuitively navigate the fragment database with just the viewing and sorting capabilities above, the FAKtory further provides an SQL-like query language for selecting subsets of the database whose description is more complex or which need to be selected frequently. The rules for forming queries are as follows:

A query is a predicate or any boolean combination of predicates. The operator symbols used are: | for `or', & for `and', - for `minus', and ! for `not'.
A predicate may be a comparison between two operands using the conventional operator symbols =, !=, >, <, <=, and >=. The meaning of the comparison depends on the types of the operands: alphabetic order is used for string data, temporal order for time data, and numeric order for number data.
The notations X in [Y,Z], X in (Y,Z], etc., are available as shorthands for the predicates Y <= X & X <= Z, Y < X & X <= Z, etc.
An operand may be either field names or constants.
A numeric operand may also be any arithmetic expression composed from *, /P, +, and - over numeric operands.
The notation X in Y where X is an operand of type string and Y is a constant of type string, is a predicate which returns true only if X is a string matched by Y when it is interpreted as a regular expression.
The built-in function len(X) returns the length of a string operand X.
The built-in function undef(X) where X is a field name, is a predicate which returns true only if field X is undefined for the fragment record in question. Undefined fields arise when an optional field without a default is missing when input to the FAKtory.
A string operand may also be X[I,J] where X is a string operand, and I and J are integer operands. The result is the relevant substring of X where negative indices denote an index from the end of the string (e.g. `abcde'[2,-2] is bcd)

There are a few more additional forms to FAKtory's query language, these are deferred until the necessary concepts are introduced. The bullet list should make clear that the language is equivalent in power to the query language of a commercial relational database. However, it is simply implemented as an interpreted search. The performance for such is more than adequate as even a bacterial shotgun project involves only tens of thousands of fragments. The complexity and optimization of systems designed to handle tens of millions of, say airline reservation records, is not necessary in our context. Moreover, FAKtory's query language offers regular expression matching over string fields and string operators, something not found in conventional RDBMs.

The FAKtory keeps track of a subset of the fragments in the database, called the current fragment selection. The current selection may be modified manually or by queries. All selected fragments are highlighted in the fragment display window, if visible. The utility of the current fragment selection is that it provides the set of fragment records to be operated on in a variety of circumstances. For example, which fragments to advance through the pipeline, or which fragments to add to an assembly.

There are buttons on the console to clear the current selection, to make it consist of all the fragments in the database, or to invert its contents. Clicking on an unhighlighted fragment record in the display, causes it to be added to the current selection. Clicking on a highlighted fragment, causes it to be removed. One may also sweep over a collection of fragments with the left or right mouse button depressed to add or remove them in a single step. In addition to these manual methods of altering the current selection, one may use FAKtory's query mechanism to do so. One can set the current selection to be the result of any query. This is done by pushing the console button labeled Select Query ..., where upon a dialog in which one can formulate a query expression pops to the screen. Alternately, one can union the results of a query with the current selection, or intersect it, or subtract it, using the appropriately labeled buttons. This permits one to build up the current selection in a number of independent steps.

Often one finds that they have need to perform a particular query repeatedly, or they would like to remember a particular set of fragments. The FAKtory permits users to save the current selection as a named fragment set. If the current selection was produced solely using queries then a query is saved as the functional representation of the set. Otherwise there were some manual operations involved in arriving at the current selection, and an explicit list is saved as the representation of the set. To distinguish between these two cases, after a user creates a set with the name, say Foo, it appears in the list of user-defined fragment sets as Foo() if it was saved as a query (i.e. functionally), and as Foo if it was saved explicitly. Once a fragment set F has been defined, one may re-select it later by pushing the appropriate console buttons or by referring to the special predicate %F in a query expression. The important thing to note, is that the functional sets re-evaluate their query over the current database to arrive at the set, giving possibly different result over time, whereas the explicit sets always deliver the same list of fragments that were explicitly saved. In addition to user-defined sets, the FAKtory provides builtin functional queries that select the fragments currently in a given stage of the pipeline.