"In many event processing systems [...] events are immutable"1. This stems from the definition of what an event is: "An event is an occurrence within a particular system or domain; it is something that has happened, or is contemplated as having happened [...]"2. So events cannot be made to unhappen.
Open Question: Does this apply to all systems/applications/usecases or just to "many" as stated above?
I made immutability a general assumption in my work3. It is very useful for building systems (distributed systems, consistency, ...).
Q: How can a Stream processing agent process events if they are immutable?
A: Every processing task produces new derived events as results. Advantage: the underived events are still available for other uses and remain immutable.
For RSP this means: (1) create a new (unique) graph for the derived event (2) possibly link back to the base event(s) thus enabling drill-down or root cause / provenance analysis of the derived event. The links can be made with
DUL:hasConstituent from DOLCE Ultralight4. In my own work5 I use a new
:members property to link from a derived event to its simple events. The property is a subproperty of the mentioned
Observation: We talk about adding "received time" and other metadata later by receiving agents: Adding triples later to the event graph with graphname as subject can still be legal and considered as amending the event header. Much like with email: headers can be added by intermediate mail servers but the mail body and ID are immutable.
Etzion, O. & Niblett, P. Event Processing in Action Manning Publications Co. (2010) ↩︎