Skip to content

possible_data_model_schema

aidanfar0 edited this page Mar 26, 2021 · 3 revisions

A possible Data Model

Syntax & convention

  • An all-caps name refers to a constant e.g. "MAX_ENTRIES"
  • A title case name refers to a type e.g. "Integer", "String" or "Bone" (note that this type is not the same as a JSON or JavaScript type) or a
  • Members (need a better term here) of a type will use snake-case e.g. "creek_name"
  • Named constraints (if we need them) use camel case e.g. "inSouthernHemisphere"
  • Namespaces are denoted by "::" e.g. "faims-core::Integer"
  • Settings for the type (need a better term here also) use kebab case e.g. "super-types"

Semantics

  • A datum corresponds to the data for 1 'submission'. This is submitted by 1 person, on one device.
  • A datum has a list of CouchDB _id linking to other datums that are the 'history' of this submission
  • Historical datums are those that correspond to a submission which now has a more recent version in the DB. These are modified to point to the datum which overwrite it (This creates a linked list, which may be terrible for performance. TO investigate)
  • Datums have metadata: "date" and "person"
  • Datums require ONE project model schema id with revision id. This defines the types and metadatas allowable.
  • Datums have a "type", any namespaced type (possibly a faims builtin type),

Data

Datums have a "data", which is data of the type defined by the "type" string.

  • Classes store their data as JSON Objects, member being object members.
  • Primitives are stored as primitives if possible (Strings, Numbers). when conversion to JSON is performed, if a loss of precision is detected reading said numbers back into the program, (When would be possibly encounter this in FAIMS??), an error is raised to the user.
  • Arrays are stored as JSON arrays
  • Maps are stored as a JSON array of key-value pairs. e.g: "key1", 5], ["key2", 7

MetaData

Datums have a "metadata", which contains the annotations, certainties, etc. When the value of an individual metadatum for a field is left as-is, then it is not written into the datum (to save space), which means accesses use the default for the project. (This does mean that any change in default in the project spec will change values that were already set to the previous default.)

  • There is no default 'namespace', all types must be qualified even if they are defined in the corresponding project schema.

initial passes at using the new data model encoding for the primary models