Creating a standard 'interpretation' layer on top of core farmOS schema

I think having a well-specified data schema separate from the actual farmOS implementation of that schema could be very trasformative to the software ecosystem around farmOS.

Some of the uses I can imagine;

  • Caching/aggregation layers
  • API decorators/facades
  • Representing complex test data to be loaded into farmOS for integration-level testing and/or demo/tutorial purposes
  • Drupal-version-agnostic backup/migration tooling - e.g. the farmOS 2.x migration could use a well-defined schema as part of the migration path

These might be obvious or captured elsewhere already, but here’s a stab at a few axioms for defining such a schema;

  • Three categories of data types model all data in the schema; data-field types, top-level data types, and views.
  • Three top-level data types exist in the schema; assets, areas, and logs.
  • Top-level data types have two immutable attributes; type and primary-id.
  • Assets represent physical things or logical collections of things.
  • Areas represent logical - possibly geospatial - locations where assets can be or logs can take place.
  • Logs hold data associated with a point in time - and possibly associated with one or more assets or areas.
  • Logs are mutable, but should rarely be changed after creation except where the data therein was in error at the time it was created. Generally, new information should just go in a new log to supersede the old one.
  • Data-fields apply to one or more types of assets, areas, or logs.
  • Data-fields of assets and areas are modeled via logs which reference that asset thereby providing both the current value and a history of the values of those data fields.
  • The manner in which the logs for an asset or area are combined to determine its current data-fields is defined on a field-by-field basis - i.e. some fields might just take the most recent log value for that field whereas others might be the sum of the log values for that field.
  • Data-field types are defined in a manner which is format/language agnostic while being conducive to easy implementations in common formats/languages - e.g. ISO8601 dates as UTF8 strings or numbers conforming to RFC 7159 but implemented as either a numeric or string type depending on format support.
  • Views represent the current state of a asset, area, or log including all its data-fields.
  • A log is effectively a view of itself.
  • The view of an asset or area is the current value for each data-field from its logs.
  • The format of the core schema specification encourages extension via new types of assets, areas, or logs and new data-field types.
  • These extensions to the core schema are specified in the same format as the core schema and implementations are encouraged to support use of the core schema plus any number of extensions.
1 Like