1. Introduction
Answer Set Programming (ASP) is a well-established declarative paradigm for solving complex combinatorial problems, offering a clean separation between problem modeling and computation (Brewka et al. Reference Brewka, Eiter and Truszczynski2011; Erdem et al. Reference Erdem, Gelfond and Leone2016; Lifschitz Reference Lifschitz2019; Kaminski et al. Reference Kaminski, Romero, Schaub and Wanko2023; Alviano et al. Reference Alviano, Dodaro, Fiorentino, Previti and Ricca2023). While modern ASP solvers can efficiently compute answer sets, interpreting and presenting these solutions in practical applications often requires substantial custom post-processing that motivated the development of several tools for answer set visualization (Cliffe et al. Reference Cliffe, Vos, Brain and Padget2008; Kloimüllner et al. Reference Kloimüllner, Oetsch, Pührer and Tompits2011; Lapauw et al. Reference Lapauw, Dasseville and Denecker2015; Bourneuf Reference Bourneuf2018; Hahn et al. Reference Hahn, Sabuncu, Schaub and Stolzmann2024; Bertagnon and Gavanelli Reference Bertagnon and Gavanelli2024). In the same spirit, ASP Chef (Alviano et al. Reference Alviano, Dodaro, Fiorentino, Previti and Ricca2023) was introduced to streamline the construction of pipelines that combine ASP-based search and optimization tasks with other tools for filtering, aggregation, and visualization (Alviano and Rodriguez Reiners Reference Alviano and Rodriguez Reiners2024).
In previous developments, ASP Chef has demonstrated its flexibility in composing pipelines involving combinatorial search and optimization by integrating external tools through mappings, that is, sets of procedures that convert ASP facts into representations suitable for systems implemented in other languages. This methodology enabled meaningful collaborations with tools such as MiniZinc (Nethercote et al. Reference Nethercote, Stuckey, Becket, Brand, Duck, Tack and Bessiere2007), for constraint modeling and solving, and Structured Declarative Language (SDL) (Alviano et al. Reference Alviano, Guarasci, Reiners and Vasile2024), for structured problem descriptions. These integrations (Alviano et al. Reference Alviano, Guarasci, Reiners and Vasile2024) relied on defining specific interpretations of ASP facts to match the syntax and semantics required by each target system. However, as the expressiveness and complexity of the external language increased, so did the difficulty and cost of building and maintaining the corresponding mappings. Consequently, such efforts often focused on a limited subset of the features available in the target language, hindering full exploitation of the capabilities of the integrated tool.
In this work, we introduce a different and more scalable approach to tool integration, grounded in the use of Mustache templates (a popular web templating system; Mittapalli and Arthur Reference Mittapalli and Arthur2021). Rather than building logic-based rules to obtain ASP facts that are later interpreted to interact with third-party tools, users can now define output templates using the native format of the target tool, embedding variable placeholders that are filled directly using the answer sets. This shift in paradigm allows ASP developers to write plain templates in the language of the external tool, with minimal effort and no need for custom interpreters or adapters. As a result, the richness of the target system no longer translates into integration complexity. Instead, users are empowered to access the full feature set of the external tool by simply referring to its original documentation and writing the appropriate Mustache template. This template-based mechanism preserves the declarative spirit of ASP while promoting openness, modularity, and extensibility in the design of logic-based pipelines. Thanks to Mustache, we extend ASP Chef to support the embedding of interactive views using popular JavaScript libraries such as Tabulator (for dynamic tables), Chart.js (for customizable charts), and vis.js (for networks, timelines, and 3D visualizations). This enhancement empowers ASP developers to generate human-readable reports, dashboards, and exploratory interfaces with minimal additional effort, all within a declarative framework. The newly integrated libraries find application in several common and new use cases of ASP, including scheduling and data analysis.
2. Background
2.1 Mustache templating system
Mustache is a logic-less templating system designed for generating HTML, configuration files, and other structured documents. Its simplicity and flexibility make it a popular choice for developers who need to separate data from presentation while avoiding complex scripting within templates. At its core, Mustache templates use placeholders enclosed in
to insert dynamic content. In this work, we restrict placeholders to be variables that get assigned values during template rendering, or sections of the form
that enable loops and conditionals. Data are taken from a YAML or JSON file during template rendering.
Example 1. Let us consider the following Mustache template:
Applying the above template to the JSON object
renders the following text (which can be part of a Markdown document):
2.2 Answer set programming
A program is a set of rules defining conditions (conjunctive bodies) under which atoms must be derived (atomic heads) or guessed (choices). Programs are associated with zero or more answer sets, that is, interpretations satisfying all rules and a stability condition (Gelfond and Lifschitz Reference Gelfond and Lifschitz1990). Programs are extended with #show directives of the form
where
$p$
is an optional predicate,
$\overline {t}$
is a possibly empty sequence of terms, and
$\mathit{conjunctive\_query}$
is a conjunction. Answer sets of the program are projected according to the #show directives. We refer the ASP-Core-2 format for details (Calimeri et al. Reference Calimeri, Faber, Gebser, Ianni, Kaminski, Krennwallner, Leone, Maratea, Ricca and Schaub2020).
Example 2. The following program solves the K-Clique problem in ASP:
Rule
$r_1$
defines edge as a symmetrically closed relation (as the graph is undirected). The choice rule
$r_2$
guesses
$K$
nodes (a
$K$
-clique candidate). The constraint
$r_3$
checks that all selected nodes are linked (a valid clique). Finally, the #show directive
$r_4$
projects the answer sets over the selected nodes, indexing them according to their natural ordering. Given size(3), and the graph node(a), node(b), node(c), node(d), edge(a,b), edge(a,c), edge(b,c), edge(c,d), the program has one (projected) answer set, namely (1, a), (2, b), (3, c).
2.3 ASP chef
An operation
$O$
is a function receiving in input a sequence of interpretations and producing in output a sequence of interpretations. Operations may produce side outputs (e.g., a graph visualization) and accept parameters to influence their behavior. An ingredient is an instantiation of a parameterized operation with side output. A recipe is a tuple of the form
$(\mathit{encode},\mathit{Ingredients},\mathit{decode})$
, where
$\mathit{Ingredients}$
is a (finite) sequence
$O_1\langle {P_1}\rangle ,$
$\ldots ,$
$O_n\langle {P_n}\rangle$
of ingredients, and
$\mathit{encode}$
and
$\mathit{decode}$
are Boolean values. If
$\mathit{encode}$
is true, the input of the recipe is mapped to [[__base64__("
$s$
")]], where
$s = \mathit{Base64}(s_{\mathit{in}})$
(i.e., the Base64–encoding of the input string
$s_{\mathit{in}}$
). After that, the ingredients are applied one after another. Finally, if
$\mathit{decode}$
is true, every occurrence of __base64__(
$\mathit{s}$
) is replaced with (the ASCII string associated with)
$\mathit{Base64}^{-1}(s)$
. Among the operations supported by ASP Chef there are Encode
$\langle {p, s}\rangle$
to extend every interpretation in input with the atom
$p$
("
$t$
"), where
$t = \mathit{Base64}(s)$
; Search Models
$\langle {\Pi ,n}\rangle$
to replace every interpretation
$I$
in input with up to
$n$
answer sets of
$\Pi \cup \{p(\overline {t}). \mid p(\overline {t}) \in I\}$
; Optimize
$\langle {\Pi ,n}\rangle$
to replace every interpretation
$I$
in input with up to
$n$
optimal answer sets of
$\Pi \cup \{p(\overline {t}). \mid p(\overline {t}) \in I\}$
.
Example 3 (Continuing Example
2). The recipe
$(\mathbf{F}, [\mathit{Search\ Models}\langle {\{r_1, \ldots , r_4\},1}\rangle ], \mathbf{F})$
addresses the K-Clique problem in a single step. With
$(\mathbf{F}, [\mathit{Search\ Models}\langle {\{r_1\},1}\rangle , \mathit{Search\ Models}\langle {\{r_2, r_3\},1}\rangle , \mathit{Search\ Models}$
$\langle {\{r_4\},1}\rangle ], \mathbf{F})$
, instead, the problem is addressed in three steps: (i) symmetric closure of edge/2; (ii) clique search; (iii) solution projection.
3. ASP chef mustache
We introduce the main linguistic constructs of our Mustache template system. While the original system mainly deals with variables and sections to enable loops and conditionals, our system relies on ASP terms and queries. At the core of our system there is the expansion of Mustache queries, whose results can be sorted, formatted and projected to handle duplicates (Section 3.1). More advanced constructs enable string manipulation and interpolation, the sharing of common elements among several Mustache queries, and nesting of loops and conditionals (Section 3.2).
3.1 Core functionalities
3.1.1 Mustache queries and expansion
A Mustache query has the form {{
$\Pi$
}}, where
$\Pi$
is an ASP program with #show directives. Applying a Mustache query to an interpretation
$I$
renders one projected answer set of
$\Pi \cup \{p(\overline {t}). \mid p(\overline {t}) \in I\}$
if any, and otherwise raises an error. Specifically, tuples of terms in the projected answer set are rendered, one per line and separating terms with “,” (comma followed by a blank space). A template is a text with Mustache queries.
Example 4. Let
$\Pi$
be the program and
$I$
be the facts from Example 2. Applying the template
to
$I$
renders
Note that the rendered text depends on the order in which tuples of terms are processed.
3.1.2 Shortcut form, sorting and basic formatting
Mustache queries are often one-liner, as
in Example4. Therefore, we introduce the shortcut form
equivalent to
Another shortcut is given for tuples of the form (
$t$
,) with
$t$
being a number or double-quoted string, which can be equivalently written as
$t$
. The processing order of tuples of terms can be specified by creating an instance of sort/1, where the argument represents the index of the term used for sorting. A positive index indicates ascending order, while a negative index specifies descending order, using the absolute value of the index. Ties are broken by subsequent instances of sort/1 (if available). The rendering of tuples of terms can be controlled with instances of separator/1 to specify a different separator for tuples; term_separator/1 to specify a different separator for terms; prefix/1 and suffix/1 to wrap output with specified text. As a side note, we discourage the use of guessing components (as choice rules) in Mustache queries, as they are better handled by other ASP Chef operations (e.g., Search Models and Optimize).
Example 5 (Revising Example
4). Let
$I$
be the facts from Example 2 extended with in(a), in(b), in(c) (i.e., the answer set of the program from Example 2 before projection). Applying the template
to
$I$
renders
Note that the order of tuples is specified in the Mustache query, and therefore the rendered text does not depend on the order in which tuples are produced by the underlying ASP solver.
3.1.3 Handling duplicates
ASP follows set-semantics, meaning duplicate results do not appear naturally. On the other hand, ASP can deal with duplicate addends in sums and weak constraints thanks to an extended syntax including distinguishing terms (i.e., terms that are used to differentiate between equal addends). The same technique can be adopted for tuples of terms in Mustache queries: the varadic predicate show/* renders the first of its arguments (a tuple of terms), discarding all other arguments. All of its arguments are subject to the sorting criteria specified in the Mustache query (if any), hence enabling the possibility to sort elements based on properties that are not rendered.
Example 6. Suppose a cost is associated with each node in Example 2: cost(a,1), cost(b,2), cost(c,1), cost(d,1). The following weak constraint minimizes the sum of costs in the computed clique:
Note that variable Node is a distinguishing term, thanks to which the cost 1 associated with nodes a and c can be correctly counted twice in the computed solution. Applying the template
to the clique comprising nodes a, b and c renders
Note that variable Node is a distinguish term also in the #sum aggregate and in the second Mustache query. Also note that costs are sorted by node.
3.2 Advanced functionalities
3.2.1 Lua string @-terms
Mustache queries have access to some interpreted functions that ease string manipulation. Among them, @string_join(sep, …) to concatenate two or more strings using the provided separator, @string_concat(…) as a shortcut for @string_join("", …), and @string_format(format, …) to format a string using the given format string and arguments. Floating-point numbers are represented in the format real("NUMBER").
3.2.2 Multiline strings and F-strings
Mustache queries enrich the syntax of ASP with multiline strings of the form {{"…"}} and f-strings of the form {{f"…"}}. A multiline string is mapped to a double-quoted string, representing new lines and double-quotes with the escape sequences \n and \", respectively. F-strings additionally introduce interpolation: data are interpolated in f-strings using the syntax
$\$$
$\left\{\right.\mathit{expression}$
:
$\mathit{format}\left.\right\}$
, where :
$\mathit{format}$
is optional (default :%s for string). A f-string {{f"
$\mathit{str}$
"}} is mapped to the term @string_format(
$\mathit{fmt}$
,
$e_1, \ldots , e_n$
), where
$\mathit{fmt}$
is the double-quoted string obtained by escaping
$\mathit{str}$
and replacing interpolations with the associated formats, and
$e_1, \ldots , e_n$
are the
$n \geq 0$
expressions interpolated in
$\mathit{str}$
.
Example 8. Suppose we would like to render
as part of a JSON object representing the graph and the computed clique. We could rely on
We observe that double-quoted strings of ASP require escaping of frequent characters in JSON (the double quote char in particular). Even worse, handling a large JSON object formatted as a single line is highly inconvenient. Below are more convenient representations:
In the template above, the f-string in the second #show directive essentially maps to the @string_format term in the first #show directive (modulo the value of group).
3.2.3 Persistent queries
Common elements of different Mustache queries in a template can be stored in a persistent array, initially empty, by using the expression
where
$\Pi$
is an ASP program with #show directives; or using the shortcut form
equivalent to
The content of the persistent array is prepended to the tuples of terms and atoms obtained by evaluating subsequent Mustache queries in the template. The persistent array can be reset using the Mustache expression {{-}}.
Example 9 (Continuing Example 8). Targeting the rendering of JSON objects, the separator is likely always ", \n". Instead of including the associated #show directive in all Mustache queries, a template could start with the Mustache expression {{+ separator(", \n")}}.
3.2.4 Multi-stage expansion
Mustache queries enable loops and conditionals. In some cases, nesting of Mustache queries is convenient for evaluating conditionals within loop elements or for executing inner loops. A multi-stage template expansion repeatedly processes Mustache queries until no further expansions remain.
Example 10 (Continuing Examples 8–9). As already observed, the multiline string and the f-string in Example 8 only differ in the value of group. Nesting a conditional within a single loop over nodes seems natural in this case. Assuming sort(2) and separator(", \n") are in the persistent array, we can use
Note that the first expansion renders (four inner objects like) the following:
Conditionals within each object are evaluated in the second stage to obtain the group values.
4. JSON-based frameworks integration
Several frameworks can be configured using JSON objects. To further ease their integration in ASP Chef, we rely on Relaxed JSON (https://www.relaxedjson.org/), hence accepting a more permissive syntax. The new operations presented in this section have parameters
$\langle {p,m}\rangle$
, where
$p$
is a predicate and
$m$
is a Boolean. Each atom
$p(s)$
in each input interpretation
$I$
produces a side output according to the JSON object rendered by applying the template
$\mathit{Base64}^{-1}(s)$
to
$I$
, using multi-stage expansion if
$m$
is
$\mathbf{T}$
.
Fig. 1. Side outputs associated with data from Example6: graph with highlighted clique obtained with the @vis.js/Network operation; table showing node costs and computed clique obtained with the tabulator operation; chart reporting statistics obtained with the Chart.js operation. A recipe showcasing these examples is available at https://asp-chef.alviano.net/s/ICLP2025/running-example.
4.1 @vis.js/network
The Network module in vis.js (https://visjs.org/) is a powerful JavaScript library for visualizing dynamic and interactive networks (graphs). Users can customize colors, shapes, labels, and border styles of nodes and edges. The module includes a physics-based layout engine, and supports real-time interactivity. Additionally, grouping and clustering allow for efficient visualization of large datasets by aggregating related nodes. The library also supports hierarchical layouts and directional edges with arrows. We extended ASP Chef with the @vis.js/Network operation.
4.2 Tabulator
Tabulator (https://tabulator.info/) is a powerful JavaScript library that provides a wide range of customization options to create interactive tables from various sources, including JSON. In the context of ASP Chef, Tabulator can be used to render tables from input models, taking advantage of Mustache queries to configure the table and bind data from ASP facts as needed. Specifically, we extended ASP Chef with the Tabulator operation, and enriched the JSON configuration to accept the download property, allowing users to add buttons for exporting the data in various formats such as CSV, JSON, or Excel.
Example 12 (Display data from Example 6 as a table). The following template renders the table shown in Figure 1:
Note that data is a list of objects whose properties are obtained interpolating ASP terms. Costs are shown as a (progress) bar, and membership in the computed clique using ticks. Rows are sorted by membership in the clique (descending), and node name (ascending). Finally, the user can export data as comma-separated values (CSV) by clicking a button.
4.3 Chart.js
Chart.js (https://www.chartjs.org/) is a lightweight yet powerful JavaScript library for creating interactive and customizable charts. It supports multiple chart types, including line, bar, pie, radar, and scatter plots, making it versatile for various data visualization needs. Its JSON configuration can easily customize styles, adjusting colors, fonts, and tooltips. We extended ASP Chef with the Chart.js operation.
Example 13 (Display statistics about Example 6). The following template renders the mixed chart (bar plots and line) shown in Figure 1:
The template defines three datasets, two bars and one line, using the show/* predicate to handle duplicate values. Also note that values are sorted by node (the second argument in show/*).
Other frameworks We extended ASP Chef with other frameworks, providing alternatives to build charts and images. The @vis.js/Timeline operation is specialized for temporal data. The library supports custom styling and grouping of events, making it ideal for project management, historical data visualization, and scheduling applications. The @vis.js/Graph3D operation can create interactive 3D visualizations of data, making it ideal for representing mathematical functions, scientific data, and geographical information. Data points are rendered on a 3D plane, either as surface plots or scatter plots. The module provides intuitive controls for zooming, rotating, and panning, allowing users to explore complex datasets from different angles. Customization options include color gradients, axis scaling, and grid styling, enabling precise data representation. The ApexCharts (https://apexcharts.com/) operation integrates a modern, highly customizable JavaScript charting library designed for creating interactive, responsive, and performant visualizations. It supports a wide range of chart types, including line, bar, area, pie, radar, heatmaps, and mixed charts, making it suitable for business intelligence dashboards, financial data analysis, and real-time monitoring. Interactivity is a key strength, with built-in support for tooltips, zooming and panning. The Fabric.js (https://fabricjs.com/) operation integrates a powerful and flexible JavaScript library for working with HTML5 canvas, enabling rich interactive graphics, image manipulation, and object-based drawing. It simplifies complex vector graphics operations by providing an intuitive API for creating and managing shapes, images, text, and paths. One of its standout features is object-based manipulation, allowing users to move, scale, rotate, and group elements directly on the canvas.
Fig. 2. VQR data analysis with Chart.js and ApexChart.
5 Use cases
5.1 Data analysis
Italian VQR (Valutazione della Qualità della Ricerca) is the national framework used to assess the quality and impact of research outputs through bibliometric indicators such as citation percentiles and journal impact factors. ASP finds a natural application in this context to optimize the selection of articles avoiding conflicts (see https://asp-chef.alviano.net/s/VQR2024/assegna-paper). The newly integrated libraries add several useful capabilities to analyze input data and results. Figure 2 shows a scatter plot obtained with Chart.js, where each point combines the percentiles on citations and impact factor to provide an insightful overview of research performance, and a radar chart from ApexChart to overview the number of articles per year included in the analysis. An interactive recipe starting from CSV and including a Tabulator representation is available at https://asp-chef.alviano.net/s/ICLP2025/vqr.
Fig. 3. Blocking sets and authorship graphs obtained with @vis.js/Network.
5.2 Graph analysis
The concept of blocking sets is also known as vertex cuts or vertex separators in graph theory: given a start and an end vertex, a blocking set is a set of vertices (without the start and end vertices) such that the end vertex is not reachable from the start vertex without passing a member of the blocking set. The identification of blocking sets has numerous applications, for example in VLSI design and cybersecurity. Using @vis.js/Network, ASP Chef can display blocking sets of a given directed graph, using the same layout for all computed solution to ease their understanding. A recipe is available at https://asp-chef.alviano.net/s/ICLP2025/blocking-sets. For a larger example, https://asp-chef.alviano.net/s/ICLP2025/vqr2 shows an authorship graph from which different communities of authors are easily spotted and independently optimized to select articles for the Italian VQR. Figure 3 reports networks obtained with @vis.js/Network in these contextes. For blocking sets, the start and end vertices are green, vertices in the blocking sets are red.
5.3 Planning and scheduling
Incremental Scheduling is a complex problem that involves allocating jobs to specific devices with replicas, while considering deadlines, dependencies, and importance levels. The goal is to minimize the penalty for missing deadlines and the overall completion time. To visualize this intricate process, we utilize @vis.js/Timeline to create a dynamic and interactive schedule. The timeline ingredient showcases the computed schedule, highlighting in red the penalties incurred for missing deadlines. This visualization provides a clear and concise overview of the scheduling process, allowing users to easily identify areas of improvement and optimize their scheduling strategy. Additionally, a @vis.js/Network visualization is used to illustrate the dependencies between jobs, providing a comprehensive understanding of the scheduling problem. Figure 4 reports the two visualizations obtained with the recipe at https://asp-chef.alviano.net/s/ICLP2025/incremental-scheduling.
Fig. 4. Computed scheduling and job dependencies shown with @vis.js/Timeline and @vis.js/Network.
Fig. 5. Skyscrapers solution shown using Fabric.js and @vis.js/Graph3d (from different angles).
5.4 2D and 3D solution visualization
In the Skyscrapers puzzle the goal is to determine the height of skyscrapers in a grid, given clues on the number of visible skyscrapers in some directions (https://www.puzzle-skyscrapers.com/). A recipe addressing the puzzle is available at https://asp-chef.alviano.net/s/ICLP2025/skyscrapers, and produces the visualizations shown in Figure 5. The 3D visualization is particularly interesting here, as the user can use the mouse to control the camera angle to obtain an immersive experience.
6. Extending ASP chef with new operations
A key strength of ASP Chef lies in its deliberately simple and modular architecture, which enables users to extend the system by adding new operations with minimal effort. Rather than modifying core infrastructure or registering components manually, operations are implemented as self-contained (and self-registering) .svelte files that become instantly usable within the system. This design encourages experimentation, facilitates integration of third-party libraries, and lowers the barrier for community contributions. To implement a new Mustache-based visualization operation (such as a charting or table component) developers typically create two files within src/lib/operations: (i) a file named <Operation>.svelte that defines UI controls for parameters of the operation (e.g., predicate and multi-stage), and (ii) a companion file named +<Operation>.svelte that imports and renders the third-party library, feeding it the result of the Mustache template as configuration.
For example, for the ApexCharts operation, the main ApexCharts.svelte file contains
This snippet instantiates the operation with UI controls to select the ASP predicate that encodes the chart configuration and to toggle options such as multi-stage. The #each loop adds instances of +ApexCharts.svelte for each instance of the selected predicate. The companion file +ApexCharts.svelte integrates the ApexCharts library and renders the chart:
This fragment decodes the Mustache template in the configuration atom, expands it using the current interpretation (part) as context, parses it as JSON, and invokes the rendering engine.
Despite their functionality, these files are concise: (i) ApexCharts.svelte is 73 lines; (ii) +ApexCharts.svelte is 44 lines. Similar patterns are followed for other operations: Chart.js (73 + 47 lines) replicates the same logic with a different charting library; Tabulator (74 + 70 lines) extends slightly to add features like export buttons.
7. Related work
Several tools and frameworks supporting the development of ASP have been introduced in the literature, among them Integrated Development Environments (IDEs) such as ASPIDE (Febbraro et al. Reference Febbraro, Reale and Ricca2011), SeaLion (Busoniu et al. Reference Busoniu, Oetsch, Pührer, Skocovsky and Tompits2013), and LoIDE (Calimeri et al. Reference Calimeri, Germano, Palermiti, Reale and Ricca2018). Unlike these tools, ASP Chef is designed as a platform for experimenting with ASP solutions and their integration with external tools. ASP Chef is powered by clingo-wasm and enables the development of shareable examples and interactive demos, a feature especially suited to scientific communication, as shown in Costantini and Formisano (Reference Costantini and Formisano2024). Several research efforts have explored the modular use of ASP through microservices or pipeline-based compositions (Calimeri and Ianni Reference Calimeri and Ianni2006; Costantini and Gasperis Reference Costantini and Gasperis2018; Cabalar et al. Reference Cabalar, Fandinno and Lierler2020; Costantini et al. Reference Costantini, Gasperis and Lauretis2021; Cabalar et al. Reference Cabalar, Fandinno, Schaub and Wanko2023). These works resonate with the guiding principles of ASP Chef, which promotes the decomposition of ASP workflows into manageable and reusable components. Prior versions of ASP Chef supported integration with external systems, such as MiniZinc and Structured Declarative Language (SDL), by exchanging ASP facts. However, this fact-based approach often incurred non-trivial implementation costs to interpret ASP data in the target language, especially when the target system had a rich and complex syntax. To address this limitation, the present work introduces a more direct and extensible mechanism for integration, based on Mustache templates. Instead of interpreting facts, the user defines templates that interpolate ASP data into the desired target format or language, facilitating smoother and more expressive interactions with external libraries and systems. This enables seamless integration of advanced visualization and reporting tools, without needing dedicated wrappers or converters.
A first embryonic version of templated queries was introduced in our earlier work ASP Chef Chats with Large Language Models (Alviano et al. Reference Alviano, Macrì and Rodriguez Reiners2025), where a restricted form of Mustache query was proposed to synthesize structured Markdown snippets from ASP results and feed them into LLM prompts. In that version, the output was a projection of matching atoms, formatted via special atoms like ol/1, ul/1, th and tr. The goal was to enable Markdown generation suitable for LLM consumption, with Base64-encoded answers retrieved from predicates such as __base64__/1. In contrast, the current work generalizes this idea into a full-featured templating system, decoupled from LLM usage and capable of targeting arbitrary external libraries. By adopting standard Mustache templates and extending them with ASP-aware data injection, we shift from producing static Markdown to dynamically generating JSON configurations, HTML fragments, and other consumable formats suitable for integration with a wide range of front-end and visualization frameworks.
Visual representation of ASP results has been studied through tools such as ASPViz (Cliffe et al. Reference Cliffe, Vos, Brain and Padget2008), IDPD3 (Lapauw et al. Reference Lapauw, Dasseville and Denecker2015), and Kara (Kloimüllner et al. Reference Kloimüllner, Oetsch, Pührer and Tompits2011), all of which rely on ASP facts to describe the visual layout of answer sets. In the same spirit, more recent approaches like clingraph (Hahn et al. Reference Hahn, Sabuncu, Schaub and Stolzmann2022) and ASPECT (Bertagnon et al. Reference Bertagnon, Gavanelli and Zanotti2023) offer exportable, high-quality visualizations suited for publication in 
. While these systems provide expressive rendering capabilities, they generally depend on external installations and do not focus on browser-native interaction. Moreover, their development and maintenance must face the complexity of the underlying rendering engines. The visualization operations introduced in this work, based on Tabulator, Chart.js, and vis.js, complement these efforts by enabling fully browser-based, interactive visualizations such as scatter plots, timelines, and network diagrams. Building on our experience with the previously developed Graph operation (Alviano and Rodriguez Reiners Reference Alviano and Rodriguez Reiners2024), we found that using Mustache templates to implement the @vis.js/Network and Fabric.js operations not only significantly reduced development time but also led to more powerful and expressive functionalities.
A particularly relevant application of ASP-based visualization in complex domains is presented by Gebser et al. (Reference Gebser, Obermeier, Otto, Schaub, Sabuncu, Nguyen and Son2018), who propose an ASP-based framework for experimenting with robotic intra-logistics domains. Their work highlights the value of integrating high-level reasoning with sophisticated visualization and execution environments, and shows how ASP can serve as a flexible backbone for modeling, simulation, and visualization in complex logistical settings. ASP Chef shares this ambition but places stronger emphasis on interactive, browser-native visualizations that support rapid prototyping and deployment via web technologies. Finally, we mention clinguin (Beiser et al. Reference Beiser, Hahn and Schaub2025) for developing graphical user interfaces directly in ASP. Future applications of Mustache in ASP Chef may explore convergence points between these systems, particularly in the direction of form-based input via frameworks like SurveyJS.
8. Conclusion
We presented an extension of ASP Chef that uses Mustache templates and popular JavaScript libraries to support the creation of interactive, data-driven views from ASP results. By simplifying the integration of external visualization tools, our approach enables developers to build rich, user-friendly interfaces while staying within the declarative paradigm.
Beyond its functionality, a key strength of ASP Chef is its simple and modular design. New Mustache-based operations can be added with minimal effort by creating a .svelte file that defines UI parameters and links to a third-party library using the configuration generated from the expanded template. These operations are immediately usable in recipes, without the need for manual registration or system modification. This plugin-like architecture lowers the barrier to contribution and invites experimentation. In future iterations, we plan to provide formal guidelines to support community-driven extensions and integrations.
Future work will explore the use of Mustache templates to integrate frameworks for user interface definition, particularly form-based interactions. This would allow ASP developers not only to present data, but also to collect and structure user input within a seamless and declarative pipeline. In addition, we envision integrating Controlled Natural Language (CNL) processing capabilities to allow domain experts to write specifications in a restricted natural language that can be automatically translated into ASP code (Caruso et al. Reference Caruso, Dodaro, Maratea, Mochi and Riccio2024). The combination of Mustache templating, structured input collection, and CNL2ASP translation would broaden the accessibility of ASP Chef, making it easier for non-programmers to contribute to the knowledge engineering process.
Acknowledgments
This work was supported by the Italian Ministry of University and Research (MUR) under PRIN project PRODE “Probabilistic declarative process mining”, CUP H53D23003420006, under PNRR project FAIR “Future AI Research”, CUP H23C22000860006, under PNRR project Tech4You “Technologies for climate change adaptation and quality of life improvement”, CUP H23C22000370006, and under PNRR project SERICS “SEcurity and RIghts in the CyberSpace”, CUP H73C22000880001; by the Italian Ministry of Health (MSAL) under POS projectsCAL.HUB.RIA (CUP H53C22000800006) and RADIOAMICA (CUP H53C22000650006); by the Italian Ministry of Enterprises and Made in Italy under project STROKE 5.0 (CUPB29J23000430005); under PN RIC project ASVIN “Assistente Virtuale Intelligente di Negozio” (CUP B29J24000200005); and by the LAIA lab (part of the SILA labs). This research was also funded in part by the Austrian Science Fund (FWF) within projects 10.55776/COE12 and 10.55776/PIN8782623. Mario Alviano is member of Gruppo Nazionale Calcolo Scientifico-Istituto Nazionale di Alta Matematica (GNCS-INdAM).
Open access
