Model-Adaptive Interface Generation for Data-Driven Discovery

A representative example of a data-driven discovery use case will be used to motivate our requirements and approach. The Genito-Unarary Tract Molecular Atlas (Harding et al., 2011) (GUDMAP) and (Re)Building a Kidney (Oxburgh et al., 2017) (RBK) are distributed consortium of researchers interested in understanding how the Kidney, Bladder, Prostrate, and Genitalia develop at a molecular level (e.g. genes turning on and off). A partially overlapping subgroup of researchers is then interested in understanding how the kidney develops and functions in a normal and injured state with the goal of creating or repairing kidney function.

A fundamental mechanism used in this research is to mark activity of interest, for example a specific gene being expressed, on one or more biosamples from a particular region of anatomy and developmental stage, observing this activity via a wide range of methods, and then associating the observation to the biosamples. These observations may be made over many different organisms including mouse, human, zebrafish, or organoids—cultured cell lines. In general the data is very diverse: for example, current investigations cover 16 different assay types (imaging, transcriptomics, cell lines, to name a few).

Typically, there are many concurrent research threads. However, each follows the same general form: a study, i.e. metadata describing a set of experiments are created, samples are generated, raw assays collected (e.g. image file, or sequence data), assay processed to get usable data, experiments updated to reflect the new data. When the data is first generated, it is shared among the team who generated it, so other team members can read the data, check its quality, update metadata to indicate data quality, and potentially create additional experiments. Once the research team has validated their initial results, the permissions are changed to make the data accessible to other GUDMAP consortium members, who may further analyze the data and augment the description, while not changing any of the basic experimental data provided by the data generator. For publication, a digital object identifier (DOI) is generated for the data, and may be referenced in a manuscript (Cousijn et al., 2018). After the journal-imposed embargo period, the access permissions on the data are again adjusted to allow read only access to the public. These changes in permissions happen at different intervals for individual studies, not synchronously across all content in a collaboration. Hence, from a data and metadata perspective, discovery can be generally structured as repeated and nested cycles of data and metadata creation, reading, and update, i.e. the create, read, update, delete (CRUD)¹¹1While delete may be necessary for pragmatic reasons, in general, all data from a discovery process should be preserved and therefore, we don’t include delete in this discussion. data cycle with the policy associated with CRUD operations changing for each data element over time.

Figure 1 shows a simplified view of the relational model of GUDMAP/RBK sequencing studies. A Study such as an RNA Sequencing study composes of one or more Experiment. Each experiment is performed on one or more biological Replicates which are used to help validate and quality control the results of the experiment. Each replicate is associated with a biosample (Specimen) containing biological properties such as Species, and tissue anatomical sources (Tissue). The metadata of raw and processed files specific to a replicate are stored in a File table. The analysis results done across experiments or replicates are stored in the Study_File table. An important aspect of this model is that there are multiple cardinalities at play (many replicates per experiment, one species per specimen, one replicate per file) which make this data poorly represented by the traditional methods used by scientists to organize data such as spreadsheets or file and directory naming conventions and for which databases are particularly well suited.

While the complexity of this model is necessary to adequately capture the relationship between say replicates, experiments, and samples, it can create challenges from a user interface perspective. For example, even though a user shouldn’t be expected to understand all details of the model, it is necessary to create a new replicate and establish the relationship between that replicate and experiment in as simple a way as possible. Another example is that when viewing the details of an experiment, it is likely that the user will want to know what replicates are available and what their characteristics are.

Another important element of GUDMAP/RBK is the fact that the data model had to change as new data types were required, new technology was developed and use cases were refined. For example, the use of single-cell sequencing went from being a promising approach to an essential tool for understanding how gene expression over the period of 12 months (Hedlund and Deng, 2018). Since the system inception in 2016, the GUDMAP/RBK data model has been evolving to support new data types or use cases. Figure 2 shows an example of how a subset of model was evolved. The system was initially designed to support RBK assay types. In mid 2017, the sequencing Experiment, Histology Image, and IF Image schemas independently include metadata that describe biospecimen. In late 2017, the legacy GUDMAP imaging data covering different types of images and a different way of capturing biospecimen was incorporated. In mid 2018, all imaging data are unified and extended to take any type of 2D imaging data from both consortia. We also established a standard model for capturing biospecimen (i.e. via Specimen), and extended the Experiment model to cover single-cell data. In the latest snapshot (Sep 2020), the Experiment model was further extended to support other types of experiments e.g. metabolomics. The Image Annotation model has also been added to capture and display annotated shapes within an image.

The GUDMAP/RBK example illustrates structure and user interaction that is a typical of data-driven scientific discovery. We have seen similar patterns in many other scientific use cases (Bugacov et al., 2017) and from these have synthesized what we believe to be key cross cutting requirements for mediating the interaction between users and scientific data repositories in data-driven collaborative efforts. These requirements were derived iteratively as an integrated part of an agile software development process. Inputs to the requirements synthesis included use case collection and analysis, surveys, and interviews gathered from diverse scientific communities, and continuous production deployments over a 5 year period.

Figure 3 illustrates the overall structure of our approach. A “Data Modeler,” possibly a researcher, specifies her domain in the form of a relational model, which describes the methods and materials of her research and which will evolve over time. Relational modeling is a common approach to database design; because of our ecosystem of tools and methods focused on model evolution (Schuler et al., 2020) including high-level tools to streamline model evolution in-situ (Schuler and Kessleman, 2019), a modeling approach that emphasizes iterative refinement with increasing levels of detail can be realistically pursued.

In a separate step, model annotations may be associated with parts of the model, such as a table or column, to provide additional guidance for interpreting the model. Available annotations can specify a range of simple display directives but also can overlay more sophisticated ER model concepts such as interpreting a chain of foreign key references as an abstracted relationship. While model annotations augment and refer to model elements, they are loosely coupled. They can evolve at a more rapid rate than the underlying data model, and they may be maintained by a different user, who is more concerned with use case specific interaction issues.

The final configuration step is to classify the users of the system in terms of role-based access control policies. The policies may be used to prevent some users from viewing or editing particular entity types, particular entities, particular attributes of an entity type, or particular relationships. A common need in scientific use cases is to be able to have access control which varies over time and which is data dependent (Czajkowski et al., 2017). For example in initial phases of an investigation, data may be restricted to a small group of investigators, later shared across a research consortium, and eventually made available to a broad research community once pre-publication data embargoes are lifted. This requirement dictates that the generated interfaces adapt to both the user’s role and the data access policies.

Our interaction templates are model-driven, meaning that they interpret database structure and adapt, not encoding any fixed assumption as to what model should exist. These templates are designed for specific modes of presentation or interaction which are suitable for our data-management use cases, generalized as manipulation of entity-relationship (ER) structures we can derive from the database model. We have designed interaction elements for filtering sets of entities by search criteria, listing sets of entities, viewing details of an entity, creating and editing specific entities, creating and destroying relationships between entities, viewing sets of entities related to a single entity, choosing entities from a listing, etc.

Because we provide interaction over a relational database rather than a more abstract entity-relationship store, we must bridge the gap between the extant relational database model and the desired ER concepts. This is not a fully formalized ER model, but rather a set of ER vignettes providing just the aspects of the ER model needed by the interaction templates. We use heuristics to map the database model onto these concepts, recognizing certain idioms for how relationships are encoded in relational databases. For our purposes, relational tables simultaneously correspond as entity types and as entity sets, and scalar properties of an entity type can be derived from the columns of a table. Thus, creation or editing of entities corresponds to creation or editing of rows in a table. Search of an entity set is search over rows in a table. Relationships correspond to foreign key references or chains of such references. Our interaction templates consider an abstracted list of relationships, abstracting over the foreign key constraints involving the table. To provide further options for customization and guidance in these mappings, we use model annotations. These allow users to provide further hints to enhance or override our heuristic interpretation of their database model.

When instantiated, each generic template produces an interface element. Many of these templates are model-driven composites, translating the model structure into isomorphic interface structure, where nested templates are used to translate individual parts of the model. For example, the properties of an entity type inform the input fields in a data-entry form. Others are data-driven composites, translating query results into display values. For example, a variable-length query result instantiates a variable-length result listing. Of course, many templates are simultaneously model-driven and data-driven, as mapping of structured data into an interface requires an awareness of the data structure and content. For example, a set of entities in a tabular listing would use a table structure derived from the shared entity type, iterating over the number of entities in the result set, and appropriately mapping the datum in each field of each entity into a cell in the tabular representation.

Model annotations are used to customize the interfaces generated from the database model. Here, we provide a brief summary of concepts necessary to understand our approach. In subsequent sections, we will expand on these topics in more detail.

Simple display directives may introduce small amounts of content denormalization or reformatting, such as formatting of numbers or dates, converting raw URLs into an inline thumbnail display versus a download link, or splicing together several fields based on an interpolation pattern. The list of properties displayed for an entity type can be reordered or selectively suppressed via an annotation. Similarly, the list of displayed entity relationships can be customized to reorder or suppress relationships. For complex cases, a chain of foreign key references can be abstracted as a named relationship and supplied to augment the list of available relationships understood by the interface. These can also be used to augment the list of properties, i.e. a relationship to another entity can be presented as a logical property of the entity, or a set of related entities presented as a nested set. Similarly, aggregate calculations over related entities can augment the entity with a computed result.

An important variant of the property list for an entity type is a list of search controls or search facets. While heuristics can infer a default list of facets by combining the list of properties and list of relationships, an annotation may also customize this list to reorder, suppress, or augment the choices. In this way the user can enable and promote useful search controls over the most relevant aspects of an entity.

Together, the three elements of domain-specific configuration (schema, annotations, and policy) create an enriched model. Combining this with information about user identity and role, our framework converts the enriched model into a role-based model—a model decorated with the user’s data-access privileges (create, read, update, delete) and pruned of any columns, tables, or foreign key references the user is not allowed to view. With this, the interaction templates can selectively disable or hide structures and controls depending on the user role.

The storage platform provides access to database content that has been structured and filtered to produce role-based data conforming to the role-based model. Together, these byproducts are supplied to the interaction templates to generate a fully concrete interface providing a given user with appropriate access to specific database content. This dynamic combination of configuration, policy, user identity, and interaction templates provides an interface that constantly adapts to changes in various deployments. This approach allows the reuse of the technology to support multiple user communities without repeated software development to adapt services and applications for each project and model revision.

Modeling techniques that can improve accuracy and integrity of data often complicate issues of search and display, in that information best presented together may be separated by one or more relationships. While it is considered a best practice to design a well normalized model, interacting with highly normalized data is difficult and can degrade the user experience. Often, the solution to this is to resort to relaxing the data normalization practice, which sacrifices data fidelity or increases model complexity. Our approach provides the opportunity to denormalize data on the fly to improve the user experience without sacrificing model accuracy.

In the simplest case, our interaction templates understand zero-or-one and exactly-one cardinality relationships encoded as foreign key references in the relational model. We represent the single related entity as a logical property named by the relationship and present the name of the related entity as the property’s value. Editing features can then provide an entity-selection interaction to choose appropriate values. The entity name is denormalized content retrieved from the referenced entity. Heuristics can find typical entity properties which serve as entity name, e.g. fields like title, name, or accession_number, but this can also be customized using model annotations. This form of denormalization serves two common user intents: representation of properties governed by controlled vocabularies and designation of a parent entity with respect to a specific child entity. These are two alternate ways of thinking about the identical data structures, differing only in the intent behind the referenced entity set (for example, the experiments in a study and the specimens of a species use the same simple foreign-key structure in the database model in Figure 1).

Two closely related cases are zero-or-more cardinality relationships encoded idiomatically as a single foreign key reference or as a binary-association table. We can represent the set of related entities in several forms, including lists of entity names and nested tabular listings. These relationships can be rendered as complex properties of an entity or in summaries of related entities for a given, focal entity. Editing features vary by the relational encoding. The foreign key scenario is a set of child entities for a given parent entity, an inversion of the simple case described above, and we can provide interactions to create new child records or direct the user to edit an existing child record to change its parentage. A binary association table captures many-to-many peer relationships and we can provide interactions starting from an entity on either side of the relationship to prune connections or to make bulk revisions using an entity-multi-selection interaction.

As a generalization, we can also present user-defined relationships which abstract over other chains of foreign key references in the database. For read-only interactions, these can be presented like the previously described relationships. However, we cannot support concise relationship editing since there would be ambiguity as to how to change the database state. Editing of such structured content requires a less abstract ER interpretation, more closely aligned to the actual relational storage model. For example, the individual links in the chain of foreign key references are each embedded in tables, and these tables can be interpreted in simpler parent-child entity vignettes to incrementally create or revise intermediate records in the chain. In fact, if instructed to do so, our application templates would also represent a binary association table in such a way—it is simply an entity with two entity-typed properties, relating it to the entity on either side of the binary association.

All of the preceding relationship types can also be used to denormalize related entities as search facets. Search features can provide an entity-multi-selection interaction to set search criteria with respect to each named relationship. As a variation for both search and read-only presentation, we can also denormalize other related entity content such as scalar properties, rather than representing a set of entities in the user interface. Search features can provide appropriate interactions to control search criteria based on these related scalar values, e.g. range selectors for numbers and dates. For presentation, some interaction templates can directly represent sets of related scalar values. As a final option, we can expose computed aggregates over sets of related entities or related scalar values, representing the computed result of a chosen function (e.g. count, minimum, maximum, sum) as another scalar property. Earlier, in Section 2.1, we illustrated some of these denormalization concepts with respect to an actual problem domain.

Across our application templates, we have identified a set of significant presentation contexts where different interaction modes may benefit from different interface customization directives. To support such selective reconfiguration, we define a set of context names, including:

• •

  detailed: A focused view of one entity.

• •

  compact: A listing of multiple entities, such as a search result.

• •

  row_name: A concise reference to one entity by human-readable name.

• •

  entry: A data-entry form for one entity type.

• •

  filter: A collection of filter controls for searching an entity set.

• •

  *: A default configuration for many contexts.

For convenience, we define a “*” default context which can be used to share a common configuration across multiple presentation contexts, for those situations where differentiated configuration is not felt necessary. Conversely, we also define addition sub-contexts (not listed) to allow narrowly-targeted reconfiguration for certain modes, e.g. a data-entry form might benefit from differentiated configurations when creating entities versus when editing existing entities. Configuration search rules allow a user to mix and match some of these context-specific configurations without being forced to overly specify instructions where the defaults are satisfactory.

Many of these presentation contexts are closely aligned with the major mode of an application template. However, a particular application template can contain several modular templates, each of which exhibits a distinct presentation context or in fact might activate/deactivate such auxiliary presentation contexts as user-driven interaction is performed. The model-driven interface generator can determine an entity-relationship interpretation of any table in the model for any desired presentation context, as required to process and instantiate interaction templates. This allows for very precise and selective configuration of interfaces by annotating specific parts of the model with contextualized instructions.

The data-entry template (Figure 4(c)) enables users to create, update, or delete an entity or set of entities in the database. Data-entry forms are generated based on the interpretation of the storage table as an entity type, with appropriate input fields for inferred properties of that entity type. It uses the entry/edit or entry/create contexts to determine the configuration when producing this property list. Likewise, NOT NULL constraints are translated into required properties, and suitable data-entry tools are offered for typed scalar properties such as numbers, dates, and timestamps. Relationships encoded as foreign key references in the table are mapped as properties containing a selected entity. Such controlled inputs supplant free-text entry and prevent many accidental data errors. The template can also pre-validate entries to alert users to likely errors, or surface errors detected by the relational database storage platform.

Available and selected foreign entities are displayed with human-readable entity names while populating actual foreign key fields with their often cryptic values. During entity-selection, users can follow an auxiliary flow, if desired, to extend the set of available entities. This can be used to add a new term to a controlled vocabulary and immediately choose the new term in the data-entry template. For further customization, the entity-selection template can be configured to filter choices based on the earlier user inputs in the form, smoothing some data-entry tasks with many interrelated choices.

We provide a bulk variant of the data-entry template. When creating entities, a user can incrementally expand the form to edit multiple entity descriptions at once and request that they all be created together. When accessed by cross-links from other application templates, bulk-editing of multiple existing entities can also be performed. The forms also adapt to access rights, e.g. disabling input on fields immutable for a given user or completely hiding fields that a user is not allowed to see. This adaptive data-entry form for structured data addresses drawbacks of typical approaches to managing scientific data—like shared spreadsheets, where collected data often accumulates with latent errors and omissions.

The faceted search template (Figure 4(a)) provides structured filter controls and basic text search over a table using an entity-relationship interpretation. The facet panel contains a list of filter controls, providing appropriate filter predicates for either basic entity properties, basic properties of entities linked by a given relationship, or identity of linked entities by a given relationship. It uses the filter context to determine the configuration for this panel. As users select or deselect the predicate values of a facet, search results and potential values of other facets are automatically updated. Search results are displayed as tabular data. It uses the compact context to determine the configuration of the search results table. The results template shows a subset of entity details and provides per-result navigation to detailed entity views or data-entry views. Certain bulk operations are also offered, such as deletion of entities found by a particular search criteria, or a bulk-editing variation of data-entry.

The entity viewing template (Figure 4(b)) presents details of a focal row of one table using an entity-relationship interpretation which also includes summaries of related entities—entities linked to the focal entity by named relationships. It uses the row_name context to determine the configuration for the focal entity’s name, the detailed context to determine the configuration of the focal entity’s property list, and the compact/brief context to determine the configuration of each set of related entities. An auxiliary interaction allows management of certain relationships as described in Section 3.5.

The related entity sets are usually displayed as embedded tabular sets, but this can be customized through model annotations. Scientific data visualization, such as plots or 3D rendering, can be flexibly integrated into the display via a customized markup rendering engine and hypertext iframe elements embedded in the display. (An illustration of this appears under "Cell Browser" in Figure 9 in our subsequent implementation description in Section 6.)

Often, users start with search or data-entry templates for a small number of important entity types. Then, more complex workflows branch off as users traverse navigable links or activate editing tools embedded in subsequent views. This approach allows a collaboration to synthesize new workflows from these reusable tools. As new projects are formed or an existing project evolves, we avoid the repeated engagement with UI developers that is typical of conventional approaches.

We demonstrate the role of these three application templates in composing a complex curation workflow through our GUDMAP/RBK example (Section 2.1). Figure 5 and  1 show a typical sequencing data curation workflow and the relevant model. A sequencing Study submission is completed when its core entity and related entities are properly created. The same rule is (recursively) applied to each related entity. These basic steps form building blocks for composing complex workflow involving arbitrary number of tables. As a collaborative environment, the database may reflect incomplete work depending on the integrity constraints chosen by the data modeler.

A typical workflow starts with a lab member searching for their on-going study in Study search (illustrated in Figure 8 in Section 6). If their study isn’t found, they then click the "Create" button on the search page which will direct them to a data-entry page with a blank Study form to create a new entity (Figure 7 in Section 6). While entering a foreign key field (e.g. Curation_Status), they search for a specific entry. If the entry is not found, they can then branch off to create a new entity in the foreign key table by clicking "Create New". This action will open another data-entry tab which leads to its own entity creation workflow. In many cases, the foreign key entities are representing controlled vocabulary terms that become terminal leaves in this recursive workflow.

In Figure 5, we depict the common foreign key editing process with "edit foreign key field" boxes. After the foreign key entity is created, the user can select the newly created entry, then proceed to complete the rest of the Study form. After a Study entity is created, a detailed entity view with empty related entity sections is shown (since the user has not yet populated these relationships for the new Study). The user can then create related entities (e.g. Experiment and Study_File) by clicking "Add" for the corresponding relationships. The "Add" button will direct the user to another data-entry tab for creating the corresponding related entity (e.g. Experiment) with the parent Study already filled in. The same curation workflow—creation of an entity and its related entities, depicted as "create/edit entity" boxes—is repeated for all related entities which form part of this new Study. An alternative flow to creating/editing a related entity is to initiate a search in the appropriate entity type by desired criteria, and then activate an edit view on the found result. This is useful in curation, e.g. when an Experiment has been erroneously assigned to the wrong Study, but can be found by other characteristics and edited to relate it to the correct parent Study.

To revisit a partially completed Study, the user can first search for their study, then navigate to its detailed entity view. Once there, they can either edit the existing Study entity, add new related entities, or edit/delete existing related entities. The user can traverse a sequence of related entities to navigate to a specific part of the workflow (e.g. Study->Experiment->Replicate) to fill in missing details. The preceding example is a typical top-down approach. Different variations of the curation workflow can also be applied to achieve the same goal e.g. creating all Specimen entities in bulk first, then proceed to create a study, an experiment, and all related replicates in bulk. A Study entity is completed as long as its corresponding Experiment and Study_File entities are completed, which implies all Replicate entities associated individual experiments, and all File entities associated with individual replicates are completed.

Table-specific annotations are only meaningful when applied to a table in the model. They influence the overall interpretation or presentation of the table as an entity type.

Column-specific annotations are only meaningful when applied to a column in the model. They influence the interpretation or presentation of the column as a property of an entity type.

One foreign-key-specific annotation is understood by our current templates, influencing our heuristic interpretation of foreign keys as relationships.

Generic annotations are applicable at more than one level of the model, i.e. they can customize behaviors of entities when applied to tables, properties when applied to columns, or even sets of tables when applied at the schema level in the relational model.

Chaise supports authenticated and unauthenticated users. All authentication and authorization decisions are enforced by the back end data service. Chaise applications facilitate login for interactive users to establish an authenticated user session, and use policy decision information (access rights summaries embedded in the role-based model) to customize the interface. For example, edit options are not shown for tables that cannot be edited. Identity and group membership are managed by the Globus Authentication service (Tuecke et al., 2016) which allows authentication across a wide range of identity providers and manages group membership.

The  Deriva platform provides a tailored model introspection response which takes into account the privilege level of the requesting user to return a detailed description of the relational model and any associated annotations. The enumerated model is further qualified with data-independent access rights of the user, i.e. whether the user can use the table or column for select, insert, update, and/or delete requests. For low-privilege users, parts of the model (e.g. tables, columns, and relationships) can be entirely hidden. The model description document also contains machine-readable model annotations as described in Section 5. To support evolution and collaboration, Chaise performs model introspection every time an application page loads (or reloads).

The data-independent policy can allow a column to be hidden depending on the role of the user. In GUDMAP/RBK, only entities that are released should be visible to the public. To achieve this, a Curation_Status column is included in all primary tables associated with different assay types, as exemplified by the Study table metadata. The Curation_Status tracks the status of individual entities in the curation process e.g. In preparation, PI review, Biocurator review, or Release. Members of the project who manage data release can see this column and manage its content, while this concept is hidden from members of the public at large. The Deriva database platform also supports data-dependent policies to control access on a row-by-row basis. These are used to enforce row visibility rules that depend on the value in this Curation_Status column, only showing rows to the public when the status is set to Release.

With such a policy, when an anonymous user engages with Chaise, the returned role-based model (as shown in Figure 3) will omit all the hidden columns, and the role-based data will only include the released entities. The hidden column, and other features dependent on the hidden column, will be invisible to the public user. Of course, anonymous users have read-only access and so will see an interface optimized for searching and browsing without extraneous editing controls.

Application templates use heuristics, model annotations, and built-in assignment of presentation contexts to build the most relevant ER interpretation of the database for the given user and interaction. In Deriva, annotation values are stored as arbitrarily-structured, machine-readable JSON documents. For annotations summarized in Section 5, we have defined specific JSON document structures and annotation keys which may be placed into this generic Deriva annotation storage, and Chaise validates the documents against its expectations and the discovered relational model while building this ER interpretation. Invalid parts of annotations will be pruned at narrowly-scoped boundaries, printing diagnostic information to the browser developer console but continuing with the valid subset of annotation content. This is important to provide full adaptation to the role-based model, which may prune columns, tables, or foreign keys for some users and therefore cause some custom ER property or relationship definitions to be valid for some users and invalid for others. It is also helpful for a collaboratively managed catalog, so that small configuration mistakes do not interrupt service. The downside to this approach is allowing some configuration errors to go unnoticed if the user does not recognize that the customization they tried to deploy is not actually appearing.

Deriva provide APIs, python/javascript libraries, and command line tools to perform Create, Read, Update, Delete (CRUD) operations on models and we have added validation rules for the annotations understood by Chaise. Users can validate annotations syntax against the models and annotation JSON schema before committing their annotation changes, to lessen the chance of deploying custom configurations which are silently ignored from the perspective of regular users. Annotation changes require no system downtime and will be reflected during the next page load. Based on our science collaborators’ experience, which is consistent with ours, most of the effort spent in creating annotations is not on the technical hurdle of writing an annotation, but rather on refining the custom ER abstractions and other display customizations that they wish to impose over the relational data. We have reduced the technical barrier to deploying interface changes, but exploration and user-testing (Scowcroft et al., 2015) are still important when trying to solve interaction problems.

After Chaise builds its ER model interpretation and plans its interface layout, it plans queries satisfying the dynamic presentation mapping. On the back end, Deriva provides access aligned to the relational storage, and so these queries include the necessary table instances, filter predicates, and joins to retrieve core entity content and denormalized content. For example, in the experimental study model mentioned in Section 2, to display only human studies, the generated query involves joining the study, experiment, and biosample tables, then filter the studies to only those that contain biosamples with human species. The species concept is defined in the enriched model as a custom relationship between the study and species controlled vocabulary, chained across those other intervening tables. The core UI elements of Record, RecordEdit, and RecordSet are data-driven pages representing one entity or entity set which is the result of a single query request. However, other surrounding UI elements and features, like reachable values in a search facet or computed aggregate properties, may involve additional queries. These extra results are progressively rendered in priority order to help mask system latency. Some UI elements act lazily, requesting and rendering data only as the user activates them.

Chaise implements default behaviors to render typed column values such as numbers, dates, timestamps, plain unicode text, and Markdown text without requiring any model annotations. It also implements the other heuristics and annotation-driven customization described in previous sections. As a web-based UI, Chaise also allows extensive opportunities to override column or row display behaviors by specifying custom interpolation patterns. These are small template strings expressing (conditional) interpolation of structured metadata into an intermediate Markdown fragment, which is text with some optional mark-up syntax for basic text formatting, bullet lists, embedded image tags, and links. The output of this embedded template engine (Handlebars Template Engine, 2019) is then fed to a Markdown renderer to produce structured HTML suitable for inclusion in the overall interface that has been generated by the application templates built into Chaise. To enable flexible integration with other web applications and visualizations, the extended Markdown module supports inclusion of iframe elements. Through the iframe feature, applications can integrate virtually any standard Web component to customize a Chaise deployment to its use case requirements. For example, we routinely add data visualizations such as scatter plots, histograms, as well as specialized data viewers such as high-resolution zoom-able image viewers and volume renderers. Figure 9 shows an example of an embedded specialized data viewer on a Record page. Some of these extensibility features might not be feasible in an implementation of our approach which lacks the sandboxed execution and formatting environment of a modern web browser.

Finally, all the application templates produce systematic identifiers and classes in the generated HTML pages for different UI elements on the page. This allows the styles of those elements to be overridden through the Custom Style Sheet (CSS), enabling even more avenues for interface customization without requiring redevelopment of our application templates. For example, when presenting a property containing a controlled term, a colored symbol may be added alongside the term value to visually reflect distinct states, as shown in the Record_Status column in Figure 8; or for a column with visualization, the column heading may be suppressed to better utilize the space, as shown by the Cell Browser in Figure 9.

Chaise is adaptive to diverse model complexity. Table 2 shows model complexity based on the number of tables, table widths (max, 95th, and 50th percentile), outbound foreign keys (max, 95th, and 50th percentile), inbound foreign keys (max, 95th, and 50th) across the 4 deployments. The number of model-driven application instances correlates with the number of tables, but is potentially much higher, e.g. the Record app generates potentially unique layouts for different entities due to sparse usage of relationships, and the role-based aspects may generate different variants of the application for different users of the same tables. Similarly, the complexity of pages correlates with the width of tables and stored foreign key relationships, but these other factors of role-based layouts and sparse data may generate a vast number of variant page layouts. The wider tables require more columns to be retrieved and tend to need UI customization, as not all columns should be shown in all contexts. The outbound foreign keys influence the number of joins required in a query in order to present readable display in a default interpretation of the model. The inbound foreign keys influence the number of requests needed to present the related data associated with a table of interest in the default interpretation of the model.

Chaise supports multiple customization options for its interfaces. Figure 10 shows the normalized annotation distribution across different annotation keys (Table 1) used to configure these options. Many annotation keys are targeted toward specific model classes, while some can be applied to multiple classes. The labels/colors in the figure correspond to different model classes that each annotation key is applied. For column-level annotations, the column and system column labels capture annotations applied to user-defined columns and system columns, respectively. The system columns—namely, RID, RCB, RMB, RCT, RMT representing row ID, row creation and modified by, and row creation and modified time, respectively—were introduced in later Deriva release as a requirement in individual tables to enable data versioning and provenance. The annotation count is normalized by dividing the number of annotation occurrences by the total number of potential sites associated with each model class (e.g. a normalized table annotation is the number of annotated tables divided by the total number of tables).

All deployments utilize various types of annotations to address their different use cases. Across all deployments, the table-level annotations are extensively utilized, while the column and foreign key annotations are sparsely used. The top table-level annotations are visible-columns, visible-foreign-keys, and table-display. The visible-columns are mostly used to suppress and reorder columns in different contexts, especially when there are large number of columns. For example, a small subset of columns are shown in the compact form for a quick summary, only columns relevant to user inputs are shown for editing to avoid visual clutter, and (almost) all columns are shown for a record-centric view. The most often use column-level annotations are generated, immutable, and column-display, most of which are applied to system columns. These annotations can be removed in the future when Chaise expands its support to allow system column configuration at the catalog level.

Note that a large number of annotations do not necessarily imply bad Chaise heuristics, as many annotations only provide extra hints to modulate heuristics e.g. disable user input. In addition, annotations can be dormant and get applied only when they become relevant (e.g. column annotations are only applied when the columns are visible). We observe quite a few dormant annotations in some deployments (e.g. GUDMAP/RBK mark all ID column generated). Moreover, some annotations are legacy and no longer needed as Chaise expands its functionality e.g. no need to specify visible columns just to suppress or rearrange system columns, or custom presentation of URL columns as links when also annotating them as assets which enjoy the built-in support for file upload and download. Chaise will continue to evolve to provide more functionality and reduce the annotation burden to support diverse deployment use cases.

In this section, we evaluate the customization of columns and relationships explicitly annotated in visible-columns and visible-foreign-keys which are directly responsible for the page content shown on the three templates. Though these are two separate annotations, Chaise effectively combines them for the detailed presentation context in the Record application, so we also combine them in this analysis.

For each annotated element, we classify its definition into 4 different categories: simple column, simple relationship, complex column, and complex relationship. A simple column is a native column in the table of interest. A simple relationship include a direct relationship to its immediate neighbors or a relationship through a binary association, which are things that Chaise can present automatically via its heuristic interpretation of the database. A complex column is an aggregate column or a single- or multi-relationship path that leads to a column. A complex relationship is multi-relationship path that results in a set of entities. The usage of simple definitions suggests a scenario where the customization may only be reordering or hiding content that the default behavior would support. The usage of complex definitions indicates that the customization is actually imposing novel ER concepts which Chaise would never infer on its own.

Figure 11 shows the distribution of different types of columns and relationships. All deployments utilize complex columns and relationships sporadically. We found that in the hub deployments, the complex columns are mostly used to show aggregate data in the compact context, while in Synapse, they are used for searching on columns in the filter context. There is no usage of complex columns in CIRM. Across all deployments, the complex relationships are primarily utilized in the filter context to improve search-ability, follow by visible-foreign-keys for showing multi-hops related tables. Figure 11(b) shows the percentage of tables with annotations containing at least one annotated element categorized as each of the categories defined above. The low fractions of tables with complex columns or relationships implies that the visible-columns and visible-foreign-keys are mostly used to suppress or re-arrange columns and relationships. Smaller deployments seem to have higher fractions of tables annotated with complex columns and relationships.

Chaise supports model and annotation changes as deployments evolve. Figure 12 displays the monthly changes of models and annotations across all deployments from Oct 1, 2019, to Sep 30, 2020. The model and annotation changes associated with each model class are normalized by the total number of model elements and the annotations, respectively, within each class reported in the previous month. The column and system-column are user-defined columns and system-specific columns introduced earlier.

There were multiple model and annotation changes made in all deployments except CIRM over the last 12 months. As expected, the changes are bursty—there were a few larger changes mixed in with no or small changes. The bigger changes correspond to model extensions to support new assay types or use cases. For example, the model changes in GUDMAP/RBK in Sep 2020 were due to the image annotation addition. Similarly, the spike in changes for Synapse reflects a shift from a completely private collaboration to one supporting a mixture of unreleased and public results. Across projects, the smaller changes usually relate to model tweaking to add or remove metadata fields, types, or linkage. The annotation changes associated with model changes are usually deployed together. However, we also see annotation changes that happened independently of model changes. This is to be expected as presentations can continue to be tweaked for better user experiences or to refactor the annotations when Chaise released new features. Chaise has been successfully used to support model and annotation changes as the science investigations evolve to accommodate more use cases since their inception circa 2016.

Chaise supports diverse user communities and their usage of scientific data. Table 3 summarizes user and data usage statistics of four different user communities through the use of the three application templates between a six-month period from May 1, 2019, to Oct 31, 2019. The table shows: 1) the number of users representing the scale of user communities; 2) the number of data requests across three different Chaise templates and data mutation requests representing the data usage; and 3) the table coverage—the number of tables involved in all Chaise requests—representing the model exposure. Traffic from within our organization is excluded. The number of Chaise requests only reflects the main page events; subsequent requests within the same pages are excluded. Individual mutation requests can involve one or multiple rows.

The data hub deployments (GUDMAP/RBK, FaceBase) have bigger user communities and hence more data requests compared to the smaller closed collaboration deployments (Synapse, CIRM). GUDMAP/RBK and FaceBase are similarly used to curate and publish final data products. There are more assay types in GUDMAP/RBK compared to FaceBase, which potentially explains the higher mutation requests. In Synapse, Chaise plays a key role in facilitating day-to-day collaboration activities to conduct complicated science experiments. Therefore, it is not surprising to see high data usage despite its smaller user community. CIRM data is primarily acquired through an automatic ingest pipeline and Chaise is mostly used to view and/or edit data; this practice is reflected in the low number of mutation requests. Note that the CIRM activities of this period are only 20% comparing to the 12-month period (2019/03/01-2020/02/29) leading to the lab shutdown in March 2020. The model exposure among all deployments is relatively high. The unexposed tables are primarily legacy tables that are no longer linked to the primary model or data navigation menus. Our deployment data demonstrates Chaise’s adaptability to different user sizes, communities, and usage patterns.