5 Similarity computation
5.2 Enhanced search pattern building blocks
5.2.2 Restrictive blocks
5.2.2.1 Attribute constraints
In section 4.2.10.1 attribute constraints have been introduced as conditions required to be fulfilled in order to form a valid solution. Hence, it is not sufficient to set the event similarity to zero in case of an un‐fulfilled attribute constraint. Instead, it must be guaranteed that the complete solution is omitted.
This can be achieved by introducing an extended compatibility which guarantees each attribute constraint to be fulfilled. Given a pattern‐sequence , a set of attribute constraints , … , with :
0,1 1 … on events of type and a compatibility : ε 0,1 , we define an adapted version : ε 0,1 of as follows:
,
, ,
, ,
Formula 18: Extended compatibility function for attribute constraints
This means, plainly spoken, that an event is only compatible for a mapping, if all attribute constraints are fulfilled.
5.2.2.2 Required block
Given a pattern‐sequence , a “required”‐block and a compatibility : ε 0,1, we define an adapted version : ε 0,1 of as follows:
, 0,
, ,
Formula 19: Extended compatibility function for “required”‐blocks
Thus, when using instead of , null‐mappings are considered invalid for all those events that are part of the
“required”‐block.
Example. Consider two event sequences and and a “required”‐block as shown below:
Figure 37: Example for a “required” block
Given above defined, adapted compatibility the following solutions of are considered valid:
Figure 38: Tree of valid solutions in case of a “required”‐block
As a “required” block has no effect on the calculation of a solution similarity, but instead only excludes certain solutions, we omit the similarity computation n the given example.
5.2.2.3 Time of occurrence constraints
Given a pattern‐sequence , a “time of occurrence”‐block with a time interval reaching from to
as well as and a compatibility : ε 0,1, we define an adapted version of as follows:
, 0,
, ,
Formula 20: Extended compatibility function for “time of occurrence”‐blocks
Thus, when using instead of , all mappings between pattern‐sequence events in and target‐sequence events “outside” are considered invalid.
Example. Consider two event sequences and and a “time of occurrence”‐block as shown below:
Figure 39: Example for a “time of occurrence” block
In the given example, and are outside of . Therefore, with a base event‐type compatibility with , 1 for all , the following solutions of are considered valid:
48
Figure 40: Tree of valid solutions in case of a “time of occurrence”‐block
5.2.2.4 Maximal time s an p constraints
Given a solution : and a “maximal time span”‐block with a maximal time span of , let us define a maximal time‐span function : 0,1 with
, , … , 1, , , … ,
0,
Formula 21: Maximal time span function
We now consider valid only if results in 1 for all events in .
Note that an evaluation of whether the maximal time span in a set of target‐sequence events exceeds the given threshold is valuable each time a new target‐sequence event gets known: From it follows that for each . We therefore integrate the “maximal time span”‐block as follows into the base algorithm: When adding a node that represents a mapping for the th event in a “maximal time span”‐block , i.e., a mapping , with and , 1, we evaluate for the node and its 1 predecessors. If returns 1, the recursive algorithm is continued; otherwise, if
results in 0, the algorithm is cancelled for the concerned path.
In pseudo‐code, an efficient implementation of a “maximal time span”‐block can be described as follows:
Algorithm 2: Processing of maximal time span constraints ‐ AddMapping()
Input: Event prevPatternEvent, Event prevMatch, Event patternEvent, Event match, int index
Output: A BlockResult object if the mapping (patternEvent, match) is valid with respect to the given block M, null otherwise.
Variables: Pairs of time stamps (i.e. temporal ranges) lastRange and newRange. Time stamps earliest and latest.
50
State: The maximal time span timespan; ranges, a stack of maximal temporal ranges between target‐sequence events, with the ith element representing the temporal range between the first i target‐sequence events in M.
Pair<TimeStamp, TimeStamp> lastRange;
if (ranges.length == 0) then
lastRange = new Pair<TimeStamp, TimeStamp>(null, null);
else
lastRange = ranges.peek();
end
// Calculate new range…
if (match = ) then
TimeStamp latest = lastRange econd;
e
earliest = (mat );
.S
if (earliest = null or arliest > (match)) then ch
if (latest = null or latest < (match)) then
end
earliest = (match);
end
// Evaluate range afte earch new mapping, return “null” if illegal r if ( lastRange.First null and
lastRange.Second null and
(lastRange.Second ‐ lastRange.First) > timespan)) then
In the block’s RemoveMapping()‐function, the stack’s top‐element is removed via ranges.pop(). The SetSucceedingMapping()‐function is irrelevant and returns null.
Example. Consider two event sequences and and a „maximal time span“‐block with a maximal time span 20 as shown below:
Figure 41: Example for a “maximal time span” constraint block
With the above described block implementation and an event‐type compatibility with , 0 for all , the following tree is calculated; here, those nodes that are not continued due to the maximal time‐span constraint are marked with a red border:
Figure 42: Tree of solutions for a “maximal time span” constraint block
5.2.2.5 Minim al time span constraints
Given a solution : and a “Minimal time span” constraint with a minimal time span , let us define a minimal time‐span function : 0,1 as
, , … , 1, max min
0, .
Formula 22: Minimal time span function
We now consider valid only if results in 1 for the events in .
Unlike in case of the maximal time‐span constraint, evaluating whether the minimal time span in set of target‐
sequence events is greater than a certain threshold is only possible as soon as the complete set of target‐sequence events is known: From it does not follow that for an . We therefore integrate the minimum‐time‐span functionality as follows into the base algorithm:
When adding a node that represents a mapping for the last event of a “minimal time span”‐block , i.e., a mapping , with and , | |, we evaluate for the node and its | | 1
52
predecessors. If results in 1, the recursive algorithm is continued; otherwise, if results in 0, the algorithm is cancelled for the given certain path.
Output: A BlockResult object if the mapping (patternEvent, match) is valid with respect to the given block M, null otherwise.
Variables: Pairs of time stamps (i.e. temporal ranges) lastRange and newRange. Time stamps earliest and latest.
State: The position endPosition of the last pattern‐sequence element in M. The minimal time span timespan. A stack ranges of maximal temporal ranges between target‐sequence events, with the ith element representing the temporal range between the first i target‐sequence events in M.
TimeStamp latest = lastRange econd;
e
earliest = (match);
.S
if (earliest = null or arliest > (match)) then
end
if (latest = null) or latest < (match)) then earliest = (match);
end
lastRange.First == null or
lastRange.Second == null or
(lastRange.Second ‐ lastRange.First) < timespan) then
SetSucceedingMapping() function is irrelevant and returns null.
Example. Consider two event sequences and and a „minimal time span“‐block with a maximal time span 20 as shown below:
Figure 43: Example for a “minimal time span” constraint block
With the above block implementation and an event‐type compatibility with , 0 for all , the solutions tree is generated as shown in Figure 44. Here, those nodes that are not continued due to the minimal time‐span constraint are marked with a red border:
Figure 44: Tree of solutions for a “minimal time span” constraint block
5.2.2.6 Strict order con tra s int block
Given a solution : and a “strict order”‐constraint block , let us define an order‐function
: 0,1 as
, 0, , , ,
1, .
Formula 23: Strict order function
We now consider valid only if results in 1 for each pair of successive pattern‐sequence events , ,
, , , , 1.
54
Output: A BlockResult object if the mapping (patternEvent, match) is valid with respect to the given block M, null otherwise.
Variables: Positions in the target‐sequence lastPosition and nextPosition.
State: positions, a stack of positions of target‐sequence events in the target sequence, with the ith element representing the last position throughout the first i target‐sequence events in M.
If (position.length == 0) then lastPosition = null;
else
lastPosition = position.peek();
end
// Calculate new position…
if (match = ) then
new int[] { index + 1},
CalcDefaultCosts(prevPatternEvent, prevMatch, patternEvent, match));
end
Example. Consider two event sequences and and a „strict order“‐constraint block as shown below:
Figure 45: Example for a “strict order” constraint block
With an order‐function as defined above and an event‐type compatibility with , 0 if , the
following tree of solution is generated. Again, those nodes that are not continued are marked with a red border.
Figure 46: Tree of solutions for a “strict order” constraint block