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.
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.
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.
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.
The matching process narrows down the available facilities in three broad steps (each building on the previous step):
- 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?)
- Analyses offered
- does the facility offer at least one of the analytical services required?
- 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.
The code for the app is fully open source and can be found on GitHub.