MSc
python-oced
A reference implementation of the Object-Centric Event Data model in one module and, more usefully, the design journal of the eleven modelling problems it ran into.
Classical process mining assumes every event belongs to exactly one case. Object-Centric Event Data drops that assumption: an event can create, delete, modify or merely involve any number of objects, and those objects carry attributes and relationships that change over time. This implements that model in a single module.
- Shape
- One module, 13 tables, 13 qualifier types, 15 classes
- Storage
- Interlinked pandas DataFrames with declared keys
- Design notes
- NOTE.md, 11 numbered problems each with its resolution
- Role
- Author
- Repository
- VincenzoImp/python-oced
The problem
The single-case assumption is convenient and false. An order, the items in it, the payment and the shipment are separate objects with separate lifecycles, and forcing each event to belong to one of them means choosing which perspective to lose.
Removing that assumption creates a harder question, though, and it is not about code: if an event can touch any number of objects in any combination, what exactly is an event allowed to do, and what does the store have to remember so that a question asked later still has an answer?
What I built
Everything an event does is expressed as an ordered list of qualifiers, and the qualifiers form a
grid: create, delete, modify and involve, applied to objects, object relations and object
attribute values. Thirteen of those combinations exist. An Event carries a time, a type, its
ordered qualifiers and its own attributes, and lands in thirteen interlinked tables.
Insertion is precondition, then execute, then log. The precondition validates the entire qualifier list before any of it runs, so an event that is invalid halfway through leaves no trace: there is no partial application to unwind. Sixty-three distinct validation sites enforce types, identifier uniqueness, existence, self-relations and no-op modifications.
Deletion is soft: an existency flag rather than a removed row, so history survives. Getters
return deep copies, so no caller can reach in and mutate the store.
Hard parts
The interesting part of this repository is not the code. It is NOTE.md, a handwritten journal
of eleven modelling problems, each with the option taken and the cost accepted.
Order inside an event. If one event creates an object, deletes it, and creates it again, the store has to record that object three separate times and preserve the sequence. The resolution was to keep the full ordered qualifier history rather than collapse to a final state, so the true order is recoverable afterwards.
What belongs in the key. Attribute values are keyed by value and object, deliberately not by name. The note records the price of that: two attributes can end up with different identifiers but the same name and the same value, and a human reading the table cannot tell them apart.
Rules that only hold locally. Modifying a value to the value it already has is forbidden, but the check only compares a qualifier with its immediate successor, so modify to 2, modify to 1, modify to 2 slips through. The note writes out that exact hole rather than claiming the rule is general.