Skip to main content

Quality indicators

Quality information on trees, logs and boards can be assigned at several stages, such as inventory, harvesting, and sawmilling. Given that specific indicators might be numerous or change over the project duration, we use a customizable and flexible way to describe quality indicators and define their respective instance values in quality indicator items.

A quality indicator must have the following attributes:

  • name: short indicator title
  • description: indicator notes or textual specifications
  • kind: to what qualifiable entities this indicator can be applied (i.e., trees, tree logs, or boards)
  • value_schema: formal definition of the constraints for values of related quality indicator items

A quality indicator item must:

  • belong to an indicator
  • belong to a qualifiable entity of the indicator kind: tree (harvested or inventory), tree log, or board
  • have a value that conforms to the value schema of the indicator

In addition, for reporting on aggregated quality indicator items, we use a likewise way to describe quality indicator aggregations and define their respective instance values in quality indicator aggregates.

Hence, a quality indicator aggregation specifies the constraints of aggregate values, and must have the following attributes:

  • quality_indicator_id: the ID of the quality indicator to which it belongs
  • name: short aggregation title
  • description: aggregation notes or textual specifications
  • kind: to what reportable entities this aggregation can be applied (e.g., inventory or harvesting report)
  • value_schema: formal definition of the constraints for values of related quality indicator aggregates

A quality indicator aggregate must:

  • belong to an aggregation
  • belong to a reportable entity of the aggregation kind (e.g., inventory or harvesting report)
  • have a value that conforms to the value schema of the aggregation
note

Due to schema and kind validation of indicators and aggregations, once created one can only update their name and description to avoid having invalid quality indicator items or aggregates.

Value schemas

To formally define a value schema, we use a subset of JSON Schema.

To specify that an item value can only have a single number:

{
"type": "number"
}

To specify that an item value can only have a single string:

{
"type": "string"
}

To specify that an item value can only be one from a predefined set:

{
"enum": ["a", "b", "c"]
}

You can also specify additional type constraints:

{ 
"type": "string",
"minLength": 3,
}
{ 
"type": "integer",
"minimum": 0,
"maximum": 100
}

Or more complex objects:

{
"type": "object",
"required": ["count", "kind"],
"properties": {
"count": {
"type": "integer",
"minimum": 1
},
"kind": { "enum": ["a", "b"] },
"note": { "type": "string" }
}
}

Supported JSON Schema features

Supported types:

  • string
  • number and integer
  • array
  • object
  • null
  • boolean

Supported enumerated and constant values:

  • enum can be provided either as a generic keyword (schema without a type value), or on a typed schema.
  • const may only be provided as a generic keyword.

Supported boolean combinations:

  • not
  • anyOf
  • allOf
  • oneOf
tip

Try to keep composite value schemas simple, otherwise working with item values could be cumbersome.