@isrd-isi-edu/chaise NPM

Chaise (Computer-Human Access Interface with Schema Evolution)

A suite of web applications that adapt to the data model for data discovery, analysis, visualization, editing, sharing and collaboration.

Chaise is the main front-end component of the DERIVA asset management Platform and utilizes ERMrestJS client library to interact with the DERIVA services including ERMrest (a general relational data storage service), webauthn (authentication provider framework), Hatrac (an object store service), and deriva-web export (allows export from an ERMrest catalog).

Applications

Chaise includes the following applications:

How it works

The following papers describe Chaise in detail:

Model-Adaptive User Interfaces For Collaborative Scientific Data Management. Tangmunarunkit, H.; Shafaeibejestan, A.; Chudy, J.; Czajkowski, K.; Schuler, R.; and Kesselman, C. In Copenhagen, Denmark, March 2020. pdf
Model-Adaptive Interface Generation for Data-Driven Discovery. Tangmunarunkit, H.; Shafaeibejestan, A.; Chudy, J.; Czajkowski, K.; Schuler, R.; and Kesselman, C. In Sophia Antipolis, France, June 2020. pdf

Chaise is intended to support specific user interactions, as briefly introduced above (e.g., discovery, analysis, editing, etc.). As such, its presentation capabilities are narrowly scoped to support these interactions. Thus, Chaise makes a few assumptions about how users will interact with the underlying data.

A few representative but non-exhaustive examples of these assumptions include:

search, explore, and browse collections of data
navigate from one data record to the next by following their relationships (i.e., following links)
add, edit, remove data records from the database
create, alter, or extend the data model itself
subset and export data collections
share data with other users
annotate data records with tags or controlled vocabulary terms

Beyond these baseline assumptions about basic usage, Chaise makes almost no assumptions about the structure of the underlying data model, such as its tables, columns, keys, foreign key relationships, etc. Chaise begins by introspecting the data model by getting the catalog/N/schema resource from ERMrest. The schema resource includes lightweight semantic annotations about the model in addition to the underlying relational database schema.

Chaise uses its rending heuristics to decide, for instance, how to flatten a hierarchical structure into a simplified (or denormalized) presentation for searching and viewing. The schema annotations are then used to modify or override its rendering heuristics, for instance, to hide a column of a table or to use a specific display name in the interface that is different than the column name from the table definition of the schema. Chaise then applies user preferences to further override the rendering decisions and annotations, for instance, to present a nested table of data in a transposed layout (i.e., with the columns and rows flipped).

Resources

The following are some of the documents and resources that we've prepared for users and developers of Chaise. Please refer to docs folder for a full list of documents:

User guides: Contains documents and examples on how you can configure and use Chaise. Some of the more notable documents are:
- Installation: How to install Chaise.
- Chaise Config: How to configure Chaise.
- Navbar app integration: Goes over how the Chaise's Navbar app can be embedded in other web applications.
- Logging: How Chaise is logging server requests as well as client actions.
- Query parameters: Query parameters that can be used in different Chaise applications.
Deveoper guides:
- Chaise developer guide: Useful information for developers of Chaise.
- End to End Testing: How end to end testing in Chaise works.

How to Contribute

When developing new code for Chaise, please make sure you're following these steps:

create a new branch and make your updates to the code in the branch (avoid changing master branch directly);
do your own quality assurance;
update the e2e tests (if applicable);
make sure the liner doesn't throw any errors (make lint should not fail);
make sure you can deploy your code without any issues (make dist && make deploy should not fail);
make sure that all tests are passing before submitting the pull request (make test should be free of errors);
make your pull request, assign it to yourself, and ask someone to review your code.
- Try to provide as much information as you can on your PR. Explain the issues that the PR is fixing, and the changes that you've done in the PR.
- Provide examples if applicable.
- Deploy your changes to a server if applicable and provide links. You should not expect reviewers to deploy your code.
- Make sure Github Action build is successful before merging your PR.
- Resolve the conflicts with master before merging the code (and go through the process of making sure tests are good to go).