Logic programming is a declarative programming paradigm that finds extensive use in the field of Artificial IntelligenceA(I). As a result, it has become a valuable tool used in university courses for teaching students AI techniques. Besides Prolog language, the more recent Answer Set ProgramAmSinPg)l(anguage turns out to be a powerful tool for developing advanced applications due to the expressiveness of the language and the availability of eficient solving systems. Unfortunately, the ouAtpSuPtsolfvers can be dificult to interpret, since it is a set of atoms, often long and verbose. This is most true in the case of students learning the language or in the case of experts developing applications for complex real-world problems. For these reasons, the ability to produce, when possible, a graphical representation of the solver output becomes useful to ensure easier interpretation of the results. In this paper we present ASPECT, a sub-language oAfSP in which the user can directly define, in an intuitive and declarative way, a graphical representation of the answer set. The ASPECT atoms can be converted into the popular LaTeX markup language to produce vector graphics. The documents produced by ASPECT are easy to embed in documents such as scientific articles, course handouts, and presentations. Also, the development of user-friendly interfaces is critical for wider use of similar technologies in the industrial sector as well.
Logic programming is a declarative programming paradigm that finds extensive use in the ifeld of Artificial IntelligenceA( I). As a result, it has become a valuable tool used in university courses for teaching students AI techniqu1e]s. [
Answer Set ProgrammingA(SP) is a logic programming language with a semantics known as the stable models semantic2s].[The popularity of this language is due to its expressiveness and the availability of eficient solving system3,s4[], which allow its use even in advanced applicationsA.SP programs are logic programs composed of facts and rules that represent the problem to be solved. The key ideaAoSfP is to model problems in such a way that its stable model(s) provides the solution(s). Stable models, also called answer sets, are represented by consistent sets of ground facts provided to the user through a textual representation often long nEvelop-O and verbose. Unfortunately, text-based representation makes it dificult to interpret the answer sets, because important information is not easily identifiable. This problem equally impacts both students taking their first steps wAitShP and experienced programmers when dealing with very complex applications.
In this paper we introduce ASPECT, a sub-languageAoSfP in which the user can directly define, in an intuitive and declarative way, a graphical representation of answer sets. This language complements other tools already presented for the graphical representation of answer sets [5, 6, 7, 8] but at the same time introduces some noteworthy advantages. First, ASPECT is designed to generate high-quality vector graphics. In fact, ASPECT atoms are converted to the popular markup languageATLEX making it easy to incorporate those graphics into documents such as scientific papers, course handouts and presentations. ASPECT also gives the programmer complete flexibility in graphics design since it provides only low-level graphical primitives (e.g., lines, polygons, ellipses, etc.) that can be exploited for any type of visualization. Finally, the syntax of ASPECT, although compatible wAitShP, is strongly inspired by that of the popular TikZ language making its use more intuitive to those already familiar with the latter.
A preliminary version of the interpreter for the ASPECT language is available online at https://github.com/abertagnon/asp.ect
The rest of the paper is organized as follows. First the ASPECT language and the current structure of its interpreter are described in Se2c.tSioomne examples of possible uses of the ASPECT language are presented in Secti3o.nRelated works are described in Sect4i.oTnhe ifnal section contains conclusions and some possible future developments of this project.
ASPECT is declarative sub-languageAoSfP that can be used to define the graphical representation of an answer set. ASPECT syntax consists of special atomic formulas that define rendering of geometric primitives such as points, lines, polygons, ellipses, etc. Currently, the language consists of 21 atoms that allow the user to represent 8 diferent geometric shapes and also manage their style properties such as color and fill (if applicable). The positioning of each element is determined by Cartesian coordinates. A complete list of ASPECT atoms is given in Tables1 and2.
The syntax of the ASPECT language is inspired by the popular PGF/TikZ language developed for drawing vector graphics in the markup languAaTgEeXL.Portable Graphics FormaPtG(F) is a language that provides a collection of low-level graphics primitAiTvEeXfoarndLTikZ is a set of higher-level macros that maPkGeF easier to use. To date, users who want to make graphics in LATEX interact almost exclusively with TikZ, which has become a whole language of its own. ASPECT atoms can indeed be easily converted to the TikZ language. The ASPECT interpreter is responsible for the conversion.
The ASPECT interpreter is written in Java, and it depends oAnSPansolver and a LaTeX distribution. In the current implementation we cchloisnego1 as ASP solver and TeX Liv2eas LATEX software distribution, but other systems can be supported with minor implementation 1https://potassco.org/clingo/ 2https://www.tug.org/texlive/ aspect_drawarc(x1,y1,a1,a2,r1) aspect_colorarc(x1,y1,a1,a2,r1,color) aspect_drawarrow(x1,y1,x2,y2) aspect_drawarrow(x1,y1,x2,y2,color) x1,y1 x a2 x1,y1 x x x1,y1
x x2,y2 aspect_drawnode(x1,y1,"s1") aspect_drawnode(x1,y1,X) aspect_colornode(x1,y1,"s1",color) aspect_imagenode(x1,y1,image,width) aspect_drawline(x1,y1,x2,y2) aspect_colorline(x1,y1,x2,y2,color) aspect_drawrectangle(x1,y1,x2,y2) aspect_colorrectangle(x1,y1,x2,y2,color) aspect_fillrectangle(x1,y1,x2,y2,fill) node line arc triangle circle ellipse aspect_drawtriangle(x1,y1,x2,y2,x3,y3) aspect_colortriangle(x1,y1,x2,y2,x3,y3,color) aspect_filltriangle(x1,y1,x2,y2,x3,y3,fill)
x x3,y3 x x1,y1 x
x2,y2 aspect_drawcircle(x1,y1,r1) aspect_colorcircle(x1,y1,r1,color) aspect_fillcircle(x1,y1,r1,fill) changes. These dependencies are due to the fact that we initially wanted to develop a quick-touse tool capable, with a single command-line invocation, of generating frAoSmPapnrogram a vector graphic representation of its solution(s) inAbTEoXthanLd Portable Document Format (PDF) file formats at the same time.
In order to more easily handle diferent types of problems, four operating modes have been provided.
The usage of ASPECT in standard mode is very simple. The interpreter should be invoked from the command line using the following scheme: java ASPect <clingo arguments> <input file(s).lp> First, theASP program along with the ASPECT code for the visualization are passed to clingo together with the opportune solver options (if needed). The problem ASP code and the ASPECT code for visualization can be in the same file or in separate files since clingo also accepts multiple ifles as input. The output from clingo is redirected to a thread that is responsible, for each answer set, for generating the correspondAiTnEgXLfile.
Then, each LATEX file containing the TikZ description of the vector graphics is automatically converted into a PDF file using the pdfTeX extension.
The architecture of the ASPECT interpreter standard mode is sketched in Al1g.oTrihtehm atom2TikZ function (line7) simply rewrites each ASPECT atom into a corresponding TikZ instruction. Below an example of an ASPECT atom converted into a TikZ instruction: aspect_fillrectangle(3,15,5,17,gray) ----> (atom2TikZ) (atom2TikZ) ---> \draw [fill=gray] (3,15) rectangle (5,17); Algorithm 1 Sketch of ASPECT interpreter 9: 10: 1: AnswerSets =ASP solver(solver arguments and input file(s)) 2: for each answerSet ∈ AnswerSetdso 3: LaTeXOutput = new outpuAtTLEX file 4: write preamble on LaTeXOutput 5: for each atom ∈ answerSetdo 6: if ∈ ASPECT languagethen 7: tikz_istruction a=tom2TikZ( ) 8: write tikz_istruction on LaTeXOutput write end section on LaTeXOutput
PDFOutput =pdflatex (LaTeXOutput)
The merge andfree modes are designed specifically for handling problems that admit more than one solution and also implement support for AtThEeXbLeamer class.
The merge mode, which can be invoked using the syntax: java ASPect merge resize<dim> <clingo arguments> <input file(s).lp> groups all the graphical representations of answer sets into aATsEiXngbleaLmer document and consequently a singlPeDF file. This mode is aimed at creating animations for presentations in LATEX in fact if the problem admits multiple solutions each of these will be placed in a diferent beamer frame. In the case of optimization problems, with this mode, it is possible to show in a simple way the successive solutions of increasing quality found by the solver up to the optimal one.
Use of the merge mode is not recommended if the user wants to constantly monitor the output produced by theASP solver, as thPeDF file will not be produced until the solver has completed the computation. The merge mode accepts a resize parameter that usreesstihzeebox command of the ALTEX graphicx package to resize the produced graphic. The value odfitmheparameter uses em (em quadrat) as the unit of measure, which is applied as both vertical and horizontal length.
Free mode works similarly to merge, but allows the user to customize beamer frames and the tikzpicture environment by entering custom commands through the incorporation of two ifles calledbefore.tex andafter.tex . A schematic of the architecture of the ASPECT interpreter when operating in free mode is depicted in Figu1r. eFree mode, similarly to the merge mode, can be invoked using the command line by entering: java ASPect free <clingo arguments> <input file(s).lp> problem.lp draw.lp
ASPECT interpreter
solution.tex solution1.tex solution2.tex
solutionN.tex stdout clingo pdflatex after.tex
before.tex solution.pdf
Graph mode as the name suggests allows for quick visualization of solutions that can be represented by a graph. An example is shown in Secti3o.1n. This mode can be invoked with the command: java ASPect graph <clingo arguments> <input file(s).lp> Graph mode allows the user to insert graphical elements without having to worry about specifying coordinates, which will be handled automatically by the TikZ package.
Graph mode handles a diferent set of ASPECT atoms than the previous modes. The complete list of ASPECT atoms that can be used in this mode is given in T3a.bAlegain note how these graph elements do not require coordinates to be specified for their visualization.
In this section we show how to use ASPECT syntax in various problems typical oAfStPhe context.
Graph coloring is a well-known problem that is often used as an example to introduce answer set programming to students. The problem consists of assigning colors to vertices of a graph such that two adjacent vertices do not share the same color.
The ASP encoding of the problem consists noofde(N) atoms to denote the nodes of the graph whereN is an index that identifies the node. Also part of the encodingaracr(eA,B) atoms indicating the edges of the graph acnodlour(N,Color) atoms indicating the colour associated with each vertex.
The coordinates of the various graph nodes in the visualization are not important therefore we used the graph mode described in the previous section. Below are the ASPECT lines of code for the visualisation of the problem shown in Fig2u.re aspect_colornode(X,Color):- color(X,Color). aspect_drawline(A,B):- edge(A,B).
In the first line, theaspect_colornode command draws a node graph witCholour filling. In the second line, thaespect_drawline command draws the edges of the graph. 4 5 0 1 3 2
The N-queens problem is a classic puzzle that involves pla cinchgess queens on an × chessboard such that no two queens threaten each other: so, no pair of queens should share the same row, column, or diagonal. The challenge is to find a solution for any given v al.ue of Suppose that we are using aAnSP encoding where the chessboard is described with an atom grid(I,J) for all the possible squares of the board, while the solution has aqnueaetno(mR,C) indicating each queen positioned on the board; the programmer can draw the chessboard by adding just two lines of code. aspect_fillrectangle(2*I-1,2*J-1,2*I+1,2*J+1,gray):- grid(I,J), I\2=J\2. aspect_drawrectangle(2*I-1,2*J-1,2*I+1,2*J+1):- grid(I,J), I\2!=J\2.
These two lines of ASPECT code draw the squares of the checkerboard, each with side length 2 and centered in(2I,2J). In particular, the first line set the background color to gray for half of the squares to create the classic chequered pattern. In a similar fashion, we can draw the queens with: aspect_imagenode(2*I,2*J,"queen.png",50):- queen(I,J).
ASPECT allows the programmer to further customize the visualization of a solution: as observable in the line above, users can include their own images in the plot just by specifying the respective filenames in the left-hand side of the desired rule. An example of the vector graphic produced by ASPECT, for this problem, using the syntax presented abov e=a8nd is presented in Figure3a.
On this well-known problem we also decided to evaluate the performance of the ASPECT interpreter. Tabl4eshows how the time required by APSECT interpreter to generate the visualization varies as the problem size varies. The setup used in the tests consisted o®f an Intel Core® i7-9750H CPU running at 2.6GHz with 16GB of RAM and Ubuntu 22.04 as OS. clingo
the N-queens problem as the number of chess queens varies. A visualization of the problem with = 100 is shown in Figure 4.
Hitori is a logic puzzle that is played on a grid of squares, where each square contains a number. The goal is to shade in some of the squares so that no number appears more than once in any row or column, and all unshaded squares are connected to each other horizontally or vertically.
Using a similar syntax as the one adopted forNt-qhueeens problem to represent squares and nodes, we can obtain the graphical representation of the solution (see3bF)i.gure
The squares are encoded usinsgchema(X,Y,N) atoms whereX,Y indicates the position of the square in the grid anNdis the displayed number. Thbelack(X,Y) atoms indicate the shaded squares.
10 30 60 100 2 1 4 1 4 3 4 2 3 4 1 4 5 4 1 3 4 1 2 5 (a) N-queens problem (b) Hitori aspect_fillrectangle(2*(X-1),2*(Y-1),2*X,2*Y,gray):- schema(X,Y,N), black(X,Y). aspect_drawrectangle(2*(X-1),2*(Y-1),2*X,2*Y):- schema(X,Y,N). aspect_drawnode(2*X-1,2*Y-1,N):- schema(X,Y,N).
Diferently from the previous case, here “standard” nodes were needed in order to draw the correct number in each square, rendered through the vaNr,iabbultethe programmer can arbitrarily choose to use any desired character or string to represent the nodes. Another famous logic puzzle that can be represented in a similar way to Hitori is Sudoku.
Minesweeper is a logic puzzle that is played on a game board divided into cells. The player’s goal is to find where the hidden mines are located using clues found on the game board as numbers. The number in some cells corresponds to the number of mines in the 8 cells surrounding it.
A classicASP coding for this game involvensumber(X,Y,N) atoms whereX and Y are the row and column indexes of the game board aNndis the clue that is displayed in the cell at that position. Themine(X,Y) atoms represent the position of the mines.
Using a combination of ASPECT atoms presented in the previous examples, the game board graphical representation can be easily obtained. In fact, this game requires the visualization of nodes both containing variables and containing images (for mines). An example is shown in Figure5, and the code used to obtain the figure is shown below. aspect_drawrectangle(2*(X-1),2*(Y-1),2*X,2*Y):- rows(X), cols(Y). aspect_drawnode(2*X-1,2*Y-1,N):- number(X,Y,N). aspect_imagenode(2*X-1,2*Y-1,"mine.png",40):- mine(X,Y).
2 2 2 1 1 4 2 3 4 3 1 3 1 3 2 3 1 1 2 1 2 2 3 2 2 3 2 3 2 3 3 3 3 3 2 2 2 2
A scheduling problem involves determining the order of execution of a set of tasks while taking into account constraints such as: precedence constraints, capacity constraints, etc. The solution of a scheduling problem can be graphically represented by a Gantt chart. In the following we will show, with a simple example, how ASPECT can be used to generate Gantt charts. In our example we consider a very simple scheduling problem that consists of 4 activities each associated with its own duration and an identifying color: going to the bank (1 hour, green), going to the store (2 hours, blue), going to the post ofice (1 hour, red), and going to work (4 hours, yellow). The constraints of the problem state that it is necessary to go to the bank before the store and it is necessary to go to the post ofice before work. All activities should take place between 9 a.m. (begin) and 5 p.m. (end), and the activities obviously should not overlap.
The ASP encoding of the problem consists otafsks(T,Colour) atoms representing the various tasks to be scheduled wheTries a sequential numerical identifier for each task and Color the colour associated with it. Tsehqeuence(T,S,E) atoms encode the solution; in these atomsT identifies a specific task while S and E are the start and end times of that task, respectively.
The complete ASPECT code with which we obtained the six solutions of the example problem described (see Figure6) is shown below. aspect_fillrectangle(S-begin,I,E-begin,I+1,Color) :- sequence(T,S,E), task(T,Color). aspect_drawline(T-begin, 1, T-begin, N+1):- T=begin..end, n_tasks(N). aspect_drawnode(T-begin, N+2, T):- T=begin..end, n_tasks(N).
The Traveling Salesperson ProbleTmS(P) is a classic optimization problem that involves finding the shortest possible route that a traveling salesperson can take to visit a given set of cities exactly once and return to his starting point. The objective is to find the Hamiltonian cycle with the minimum total edge weight. Many instances of this problem include the coordinates of cities on the plane. Such coordinatesAiSnP can be represented by atoms apsoint(C,X,Y). The solution is usually given as a predicate representing the arcs being followed: supposing that those arcs are identified by atocmyscle(A,B), where and are the nodes of the graph with coordinate(s , ) and( , ) respectively, we can obtain a graphic representation of (every) solution just by adding the lines: aspect_drawline(XA,YA,XB,YB):- cycle(A,B), point(A,XA,YA), point(B,XB,YB). aspect_fillellipse(XA,YA,1,1,gray):- point(_,XA,YA). to the ASP code of the problem. The first rule will plot the forementioned arcs, while the second one is in charge of drawing the nodes between the lines, represented as gray filled circles.
As known, optimization problems usually find a plethora of feasible solutions while searching for the optimal one(s), i.e. the solution(s) optimizing the objective function: using ASPECT, programmers have the possibility of automatically plotting all the solutions found, either in separate files or in a single one. A visualization using APSECT TofSPa is shown in Figure7, in particular, the first solution found by the ASP solver and the optimal solution are shown. (a) First solution (b) Optimal solution
The dificulty in interpreting answer sets has led to the development over the years of tools, leveraging diferent technologies, aimed at producing easier-to-read graphical representations.
ASPViz [7] is a Java program that constructs images from the answer set of a given program. ASPViz uses theASP language to define how elements of the problem solution should be displayed. Atoms of ASPViz language are extracted from the answer set and used to produce a graphical visualization using the Java SWT graphical toolkit. In addition to rendering answer sets of a program individually, ASPViz may be used also to create animations and multi-framed image visualisations.
Although ASPViz ofers powerful visualization options like the animation of multiple solution outputs and the possibility to customize the atoms with external image files, it forces the user to create a second.aspviz program. In that file, the user has to specify the relationships between the atoms of the originAalSP program and the desired visual representation, together with the customization options: such process could be cumbersome in some applications, we find that our approach is simpler for the novice user.
IDPDraw [6] is a tool for visualizing finite structures that can be used to visualize the output of an ASP solver written in C++.IDPDraw recognizes 8 types of atoms that allow the programmer to draw elementary geometric shapes (e.g., polygons, ellipses) and define their display properties (e.g. foreground color, background color, position, etc). IDPDraw atoms are interpreted and displayed through a user interface based on the Qt library. As in the case of the previous system, it is possible to create animations by associating each atom with a time argument. A9]S,PIDE [ an Integrated Development EnvironmentAfoSrP, includes IDPDraw as visualization tool. The sources of IDPDraw are available on3l,inbuet they rely on outdated Qt4 libraries which, having reached the end of life, have been removed from the repositories of the major Linux distributions.
Kara [5] is a tool created following the approach already introduced by ASPVIZ and IDPDraw as it uses theASP language itself to define the visualization of answer sets. Unlike the latter, which position graphic primitives according to static coordinates only, Kara allows for more high-level specifications, supporting graph structures, grids, and relative positioning of graphical elements. Kara is written in Java and integrated in the Se1a0L]ioinnt[egrated development environment forASP. The SeaLion executable we obtained via the4lirnekported in1[0] has as its latest update May 2017 and we were not able to run it on the latest Ubuntu 22.04.
More recently Dovier et a1l1.][developed, for teaching purposes, a Java tool capable of visualizing the output returned byAtShPe solverclingo [3]. However, this tool turns out to be limited to displaying only problems concerning a grid (e.g. magic square, sokoban, Sam Lloyd’s puzzles etc.) which are the ones considered in their publication.
A recent publication from last year concerning the visualisation of answer sets presented clingraph. Clingraph 8[] is a tool which aims at visualizing answer sets by meanAsSoPf language itself. Clingraph is based on ASPViz, which, however, has been completely redesigned and adapted to work with modeArSnP systems. Clingraph was originally designed as a visualizer for graphs defined as a set of facts but is now able to generate images similar to those produced by ASPECT. Among other features, it allows the export of imagATeEsXincoLde but lacks the more advanced features provided by ASPECT such as integration with beamer for the automatic creation of presentations and the possibility of custoATmEiXsindgocLument by importing external files.
We presented ASPECT, a language for describing graphical elements that can be easily provided as answer sets, letting the user describe complex drawings in an intuitive and declarative way. The ASPECT syntax consists of special atoms that define the graphical rendering of geometric 3https://wms.cs.kuleuven.be/dtai/pages/software/idpdraw/idpdraw 4https://sourceforge.net/projects/mmdasp/
primitives such as points, lines, polygons, ellipses, etc. Users can combine ASPECT atoms to generate figures of any complexity as answer sets.
We also presented a preliminary version of the ASPECT interpreter, written in Java, that is responsible for converting ASPECT atoms into the popuATlEaXr mLarkup language to produce vector graphics. A preliminary version of the interpreter for ASPECT is available online at https://github.com/abertagnon/asp.ecStince it usesALTEX as output format, the documents produced by ASPECT are easy to embed in scientific articles, course handouts, and presentations. Nonetheless, theATLEX output can also be converted to other (vectorial) graphic formats for other uses, such as in web pages.
The syntax of ASPECT is inspired by the TikZ language. To date, the graphical primitives implemented in ASPECT are limited compared to those provided by TikZ especially in terms of the style properties of geometric primitives. However, the structure of the interpreter is easily adaptable to allow extension to more TikZ features in the future.
A future extension is to make the ASPECT interpreter independentclfrionmgo and the pdfTeX extension. The choice to introduce these systems into the pipeline while speeding up image generation at the same time prevents the user from choosing their faAvSoPrsitoelver and LATEX compiler.
Another extension would involve visualizing a single answer set through a sequence of graphical representations, for problems whose answer set is a sequence of actions. This would be useful in planning problems (e.g. Tower of Hanoi, Block world) where atoms include the timestep at which the action they represent is actually performed. teaching AI and expert systems courses, IEEE Transactions on Education 36 (1993) 193–197. doi:10.1109/13.204845. [2] M. Gelfond, V. Lifschitz, The stable model semantics for logic programming, in: R. A.
Kowalski, K. A. Bowen (Eds.), Logic Programming, Proceedings of the Fifth International Conference and Symposium, Seattle, Washington, USA, August 15-19, 1988 (2 Volumes), MIT Press, 1988, pp. 1070–1080. [3] M. Gebser, R. Kaminski, B. Kaufmann, T. Schaub, Clingo = ASP + control: Preliminary report, CoRR abs/1405.3694 (2014). [4] N. Leone, G. Pfeifer, W. Faber, T. Eiter, G. Gottlob, S. Perri, F. Scarcello, The DLV system for knowledge representation and reasoning, ACM Trans. Comput. Logic 7 (2006) 499–562.
URL: https://doi.org/10.1145/1149114.114911.7doi:10.1145/1149114.1149117. [5] C. Kloimüllner, J. Oetsch, J. Pührer, H. Tompits, Kara: A system for visualising and visual editing of interpretations for answer-set programs, in: H. Tompits, S. Abreu, J. Oetsch, J. Pührer, D. Seipel, M. Umeda, A. Wolf (Eds.), Applications of Declarative Programming and Knowledge Management - 19th International Conference, INAP 2011, and 25th Workshop on Logic Programming, WLP 2011, Vienna, Austria, September 2830, 2011, Revised Selected Papers, volume 7773 Loefcture Notes in Computer Science, Springer, 2011, pp. 325–344. URL:https://doi.org/10.1007/978-3-642-41524-1_2.0doi:10. 1007/978-3-642-41524-1\_20. [6] J. Wittocx, Idpdraw, a tool used for visualizing answer sets, 2009. [7] O. Clife, M. D. Vos, M. Brain, J. A. Padget, ASPVIZ: declarative visualisation and animation using answer set programming, in: M. G. de la Banda, E. Pontelli (Eds.), Logic Programming, 24th International Conference, ICLP 2008, Udine, Italy, December 9-13 2008, Proceedings, volume 5366 of Lecture Notes in Computer Science, Springer, 2008, pp. 724–728. URL: https://doi.org/10.1007/978-3-540-89982-2_6.5doi:10.1007/978-3-540-89982-2\_65. [8] S. Hahn, O. Sabuncu, T. Schaub, T. Stolzmann, Clingraph: ASP-based visualization, in: G. Gottlob, D. Inclezan, M. Maratea (Eds.), Logic Programming and Nonmonotonic Reasoning - 16th International Conference, LPNMR 2022, Genova, Italy, September 5-9, 2022, Proceedings, volume 13416 oLfecture Notes in Computer Science, Springer, 2022, pp. 401–414. URL: https://doi.org/10.1007/978-3-031-15707-3_3.1doi:10.1007/978-3-031-15707-3\ _31. [9] O. Febbraro, K. Reale, F. Ricca, ASPIDE: integrated development environment for answer set programming, in: J. P. Delgrande, W. Faber (Eds.), Logic Programming and Nonmonotonic Reasoning - 11th International Conference, LPNMR 2011, Vancouver, Canada, May 16-19, 2011. Proceedings, volume 6645 oLfecture Notes in Computer Science, Springer, 2011, pp. 317–330. URL: https://doi.org/10.1007/978-3-642-20895-9_3.7 doi:10.1007/978-3-642-20895-9\_37. [10] J. Oetsch, J. Pührer, H. Tompits, The sealion has landed: An IDE for answer-set programming - preliminary report, in: H. Tompits, S. Abreu, J. Oetsch, J. Pührer, D. Seipel, M. Umeda, A. Wolf (Eds.), Applications of Declarative Programming and Knowledge Management - 19th International Conference, INAP 2011, and 25th Workshop on Logic Programming, WLP 2011, Vienna, Austria, September 28-30, 2011, Revised Selected Papers, volume 7773 ofLecture Notes in Computer Science, Springer, 2011, pp. 305–324. URL: https://doi.org/10.1007/978-3-642-41524-1_1.9doi:10.1007/978-3-642-41524-1\_19. [11] A. Dovier, P. Benoli, M. C. Brocato, L. Dereani, F. Tabacco, Reasoning in high schools: Do it with ASP!, in: C. Fiorentini, A. Momigliano (Eds.), Proceedings of the 31st Italian Conference on Computational Logic, Milano, Italy, June 20-22, 2016, volume 1645 of CEUR Workshop Proceedings, CEUR-WS.org, 2016, pp. 205–213. URL: https://ceur-ws.org/ Vol-1645/paper_9.pd.f