pm4py.conformance module#
The pm4py.conformance module contains the conformance checking algorithms implemented in pm4py.
- pm4py.conformance.conformance_diagnostics_token_based_replay(log: EventLog | DataFrame, petri_net: PetriNet, initial_marking: Marking, final_marking: Marking, activity_key: str = 'concept:name', timestamp_key: str = 'time:timestamp', case_id_key: str = 'case:concept:name', return_diagnostics_dataframe: bool = False, opt_parameters: Dict[Any, Any] | None = None) List[Dict[str, Any]][source]#
Apply token-based replay for conformance checking analysis. This method returns the full token-based replay diagnostics.
Token-based replay matches a trace against a Petri net model, starting from the initial marking, to discover which transitions are executed and in which places there are remaining or missing tokens for the given process instance. Token-based replay is useful for conformance checking: a trace fits the model if, during its execution, all transitions can be fired without the need to insert any missing tokens. If reaching the final marking is imposed, a trace fits if it reaches the final marking without any missing or remaining tokens.
In PM4Py, the token replayer implementation can handle hidden transitions by calculating the shortest paths between places. It can be used with any Petri net model that has unique visible transitions and hidden transitions. When a visible transition needs to be fired and not all places in its preset have the correct number of tokens, the current marking is checked to see if any hidden transitions can be fired to enable the visible transition. The hidden transitions are then fired, reaching a marking that permits the firing of the visible transition.
The approach is described in: Berti, Alessandro, and Wil MP van der Aalst. “Reviving Token-based Replay: Increasing Speed While Improving Diagnostics.” ATAED@ Petri Nets/ACSD. 2019.
The output of the token-based replay, stored in the variable replayed_traces, contains for each trace in the log:
trace_is_fit: Boolean value indicating whether the trace conforms to the model.
activated_transitions: List of transitions activated in the model by the token-based replay.
reached_marking: Marking reached at the end of the replay.
missing_tokens: Number of missing tokens.
consumed_tokens: Number of consumed tokens.
remaining_tokens: Number of remaining tokens.
produced_tokens: Number of produced tokens.
- Parameters:
log – Event log.
petri_net – Petri net.
initial_marking – Initial marking.
final_marking – Final marking.
activity_key – Attribute to be used for the activity (default is “concept:name”).
timestamp_key – Attribute to be used for the timestamp (default is “time:timestamp”).
case_id_key – Attribute to be used as the case identifier (default is “case:concept:name”).
return_diagnostics_dataframe – If possible, returns a dataframe with the diagnostics instead of the usual output (default is constants.DEFAULT_RETURN_DIAGNOSTICS_DATAFRAME).
opt_parameters – Optional parameters for the token-based replay, including: * reach_mark_through_hidden: Boolean to decide if the final marking should be reached through hidden transitions. * stop_immediately_unfit: Boolean to decide if the replay should stop immediately when non-conformance is detected. * walk_through_hidden_trans: Boolean to decide if the replay should walk through hidden transitions to enable visible transitions. * places_shortest_path_by_hidden: Shortest paths between places using hidden transitions. * is_reduction: Indicates if the token-based replay is called in a reduction attempt. * thread_maximum_ex_time: Maximum allowed execution time for alignment threads. * cleaning_token_flood: Decides if token flood cleaning should be performed. * disable_variants: Disable variants grouping. * return_object_names: Decide whether to return names instead of object pointers.
- Returns:
A list of dictionaries containing diagnostics for each trace.
- Return type:
List[Dict[str, Any]]
- Example:
-
- net, im, fm = pm4py.discover_petri_net_inductive(
dataframe, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
) tbr_diagnostics = pm4py.conformance_diagnostics_token_based_replay(
dataframe, net, im, fm, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
- pm4py.conformance.conformance_diagnostics_alignments(log: EventLog | DataFrame, *args, multi_processing: bool = False, activity_key: str = 'concept:name', timestamp_key: str = 'time:timestamp', case_id_key: str = 'case:concept:name', variant_str: str | None = None, return_diagnostics_dataframe: bool = False, **kwargs) List[Dict[str, Any]][source]#
Apply the alignments algorithm between a log and a process model. This method returns the full alignment diagnostics.
Alignment-based replay aims to find one of the best alignments between the trace and the model. For each trace, the output of an alignment is a list of pairs where the first element is an event (from the trace) or
»and the second element is a transition (from the model) or». Each pair can be classified as follows:Sync move: The event and transition labels correspond, advancing both the trace and the model simultaneously.
Move on log: The transition is
», indicating a replay move in the trace that is not mirrored in the model. This move is unfit and signals a deviation.- Move on model: The event is
», indicating a replay move in the model not mirrored in the trace. These can be further classified as: Moves on model involving hidden transitions: Even if it’s not a sync move, the move is fit.
Moves on model not involving hidden transitions: The move is unfit and signals a deviation.
- Move on model: The event is
For each trace, a dictionary is associated containing, among other details:
alignment: The alignment pairs (sync moves, moves on log, moves on model).
cost: The cost of the alignment based on the provided cost function.
fitness: Equals 1 if the trace fits perfectly.
- Parameters:
log – Event log.
args – Specifications of the process model.
multi_processing – Boolean to enable multiprocessing (default is constants.ENABLE_MULTIPROCESSING_DEFAULT).
activity_key – Attribute to be used for the activity (default is “concept:name”).
timestamp_key – Attribute to be used for the timestamp (default is “time:timestamp”).
case_id_key – Attribute to be used as the case identifier (default is “case:concept:name”).
variant_str – Variant specification (for Petri net alignments).
return_diagnostics_dataframe – If possible, returns a dataframe with the diagnostics instead of the usual output (default is constants.DEFAULT_RETURN_DIAGNOSTICS_DATAFRAME).
- Returns:
A list of dictionaries containing diagnostics for each trace.
- Return type:
List[Dict[str, Any]]
- Example:
-
- net, im, fm = pm4py.discover_petri_net_inductive(
dataframe, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
) alignments_diagnostics = pm4py.conformance_diagnostics_alignments(
dataframe, net, im, fm, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
- pm4py.conformance.fitness_token_based_replay(log: EventLog | DataFrame, petri_net: PetriNet, initial_marking: Marking, final_marking: Marking, activity_key: str = 'concept:name', timestamp_key: str = 'time:timestamp', case_id_key: str = 'case:concept:name') Dict[str, float][source]#
Calculate the fitness using token-based replay. The fitness is calculated on a log-based level. The output dictionary contains the following keys: - perc_fit_traces: Percentage of fit traces (from 0.0 to 100.0). - average_trace_fitness: Average of the trace fitnesses (between 0.0 and 1.0). - log_fitness: Overall fitness of the log (between 0.0 and 1.0). - percentage_of_fitting_traces: Percentage of fit traces (from 0.0 to 100.0).
Token-based replay matches a trace against a Petri net model, starting from the initial marking, to discover which transitions are executed and in which places there are remaining or missing tokens for the given process instance. Token-based replay is useful for conformance checking: a trace fits the model if, during its execution, all transitions can be fired without the need to insert any missing tokens. If reaching the final marking is imposed, a trace fits if it reaches the final marking without any missing or remaining tokens.
In PM4Py, the token replayer implementation can handle hidden transitions by calculating the shortest paths between places. It can be used with any Petri net model that has unique visible transitions and hidden transitions. When a visible transition needs to be fired and not all places in its preset have the correct number of tokens, the current marking is checked to see if any hidden transitions can be fired to enable the visible transition. The hidden transitions are then fired, reaching a marking that permits the firing of the visible transition.
The approach is described in: Berti, Alessandro, and Wil MP van der Aalst. “Reviving Token-based Replay: Increasing Speed While Improving Diagnostics.” ATAED@ Petri Nets/ACSD. 2019.
The calculation of replay fitness aims to assess how much of the behavior in the log is admitted by the process model. Two methods are proposed to calculate replay fitness, based on token-based replay and alignments respectively.
For token-based replay, the percentage of traces that are completely fit is returned, along with a fitness value calculated as indicated in the referenced contribution.
- Parameters:
log – Event log.
petri_net – Petri net.
initial_marking – Initial marking.
final_marking – Final marking.
activity_key – Attribute to be used for the activity (default is “concept:name”).
timestamp_key – Attribute to be used for the timestamp (default is “time:timestamp”).
case_id_key – Attribute to be used as the case identifier (default is “case:concept:name”).
- Returns:
A dictionary containing fitness metrics.
- Return type:
Dict[str, float]
- Example:
-
- net, im, fm = pm4py.discover_petri_net_inductive(
dataframe, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
) fitness_tbr = pm4py.fitness_token_based_replay(
dataframe, net, im, fm, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
- pm4py.conformance.fitness_alignments(log: EventLog | DataFrame, petri_net: PetriNet, initial_marking: Marking, final_marking: Marking, multi_processing: bool = False, activity_key: str = 'concept:name', timestamp_key: str = 'time:timestamp', case_id_key: str = 'case:concept:name', variant_str: str | None = None) Dict[str, float][source]#
Calculate the fitness using alignments. The output dictionary contains the following keys: - average_trace_fitness: Average of the trace fitnesses (between 0.0 and 1.0). - log_fitness: Overall fitness of the log (between 0.0 and 1.0). - percentage_of_fitting_traces: Percentage of fit traces (from 0.0 to 100.0).
Alignment-based replay aims to find one of the best alignments between the trace and the model. For each trace, the output of an alignment is a list of pairs where the first element is an event (from the trace) or
»and the second element is a transition (from the model) or». Each pair can be classified as follows:Sync move: The event and transition labels correspond, advancing both the trace and the model simultaneously.
Move on log: The transition is
», indicating a replay move in the trace that is not mirrored in the model. This move is unfit and signals a deviation.- Move on model: The event is
», indicating a replay move in the model not mirrored in the trace. These can be further classified as: Moves on model involving hidden transitions: Even if it’s not a sync move, the move is fit.
Moves on model not involving hidden transitions: The move is unfit and signals a deviation.
- Move on model: The event is
The calculation of replay fitness aims to assess how much of the behavior in the log is admitted by the process model. Two methods are proposed to calculate replay fitness, based on token-based replay and alignments respectively.
For alignments, the percentage of traces that are completely fit is returned, along with a fitness value calculated as the average of the fitness values of the individual traces.
- Parameters:
log – Event log.
petri_net – Petri net.
initial_marking – Initial marking.
final_marking – Final marking.
multi_processing – Boolean to enable multiprocessing (default is constants.ENABLE_MULTIPROCESSING_DEFAULT).
activity_key – Attribute to be used for the activity (default is “concept:name”).
timestamp_key – Attribute to be used for the timestamp (default is “time:timestamp”).
case_id_key – Attribute to be used as the case identifier (default is “case:concept:name”).
variant_str – Variant specification.
- Returns:
A dictionary containing fitness metrics.
- Return type:
Dict[str, float]
- Example:
-
- net, im, fm = pm4py.discover_petri_net_inductive(
dataframe, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
) fitness_alignments = pm4py.fitness_alignments(
dataframe, net, im, fm, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
- pm4py.conformance.precision_token_based_replay(log: EventLog | DataFrame, petri_net: PetriNet, initial_marking: Marking, final_marking: Marking, activity_key: str = 'concept:name', timestamp_key: str = 'time:timestamp', case_id_key: str = 'case:concept:name') float[source]#
Calculate precision using token-based replay.
Token-based replay matches a trace against a Petri net model, starting from the initial marking, to discover which transitions are executed and in which places there are remaining or missing tokens for the given process instance. Token-based replay is useful for conformance checking: a trace fits the model if, during its execution, all transitions can be fired without the need to insert any missing tokens. If reaching the final marking is imposed, a trace fits if it reaches the final marking without any missing or remaining tokens.
In PM4Py, the token replayer implementation can handle hidden transitions by calculating the shortest paths between places. It can be used with any Petri net model that has unique visible transitions and hidden transitions. When a visible transition needs to be fired and not all places in its preset have the correct number of tokens, the current marking is checked to see if any hidden transitions can be fired to enable the visible transition. The hidden transitions are then fired, reaching a marking that permits the firing of the visible transition.
The approach is described in: Berti, Alessandro, and Wil MP van der Aalst. “Reviving Token-based Replay: Increasing Speed While Improving Diagnostics.” ATAED@ Petri Nets/ACSD. 2019.
The reference paper for the TBR-based precision (ETConformance) is: Muñoz-Gama, Jorge, and Josep Carmona. “A fresh look at precision in process conformance.” International Conference on Business Process Management. Springer, Berlin, Heidelberg, 2010.
In this approach, the different prefixes of the log are replayed (if possible) on the model. At the reached marking, the set of transitions that are enabled in the process model is compared with the set of activities that follow the prefix. The more the sets differ, the lower the precision value. The more the sets are similar, the higher the precision value.
- Parameters:
log – Event log.
petri_net – Petri net.
initial_marking – Initial marking.
final_marking – Final marking.
activity_key – Attribute to be used for the activity (default is “concept:name”).
timestamp_key – Attribute to be used for the timestamp (default is “time:timestamp”).
case_id_key – Attribute to be used as the case identifier (default is “case:concept:name”).
- Returns:
The precision value.
- Return type:
float
- Example:
-
- net, im, fm = pm4py.discover_petri_net_inductive(
dataframe, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
) precision_tbr = pm4py.precision_token_based_replay(
dataframe, net, im, fm, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
- pm4py.conformance.precision_alignments(log: EventLog | DataFrame, petri_net: PetriNet, initial_marking: Marking, final_marking: Marking, multi_processing: bool = False, activity_key: str = 'concept:name', timestamp_key: str = 'time:timestamp', case_id_key: str = 'case:concept:name') float[source]#
Calculate the precision of the model with respect to the event log using alignments.
Alignment-based replay aims to find one of the best alignments between the trace and the model. For each trace, the output of an alignment is a list of pairs where the first element is an event (from the trace) or
»and the second element is a transition (from the model) or». Each pair can be classified as follows:Sync move: The event and transition labels correspond, advancing both the trace and the model simultaneously.
Move on log: The transition is
», indicating a replay move in the trace that is not mirrored in the model. This move is unfit and signals a deviation.- Move on model: The event is
», indicating a replay move in the model not mirrored in the trace. These can be further classified as: Moves on model involving hidden transitions: Even if it’s not a sync move, the move is fit.
Moves on model not involving hidden transitions: The move is unfit and signals a deviation.
- Move on model: The event is
The reference paper for the alignments-based precision (Align-ETConformance) is: Adriansyah, Arya, et al. “Measuring precision of modeled behavior.” Information systems and e-Business Management 13.1 (2015): 37-67.
In this approach, the different prefixes of the log are replayed (if possible) on the model. At the reached marking, the set of transitions that are enabled in the process model is compared with the set of activities that follow the prefix. The more the sets differ, the lower the precision value. The more the sets are similar, the higher the precision value.
- Parameters:
log – Event log.
petri_net – Petri net.
initial_marking – Initial marking.
final_marking – Final marking.
multi_processing – Boolean to enable multiprocessing (default is constants.ENABLE_MULTIPROCESSING_DEFAULT).
activity_key – Attribute to be used for the activity (default is “concept:name”).
timestamp_key – Attribute to be used for the timestamp (default is “time:timestamp”).
case_id_key – Attribute to be used as the case identifier (default is “case:concept:name”).
- Returns:
The precision value.
- Return type:
float
- Example:
-
- net, im, fm = pm4py.discover_petri_net_inductive(
dataframe, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
) precision_alignments = pm4py.precision_alignments(
dataframe, net, im, fm, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
- pm4py.conformance.generalization_tbr(log: EventLog | DataFrame, petri_net: PetriNet, initial_marking: Marking, final_marking: Marking, activity_key: str = 'concept:name', timestamp_key: str = 'time:timestamp', case_id_key: str = 'case:concept:name') float[source]#
Compute the generalization of the model against the event log. The approach is described in the paper:
Buijs, Joos CAM, Boudewijn F. van Dongen, and Wil MP van der Aalst. “Quality dimensions in process discovery: The importance of fitness, precision, generalization, and simplicity.” International Journal of Cooperative Information Systems 23.01 (2014): 1440001.
- Parameters:
log – Event log.
petri_net – Petri net.
initial_marking – Initial marking.
final_marking – Final marking.
activity_key – Attribute to be used for the activity (default is “concept:name”).
timestamp_key – Attribute to be used for the timestamp (default is “time:timestamp”).
case_id_key – Attribute to be used as the case identifier (default is “case:concept:name”).
- Returns:
The generalization value.
- Return type:
float
- Example:
-
- net, im, fm = pm4py.discover_petri_net_inductive(
dataframe, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
) generalization_tbr = pm4py.generalization_tbr(
dataframe, net, im, fm, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
- pm4py.conformance.replay_prefix_tbr(prefix: List[str], net: PetriNet, im: Marking, fm: Marking, activity_key: str = 'concept:name') Marking[source]#
Replay a prefix (list of activities) on a given accepting Petri net using Token-Based Replay.
- Parameters:
prefix – List of activities representing the prefix.
net – Petri net.
im – Initial marking.
fm – Final marking.
activity_key – Attribute to be used as the activity key (default is “concept:name”).
- Returns:
The marking reached after replaying the prefix.
- Return type:
Marking
- pm4py.conformance.conformance_diagnostics_footprints(*args) List[Dict[str, Any]] | Dict[str, Any]#
Provide conformance checking diagnostics using footprints.
- Parameters:
args – Arguments where the first is an event log (or its footprints) and the others represent the process model (or its footprints).
- Returns:
Conformance diagnostics based on footprints.
- Return type:
Union[List[Dict[str, Any]], Dict[str, Any]]
- Example:
-
- net, im, fm = pm4py.discover_petri_net_inductive(
dataframe, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
) footprints_diagnostics = pm4py.conformance_diagnostics_footprints(
dataframe, net, im, fm, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
- pm4py.conformance.fitness_footprints(*args) Dict[str, float]#
Calculate fitness using footprints. The output is a dictionary containing two keys: - perc_fit_traces: Percentage of fit traces (over the log). - log_fitness: The fitness value over the log.
- Parameters:
args – Arguments where the first is an event log (or its footprints) and the others represent the process model (or its footprints).
- Returns:
A dictionary containing fitness metrics based on footprints.
- Return type:
Dict[str, float]
- Example:
-
- net, im, fm = pm4py.discover_petri_net_inductive(
dataframe, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
) fitness_fp = pm4py.fitness_footprints(
dataframe, net, im, fm, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
- pm4py.conformance.precision_footprints(*args) float#
Calculate precision using footprints.
- Parameters:
args – Arguments where the first is an event log (or its footprints) and the others represent the process model (or its footprints).
- Returns:
The precision value based on footprints.
- Return type:
float
- Example:
-
- net, im, fm = pm4py.discover_petri_net_inductive(
dataframe, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
) precision_fp = pm4py.precision_footprints(
dataframe, net, im, fm, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
- pm4py.conformance.check_is_fitting(*args, activity_key='concept:name') bool#
Check if a trace object fits a process model.
- Parameters:
args – Arguments where the first is a trace object and the others represent the process model (process tree, Petri net, BPMN).
activity_key – Attribute to be used as the activity key (default is defined in xes_constants.DEFAULT_NAME_KEY).
- Returns:
True if the trace fits the process model, False otherwise.
- Return type:
bool
- Note:
This is an internal method and is deprecated.
- pm4py.conformance.conformance_temporal_profile(log: EventLog | DataFrame, temporal_profile: Dict[Tuple[str, str], Tuple[float, float]], zeta: float = 1.0, activity_key: str = 'concept:name', timestamp_key: str = 'time:timestamp', case_id_key: str = 'case:concept:name', return_diagnostics_dataframe: bool = False) List[List[Tuple[float, float, float, float]]][source]#
Perform conformance checking on the provided log using the provided temporal profile. The result is a list of time-based deviations for every case.
For example, consider a log with a single case: - A (timestamp: 2000-01) - B (timestamp: 2002-01)
Given the temporal profile: ```python {
(‘A’, ‘B’): (1.5, 0.5), # (mean, std) (‘A’, ‘C’): (5.0, 0.0), (‘A’, ‘D’): (2.0, 0.0)
}#
and setting zeta to 1, the difference between the timestamps of A and B (2 years) exceeds the allowed time (1.5 months + 0.5 months), resulting in a deviation.
- param log:
Log object.
- param temporal_profile:
- Temporal profile. For example, if the log has two cases:
Case 1: A (timestamp: 1980-01), B (timestamp: 1980-03), C (timestamp: 1980-06)
Case 2: A (timestamp: 1990-01), B (timestamp: 1990-02), D (timestamp: 1990-03)
- The temporal profile might look like:
-
(‘A’, ‘B’): (1.5, 0.5), # (mean, std) (‘A’, ‘C’): (5.0, 0.0), (‘A’, ‘D’): (2.0, 0.0)
- param zeta:
Number of standard deviations allowed from the average (default is 1.0). For example, zeta=1 allows deviations within one standard deviation from the mean.
- param activity_key:
Attribute to be used for the activity (default is “concept:name”).
- param timestamp_key:
Attribute to be used for the timestamp (default is “time:timestamp”).
- param case_id_key:
Attribute to be used as the case identifier (default is “case:concept:name”).
- param return_diagnostics_dataframe:
If possible, returns a dataframe with the diagnostics instead of the usual output (default is constants.DEFAULT_RETURN_DIAGNOSTICS_DATAFRAME).
- return:
A list containing lists of tuples representing time-based deviations for each case.
- rtype:
List[List[Tuple[float, float, float, float]]]
- Example:
-
- temporal_profile = pm4py.discover_temporal_profile(
dataframe, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
) conformance_temporal_profile = pm4py.conformance_temporal_profile(
dataframe, temporal_profile, zeta=1, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
- pm4py.conformance.conformance_declare(log: EventLog | DataFrame, declare_model: Dict[str, Dict[Any, Dict[str, int]]], activity_key: str = 'concept:name', timestamp_key: str = 'time:timestamp', case_id_key: str = 'case:concept:name', return_diagnostics_dataframe: bool = False) List[Dict[str, Any]][source]#
Apply conformance checking against a DECLARE model.
Reference paper: F. M. Maggi, A. J. Mooij, and W. M. P. van der Aalst, “User-guided discovery of declarative process models,” 2011 IEEE Symposium on Computational Intelligence and Data Mining (CIDM), Paris, France, 2011, pp. 192-199, doi: 10.1109/CIDM.2011.5949297.
- Parameters:
log – Event log.
declare_model – DECLARE model represented as a nested dictionary.
activity_key – Attribute to be used for the activity (default is “concept:name”).
timestamp_key – Attribute to be used for the timestamp (default is “time:timestamp”).
case_id_key – Attribute to be used as the case identifier (default is “case:concept:name”).
return_diagnostics_dataframe – If possible, returns a dataframe with the diagnostics instead of the usual output (default is constants.DEFAULT_RETURN_DIAGNOSTICS_DATAFRAME).
- Returns:
A list of dictionaries containing diagnostics for each trace.
- Return type:
List[Dict[str, Any]]
- pm4py.conformance.conformance_log_skeleton(log: EventLog | DataFrame, log_skeleton: Dict[str, Any], activity_key: str = 'concept:name', timestamp_key: str = 'time:timestamp', case_id_key: str = 'case:concept:name', return_diagnostics_dataframe: bool = False) List[Set[Any]][source]#
Perform conformance checking using the log skeleton.
Reference paper: Verbeek, H. M. W., and R. Medeiros de Carvalho. “Log skeletons: A classification approach to process discovery.” arXiv preprint arXiv:1806.08247 (2018).
A log skeleton is a declarative model consisting of six different constraints: - directly_follows: Specifies strict bounds on activities directly following each other. For example, ‘A should be directly followed by B’ and ‘B should be directly followed by C’. - always_before: Specifies that certain activities may only be executed if some other activities have been executed earlier in the case history. For example, ‘C should always be preceded by A’. - always_after: Specifies that certain activities should always trigger the execution of other activities in the future history of the case. For example, ‘A should always be followed by C’. - equivalence: Specifies that pairs of activities should occur the same number of times within a case. For example, ‘B and C should always happen the same number of times’. - never_together: Specifies that certain pairs of activities should never occur together in the case history. For example, ‘No case should contain both C and D’. - activ_occurrences: Specifies the allowed number of occurrences per activity. For example, ‘A is allowed to be executed 1 or 2 times, and B is allowed to be executed 1 to 4 times’.
- Parameters:
log – Log object.
log_skeleton – Log skeleton object, expressed as dictionaries of the six constraints along with the discovered rules.
activity_key – Attribute to be used for the activity (default is “concept:name”).
timestamp_key – Attribute to be used for the timestamp (default is “time:timestamp”).
case_id_key – Attribute to be used as the case identifier (default is “case:concept:name”).
return_diagnostics_dataframe – If possible, returns a dataframe with the diagnostics instead of the usual output (default is constants.DEFAULT_RETURN_DIAGNOSTICS_DATAFRAME).
- Returns:
A list of sets containing deviations for each case.
- Return type:
List[Set[Any]]
- Example:
-
- log_skeleton = pm4py.discover_log_skeleton(
dataframe, noise_threshold=0.1, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’
) conformance_lsk = pm4py.conformance_log_skeleton(
dataframe, log_skeleton, activity_key=’concept:name’, case_id_key=’case:concept:name’, timestamp_key=’time:timestamp’