Product configuration is one of the most important industrial applications of artificial intelligence. In order to enable customers to individualize complex products, usually logical configuration models are necessary. One challenge that exists here is the communication of product knowledge to the customer. This work deals with the situation of invalid customer requirements under given logical constraints. The goal is to explain why configurations are invalid and how they can be minimally changed to become valid again. This involves computing all minimal subsets of both constraints and requirements that make the configuration unsatisfiable. For this, we present a novel approach based on the declarative paradigm of Answer Set Programming. We empirically demonstrate its suitability for real-time configurators with thousands of features and constraints. The approach thus fills the gap of an easy-to-implement as well as high-performing conflict resolution component.
Product configuration deals with the commercial interest of making an ofering more attractive
by allowing it to be personalized by customers. As a result, products or services are more
likely to be purchased. Instead of ofering a predefined set of cars, for example, customers can
instead assemble the exact car they want from components such as diferent wheels, colors,
and assistants. Many products are also often too complex that there is no other option than to
configure them specifically for each customer. This typically happens with non-standardizable
parameters, such as the dimensions and quantity of window blinds. Similar to software
development, product configuration has thus accompanied many companies for a long time. It is
therefore considered one of the most successful applications of artificial intelligence. Product
configuration is not only used for simple products, but for a variety of diverse problems [
To avoid overwhelming the user with unnecessary information, minimal subsets have to be
calculated in both cases. For Goal 1 these are the subsets of unsatisfied constraints. For Goal 2
they are the subsets of feature selections that make the configuration unsatisfiable. Although
various solutions for computing minimal subsets exist, e. g., QuickXPlain [
ASP. • We present an easy-to-implement approach for explaining and resolving conflicts during product configuration. • We demonstrate the high performance of the approach, which makes it well suited for real-time applications.
For this, in Section 2, we first define product configuration and in particular the explanation as well as the resolution of conflicts. Based on this definition of the problem, we show the related literature in Section 3. Here, we first discuss the broader context, then specifically ASP and the algorithm needed for our implementation. Subsequently, we present this implementation in Section 4 and show an evaluation of our approach in Section 5. Finally, we conclude this work in Section 6.
Product configuration is a well researched area and there are several eforts for a general
ontology [
Product configuration involves the feature-based personalization of a product, which is assembled from various components. A simple example of this is the configuration of a car. Customizable features here include the type of steering wheel and the color of the casing. The lowest common denominator of general ontologies are therefore features and their type in the knowledge modeling, i. e., variable characteristics of the product and their domains. Definition 1 (Feature). The properties of a product are specified by 1 ≤ ≤ features. A feature is a variable defined by its feature type. The type domain ( ) of a feature determines its discrete, finite, and non-empty domain.
We use typewriter font for concrete examples and write features with a capital initial letter. Domain values are completely capitalized. For example, the color of a car could be described by a feature Color, where domain (Color) = {BLACK, WHITE, RED}. Features define the structural knowledge about configurable aspects in a product. But a large part of the knowledge is behavioral, i. e., the constraints on the interaction between features. The set of all possible configurations results from the cross product of the domains of all features. However, usually only a fraction of them form valid configurations, i. e., combinations of feature values that can be manufactured. To capture this set of valid solutions in the space of all possible solutions, constraints are defined.
Definition 2 (Constraint). A constraint restricts the solution space of possible configurations. It is defined as a relation that maps a configuration to a boolean truth value, i. e., ∶ → {⊤, ⊥} .
(1)
While the configuration will be defined in more detail shortly, the combination of features and constraints of a product forms a knowledge base.
Definition 3 (Configuration Knowledge Base) . A configuration knowledge base is a triple ( , , ), where is the set of all features, is the set of all feature types, and is a set of constraints over .
Although here we bypass the dynamic nature of product configuration, where features become active depending on the configuration, our approach can be easily extended to do so. This requires introducing cardinalities for features, e. g., to define optional features. Regardless, the knowledge base can be used to ofer individual configurations to customers. Definition 4 (Configuration) . A configuration binds values to features ∈ in a knowledge base ( , , ).
= { = ∣ ∈ ∧ ∈ domain ( )} . is complete, if (3) holds, and valid if (4) holds. (2) (3) (4) complete ( ) ∶ ∀ ∈ ∶ ∈ valid ( ) ∶ ∀ ∈ ∶ ( ) = ⊤
A configuration is therefore merely the finished process of feature binding where exactly one value exists for each feature. The user requirements are a partial configuration, where each feature assignment = is explicitly given by the user. Neither complete ( ) nor valid ( ) have to be true. If valid ( ) holds, the configuration task consists of completing to a configuration such that complete ( ) and valid ( ) holds. Note that multiple configurations may be possible for completing a configuration task. The amount of options is upper bounded by the cross product of the domains of all features. There is not always a solution to a configuration problem, though, namely when valid ( ) does not hold. In this paper we are interested in exactly this case, which we refer to as conflict . To sell a configuration despite invalid requirements, the conflict must be explained and resolved interactively with the customer.
2. A description of the violated constraints in natural language
Even if the general definition 2 of constraints as arbitrary relations is restricted to, for example,
ifrst order logic, it is very dificult to automatically generate natural language explanations.
While it is easy to assemble explanations from blocks of text for each logical operator, the
result is typically hard to parse and not helpful to the user. In most cases, it is also not in a
company’s best interest to disclose the exact constraints of the knowledge base to the public.
Instead, to concisely explain the higher purpose of violated constraints and in particular the
interaction of multiple constraints, usually external knowledge is required. We therefore argue
that explanations have to be manufactured in natural language as part of knowledge modeling.
One solution to this may be the use of modern language modeling and its ability for zero shot
learning [
Instead, this paper focuses on Step 1 — the analysis of violated constraints. These are especially important for debugging during the development of the knowledge base. Although it is easy to output which constraint was violated during the reasoning process, two challenges arise: 1. A conflict only arises through the interaction of several constraints. Each individual constraint would not yield an unsatisfiable configuration. 2. Only the minimal set of constraints yielding an unsatisfiable configuration has to be determined. Note that there may be several independent sets.
As an example, we look again at the car configuration problem. Here, among others, four constraints exist, for example, as a consequence of a larger table of allowed values. • 0 ∶ Body = OFF_ROAD → Drive = ALL_WHEEL • 1 ∶ Drive = ALL_WHEEL → Transmission = AUTOMATIC • 2 ∶ Transmission = AUTOMATIC → CruiseControl = TRUE • 3 ∶ ((Leather = TRUE) ∧ (Color = BLACK ∨ Color = WHITE))∨ … Note that this example formally hurts the definition of a constraint as a relation, but it is purely for intuition. Body determines the type of car, e. g., sport, cabriolet, or SUV, and Color its finish. A customer now wants to buy a black of-road vehicle, i. e., 0 = {Body = OFF_ROAD, Color = BLACK}. Since they want to save money, they choose faux leather and deactivate the cruise control assistant resulting in 1 = 0 ∪ {Leather = FAUX, CruiseControl = FALSE}. The example is tailored to intuitively see that the user requirements are thereby unsatisfiable. In addition, both Challenges 1 and 2 are illustrated.
1. There is a chain of constraints which only together yield unsatisfiability, namely 0, 1, and 2 together with requirements for CruiseControl and Body. 2. Two independent conflicts occur. First, the conflict chain of the previous point. Second, the choice of color Color which is incompatible with the faux leather Leather by 3. Based on this, we define the goal of analysing conflicts in Equation 5. It consists of determining the set − of all ⊆-minimal sets of constraints which alone lead to the unsatisfiability of user requirements .
− = { − ⊆ ∣ ¬ valid ( ) given ( , , ∩
−)} such that ∀ , ∈ − ∶ ⊈ . (5)
In practice, a suggestion should be ofered to the user on how to change the set of unsatisfiable requirements to resolve all conflicts. For this, a subset of needs to be found, whose removal makes it possible to complete into a valid configuration again. Again, there are two challenges: 1. There can be diferent ways to resolve a conflict. For example, with a constraint on a combination of multiple features, each individual feature can be reset on its own. 2. Each way to resolve a conflict should be minimal, i. e., no subset of any possibility also leads back to satisfiability.
Given Challenge 1, we are interested in computing all ⊆-minimal candidates for resolving the conflict. These can be subsequently ranked by a recommender system to maximize user or company interest. We again examine the car example from Section 2.2. To resolve the two conflicts under the given four constrains and the requirements
{Body = OffRoad, Color = Black, Leather = Faux, CruiseControl = False} there are four optimal possibilities for removing requirements.
1. {CruiseControl, Color} 2. {CruiseControl, Leather} 3. {Body, Color} 4. {Body, Leather} Similarly to explaining conflicts the task of resolving conflicts defines itself by calculating ⊆-minimal answers. Instead of the constraints, however, all sets − of the user requirements are to be computed, by whose exclusion the configuration becomes valid again. − = { − ⊆ ∣ valid ( ⧵ −) given ( , ,
)} such that ∀ , ∈ − ∶ ⊈ . (6) Note that every single set − ∈ − must contain at least one value for all − ∈ −, that gives rise to the respective conflict, i. e., | | ≥ | −|. For this reason, each of the four conflict resolution options consists of two features, one for each of the conflicts.
Based on the preceding problem definition, we now contextualize our work in the literature in
Section 3.1 and present the background of Answer Set Programming in Section 3.2.
The explanation of unsatisfiable constraint systems has a large background [
A recent survey classifies methods along four dimensions [ 25]: First, whether the solution is solver-specific or solver-agnostic. Solver-agnostic methods typically use a-posteriori analyses to generate explanations. In this respect, our approach is specific to Conflict Driven Nogood Learning [26], though agnostic to the specific implementation. The second dimension is user or solver focused. Our explanations are directed at users rather than to support the search process of a solver. The third dimension is about various quality metrics, e. g., to prefer the smallest possible explanation size. Since our methods potentially find all unsatisfiable constraint and user requirement sets, any kind of ranking metrics can be easily implemented. This also provides an answer to the last dimension, namely whether all or only a subset of the declarations are computed. It is relevant here to mention that our conflict analysis is only partially any-time capable, but our conflict resolution works completely any-time, which is explained in more detail in Section 4.
While there is a lot of literature on general approaches for constraint satisfaction problems,
the literature specific to product configuration is much sparser [
A logic program in Answer Set Programming consists of rules of the form a1 ; … ; a :- a+1
, … , a , not a+1 , … , not a . where each a is an atom of form p(t1,...,t ) and all t are terms, composed of function symbols and variables. For 1 ≤ ≤ ≤ , atoms a1 to a are often called head atoms, while a+1 to a and not a+1 to not a are also referred to as positive and negative body literals, respectively. An expression is said to be ground, if it contains no variables. As usual, not denotes (default) negation. A rule is called a fact if = = = 1 , normal if = 1 , and an integrity constraint if = 0 . In this work, we deal with normal logic programs only. Semantically, a logic program induces a set of stable models, being distinguished models of the program determined by the stable models semantics [28].
To ease the use of ASP in practice, several extensions have been developed. First of all, rules with variables are viewed as shorthands for the set of their ground instances. Further language constructs include conditional literals and cardinality constraints [29]. The former are of the form a:b1,...,b , the latter can be written as s {d1;...;d } t, where a and b are possibly negated (regular) literals and each d is a conditional literal; s and t provide optional lower and upper bounds on the number of satisfied literals in the cardinality constraint. We refer to b1,...,b as a condition. The practical value of both constructs becomes apparent when used with variables. For instance, a conditional literal like a(X):b(X) in a rule’s body expands to the conjunction of all instances of a(X) for which the corresponding instance of b(X) holds. Similarly, 2 {a(X):b(X)} 4 is true whenever at least two and at most four instances of a(X) (subject to b(X)) are true. Note that we name a normal rule with a cardinality constraint construct as the head a choice rule.
Next, let us consider a system directive particular to clingo. Clingo ofers means for manipulating the solver’s decision heuristics. We rely on this capacity to compute answer sets that are subset minimal with respect to the choices of the solver. Such heuristic directives are of form #heuristic a:b1,...,b . [w,m] where a:b1,...,b is a conditional literal; w is a numeral term and m a heuristic modifier, indicating how the solver’s heuristic treatment of a should be changed whenever b1,...,b holds. The modifier false, for instance, not only assigns w as the level of a given that clingo decides first upon atoms of the highest level, but also enforces that a becomes false whenever it is chosen by the solver.
Finally, Algorithm 1 for finding ⊆-minimal answers involves two ideas [30]. 1. First, all atoms that are to be ⊆-minimized are set to false using heuristic directives before deciding on the truth values of other atoms. This ensures that the first answer found is ⊆-minimal with respect to . 2. To enumerate all ⊆-minimal responses, the solver adds a nogood over the true atoms in ⊆ after each call. This constraint ensures that no superset of the ⊆-minimal answer is found, which ultimately leads to enumerating all ⊆-minimal answers.
The loop of solving and adding nogoods is iterated until the program is no longer satisfiable and thus all answers have been found.
foreach ∈ do
SetSign(, , 1 ); while satisfiable do
S←Solve(P); P←AddConstraint(⊥ ← 0, … , for { 0, … , } = ∩ ); Output( );
Algorithm 1: Algorithm used for finding minimal subsets [ 30]
This section shows how to make use of ASP for the problem definition of Section 2. For that, we ifrst define the product configuration knowledge base in ASP syntax. Then, both conflict analysis and resolution are presented. Note that ASP generally restricts the definition of constraints as arbitrary relations. However, clingoofers with so-called theories capabilities to introduce foreign solving techniques and thus to remove this restriction [31]. For the scope of this paper, we nevertheless limit the expressive power of constraints to the capabilities of ASP.
In ASP, problem instances are specified as facts. For this, we first formulate the structural and behavioral knowledge. We then describe the solution path of the search problem, known as encoding. 4.1.1. Structural Knowledge The main predicate of the hierarchy is feature/2 with arguments TYPE, and NAME. Note that by convention capitalized symbols define variables. Here for feature , TYPE refers to domain ( ) and NAME is the unique feature name. These are specified as facts in the program, i. e., the variables are replaced with specific values. The domain of concrete features is defined using domain/2 to specify a value VALUE for domain TYPE. Lastly, value/2 exists to bind values VALUE to features FEATURE. This predicate is used during inference and to specify user requirements. 4.1.2. Behavioral Knowledge Since constraints are part of a specific problem instance, we reify them into facts from which respective rules are instantiated [31]. For this purpose, we formulate a simplified meta-encoding to instantiate equations, disjunctions, conjunctions, and negations from facts. The facts contain literal identifiers, e. g. variables X, L, R, O, or A as arguments, which are abstract symbols. holds(X) :- eq(X, L, R), value(L, VL), value(R, VR), VL = VR. holds(X) :- or(X), #count{ O : or(X, O), holds(O)} > 0. holds(X) :- and(X), #count{ A : and(X, A), not holds(A)} = 0. holds(X) :- neg(X, N), not holds(N).
Thus, arbitrarily complex syntax trees of logical statements can be created. Note that this encoding can be easily extended, e.g. to formulate inequalities or arithmetic expressions. Wherever we use predicates with the same name but diferent arity, e. g. or/1 and or/2, the shorter predicates just omit the last arguments. 4.1.3. Generate and Test We define the encoding of the problem according to the “generate and test” ASP convention. First, a choice rule describes a set of all possible solutions, i. e., a simple superset of the set of solutions to the given search problem. 1 {value(F, V) : domain(T, V)} 1 :- feature(T, F).
Second, it is followed by an integrity check, which eliminates all solutions that lead to an invalid configuration, i. e., :- constraint(C), not holds(C).
Here C points to the root literal of the syntax tree for any constraint.
Conflict analysis requires finding the set of all ⊆-minimal constraint sets of a knowledge base ( , , ) that alone yield unsatisfiability. Instead of directly calculating these minimally unsatisfiable subsets (MUSs) it is easier to calculate minimal correction sets (MCSs). This requires only an additional predicate mcs/1, which takes as argument the literal C of a constraint/1 atom. The solver decides about the truth value of mcs/1 to deactivate constraints as desired. To then determine all MCSs, the solver initially assigns all mcs/1-atoms to false, as presented in Section 3.2, and learns nogoods about all included mcs/1-atoms after each answer. This requires a modification of the previous integrity check: it cannot be that a constraint does not hold and is not part of a MCS. {mcs(C) : constraint(C)}. :- constraint(C), not holds(C), not mcs(C). #heuristic mcs(C) : constraint(C). [1,false] It is then easy to use the MUS/MCS duality from subsection 3.1 to compute the corresponding MUSs, i. e., the hitting sets of the MCSs. A pure solution in ASP without further implementation requires for example the encoding below. {mus(C) : mcs(I, C)}. :- mcs(I), #count{ C : mus(C), mcs(I, C)} != 1.
Here mcs/2 is the I-th MCS with constraint C and mus/1 is a MUS with constraint C (the index is implicitly given by the answer set). Note that this happens in a separate step. However, the complexity is much less than computing the MCSs and thus negligible. For the car example in Section 2.2 three MCSs result: 1. { 0, 3}
2. { 1, 3}
1. { 0, 1, 2} 2. { 3} 3. { 2, 3} Besides simplicity, a major advantage is the loose description of constraints. The approach is thus agnostic about their concrete implementation. E. g., theory atoms [32] can be easily implemented to simplify numerical calculations [33].
For conflict resolution, we need to find the ⊆-minimal set of user requirements to change. Similar to the previous section, we introduce two predicates mcs/2 and assumption/2. Both take as arguments a FEATURE and VALUE. Note that this formulation is a simplification and can easily be generalized to arbitrary arguments. We then formulate an encoding around the original choice rule for selecting values out of feature domains. Again, we let the solver decide on the truth value of the mcs/2 atom. If it chooses false, the passed assumption is true, i. e., the original user requirement. Otherwise, the solver can make a free choice for the feature. To determine the ⊆-minimal required changes, the solver again uses the algorithm from Section 3.2 and initially assigns all mcs/2-atoms to false. The following listing shows the required modification of the ASP encoding, with the first line giving an example of assumption/2. assumption(color, black). {mcs(F, V)} :- assumption(F, V). value(F, V) :- assumption(F, V), not mcs(F, V). #heuristic mcs(F, V) : assumption(F, V). [1,false]
Finally, we demonstrate the high performance of our approach in Section 5.2. For legal reasons, we do not publish real knowledge bases, but generate synthetic knowledge bases utilizing real ones in Section 5.1.
To evaluate the performance of our approach, we probabilistically generate synthetic knowledge bases ( , , ) for publication. Here, the parameters of the probabilistic distributions are extracted from real knowledge bases of industrial partners. First, and are generated. The number of options of each feature follows a log-normal distribution. Second, a predetermined number of constraints are generated according to the scheme conditions → consequences. The conditions are a binomially distributed conjunction of = or ≠ pairs. Here, for each constituent of the conjunction, an ∈ is drawn at random without replacement, and correspondingly an ∈ domain ( ). An empty set of conditions is allowed. The consequences represent a set of allowed feature combinations, which is the most common constraint type in our real knowledge bases. We first randomly draw a binomially distributed set of more than one feature. This set represents the columns of the combination table. Then, the number of allowed feature-value combinations, i. e., the rows of the table, is generated log-normally distributed. Each combination here consists of a conjunction over a range of values for each feature. Each constituent of the conjunction, i.e., a cell of the table, in turn describes as a disjunction a set of allowed or disallowed values. We ensure that each generated knowledge base allows at least min (1, 000, 000, | | 2) valid configurations.
Finally, we generate problem instances, i. e., ∶ ¬ valid ( ). For this we draw a log-normally distributed percentage of constraints to be violated and slightly modify the integrity check of our encoding: :- #count{ C : constraint(C), not holds(C) } != n.
Here = round ( ∗ || ). We then let the solver decide randomly during search to generate diverse instances. Our data is publicly available. 1
The results of the experiments are shown in Table 1. We evaluate problem instances with 10, 100, 1000 and 10,000 both features as well as constraints. For each size, we create 100 problem instances and report the mean. On average, the programs have relative to their size 890, 10,625, 95,617, and 2,739,913 atoms, and a similar albeit slightly higher number of rules. Note that grounding may typically be performed only once per knowledge base as a preprocessing step. Subsequently, for example, assumptions or multishot capabilities can be used to solve all problem instances [31]. 1https://github.com/kherud/product-configuration-synthetic-data
The explanation of conflicts in unsatisfiable constraint systems has historically been of great interest. Although a variety of approaches exist, they are often purely of academic relevance. Since there are rarely reference implementations, own implementations require profound scientific knowledge. These problems make conflict analysis a major challenge in practice. Product configuration is one of the most important practical areas of artificial intelligence. Yet, comparatively little literature exists that addresses its application in practice. Answer Set Programming (ASP) is the right tool due to its declarative abstraction of the problem description from the solution path. Thus, we first developed a general and extensible framework for modeling product configuration in ASP. We then showed how both the explanation of conflicts and their resolution can be solved in under ten lines of declarative ASP syntax. Finally, our empirical evaluation showed that the technique is well suited for the high performance demands of real-world applications. A major scientific challenge that remains open is communicating the identified conflicts to non-expert users in natural language. [19] C. Desrosiers, P. Galinier, A. Hertz, S. Paroz, Using heuristics to find minimal unsatisfiable subformulas in satisfiability problems, J. Comb. Optim. 18 (2009) 124–150. URL: https: //doi.org/10.1007/s10878-008-9142-4. doi:10.1007/s10878-008-9142-4. [20] J. P. M. Silva, Minimal unsatisfiability: Models, algorithms and applications (invited paper), in: 40th IEEE International Symposium on Multiple-Valued Logic, ISMVL 2010, Barcelona, Spain, 26-28 May 2010, IEEE Computer Society, 2010, pp. 9–14. URL: https: //doi.org/10.1109/ISMVL.2010.11. doi:10.1109/ISMVL.2010.11. [21] A. Nadel, Boosting minimal unsatisfiable core extraction, in: R. Bloem, N. Sharygina (Eds.), Proceedings of 10th International Conference on Formal Methods in Computer-Aided Design, FMCAD 2010, Lugano, Switzerland, October 20-23, IEEE, 2010, pp. 221–229. URL: https://ieeexplore.ieee.org/document/5770953/. [22] V. Ryvchin, O. Strichman, Faster extraction of high-level minimal unsatisfiable cores, in: K. A. Sakallah, L. Simon (Eds.), Theory and Applications of Satisfiability Testing - SAT 2011 - 14th International Conference, SAT 2011, Ann Arbor, MI, USA, June 19-22, 2011. Proceedings, volume 6695 of Lecture Notes in Computer Science, Springer, 2011, pp. 174–187. URL: https://doi.org/10.1007/978-3-642-21581-0_15. doi:10.1007/978-3-642-21581-0\ _15. [23] A. Belov, J. Marques-Silva, Accelerating MUS extraction with recursive model rotation, in: P. Bjesse, A. Slobodová (Eds.), International Conference on Formal Methods in ComputerAided Design, FMCAD ’11, Austin, TX, USA, October 30 - November 02, 2011, FMCAD Inc., 2011, pp. 37–40. URL: http://dl.acm.org/citation.cfm?id=2157663. [24] M. H. Lifiton, K. A. Sakallah, Algorithms for computing minimal unsatisfiable subsets of constraints, J. Autom. Reason. 40 (2008) 1–33. URL: https://doi.org/10.1007/ s10817-007-9084-z. doi:10.1007/s10817-007-9084-z. [25] S. D. Gupta, B. Genc, B. O’Sullivan, Explanation in constraint satisfaction: A survey, in: Z. Zhou (Ed.), Proceedings of the Thirtieth International Joint Conference on Artificial Intelligence, IJCAI 2021, Virtual Event / Montreal, Canada, 19-27 August 2021, ijcai.org, 2021, pp. 4400–4407. URL: https://doi.org/10.24963/ijcai.2021/601. doi:10.24963/ijcai. 2021/601. [26] M. Gebser, B. Kaufmann, T. Schaub, Conflict-driven answer set solving: From theory to practice, Artif. Intell. 187 (2012) 52–89. URL: https://doi.org/10.1016/j.artint.2012.04.001. doi:10.1016/j.artint.2012.04.001. [27] A. Felfernig, M. Schubert, C. Zehentner, An eficient diagnosis algorithm for inconsistent constraint sets, Artif. Intell. Eng. Des. Anal. Manuf. 26 (2012) 53–62. URL: https://doi.org/ 10.1017/S0890060411000011. doi:10.1017/S0890060411000011. [28] M. Gelfond, V. Lifschitz, Logic programs with classical negation, in: D. Warren, P. Szeredi (Eds.), Proceedings of the Seventh International Conference on Logic Programming (ICLP’90), MIT Press, 1990, pp. 579–597. [29] P. Simons, I. Niemelä, T. Soininen, Extending and implementing the stable model semantics,
Artificial Intelligence 138 (2002) 181–234. [30] M. Razzaq, R. Kaminski, J. Romero, T. Schaub, J. Bourdon, C. Guziolowski, Computing diverse boolean networks from phosphoproteomic time series data, in: M. Češka, D. Šafránek (Eds.), Computational Methods in Systems Biology, Springer International Publishing, Cham, 2018, pp. 59–74. [31] R. Kaminski, J. Romero, T. Schaub, P. Wanko, How to build your own asp-based system?!,
CoRR abs/2008.06692 (2020). URL: https://arxiv.org/abs/2008.06692. arXiv:2008.06692. [32] M. Gebser, R. Kaminski, B. Kaufmann, M. Ostrowski, T. Schaub, P. Wanko, Theory solving made easy with clingo 5, in: M. Carro, A. King, N. Saeedloei, M. D. Vos (Eds.), Technical Communications of the 32nd International Conference on Logic Programming, ICLP 2016 TCs, October 16-21, 2016, New York City, USA, volume 52 of OASIcs, Schloss Dagstuhl Leibniz-Zentrum für Informatik, 2016, pp. 2:1–2:15. URL: https://doi.org/10.4230/OASIcs.
ICLP.2016.2. doi:10.4230/OASIcs.ICLP.2016.2. [33] M. Banbara, B. Kaufmann, M. Ostrowski, T. Schaub, Clingcon: The next generation, Theory Pract. Log. Program. 17 (2017) 408–461. URL: https://doi.org/10.1017/S1471068417000138. doi:10.1017/S1471068417000138.