GeoCoLab – the ‘match-making’ app for geoscience researchers and labs

In order to demonstrate the GeoCoLab concept, we created an interactive website (the “app”) that serves as a simplified version of the intended final product. Once populated with a set of example facilities and institutions, the user can make an “application” to access particular analytical facilities and be instantly matched with labs that are able to meet their needs.

Architecture

The app is currently hosted on Heroku, which provides free (for small apps) hosting with minimal server configuration. For a pilot project, this is ideal, but it does mean that there are some constraints that would not usually be an issue in a full production setup.

The image above shows a brief overview of the app’s structure on Heroku. The main process is a Flask server run with gunicorn, pulling various static files and templates that have been transformed/built before deployment using Snowpack. The Flask server also has access to a PostgreSQL database, provided by a Heroku “add-on”, where the app’s data are stored. The user interacts with the pages displayed by the Flask server.

Database

As a pilot project, the database models do not cover all the attributes that will likely be covered in a production environment; they instead contain more obvious or quickly implemented data points that will help to illustrate the concept.

The diagram above shows the seven database models implemented in the app. These are defined using SQLAlchemy and migration/upgrade scripts are generated and applied using Alembic.

A User is an account on the app, i.e. a person with a login. Each User can create one or more Application instances (e.g. for different analyses or different time periods). Each User can also manage multiple Org or Facility instances; an Org is an organisation such as a university or company, and a Facility is a collection of equipment or services owned by one Org (e.g. a lab or a department). A User who manages an Org automatically has management access to all of its Facility instances, but they can also manage a Facility directly if they do not have access to the whole Org.

Each Facility can offer a number of Analysis services. These analyses are predefined by GeoCoLab admins and are organised hierarchically, e.g.:

Imaging > Optical microscopy
        > Electron microscopy > Scanning
                              > Transmission

Thus a Facility providing the Imaging Analysis would also provide all four of its child Analysis services.

An Application also links to a number of Analysis services in order to request access.

Each Facility has one or more Slot instances, each signalling availability of the facility’s services. The number of associated Slot instances is the number of simultaneous requests that the Facility can handle.

When an Facility meets the requirements of an Application, an Offer can be created to “book” a Slot for a given length of time. Any subsequent searches from other applications will consider that Slot unavailable for that time period.

Matching

The matching process narrows down the available facilities in three broad steps (each building on the previous step):

1. Location, access type, and funding
   • does the org allow the requested access type (e.g. can an applicant visit if desired)?
   • does the org provide the funding needed based on its location (e.g. applicant can only fund domestic travel, but Org is in another country - does the org provide international travel funding?)
2. Analyses offered
   • does the facility offer at least one of the analytical services required?
3. Open slots
   • ignoring any slots that are fully occupied during the search date range, are there any open slots for the facility?

From the results, the first available gap of the required length across all slots of each facility is found and then the facilities are presented anonymously to the applicant.

Further information

The code for the app is fully open source and can be found on GitHub.