A couple of weeks ago, I sat down with Sidney, Thieme, and Daniel to brainstorm about the data model to represent data and data flows in the AstroPlant system, and also to build an API that allows people to pull data and to push instructions.
One core element in the data model is ‘experiment’. Every growth process within a specified period (whether it’s a mushroom, a plant, a fish, larvae, or bacteria) is captured in an experiment: we see growing in and of itself as experimental. By calling it an experiment, we put people in the explorative mindset to see biological growth processes as something to be discovered.
We came up with the following structure – explained beneath the image (relevant UML notations are explained in the UML notation reference sheet at the bottom of this post).
I wonder if you can take a look at it, and see if this fits in the process as you envision it. A UML diagram of the API structure is attached, please use that in combination with my explanation below:
- A user is someone registered. Can be an admin, teacher, project manager, or student. This is defined by roles. Roles are linked to responsibilities and accessibility to features (such as creating a new project).
- A project is a project with a certain (scientific) goal, which is described on the project page. A project can be linked to experiments.
- An experiment is a static object describing details about the research, e.g. – influence of high temperature extremes on survivability of plants (or any other experiment). An experiment is defined broadly, it does not have to be a controlled experiment. Anyone can propose an experiment, and to ‘validate’ experiments proposed or accepted by established institutions/consortia like MELiSSA, we use ‘certificates’.
- A mission can be considered an instance of an experiment, or experiment in action, so it’s more dynamic and updated continuously. An experiment that is executed multiple times has multiple missions capturing the data and other information of these instantiations. It contains information about whether or not the experiment is active, at what stage, and is linked to sensor and user data and hardware/kit(s) being used for the experiment. When executed well, and validated (automatically or by a person qualified for that), a mission can become a ‘certified mission’. That would allow us to provide badges or other types of remunerations for people and organisations that execute experiments well.
- The experiment protocol describes the requirements to be able to do the experiment, both for the user and for the actuators (the light recipe for example). So it has information about what seeds to use, what nutrition, which ‘growth recipe’, what to measure and when and how often, what to do during the different stages and after the experiment, etc. Also the certification details and requirements are part of the protocol (when will a mission be certified?).
Currently we’re using this model to construct our back-end system as well as UX and front-end development. At the same time, we try to maintain consistency with the recently announced Open AgTech API initiative.
What do you think? Let us know – we’re open for feedback!