"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 <abbr title="RDF Stream Processing">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.
- Luckham, D. C. & Schulte, R. Event Processing Glossary – Version 2.0 (2011) ↩
- Etzion, O. & Niblett, P. Event Processing in Action Manning Publications Co. (2010) ↩
- Stühmer, R. Web-oriented Event Processing Karlsruhe Institute of Technology, KIT Scientific Publishing, Karlsruhe, 2014 ↩
- Gangemi, A. DOLCE+DnS Ultralite (DUL) (2009) ↩
- Harth, A. & Stühmer, R. Publishing Event Streams as Linked Data Karlsruhe Institute of Technology, FZI Forschungszentrum Informatik (2011) ↩