ExeKGLib: Executable ML Pipelines

• ExeKGLib is an open-source library that transforms ML workflows into executable knowledge graphs by modeling tasks, methods, and data dependencies.
• It leverages dynamic mapping and SHACL-based validation to ensure pipeline compatibility and transparency throughout execution.
• Supported modes include a Python API, CLI, and a GUI with LLM recommendations, enabling seamless use for both ML novices and experts.

ExeKGLib is an open-source Python library for constructing, validating, and executing machine learning and data analytics pipelines as executable knowledge graphs. In the 2023 demo paper, it is presented as a library that allows users with coding skills and minimal ML knowledge to build pipelines whose steps, methods, data dependencies, and parameters are represented explicitly in a knowledge graph and then converted into runnable Python via dynamic mapping (Klironomos et al., 2023). The 2025 platform paper describes the same system as a broader platform backed by a graphical interface, SHACL-based validation, and multiple interaction modes, including a Python API, a Typer-based CLI, and a GUI with LLM-assisted recommendations (Klironomos et al., 1 Aug 2025). Across both accounts, its defining goals are transparency, reusability, and executability of ML workflows.

1. Problem setting and design objectives

ExeKGLib is motivated by the observation that practical ML pipelines are complex compositions of data loading, preprocessing or feature engineering, model training, evaluation, and visualization, often requiring multiple libraries such as pandas, scikit-learn, and matplotlib. The source materials characterize this as burdensome for non-ML experts and as a source of slow prototyping, low workflow transparency, limited reusability, and runtime failures caused by subtle incompatibilities in interfaces, input shapes, parameters, or task ordering (Klironomos et al., 2023).

The library’s response is to model pipelines as knowledge graphs with explicit entities for tasks, methods, and data, and to validate those graphs before execution. In the 2023 description, ExeKGLib “works in two steps: first, it generates an executable ML pipeline represented as a KG; second, it converts that KG into runnable Python (via dynamic mapping) and executes it” (Klironomos et al., 2023). The 2025 paper refines this by describing RDF/OWL pipeline graphs conforming to domain-specific schemas and validated by SHACL shapes, then translated into executable Python code (Klironomos et al., 1 Aug 2025).

This design places ExeKGLib in a specific niche. It is intended for settings in which users want explicit, inspectable, shareable pipeline representations and schema-guided construction. The papers repeatedly frame the target audience as users with minimal ML expertise, including domain experts in science and engineering, while also emphasizing value for mixed-expertise teams in which ML specialists and domain specialists need a common representation.

2. System architecture and operational layers

The 2023 demo paper describes ExeKGLib through a set of core components: a KG schema and interface, a pipeline builder, a validator implicit in the builder, an executor and code generator, and both CLI and API interfaces (Klironomos et al., 2023). The pipeline builder extracts dataset columns from CSV, populates the graph with DataEntity individuals, adds Task and Method individuals based on user choices, links them with input data and datatype properties, checks compatibility, and serializes the graph to Turtle. The executor parses the KG, traverses tasks sequentially, dynamically maps each task’s IRI or type to a Python object, and invokes the Python implementation of the selected method.

The 2025 platform paper reorganizes the same functionality into three layers: a Python library layer, a knowledge-graph component, and a graphical user interface (Klironomos et al., 1 Aug 2025). The Python library implements KG construction, validation, traversal, and execution. The KG component contains RDF graphs following schemas in the namespaces ds, ml, stats, and visu, plus a SHACL shapes graph. The GUI adds a drag-and-drop canvas, node and parameter editors, server-side execution, and an LLM assistant that recommends tasks and methods from the ExeKGLib graph.

At the implementation level, the papers identify a stable set of technologies. rdflib is used for RDF construction and SPARQL querying. The later paper adds pySHACL for validation and identifies the PyData execution stack as pandas, scikit-learn, matplotlib, and numpy (Klironomos et al., 1 Aug 2025). This architecture is explicitly designed so that graph content can be extended without changing traversal logic: the executor remains agnostic to future extensions because runtime behavior is selected through dynamic mapping from task and method identifiers to Python implementations (Klironomos et al., 2023).

3. Schema design and knowledge-graph representation

ExeKGLib organizes ML knowledge through a compact ontology and lower-level schemata. In the 2023 demo paper, the upper-level ds schema defines core concepts such as DataEntity, Task, and Method, with ds:hasNextTask as the key object property for chaining tasks (Klironomos et al., 2023). The lower-level schemata specialize tasks and methods for visualization, statistics and feature engineering, and ML. The later platform paper presents a more articulated ontology in which the top-level Data Science schema contains Data, Method, and Task, with Data refined by DataSemantics and DataStructure, Method refined by AtomicMethod, and Task refined by AtomicTask and Pipeline (Klironomos et al., 1 Aug 2025).

The lower-level schemas in the 2025 account are namespace-separated. The ml schema specializes ML tasks such as data splitting, training and testing regression, classification, and clustering models, and performance calculation. The stats and visu schemas provide corresponding task and method vocabularies for statistical measures, transforms, and plotting. The visualization schema includes a Canvas task used to initialize grid or layout for plots. The 2023 paper lists concrete supported method families including IQR, mean/std, normalization, outlier detection, Linear Regression, MLP, k-NN, helpers for train/test split and performance calculation, and line, scatter, and bar plots (Klironomos et al., 2023).

A pipeline is represented as an ordered sequence of task individuals linked by a next-task relation. Each task is associated with one or more data entities, a selected method, and datatype properties for parameters. The 2023 paper uses ds:hasNextTask; the 2025 paper formulates traversal via ds:nextTask and also specifies relations such as ds:invokes, ds:hasInput, ds:hasOutput, ds:hasParameter, ds:hasStructure, and ds:hasSemantics (Klironomos et al., 1 Aug 2025). In both descriptions, the graph is serialized in RDF Turtle for portability, inspection, visualization, and reuse.

The papers are also explicit about what the ontology does not claim. The demo paper states that it does not claim adoption of external standards like PROV-O or ML-Schema and instead uses its own ds ontology and task or method schemata (Klironomos et al., 2023). The later paper discusses provenance vocabularies such as PROV-ML and MEX in related work, but presents ExeKGLib itself as centered on open semantic pipeline representation, validation, and executability rather than native provenance-standard integration (Klironomos et al., 1 Aug 2025).

4. Validation, formalization, and execution semantics

Executability in ExeKGLib is enforced at graph-construction and graph-validation time. In the 2023 demo, compatibility checks are performed “based on the KG schemata” and supported by SPARQL queries, with the builder enforcing task-method alignment, input datatype expectations, and parameter presence before serializing the graph (Klironomos et al., 2023). The 2025 paper makes this mechanism explicit through SHACL validation using pySHACL, with constraints on pipeline structure, data entities, and attribute values (Klironomos et al., 1 Aug 2025).

The later paper gives concrete examples of such constraints. Each ds:AtomicTask must have exactly one compatible ds:AtomicMethod; a Visualization pipeline must start with a Canvas task before plotting steps; a task may have at most one nextTask; and training a classifier must have at least two inputs, exactly one output, and an optional third input for ensembles or hyperparameter tuning. Attribute values are constrained by XSD-compatible literal typing and range restrictions; the paper gives the example that MLP batch size is an integer with an upper bound (Klironomos et al., 1 Aug 2025).

The execution model is sequential. In the 2023 account, tasks are traversed via ds:hasNextTask, and each task’s method or type IRI is dynamically mapped to a Python implementation (Klironomos et al., 2023). In the 2025 account, execution proceeds by loading the KG and dataset path, loading the CSV with pandas, traversing tasks via ds:nextTask, parsing each task’s method, inputs, outputs, and parameters, and then calling run_method(task) on the dynamically selected Python class (Klironomos et al., 1 Aug 2025). Data entities may refer either to CSV columns or to outputs of prior tasks via a referenced IRI.

The later paper gives a compact functional notation for this semantics:

$f = f_n \circ f_{n-1} \circ \cdots \circ f_1$

with step-wise dataflow

$$x_{i+1} = f_i(x_i; \theta_i), \quad i = 1, \ldots, n-1.$$

The 2023 materials also provide a formalization consistent with the demo’s design in which a pipeline graph is written as $G = (V,E)$ with $V = D \cup T \cup M$, where $D$ are DataEntity nodes, $T$ are Task nodes, and $M$ are Method nodes, and where validator rules enforce compatibility between task inputs or outputs and method signatures (Klironomos et al., 2023). Taken together, these descriptions show that ExeKGLib treats pipeline execution not as ad hoc script interpretation, but as graph traversal under schema-constrained typing and parameter binding.

5. User interaction modes and supported workflow classes

ExeKGLib provides several interaction modes. The 2023 demo paper describes a Typer-based CLI that allows users to build and execute pipelines without writing code, and a Python API in the ExeKG module with functions such as create_data_entity(), create_pipeline_task(), and add_task() (Klironomos et al., 2023). The 2025 paper expands this to a platform with a GUI in which users drag task and method nodes onto a canvas, connect them with directed edges, configure parameters through forms, and press a “Run Pipeline” button to serialize the design to an ExeKG executed on the backend (Klironomos et al., 1 Aug 2025).

The GUI introduces a searchable sidebar and an LLM-powered assistant. The assistant interprets natural-language prompts and recommends tasks or methods consistent with schemas and constraints; the paper gives the example prompt “Build a classification pipeline for predicting Q-Value from tabular features” (Klironomos et al., 1 Aug 2025). The assistance is ontology-driven rather than full AutoML optimization. This distinction is important because the source materials explicitly state that the demo paper does not describe cross-validation or AutoML and that the GUI’s planning is guided by schema-driven compatibility and SHACL constraints rather than exhaustive model search (Klironomos et al., 2023).

Supported workflow classes include visualization pipelines, statistics and feature-engineering pipelines, and ML pipelines. The 2023 demo scenarios are a classification pipeline that loads features and labels from CSV, splits data, trains and tests a k-NN classifier, and visualizes prediction errors; a statistics pipeline that loads a single feature, normalizes it, and plots values before and after normalization using a scatter plot; and a visualization pipeline that loads a feature and plots it via a line chart (Klironomos et al., 2023). At the implementation level, ExeKGLib maps these workflows onto common Python libraries: scikit-learn for ML algorithms and helpers, matplotlib for plotting, numpy for numeric operations, and pandas for data loading and manipulation (Klironomos et al., 1 Aug 2025).

The 2025 paper adds that lower-level schemas and SHACL shapes can be semi-automatically generated from class and method definitions and docstrings of popular Python libraries such as scikit-learn, matplotlib, and numpy. This suggests an extensibility mechanism in which ExeKGLib’s catalog of tasks and methods is curated semantically rather than fixed purely by hand.

6. Industrial use, comparative position, and limitations

ExeKGLib is presented not only as a research prototype but as a component used in applied settings. The 2025 platform paper states that it is the backbone of SemML, Bosch’s semantic ML solution, and that it has been used in multiple industrial projects and evaluated in EU projects including OntoCommons and Graph Massivizer (Klironomos et al., 1 Aug 2025). The most detailed use case is resistance spot welding quality monitoring, where the goal is to predict Q-Value before welding to reduce waste and avoid destructive testing. The reported datasets come from two welding machines with 2 and 4 programs, covering 1,998 and 3,996 operations, with 4 process curves sampled per millisecond and 188 single features per operation, totaling 2.74 million records and 44.61 million items. Four pipelines are listed—Base-LR, Base-LSTM, Advanced-LR, and Advanced-LSTM—and the best models per machine achieved MAPE of 1.61% and 1.94% (Klironomos et al., 1 Aug 2025).

The same paper reports user-study results with 28 experts in ML, welding, and sensor engineering. With ExeKGLib and its GUI, participants completed more tasks faster, and tasks previously undoable by non-ML experts became doable. The reported scores are Transparency: 4.28 ± 0.47, Reusability: 4.87 ± 0.36, and Communication easiness: 4.70 ± 0.50 (Klironomos et al., 1 Aug 2025). These results are presented as evidence that the ontology and mappings offer a common ground across expert groups.

In relation to other systems, the papers position ExeKGLib against AutoML tools and workflow environments. Auto-sklearn, TPOT, Auto-WEKA, Auto-Net, and Ludwig are described as automating parts of ML but often constraining customization and focusing on modeling rather than end-to-end tasks such as visualization, statistics, and feature engineering. Weka, RapidMiner, Orange, and KNIME are described as offering GUI or XML/YAML-based workflows but not generating executable KGs with semantic validation; RapidMiner is noted as having semantic annotations but not leveraging Linked Open Data across the lifecycle in the same way (Klironomos et al., 1 Aug 2025).

Several misconceptions are therefore addressed directly by the source materials. ExeKGLib is not presented as an AutoML system, not as a platform for distributed training or experiment tracking, and not as a replacement for production-oriented systems such as MLflow or Kubeflow. The 2023 paper recommends conventional scikit-learn Pipelines, MLflow, or Kubeflow when complex orchestration, distributed training, experiment tracking, or production deployment features are required, and it notes that the demo paper does not provide quantitative runtime differences, graph-size measurements, or reasoning-cost measurements (Klironomos et al., 2023). The limitations reported across the two papers include current focus on classic ML tasks, sequential execution with no mention of parallelism or distributed execution, initial algorithm coverage centered on common visualization, statistics or feature engineering, and traditional ML methods, and the absence in the 2023 demo of explicit SHACL or external ontology validation (Klironomos et al., 2023). Planned extensions include more algorithms and tasks, broader feature-engineering and classic ML coverage, more sophisticated neural networks with high customizability, public release of the GUI planned for Q4 2025, and integration with a graph database for easier ExeKG management, visualization, and reuse (Klironomos et al., 1 Aug 2025).

The project is available at https://github.com/boschresearch/ExeKGLib, with repository documentation covering installation, usage, and examples for classification, statistics, and visualization workflows.