Object-centric Process Mining Model: Difference between revisions

From QPR ProcessAnalyzer Wiki
Jump to navigation Jump to search
No edit summary
Line 46: Line 46:
== OCPM model structure ==
== OCPM model structure ==
OCPM model has the following tables:
OCPM model has the following tables:
*  
* Events: Column names: OcelEventId, OcelEventType, OcelEventTime
* Objects: Column names: OcelObjectId, OcelObjectType
* EventToObject: Column names: OcelEventObjectSourceId, OcelEventObjectTargetId, OcelEventObjectQualifier
* ObjectToObject: Column names: OcelObjectObjectSourceId, OcelObjectObjectTargetId, OcelObjectObjectQualifier
* EventType-<event type name>: Column names: OcelEventTypeEventId, <other event type related fields>
* ObjectType-<object type name>: Column names: OcelObjectTypeObjectId, OcelObjectTypeTime, OcelObjectTypeChangedField, <other object type related fields>
 
Datatables can be named freely, but the column names are predefined.
 
== Perspectives ==
OCPM perspective provides means to "project" OCPM/OCEL model into a single tabular representation based on provided additional configurations, which can then be more easily analyzed using, e.g., traditional analysis methods used for event- and case-table based event logs.
 
Perspective configuration supports the following properties and their values:
* ObjectType: The name of the object type, specifying the type of the object that all events should be projected to.
* EventTypes: An array of event type names whose attributes are to be included into the resulting projected event log. If not defined, all the events in the OCEL model will be included, but their type-specific attributes are not included.
* Recursion depth: Specifies how many object-to-object relations are to be traversed in order to find events connected to the specified object type. Default value is 0, which means that only those events are returned that are directly connected to objects of the specified object type (based on EventToObject table).


== Perspectives
OCPM perspective provides means to "project" OCPM/OCEL model (#71846#) into a single tabular representation based on provided additional configurations, which can then be more easily analyzed using, e.g., traditional analysis methods used for event- and case-table based event logs.
2. Perspective configuration supports the following properties and their values:
2.1. ObjectType:
2.1.1. The name of the object type, specifying the type of the object that all events should be projected to.
2.1.2. Mandatory.
2.2. EventTypes:
2.2.1. An array of event type names whose attributes are to be included into the resulting projected event log.
2.2.2. If not defined, all the events in the OCEL model will be included, but their type-specific attributes are not included.
2.3. RecursionDepth:
2.3.1. Specifies how many object-to-object relations are to be traversed in order to find events connected to the specified object type.
2.3.2. Default value is 0, which means that only those events are returned that are directly connected to objects of the specified object type (based on EventToObject-table #71856#).
3. Perspective is applied as follows:
3. Perspective is applied as follows:
3.1. First, take all the rows from events-table.
3.1. First, take all the rows from events-table.
Line 89: Line 92:
<all the object type specific columns found in Payment object type table>
<all the object type specific columns found in Payment object type table>
<all the event type specific columns found in all the 8 event types listed in EventTypes-property>
<all the event type specific columns found in all the 8 event types listed in EventTypes-property>
== Differences to OCEL 2.0 standard ==
Main changes to the proposed implementation:
* ocel_time-field of each event type table is moved to event-table (as every event anyways has a timestemp).
* *_map_type are not needed as we can use model configuration for the same purpose.
* ObjectType-tables: If OcelObjectTypeChangedField is not null, all the other field values are copied from the previous entry having the same OcelObjectTypeObjectId, except:
** OcelObjectTypeChangedField, which has the name(s) of the changed field(s) as comma separated string.
** The actual changed field, which has the new value.
** OcelObjectTypeTime, which has the timestamp when the value changed.

Revision as of 18:09, 24 June 2024

This page describes functionality that hasn't fully been released.

QPR ProcessAnalyzer supports object-centric process mining models (OCPM) based on the OCEL 2.0 standard (https://www.ocel-standard.org).

Create OCPM model

New OCPM model is created as follows:

  1. In the Workspace, open the project where to created the model.
  2. Select "NEW" in top right menu and select "OCPM model"
  3. Define a name for the new model and click Create.

Configure OCPM model datatables

Datatables for the OCPM model can be configured as follows:

  1. In the Workspace, select the OCPM model and click Properties.
  2. In the dialog, open the Datasource tab.
  3. Add following kind of configuration to the textbox:
{ 
  "OcelDataSource": { 
    "Events": "ocpm_model - events", 
    "EventTypes": { 
      "Approve Purchase Requisition": "ocpm_model - eventtype-Approve Purchase Requisition", 
      "Change PO Quantity": "ocpm_model - eventtype-Change PO Quantity", 
      "Create Purchase Order": "ocpm_model - eventtype-Create Purchase Order", 
      "Create Purchase Requisition": "ocpm_model - eventtype-Create Purchase Requisition", 
      "Insert Invoice": "ocpm_model - eventtype-Insert Invoice", 
      "Insert Payment": "ocpm_model - eventtype-Insert Payment", 
      "Remove Payment Block": "ocpm_model - eventtype-Remove Payment Block", 
      "Set Payment Block": "ocpm_model - eventtype-Set Payment Block" 
    }, 
    "Objects": "ocpm_model - objects", 
    "ObjectTypes": { 
      "Invoice": "ocpm_model - objecttype-Invoice", 
      "Payment": "ocpm_model - objecttype-Payment", 
      "Purchase Order": "ocpm_model - objecttype-Purchase Order", 
      "Purchase Requisition": "ocpm_model - objecttype-Purchase Requisition" 
    }, 
    "EventToObject": "ocpm_model - event-object", 
    "ObjectToObject": "ocpm_model - object-object" 
  } 
} 

Import OCPM model from OCEL file

OCPM model structure

OCPM model has the following tables:

  • Events: Column names: OcelEventId, OcelEventType, OcelEventTime
  • Objects: Column names: OcelObjectId, OcelObjectType
  • EventToObject: Column names: OcelEventObjectSourceId, OcelEventObjectTargetId, OcelEventObjectQualifier
  • ObjectToObject: Column names: OcelObjectObjectSourceId, OcelObjectObjectTargetId, OcelObjectObjectQualifier
  • EventType-<event type name>: Column names: OcelEventTypeEventId, <other event type related fields>
  • ObjectType-<object type name>: Column names: OcelObjectTypeObjectId, OcelObjectTypeTime, OcelObjectTypeChangedField, <other object type related fields>

Datatables can be named freely, but the column names are predefined.

Perspectives

OCPM perspective provides means to "project" OCPM/OCEL model into a single tabular representation based on provided additional configurations, which can then be more easily analyzed using, e.g., traditional analysis methods used for event- and case-table based event logs.

Perspective configuration supports the following properties and their values:

  • ObjectType: The name of the object type, specifying the type of the object that all events should be projected to.
  • EventTypes: An array of event type names whose attributes are to be included into the resulting projected event log. If not defined, all the events in the OCEL model will be included, but their type-specific attributes are not included.
  • Recursion depth: Specifies how many object-to-object relations are to be traversed in order to find events connected to the specified object type. Default value is 0, which means that only those events are returned that are directly connected to objects of the specified object type (based on EventToObject table).

3. Perspective is applied as follows: 3.1. First, take all the rows from events-table. 3.2. For every event row, collect all the related objects based on EventToObject-table. 3.3. For every event + object combination, do the following: 3.3.1. Set current recursion depth to 0. 3.3.2. If the object is of the object type specified in the perspective, keep this event + object combination. 3.3.3. Otherwise: 3.3.3.1. If the current recursion depth is smaller than the configured RecursionDepth, generate all event + object combinations of all the objects related to the object of the current one based on ObjectToObject-table. For each such event + related object combination, continue to 3.3. above while increasing the recursion depth by one. 3.3.3.2. If the current recursion depth equals the configured RecursionDepth, the result will not include this row + object combination. 3.4. For each remaining event + object row: 3.4.1. Join all the columns (if there are any) from configured ObjectType's-table. 3.4.2. Join all the columns (if there are any) from each configured EventType's-table. 3.4.2.1. If EventType-table does not have some column that exists in some other joined EventType's column, that column will get a null value.

Example: {

 "ObjectType": "Payment",
 "EventTypes": ["Approve Purchase Requisition", "Change PO Quantity", "Create Purchase Order", "Create Purchase Requisition", "Insert Invoice", "Insert Payment", "Remove Payment Block", "Set Payment Block"],
 "RecursionDepth": 2

}

Generates a projection where resulting rows, each representing one event, are mapped to objects of type "Payment". If an event in OCEL model is not connected to Payment-object, even after performing two iterations of searches via ObjectToObject-table rows), that event will not show up in the result.

The result will have the following columns: OcelEventId (primary key) OcelObjectId (primary key) OcelEventTime <all the object type specific columns found in Payment object type table> <all the event type specific columns found in all the 8 event types listed in EventTypes-property>

Differences to OCEL 2.0 standard

Main changes to the proposed implementation:

  • ocel_time-field of each event type table is moved to event-table (as every event anyways has a timestemp).
  • *_map_type are not needed as we can use model configuration for the same purpose.
  • ObjectType-tables: If OcelObjectTypeChangedField is not null, all the other field values are copied from the previous entry having the same OcelObjectTypeObjectId, except:
    • OcelObjectTypeChangedField, which has the name(s) of the changed field(s) as comma separated string.
    • The actual changed field, which has the new value.
    • OcelObjectTypeTime, which has the timestamp when the value changed.