Skip to content

index

Jump to bottom
Aidan Farrell edited this page Mar 26, 2021 · 5 revisions

Overall Model for FAIMS

Nuria Lorente Simon O'Toole and James Tocknell spent some time at the whiteboard trying to work how best to model the system for FAIMS 3. For consistency and to reduce confusion, we are going to use the following terms:

  • Data Model: the model for how the data (as individual datums) taken by Researchers is encoded into the database (in our case couchdb). There is a single Data Model for the FAIMS project.
  • Project Specification: the specification for what data the Project Lead wants to be collected by their research team. There is a single Project Specification per project.
  • GUI Specification: the specification for how the data in entered/displayed to users in the app. There is a single GUI Specification per project.
  • Project Lead: the person (or persons) who manage the data collection process: they decide the collection methodology, user access control etc.
  • Researcher: the person who inputs (and possibly views) the data. The Project Lead may or may not be a Researcher.
  • User Model: the per-project model of how users (i.e. Researchers) interact with access control, auth(n/z). This will likely be derived from a global models for users in FAIMS.

Here's the whiteboard of how they are related (Substitute Project Model for Project Specification, and GUI Model for GUI Specification): Photo of whiteboard session

Both the Project Specification (the what) and the GUI Specification (the how) are needed to specify the forms that make up a project (a "module" in FAIMS 2.6 parlance). The Project Specification specifies the properties of the type of the data, and how to validate the researcher input. The individual Project Specification and GUI Specification for a particular project both need to be directly encoded into the database (as both are created and modified by the project lead), so that such information can be propagated between devices (the Data Model is abstract, and set by the developers, and hence does not need to be directly encoded into the database).

James has tried using https://typeschema.org/ to encode the Project Specification, but found it somewhat cumbersome. The consensus (given we'd need a custom layer to generate forms anyway), is having something custom that fits our need is better that trying to hack our way around some other system (e.g. https://json-schema.org/ or TypeSchema). We need to think about how best to encode the Project Specification. See here for an initial design of a custom solution for the Project Specification.

James also had a vague stab at a GUI model system, though this is a very rough version.

Aidan has added examples for what he envisions the data to look like here, with oral history example. Aidan has also added onto the project model where he has seen deficiencies

Clone this wiki locally