From our first reflection, we know we need to split the logic of Semantic and Expression. But, from the second reflection, we know we need simple units for computability ease, and a system to handle events on the buffers in and out of those.
This made me think of an old, but well-defined, computation system a school teacher lend me courses about; the sequential systems.
Put in simple words, it is a finite state machine that transits knowing its current state and its input; implementations work at clock time, have locked buffers and produce deterministic output. Those systems are common for automaton; like coffee machine, red light orchestration or robotic hands in factories.
But, in the meantime, our general diagram shows another part of the system: an output Z dependant of the buffered values (x,y)->Z
We have here interdependencies of both an external output flow and an internal output state in the parameters, but no deadlock relative to this approach; the machines iterates its states and it affects its fluxes, as well as the impact of the input.
From a reactive approach, we can consider the system made of 3 fluxes;
- one input flux from which x can be considered a subset matching the unit needs
- one state flux defining internal state of the unit and transiting from y to Y
- one output flux defined as the response from the unit logic as a new flux Z
There, having both an output flux, result of an undefined process of the input and the internal state, as well as an internal flux; we have an influence but a clear split between the Experience and the Semantic in our data flow. We also know each unit creates 2 new fluxes, as expected, one for the dataflow and the other for the interpretation of the data.
We can also represent that more like 2 processes running in the same unit to define its different flows, like here below with added logic blocks on top of the previous sequential diagram. If we extrapolate its structure, to better serve user experience, we define the unit on the right; receiving both raw data encoded in a given comprenssion format, and graph-oriented data queries.
We can define the input processing, though being in a black box, as a mapping occuring under the command of the internal state and linking the input to an intermediary space to apply some thought-vector like logic for providing us with the output flux.
While the state processing defines the logical rules of the process and memorized them through states. Those can see applied to them some level of abstracted logic to define their transitions. As per grouping, generalized concept with sets of transition can be created (such as counting, driving or writing).
Finally, at higher level, the unit, and its state, is nothing more than an attribute, and its value, of some object which represents a concept in data structures.
Now that we isolated a way to represent Experience/Semantic split in data modeling, we freely expand the unit to serve some more specialized purpose. Here the fields are expected to help handle data and create a process layer, from data POV to user POV.
To wrap my head around the unit structure, I wanted to display it with a GUI. What should I graphically display for each unit? Hmm… let’s be a bit creative in the conception. I can think of a Data Vault model-like for the “higher-than-semantic” level of abstraction. This way, we define the attributes, our units, as satellites around objects, which are empty but linkable concepts, that can themselve operate as per close-to-UML rules between each others.
From each attribute, there is an instantiated State Machine Diagram, similar per type of attribute, corresponding to the internal state logic of the sequential system. The processing corresponding to a functional mapping screen. It ends by the data structure and its conversion system.
Could you imagine those bricks of logic to build anything?
As it is a data processing system, relying on its different logics but mostly on externalized processes, but also on asynchronous reactive approach, it’s probably best to consider it a machine-level service layer. Though I still have hard time thinking of use cases to make the most out of it.
I’d like to start an open source implementation for it, as I believe a modular service layer with those features, can also help fragment backend layer into scripts and more complexes processes running along according to service layer needs. I’m pretty sure it could bring some more insightful experience of any machine, so I’ll try it in Java. And, from RAES, I’ll call it Serf (which is not an acronym this time); it refers to medieval servants, as “Jenkins” is already taken and “Skynet” is way too hasty.