Proposal: "measurement observations" and EconomicResource dimensionality
A conversation has come up in a beef industry use-case regarding the tracking of custom measurements against resources. I'm opening this up as a broader conversation as it has implications for the way we conceptualise the domain of ValueFlows as a grammar.
The short version is that there is a ResourceSpecification
for "boxed beef". This ontology includes additional attributes, such as the cut of meet, breed of cow etc. EconomicResource
instances which conformsTo
this ResourceSpecification
have an additional temperature
measurement, which is tracked along the supply chain as an indicator to the quality of the final consumer product.
Option A: extensions to EconomicEvent
An original suggestion of mine was that this could be managed via the tracking of a "measure temperature" Process
, where the modify
output of the Process
would include the temperature reading as part of the EconomicEvent
(likely via an extended schema field, observedTemperature
). The system would have custom logic extending the core VF vocabulary that would handle the update of EconomicResource.temperature
in response to the observedTemperature
attribute of inbound EconomicEvents
.
In this implementation we are pushing this use-case into "nonstandard extensions", and essentially stating that ValueFlows does not consider such measurements within the domain of its model.
Option B: implement MeasurementEvent
@fosterlynn had the suggestion that we create "a very simple non-economic event, some kind of observation data recording for a resource. Seems like most often it would be very simple, and very repetitive, especially if it comes from sensors. But perhaps sometimes it could require a process to make it happen, like if someone has to go make the measurement and they want work recorded at that level of detail."
IMO this is a pretty elegant way of handling it (certainly fewer null fields being stored unnecessarily). In this case, in the process of including measurement-specific concepts in the grammar, we begin to acknowledge ValueFlows as a measurement ontology - not just an economic ontology. I'm a fan of movement in this direction as it acknowledges both the higher forms of abstraction at play and also the interaction between these areas of expertise in the real world.
This is about as far as we spoke about this, which is why I'd like to extend that idea with...
Option B+1: multi-dimensional EconomicResource
measurements
Taking Lynn's suggestion further and thinking about how we might represent these recordings as data leads me to this idea.
One reason to like it is that it gives EconomicResource.unitOfEffort
more utility- so far, I've yet to see much use for this field other than initialising the units of resource quantities. I also see this evolution in a similar light to the new metadata attributes added to Actions
- they provide additional semantic structure that makes reasoning about the semantics of ValueFlows much easier. Anyway, consider this proposal:
- We extend
EconomicResources
to allow them to be measured by multiple units, in parallel dimensions. We would add an array ofMeasures
to the record (call itEconomicResource.currentMeasurements
?) - Resources retain a "primary dimension" that we still refer to as their
unitOfEffort
. All accounting math done viaEconomicEvent
operates on the measurement dimension ofunitOfEffort
; if a conversion to that unit is not possible, theEconomicEvent
is in error. - Other "secondary dimensions" may be arbitrarily declared on the
EconomicResource
. These are manipulated viaMeasurementEvents
. LikeEconomicEvents
,MeasurementEvents
are used both to initialise new measurement dimensions on the resource and to update the value of the field. - Unlike
EconomicEvents
, the quantities specified withMeasurementEvents
are given as absolute values, and the result of the action is simply to directly update the value of the measurement against theEconomicResource
.
To run through this logic for the "boxed beef" use-case, consider the following flow:
- A
raise
EconomicEvent
is logged to initialise inventory tracking of the beef boxes as usual. - Movement of the boxes through the supply chain primarily occurs via VF's existing
transfer-*
,move
,pickup
anddropoff
actions onEconomicEvent
. - Thermal checks of the boxes are periodically performed by logging
MeasurementEvents
with{ observedQuantity: { hasNumericValue: XX, hasUnit: 'degrees_celsius' } }
. EachMeasurementEvent
logs a timestamp and observing agent automatically.
From my perspective, this ties off a few loose ends in the grammar and sets us up for the broadest possible spectrum of use-cases moving forward. Interested in hearing other reflections.