Object-centric Process Mining Model

QPR ProcessAnalyzer supports object-centric process mining (OCPM) based on the OCEL 2.0 standard (https://www.ocel-standard.org). To use the object-centric functionality, you need to transform data into the suitable format in the datatables and create an object-centric model. Object-centric models can be analyzed in the object-centric flowchart and with (case-centric) charts where the object-centric models are viewed as case-centric eventlogs based on the perspectives. To use the OCPM functionality, Snowflake will be used to store the datatables and perform the analytics calculations.

Create object-centric model

Create a new object-centric model as follows:

1. In the Workspace, open the project where to create the model.
2. Select NEW in the top right menu and select model.
3. Define a name for the new model.
4. Set Model type as Object-centric.
5. Click Create.

Configure object-centric model

Datatables for the object-centric model need to exist in the same project as the model. Datatables can be set for the model as follows:

1. In the Workspace, select an object-centric model and select Properties.
2. In the model properties dialog, open the Datasource tab.
3. Add the following kind of datasource configuration to the textbox:

{
  "Objects": "OCPM: objects",
  "Events": "OCPM: events",
  "ObjectToObject": "OCPM: object-to-object",
  "EventToObject": "OCPM: event-to-object",
  "ObjectTypes": {
    "Invoice": "OCPM object: Invoice",
    "Payment": "OCPM object: Payment",
    "Purchase Order": "OCPM object: Purchase Order"
  },
  "EventTypes": { 
    "Approve Purchase Requisition": "OCPM event: Approve Purchase Requisition",
    "Change PO Quantity": "OCPM event: Change PO Quantity",
    "Create Purchase Order": "OCPM event: Create Purchase Order",
    "Insert Invoice": "OCPM event: Insert Invoice",
    "Insert Payment": "OCPM event: Insert Payment"
  }
}

The datasource configuration needs to have following properties:

• Objects: Objects datatable name.
• Events: Events datatable name.
• ObjectToObject: Object-to-object relations datatable name.
• EventToObject: Event-to-object relations datatable name.

Additionally, the datasource configuration may contain datatables for each object and event types (needed if there are object or event type specific attributes):

• ObjectTypes: Key-value-pairs of object type datatable names. Object type names need to match with object type names in the Objects datatable.
• EventTypes: Key-value-pairs of event type datatable names. Event type names need to match with event type names in the Events datatable.

Import from OCEL 2.0 file

Object-centric model can be import from an OCEL 2.0 JSON file as follows:

1. In the Workspace, open the project where to import the model.
2. Select NEW in top right menu and select Import Model.
3. Select the OCEL 2.0 JSON file from the disk and click Open.

An object-centric model and a list of datatables is created.

Example OCEL 2.0 eventlogs: https://www.ocel-standard.org/event-logs/overview/ (download the json format supported by QPR ProcessAnalyzer)

Filtering object-centric model

Object-centric models can be filtered by object attribute values which is similar to filtering by case attribute values in case-centric models. For the object attribute filtering, following settings are defined:

• Object type to be filtered
• Object attribute name
• Object attribute values
• Include or exclude logic
• Number of object relation steps

When the number of object relation steps is zero, objects of only the selected type are filtered. For example, when including items, all other object types are excluded (when object relation steps is zero). When excluding items, all other object types are included (when object relation steps is zero).

When object relation steps is one, objects directly related to the filtered object with an object-to-object relation are included or excluded.

When object relation steps is two or more, several object-to-object relations are followed to find the included or excluded objects. The objects are traversed only in the same direction which is either forward or backward. This is based on the notion that in object-centric models, all object-to-object relations have a direction, i.e., starting object and ending object of the relation. When creating an object-centric model, this relation direction needs to be carefully selected to produce desired results in the filtering.

Object attribute filter rules can be created for the entire dashboard by pressing the blue plus button in the dashboard header (requires that an object-centric model is selected for the dashboard). Object attribute filter rules can also be added for an individual chart/flowchart by opening the Filter tab in the chart/flowchart settings and pressing the Object-centric filter button.

Alternatively, a chart showing object attribute values as dimension or columns, can be selected to start creating object attribute filter rules. When making the selection, user can choose between Include Objects and Exclude Objects. It's also possible to use the case-centric filtering by selecting Include Cases or Cases Cases. Note that the case-centric attribute filtering doesn't work with the object-centric flowchart and with other charts having different perspective selected.

Changes for QPR ProcessAnalyzer 2025.3

Starting from QPR ProcessAnalyzer 2025.3, it's possible to leave the object relation steps setting empty. This means that the object-to-object relations are followed in a way that all the object types are traversed once to find the related objects. This also means that relation direction (forward or backward) doesn't matter anymore.

Object-centric model structure

Object-centric model consists of datatables described in the table below. Datatables can be named freely, and the model datasource configuration defines the each type of datatable. The datatables need to have column names specified in the table below that are the column names assumed by the object-centric model, i.e., column names cannot be selected freely.

Datatable role	Contained data	Datatable columns
Objects	All objects in the model (one row per object).	OcelObjectId: Unique id for the object (among all objects in the model). OcelObjectType: Object type name (such as Order, Invoice, Delivery). Note that the model datasource configuration need to use same object type names. <Common object attributes>: Other columns in the datatable are common object attributes (all types of objects have these attributes).
Events	All events in the model (one row per event).	OcelEventId: Unique id for the event (among all events in the model). OcelEventType: Event type name (such as Order created, Invoice sent). Note that the model datasource configuration need to use same event type names. OcelEventTime: Event timestamp. <Common event attributes>: Other columns in the datatable are common event attributes (all types of events have these attributes).
Object-to-object relations	Relations between objects (one row per relation).	OcelObjectToObjectSourceId: Source object id in the relation. OcelObjectToObjectTargetId: Target object id in the relation. OcelObjectToObjectQualifier: Describes the type of the relation as free-form text (not used currently).
Event-to-object relations	Relations between events and objects (one row per relation).	OcelEventToObjectSourceId: Event id in the relation. OcelEventToObjectTargetId: Object id in the relation. OcelEventToObjectQualifier: Describes the type of the relation as free-form text (not used currently).
Object type specific attributes (several datatables)	If there are object type specific attributes (i.e., object attributes that only a certain object type has), these tables are used to store them. These tables are optional, so a datatable is not needed if an object type doesn't have any object type specific attributes. Additionally, these tables don't need to contain all objects in the model, so if an object is not found in these tables, all object specific attribute values have a null value.	OcelObjectTypeObjectId: Object id. Matches to the objects datatable OcelObjectId column. OcelObjectTypeTime: Timestamp from which the attribute values are valid. OcelObjectTypeChangedField: Comma separated list of changed object attribute names. <Object attributes>: Columns for the object attributes (column name is the object attribute name).
Event type specific attributes (several datatables)	If there are event type specific attributes (i.e., event attributes that only a certain event type has), these tables are used to store them. These tables are optional, so a datatable is not needed if an event type doesn't have any event type specific attributes. Additionally, these tables don't need to contain all events in the model, so if an event is not found in these tables, all event specific attribute values have a null value.	OcelEventTypeEventId: Event id. Matches to the events datatable OcelEventId column. <Event attributes>: Columns for each of the event attribute values (column name is the event attribute name).

Object-centric perspectives

Perspectives convert an object-centric model into the traditional case-centric eventlog, allowing to view and analyze object-centric models in analyses provided by charts. A single perspective is not able describe the object-centric model entirely, but just from a certain limited viewpoint. By using analyses with several perspectives, it's possible to get a more complete picture of the object-centric model. The perspective starts from a certain object type and traverses the object-to-object relations as many steps as desired.

To define a perspective, the following settings are defined in the chart settings:

• Base Object type: Object of this type will be cases in the perspective eventlog.
• Show Event Types: List of event types which are included into the perspective eventlog. If no events are defined, all events will be included, but their event attributes are not included.
• Object Relation Steps: Specifies how many object-to-object relations will be traversed in order to find events connected to the base objects. Value zero means that only those events are returned that are directly connected to the base objects. This setting is optional, and if leaving it empty, all relations are traversed.

The resulting perspective eventlog will have the following columns:

• OcelObjectId (mapped to case id)
• OcelEventType (mapped to event type)
• OcelEventTime (mapped to timestamp)
• OcelEventId
• Object attributes of the base object type. If the object attribute value changes over time, the valid value in the event's timestamp is selected. Thus different events for the same case may show different value for the same case attribute.
• Event attributes of the selected event types. Values are null for events that don't have the attribute.

The base object type's attributes are available as case attributes. As the object attribute values may change over time in the OCEL 2.0 data model, the last attribute value is used as the case attribute value. Note that other object type's attributes are not available as case attributes, so the object for which the attributes are used, need to be set as the base object.

Save perspective to filter

It's possible to include the object-centric perspective to a stored filter. When a filter is selected, also the perspective in the filter is applied to the dashboard. This allows to quickly change perspectives for the entire dashboard. The chart specific perspective overrides the dashboard level perspective, so the dashboard level perspective is only applied for charts that don't have the chart specific perspective defined.

Perspective can be added to a filter as follows:

1. Go to the Process Discovery dashboard.
2. Open the Session variables dialog in the dots menu on top right.
3. Paste the filter json to the Value of the Filter variable (it might be easiest to start with a filter without filter rules, and then add the filter rules using the UI).
4. Click Done button for the dialog.
5. Save the filter by hovering the Unsaved filter (filters dropdown list) in the header and click Save as new filter.

Example: Filter json without any filter rules:

{
  "Items": [],
  "Perspective": {
    "ObjectType": "Container",
    "RecursionDepth": 0
  }
}

Example: Filter json with a filter rule:

{
  "Items": [
    {
      "Type": "IncludeEvents",
      "Items": [
        {
          "Type": "Attribute",
          "Attribute": "OcelEventId",
          "StringifiedValues": [ "0Event 1" ]
        }
      ]
    }
  ],
  "Perspective": {
    "ObjectType": "Container",
    "RecursionDepth": 0
  }
}

Differences to OCEL 2.0 standard

Object-centric models in QPR ProcessAnalyzer are mainly following the OCEL 2.0 standard, but there are the following differences:

• Changing of object attributes values over time is not supported.
• ocel_time field of each event type table is moved to events datatable (as every event has a timestemp).
• *_map_type columns are not needed as the model settings are used for the same purpose.
• Object type tables: If OcelObjectTypeChangedField is not null, all the other field values are copied from the previous entry except:
  • OcelObjectTypeChangedField which has the names of the changed fields as a comma separated string.
  • The actual changed field which has the new value.
  • OcelObjectTypeTime which has the timestamp when the value changed.