Coordinated Queries
Coordinated queries is a visual abstraction language based on the relational database model. An expression is a tree of operators that calculates the value of an output field using the fields of a input record. Expressions make up query operations that views use to visually encode data records into graphical attributes:
  • Projections use one or more expressions to calculate successive fields of an output record for each input record. Views draw records using graphical information (such as position and color) contained in the fields of the output record. This information is often encapsulated in view-specific glyphs.
  • Filters use a single expression to calculate a boolean value for each input record. Views draw records for which this value is true.
  • Sorts use a single expression to calculate a comparator for each input record. Views draw records in the order determined by evaluating comparitors pairwise.
  • Infos use a single expression to specify a data set. Infos can load data from a variety of sources and perform queries—including projection, filtering, sorting, and grouping—on them.
Projections and filters are constructed in a tree-based expression editor. The user builds each expression top-down, by choosing an operator for each position in the tree. Subexpressions are automatically appended whenever the chosen operator takes arguments. Editing this way takes a little getting used to, but has the advantage of being syntactically constrained. Editing is live; the visualization reflects changes immediately.
Lexicon Editor
The lexicon editor, showing a projection that generates rectangle scatterplot glyphs. The expression visually encodes records of schema {T:double, X:double, Y:double, Z:double} as rectangles which have:
  • Location (Z, Y)
  • Size (0.04, 0.04)
  • No edge color
  • A fill color which is cyan if the record is selected, otherwise it is calculated by mapping T into a red-to-black color gradient relative to minimum and maximum values of T over all records. (In other words, Tmin maps into red, Tmax maps into black, T maps linearly into a color in between).
When editing expressions in the lexicon editor, users can select individual operators in an expression for modification (A), or copy-and-paste/drag-and-drop entire subexpressions. Cloning whole objects (B) allows users to experiment with variations of expressions quickly and reversibly. Large libraries can be built up for reuse or rapid switching during data exploration.
Expressions are composed of eight different kinds of operators:
  • Function operators perform a variety of duties including object construction, type casting, member access, arithmetic, and statistics.
  • Value operators evaluate to a user-edited value of a particular type.
  • Attribute operators evaluate to the value of an input record field.
  • Aggregate operators allow the calculation of simple aggregates on tables.
  • Constant operators provide easy access to frequently used fixed values (e.g. π).
  • Conversion operators perform common numeric conversions between units (e.g. feet to meters).
  • Index operators provide indexed data lookups, by mapping a primary key value of an attribute to a foreign key value of an attribute in a different dataset.
Indirect coordinations are created using variable operators. Whenever an expression is evaluated, variable operators take on the current value of their corresponding variable. When a control depends directly on a variable that contains a projection or filter, it also depends indirectly on any variables referenced by the expressions of the projection or filter. Through variable operators, expressions can depend not only on the navigation and selection parameters of a visualization, but also on its projections, filters, and datasets. This multi-stage dependence is used for aggregation, grouping, indexing, nested views, and other kinds of queries. A shortcoming of the current implementation is that it does not detect or handle cycles in coordinated query graphs. Interaction propagates through one level of dependence in an indirect coordination like this:
Indirect Coordination in Coordinated Queries
  1. An upstream object propagates a value change to a variable.
  2. The variable notifies all lexical values that contain expressions which reference the variable.
  3. Each expression notifies variables to which it is assigned as a value.
  4. The variable sends a change notification to all downstream objects. Upstream and downstream objects can be live properties or other lexical values. Upstream and downstream objects can be live properties or other lexical values.
Each Improvise visualization stores schemas, data, and query operations in a central respository called the lexicon. To access these objects, views define live properties that bind to variables of the desired lexical type. The user assigns the value of a lexical variable by choosing from available objects of the same type in the lexicon. To specify the visual abstraction of a view, the user binds lexical variables to the view's data, projection, and filter properties.
Example
This simple visualization of excited ion motion demonstrates interactive filtering using the Coordinated Queries visualization language. The primary visualization consists of five controls: a scatterplot, two axis sliders, and a slider inside a color gradient view. The scatterplot is navigationally coupled to its two labeling axes in the usual manner. The color gradient view and slider together provide a way to specify a range of colors in the gradient. The scatterplot filters out glyphs whose colors is not within the specified color range. Since the red-to-black color of glyphs represents time, the gradient slider effectively becomes a way to examine and scrub short or long segments of motion paths perceptually.
The projection expression used by the scatterplot visually encodes points along the ion trajectory by mapping (normalized) time into the same color gradient shown in the gradient view. The filter expression used by the plot elides points that would fall outside the range of color selected by the portal. This happens because the filter expression depends on the value of the time range variable. Whenever the value of that variable changes — such as by dragging or stretching the slider — the filter passes on the change notification to the scatterplot. The scatterplot updates itself appropriately using the modified filter.
Because Coordinated Queries is build upon Live Properties, notification indicates that a change has occurred, but not which upstream value modification originated the notification. As a result, controls know when they need to update themselves without requiring knowledge of the deep interactive dependencies that trigger those updates. In this example, the scatterplot neither has nor needs direct knowledge of the range variable used to filter its contents, let alone the slider that allows manipulation of that value.