Skip to content
v1.0.3

Base Tool

A fresh Ocelescope install already does a lot before you load a single plugin. The base tool is a set of built-in views for importing, inspecting, filtering, discovering, and exporting object-centric event logs (OCELs) following the OCEL 2.0 standard.

Each view focuses on one task:

  • Resource view: import and export OCELs and resources, and manage everything in your session.
  • Log Overview: profile a log at a glance to confirm it imported as expected.
  • Filter: narrow a log down before analysis.
  • Discovery: compute process models from a log.
  • Plugins: upload plugins and run their methods.

OCELs can be imported and exported in all three OCEL 2.0 serializations, and traditional XES event logs can be imported (converted to an OCEL with a single object type) or produced by flattening an OCEL.

FormatImport / Export library
.jsonocel / .jsonr4pm
.xmlocel / .xmlr4pm
.sqlitepm4py
XES (import, converted to OCEL)r4pm
XES (export, flattened to one object type)pm4py

XES export flattens the OCEL to a single object type you choose, using pm4py’s ocel_flattening and write_xes.

The Resource view lists the OCELs and resources in your current session and is where importing and exporting happen. The dropzone accepts OCELs, XES logs, plugins, and saved resources in the same place; uploaded items appear in the list, where each can be inspected, renamed, deleted, and exported.

A resource is any artifact a method consumes or produces beyond the log itself, for example a discovered PetriNet or DirectlyFollowsGraph, or a custom type defined by a plugin. Resources are what you share with others: each one can be exported and later re-imported into Ocelescope.

Resources are Python objects built on Pydantic, so exporting one serializes its fields to a JSON file (with the .ocelescope extension) that also records the resource’s type. Re-importing that file validates the JSON back into the corresponding resource object. Built-in resource types can always be inspected, but a resource produced by a plugin can only be opened if that plugin is currently loaded, since its type definition lives in the plugin.

See Resources for the full picture, including how to define your own.

The Log Overview is the quickest way to confirm a log imported as expected and to get a feel for its shape before running any analysis. It profiles the selected log at a glance and shows:

  • the event and object counts,
  • the activities (event types) with their event counts, and the object types with their object counts, each as a frequency bar list,
  • the attributes attached to events and objects, including value types, ranges, and number of distinct values, broken down per activity or object type.

You can search and filter the attribute tables by attribute name and by activity or object type. The frequency bars are scaled relative to the most frequent entry: the largest count fills the bar, and every other bar is drawn as its share of that maximum, so the bars show relative, not absolute, magnitude.

The Filter view composes filters visually to narrow a log before analysis. You can stack any number of the following conditions; only events/objects that fulfill all criteria are kept:

  • Activity filter: keep or remove all events of selected types and all objects of their E2O-relations. Any object without an event is dropped.
  • Object type filter: keep or remove all objects of selected types and all events they are related too. Any event without an object is dropped.
  • Timeframe filters: keep events within a given time window and the corresponding objects.
  • Event attribute filter: Select an attribute, an activity and a range or set of values to keep. Narrow down the events of this activity by requiring them to have a value in a specified range. Objects with no remaining E2O-relations are dropped.
  • Object attribute filter: Select an attribute, an object type and a range or set of values to keep. Narrow down the objects of this object type by requiring them to have a value in a specified range. Events with no remaining E2O-relations are dropped.
  • Event-to-object count filters: filter events of an activity based on the frequency of a particular e2o-relation.
  • Object-to-object count filters: filter objects of a type based on the frequency of a particular o2o-relation.

Each filter shows you what is in the log so you can choose without guessing:

  • Activity and object-type filters list the available activities/object types with their frequencies and an include/exclude toggle.
  • Attribute filters show a table of the attribute’s value types, ranges, and distinct values per activity or object type, from which you build the value range or set to keep.
  • Relation-count filters show the relation counts between source and target types, with a min/max selector per relation.
  • The timeframe filter shows a histogram of events over time with date pickers, so you can see the distribution and highlight the window to keep.

The Discovery view renders models out of the box: object-centric Petri nets and directly-follows graphs; both using the pm4py implementations. Discovery is also extensible, so plugin-provided discovery methods appear here as selectable algorithms.

Before computing a model, you can apply ad-hoc filters that affect only the discovery, leaving the underlying log untouched:

  • Event type: include or exclude selected activities.
  • Object type: include or exclude selected object types.
  • Event type frequency: drop activities that occur rarely, controlled by a threshold (a percentage of the total event count, 3% by default).
  • Object type frequency: drop object types that occur rarely, controlled by the same kind of threshold on the total object count.

The frequency filters are the quickest way to declutter a model by removing infrequent behavior.

The Plugins view is where you upload plugin ZIPs and run their methods. Each method renders as a generated form built from its declared inputs. This is the entry point for everything in the plugin ecosystem; see Plugins.

Beyond the core views, Ocelescope ships with Ocelot for interactively exploring how events and objects relate, searching entities, and visualizing their relationships as a graph. Ocelot is technically a module rather than part of the core, but it is bundled into the default Ocelescope images, so it is available to everyone out of the box without a custom build.