Conceptual Design

In its current state, DataNav Builder lets you construct and browse any number of archives in your DataNav workspace on the host machine. This (unordered) collection of archives is an archive vault. A DataNavportal is essentially an archive vault accompanied by a registered users list. It is accessed only through DataNav Server, and each archive in the portal's vault has a designated owner who is among the registered users. The owner can choose to add any number of other registered users as collaborators on the archive. An archive collaborator can submit revisions to the archive through a "checkout, revise, and check-in" paradigm, but he cannot add or remove users from the archive's collaborator list, nor can he unmount the archive or change its public/private status.

Archives come in one of two types, figure archives and data archives. A figure archive is nothing more than an ordered list of related Figure Composer figures, with an accompanying title and description for each figure -- the figure's "legend". A data archive, on the other hand, is far more  complex. 

Each data archive, or data hub, typically contains a number of navigation views and a data repository. The views are linked to each other in a hierarchical fashion, forming the hub’s navigation map. The data repository is not directly exposed to either the author or the readers of a hub. Instead, the author creates one or more views and pushes data into the hub by associating groups of data sets with a view. The views are typically arranged in a top-down fashion in the navigation map, with a single "root" view. This view is designated the hub's entry-point view. Pathways in the map represent logical avenues by which the reader explores the hub, "drilling down" from the summary-like entry-point view to increasing levels of detail.

The navigation view is, by far, the most complex entity in this conceptual design. A view is defined by a title, HTML-formatted description, figure template, instance configuration, and instance data. The title and description essentially serve as a legend for the view. The template is a FigureComposer figure that renders the view. Each data set in the template can be a placeholder into which hub data is injected for display in the view.

The instance configuration is what makes the view a browsable “window” into a hub’s data repository. It may contain up to four independent configuration groups, but for now we’ll focus on what will likely be the most common use case: an instance configuration with a single group. The group is defined by a reader-facing descriptive name, an iteration block size, a list of one or more placeholder sets from the view template, and a list of 1-6 search tags, or attributes. The placeholder list indicates which data sets in the template participate in the configuration group; no two groups can share any placeholders. Not every template set need be accounted for in a configuration group; if a template set does not appear in the view’s instance configuration, then it is not a placeholder and is left unchanged each time a view instance is rendered.

As the name implies, the search tags for a configuration group specify the categories over which the reader can browse instance data displayable in the view. To specify a particular data instance for a configuration group, you must specify the data set to be injected for each placeholder in the group (the injected data’s format must exactly match the placeholder’s format) and the string value assigned to each search tag. The tag values uniquely identify the view data instance: no two instances can have the same set of tag values. 

Future feature: Searching data by tag

A hub manages a “dictionary” of search tags that have been defined by the author, as well as all the string values assigned to these tags. It also manages a lookup table that allows the reader or author to search for data by specifying one or more tag-value pairs. However, this feature is not yet exposed in DataNav Builder.

A simple example

A concrete example will hopefully clarify these ideas. For simplicity’s sake, consider a view that displays both a behavioral response and a neural unit response to a fixed target stimulus trajectory. The same “trial” was presented 100 times during a given experiment. This experiment was repeated on multiple dates in three different subjects, typically over multiple units on any given date. A view template figure is constructed with three placeholder sets:

• id = ”target”, format = series

• id = ”response”, format = mseries

• id = ”spikes”, format = raster1d

The target data set shows the trajectory of the target stimulus over the course of an experiment. It is the same for all of the instance data we intend to present, so it will not serve as a placeholder. The other two template sets are “collection-type” sets which hold the behavioral response and unit spike train for the 100 trial repetitions of a given experiment. We decide we want the view to iterate over 10 reps at a time.

An instance configuration that could work for this example would have a single configuration group with two placeholders, response and spikes, both enabled for block iteration. The group’s iteration block size is set to 10. Possible search tags would be “subject”, “date”, and “unit_ID”.

The search tags and iteration block size define a browse interface for the view. When a particular instance is loaded into the view, each tag is set to the corresponding value assigned to that instance: “subject=sleepy”, “date=06nov2012”, “unit_ID=A”. To change the instance, the reader can select a different value for a particular tag from among the list of available values. Another “widget” would control which iteration block is displayed: “1-10”, “11-20”, and so on.

Order is important in both the placeholder list and the search tag list for two reasons: (1) A view data instance is defined simply by a list of data sets and a list of search tag values. The n-th data set is injected into the configuration group’s n-th placeholder, and the m-th value is assigned to the group’s m-th search tag. (2) Order in the search tag list implies a hierarchy from most general to most specific. In the above example, a logical search tag order would be “subject”, “date”, and “unit_ID”. Suppose “subject=dopey”. If the user wants to change the “date”, DataNav Builder will search the collection of all instance data to find all possible values of “date” for which “subject=dopey”. Thus, if the reader changes the “date”, “subject” will remain unchanged, but the more specific “unit_ID” tag will likely be set to another value.

Views with zero or multiple configuration groups

The preceding example described a view with a single instance configuration group. However, a view may be defined with no configuration groups at all. Such a view is a singleton because the only “instance” of the view is its template figure; there is no data to inject. A singleton view might be appropriate as the entry-point view for a hub, offering a summary picture of the hub’s content. Such a view would lie at the top of the hub's navigation map, with links to one or more descendant views by which the reader can explore actual hub data. When you display a singleton view in the Builder’s view browser, an “Explore Further” panel would offer descriptive links to these descendant views.

Why support an instance configuration with more than one group? The view browser may eventually offer a “split mode” in which two independent copies of the view canvas -- each with its own set of navigation panels -- appear side by side. This mode would let the reader compare two different sets of data side by side. But what if the author would like to be able to compare two sets of data within the same view? That is a primary reason for supporting multiple configuration groups. When a view has more than one configuration group, instance data added to the view is associated with only one of those groups. Thus, there is an instance data pool for each group, and these pools are assumed to be independent: an instance from one pool can be displayed with any other instance in a different pool. See the tutorial for an in-depth example of a navigation view having an instance configuration with two groups.