Table 2.
Tier | Implementation | Properties | Example |
---|---|---|---|
Primary | Database model |
● Fast queries via object-relational mapping ● Takes up space in database even if unused ● Significant work to add to the database model, API and user templates |
● Biosample identifier ● Patient sex, age ● Digital resource file path, size, hash |
Secondary | Database model |
● Fast queries via object-relational mapping ● Additional lookups necessary to link back to the primary database model ● Cannot assume a primary model will have a secondary |
● Cycle threshold metrics for biosamples ● BAM coverage metrics ● Patient healthcare worker or care home status |
Tertiary | Key-value row in generic model |
● More difficult to manage artifacts based on tagged properties alone ● Highly flexible ● No work required to add new tags at any time |
● Locally relevant tags not implemented in a model ● Additional anonymised patient information ● Additional sequencing run information |
Majora stores submitted metadata about artifacts and processes in an SQL database. Metadata is stored differently based on its priority. Fields that are a core part of a model (for example, a sample identifier, or the name of a file) are considered primary metadata and are stored in a distinct database model. Metrics such as the results of a PCR Ct test, or the coverage levels of a BAM are also stored in a distinct database model and are attached to primary models through a database foreign key. Arbitrary metadata can then be stored in key value pairs (not backed by any particular database model) and tagged to primary and secondary models as appropriate