How can the level of uncertainty be determined?

You may identify this formula as Heisenberg uncertainty principle,  nature is full of uncertainty and so is the world of business and any other world.  It is not difficult to convince people that uncertainty representation and handling is needed, but people wonder how in practice people will be able to consume and digest uncertainty based systems.   I'll try to refer to it in a series of posts,  the first of them deals with the following issue:  uncertainty handling models assume that the level of uncertainty can be quantified.  Quantification can be in the discrete world, a collection of values, and in the continuous world -- probability, measure of belief, and similar metrics.    The question is -- how can we determine the value that represents uncertainty.

There are three ways to determine uncertainty:   prior knowledge,  observation and  statistical reasoning.

The prior knowledge often exists due to physical properties:  the accuracy of sensor may be a property of the sensor reported by the producer, mathematical models can determine the error rate of physical measurement due to friction or other physical phenomena, this can also be rooted in statistical analysis, but for a various system it is given as prior knowledge.

Observation:  In some cases and observation includes some uncertainty, such as:  I left home somewhere between 8 - 8:30am,  there was an accident somewhere in main street that made me late for the meeting, I heard that the accident was caused due to a drunk driver (but not sure this rumor is true),  I arrived to the meeting a few minutes after the meeting start, and waited a long time to the elevator that took me into the 35th floor.     

This observation is full of inexact fact: time, space, event attributes and more.  People typically does not know how to quantify it, but can use fuzzy terms that can be translated into quantified values either in the discrete space or in the continuous space.

The statistical reasoning path is based on learning mechanism that is based on the ratio between historical input and the real value.  The assumption here is that eventually the real value is known and can be compared to the reported value.

There are some interesting questions about the representation formalism, the coverage that can be obtained by these methods, and the methodology for value assignment.    I'll write about these questions in a following post. 

On Inexact events

Back to chapter 11 in the EPIA book that deals with challenges that developers and users of event processing systems should be aware. One these topics is the issue of inexact events. The basic assumption about current systems is this is a projection of the "closed world assumption" kind of thinking, which assumes that every event that is reported really happened, that every details in the event payload is accurate, and that every event that happened was indeed reported. In reality, one or more of these assumptions may be invalid from several reasons, as shown in the following figure:

As shown in this figure there are several reasons for making one or more of these assumptions invalid.

The source (e.g. sensor) may malfunction; if the source is an instrumented program, there may be a bug in the instrumentation.

The source (event producer) may be malicious, and send wrong information in order to sabotage the system.

The inexactness maybe a projection of temporal anomalies discussed before, e.g. derived event that has not been detected.

This inexactness may be propagated, as a derived event is derived from an event which is by itself inexact.

The source itself may be imprecise, thus some of the content may not be accurate.

The input events may be based on sample or estimates.

The uncertainty does not stop in event content, it also exists in the bridge between events and situations, I'll write on that topic in a separate posting.