Immutability and monotonic reasoning for VF
I am building a SHACL-based system for automatically making all the inferences in a VF model expressed in RDF. The goal is that this gives you a VF engine that does ALL the calculations that VF prescribes, so if you build your application based on it, you can focus on providing the inputs and handling the outputs. Inputs are rejected if they violate the rules. Outputs are Fulfillments
, Claims
, Satisfactions
, changes to EconomicResources
(and probably some more).
The technique I am using is being developed as SHACL Advanced Features, especially the new Rules feature, which does monotonic reasoning. It allows you to generate triples in response to certain conditions present in the data, but not delete any triples.
Unfortunately, the VF model does not lend itself to monotonic reasoning in its current state. One problem is that an EconomicEvent
can change an EconomicResource
's (accounting|onhand)Quantity
(or currentLocation
, or primaryAccountable
- which means deleting a triple and generating a new triple. So, I am thinking about tweaking the model to accommodate for that, and I appreciate any comments:
Essentially, EconomicResources
need to become immutable, and an EconomicEvent
that involves an EconomicResource
always generates a new object - the next version or next state of the resource. Consequently an EconomicResource
can only ever be involved with one event. With that change, the VF model becomes a complete history of all resource modifications. This would require a new relationship, eg. vf:previousState
, and disallow any EconomicEvents
on EconomicResource
instances that have a vf:previousState
relationship pointing at them. Thus, the latest version of an EconomicResource
is the head of a linked list of versions, and each version is connected to the EconomicEvent
that caused the change. If you have a planning or recipe entity that references an EconomicResource
, let's say, a Commitment
, and you now want to generate the EconomicEvent
that will fulfill it, it is possible that the referenced EconomicResource
has already been involved with other EconomicEvents
. In that case, it would not be the head of the vf:previousState
chain and you would have to find the head of that chain in order to instantiate your EconomicEvent
.
Currently, I can't think of another entity in the VF model that currently needs to be mutable, so that would be the only major change. Am I missing one?