valueflows issueshttps://lab.allmende.io/valueflows/valueflows/-/issues2024-01-23T16:49:30Zhttps://lab.allmende.io/valueflows/valueflows/-/issues/654Agent agreement on events, commitments, claims2024-01-23T16:49:30ZLynn FosterAgent agreement on events, commitments, claimsThis has come up in several groups who want to validate or check events logged by members. We expect it will also come up with transfers. Basically, wherever there is a provider and a receiver, they should agree that the record is corre...This has come up in several groups who want to validate or check events logged by members. We expect it will also come up with transfers. Basically, wherever there is a provider and a receiver, they should agree that the record is correct. This becomes more critical in distributed systems, and feedback from people with that experience would be helpful. @pospi @bhaugen @mayel and anyone!
Bob's initial thought is to create some kind of state or status for those records, which could include things like "data was received" (for distributed systems), "provider asserted", "receiver agreed" or whatever names we like or are standard in other places. Might be the same as "signed", "counter-signed".
Also I don't know if this belongs in the vocabulary, or should be considered a different level - but I think it would be helpful in the vocab. It will probably be exposed in some user interfaces, where the receiver agreement cannot be fully automated.https://lab.allmende.io/valueflows/valueflows/-/issues/603Proposal: "measurement observations" and EconomicResource dimensionality2022-05-16T21:08:40ZpospiProposal: "measurement observations" and EconomicResource dimensionalityA 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 Value...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 of `Measures` to the record (call it `EconomicResource.currentMeasurements`?)
- Resources retain a *"primary dimension"* that we still refer to as their `unitOfEffort`. All accounting math done via `EconomicEvent` operates on the measurement dimension of `unitOfEffort`; if a conversion to that unit is not possible, the `EconomicEvent` is in error.
- Other *"secondary dimensions"* may be arbitrarily declared on the `EconomicResource`. These are manipulated via `MeasurementEvents`. Like `EconomicEvents`, `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 with `MeasurementEvents` are given as absolute values, and the result of the action is simply to directly update the value of the measurement against the `EconomicResource`.
To run through this logic for the *"boxed beef"* use-case, consider the following flow:
1. A `raise` `EconomicEvent` is logged to initialise inventory tracking of the beef boxes as usual.
2. Movement of the boxes through the supply chain primarily occurs via VF's existing `transfer-*`, `move`, `pickup` and `dropoff` actions on `EconomicEvent`.
3. Thermal checks of the boxes are periodically performed by logging `MeasurementEvents` with `{ observedQuantity: { hasNumericValue: XX, hasUnit: 'degrees_celsius' } }`. Each `MeasurementEvent` 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.