RunningExampleEvaluation

Evaluation Results of the Running Example

This page reports the evaluation results of the aggregation queries for the running example executed with ocean-lib. The evaluation considers only the events belonging to the Soccer match with identifier 2575959, in order to provide a small-scale and illustrative assessment of the aggregation pipeline.

The reported results include:

• The aggregation queries defining the running example
• The resulting aggregated event knowledge graph (EKG)
• Performance metrics for each aggregation step

⏱️ Execution times and processed nodes are summarized in the Performance Results section.

---

Running Example Queries

The running example consists of a sequence of aggregation steps applied to entities and events associated with a single match.

Query Step 1 - Player Aggregation

This step aggregates player entities by their role within the match.

AggrStep(
    aggr_type="ENTITIES", 
    ent_type="playerId",
    group_by=["role"],
    where=None,
    attr_aggrs=[]
)

Query Step 2 - Team Aggregation

This step aggregates team entities, grouping them by their identifier.

AggrStep(
    aggr_type="ENTITIES",
    ent_type="teamId",
    group_by=["wyId"],
    where=None,
    attr_aggrs=[]
)

Query Step 3 - Event Aggregation with Attributes

This step aggregates events, grouping them by event activity and aggregating selected attributes.

AggrStep(
    aggr_type="EVENTS",
    ent_type=None,
    where=None,
    group_by=[log.event_activity],
    attr_aggrs=[
        AttrAggr(
            name=log.event_timestamp,
            function=AggregationFunction.MINMAX
        ),
        AttrAggr(
            name="pos_orig",
            function=AggregationFunction.MULTISET
        )
    ]
)

---

Aggregated Event Knowledge Graph

The figure below shows the aggregated EKG obtained after executing the running example queries and completing the finalization and relationship inference phases.

---

Performance Results

The table below reports the execution time, number of aggregated nodes, and processing throughput for each phase of the aggregation pipeline.

Results refer exclusively to the Soccer match 2575959.

Aggregation Phase	Aggregated Nodes	Exec. Time (s)	Nodes / ms
Entity Aggregation (Players)	28	0.004	0.62
Entity Aggregation (Teams)	2	0.057	0.05
Event + Attribute Aggregation	1613	0.300	5.36
Finalization	7	0.134	0.05
Relationship Inference	–	0.182	–

---

Comparison with Classical Aggregation

In order to contextualize the results of the running example, we additionally report a comparison with a classical aggregation baseline.

The classical aggregation leverages the same aggregation pipeline implemented in ocean-lib, but applies an aggregation only over event activity names and entity types.

Importantly, the two configurations differ only in the parameters of the aggregation steps, while the underlying execution approach remains unchanged.

aggr_classical = [
    AggrStep(
        aggr_type="ENTITIES",
        ent_type="playerId",
        group_by=["type"],
        where=None,
        attr_aggrs=[]
    ),
    AggrStep(
        aggr_type="ENTITIES",
        ent_type="teamId",
        group_by=["type"],
        where=None,
        attr_aggrs=[]
    ),
    AggrStep(
        aggr_type="EVENTS",
        ent_type=None,
        where=None,
        group_by=["activity"],
        attr_aggrs=[]
    )
]

AggrSpecification(aggr_classical)

---

Aggregated Event Knowledge Graph

The figure below shows the aggregated EKG obtained after executing the classical aggregation approach.

Discussion on Proposed vs Classical Aggregation

Note

The conclusions supported by the running example would not be observable using a classical aggregation approach.

When events are aggregated exclusively by object type and activity name, the resulting aggregated event knowledge graph collapses all events sharing the same activity into a single aggregated node, thereby filtering out less frequent or context-specific behaviors.
In such a representation, directly-follows relationships connect aggregated events either from the team perspective or from the player perspective, without explicitly distinguishing their interaction patterns.

While the resulting process model can still be useful for obtaining a high-level understanding of the match and for extracting general insights, it does not allow distinguishing between the behaviors of different teams. Moreover, it does not support analyzing how team strategies, as expressed through the player perspective, influence the execution of the match.

In contrast, the proposed aggregation approach preserves the necessary structural distinctions to analyze how player-level behaviors contribute to team-level strategies, enabling a more fine-grained interpretation of the match dynamics without introducing additional aggregation setup.