ASP-Core-2 Input Language Format

Standardization of solver input languages has been a main driver for the growth of several areas within knowledge representation and reasoning, fostering the exploitation in actual applications. In this document we present the ASP-Core-2 standard input language for Answer Set Programming, which has been adopted in ASP Competition events since 2013.


page 1

page 2

page 3

page 4


Relating Two Dialects of Answer Set Programming

The input language of the answer set solver clingo is based on the defin...

Controlled Natural Language Processing as Answer Set Programming: an Experiment

Most controlled natural languages (CNLs) are processed with the help of ...

ROSoClingo: A ROS package for ASP-based robot control

Knowledge representation and reasoning capacities are vital to cognitive...

Almost Sure Productivity

We define Almost Sure Productivity (ASP), a probabilistic generalization...

plingo: A system for probabilistic reasoning in clingo based on lpmln

We present plingo, an extension of the ASP system clingo with various pr...

The Design of the Fifth Answer Set Programming Competition

Answer Set Programming (ASP) is a well-established paradigm of declarati...

The third open Answer Set Programming competition

Answer Set Programming (ASP) is a well-established paradigm of declarati...

Code Repositories

1 Introduction

The process of standardizing the input languages of solvers for knowledge representation and reasoning research areas has been of utmost importance for the growth of the related research communities: this has been the case for, e.g., the CNF-DIMACS format for SAT, then extended to describe input formats for Max-SAT and QBF problems, the OPB format for pseudo-Boolean problems, somehow at the intersection between the CNF-DIMACS format and the LP format for Integer Linear Programming, the XCSP3 format for CP solving, SMT-LIB format for SMT solving, and the STRIPS/PDDL language for automatic planning. The availability of such common input languages have led to the development of efficient solvers in different KR communities, through a series of solver competitions that have pushed the adoption of these standards. The availability of efficient solvers, together with a presence of a common interface language, has helped the exploitation of these methodologies in applications.

The same has happened for Answer Set Programming (ASP) [5]

, a well-known approach to knowledge representation and reasoning with roots in the areas of logic programming and non-monotonic reasoning

[22], through the development of the ASP-Core language [8]. The first ASP-Core version was a rule-based language whose syntax stems from plain Datalog and Prolog, and was a conservative extension to the non-ground case of the Core language adopted in the First ASP Competition held in 2002 during the Dagstuhl Seminar “Nonmonotonic Reasoning, Answer Set Programming and Constraints”111 It featured a restricted set of constructs, i.e. disjunction in the rule heads, both strong and negation-as-failure negation in rule bodies, as well as non-ground rules.

In this document we present the latest evolution of ASP-Core, namely ASP-Core-2, which currently constitutes the standard input language of ASP solvers adopted in the ASP Competition series since 2013 [9, 7, 20, 19]. ASP-Core-2 substantially extends its predecessor by incorporating many language extensions that became mature and widely adopted over the years in the ASP community, such as aggregates, weak constraints, and function symbols. The ASP competition series pushed its adoption, and significantly contributed both to the availability of efficient solvers for ASP [29, 18] and to the exploitation of the ASP methodology in academic and in industrial applications [12, 28, 21]. In the following, we first present syntax and semantics for the basic building blocks of the language, and then introduce more expressive constructs such as choice rules and aggregates, which help with obtaining compact problem formulations. Eventually, we present syntactic restrictions for the use of ASP-Core-2 in practice.

2 ASP-Core-2 Language Syntax

For the sake of readability, the language specification is herein given in the traditional mathematical notation. A lexical matching table from the following notation to the actual raw input format is provided in Section 6.


Terms are either constants, variables, arithmetic terms or functional terms. Constants can be either symbolic constants (strings starting with some lowercase letter), string constants (quoted strings) or integers. Variables are denoted by strings starting with some uppercase letter. An arithmetic term has form or for terms and with ; parentheses can optionally be omitted in which case standard operator precedences apply. Given a functor  (the function name) and terms , the expression is a functional term if , whereas is a synonym for the symbolic constant .

Atoms and Naf-Literals.

A predicate atom has form , where is a predicate name, are terms and is the arity of the predicate atom; a predicate atom of arity is likewise represented by its predicate name  without parentheses. Given a predicate atom , and are classical atoms. A built-in atom has form for terms and with . Built-in atoms  as well as the expressions and for a classical atom  are naf-literals.

Aggregate Literals.

An aggregate element has form

where are terms and are naf-literals for and .

An aggregate atom has form

where is an aggregate function name, is an aggregate relation, is a term and is a (possibly infinite) collection of aggregate elements, which are syntactically separated by “;”. Given an aggregate atom , the expressions and are aggregate literals. In the following, we write atom (resp., literal) without further qualification to refer to some classical, built-in or aggregate atom (resp., naf- or aggregate literal).

We here allow for infinite collections of aggregate elements because the semantics in Section 3 is based on ground instantiation, which may map some non-ground aggregate element to infinitely many ground instances. The semantics of Abstract Gringo [16] handles such cases by means of infinitary propositional formulas, while the Abstract Gringo language avoids infinite collections of aggregate elements in the input. As shown in [25], the semantics by ground instantiation or infinitary propositional formulas, respectively, are equivalent on the common subset of Abstract Gringo and ASP-Core-2. Moreover, we note that the restrictions to ASP-Core-2 programs claimed in Section 5 require the existence of a finite equivalent ground instantiation for each input, so that infinite collections of aggregate elements do not show up in practice.


A rule has form

where are classical atoms and are literals for and . When , the rule is called a fact. When , the rule is referred to as a constraint.

Weak Constraints.

A weak constraint has form

where are terms and are literals for and ; and are terms standing for a weight and a level. Writing the part “” can optionally be omitted if ; that is, a weak constraint has level  unless specified otherwise.


A query has form , where is a classical atom.


An ASP-Core-2 program is a set of rules and weak constraints, possibly accompanied by a (single) query.222Unions of conjunctive queries (and more) can be expressed by including appropriate rules in a program. A program (rule, weak constraint, query, literal, aggregate element, etc.) is ground if it contains no variables.

3 Semantics

We herein give the full model-theoretic semantics of ASP-Core-2. As for non-ground programs, the semantics extends the traditional notion of Herbrand interpretation, taking care of the fact that all integers are part of the Herbrand universe. The semantics of propositional programs is based on [22], extended to aggregates according to [13, 14]. Choice atoms [36] are treated in terms of the reduction given in Section 4.

We restrict the given semantics to programs containing non-recursive aggregates (see Section 5 for this and further restrictions to the family of admissible programs), for which the general semantics presented herein is in substantial agreement with a variety of proposals for adding aggregates to ASP [26, 37, 30, 35, 11, 24, 36, 10, 33, 31, 15, 32].

Herbrand Interpretation.

Given a program , the Herbrand universe of , denoted by , consists of all integers and (ground) terms constructible from constants and functors appearing in . The Herbrand base of , denoted by , is the set of all (ground) classical atoms that can be built by combining predicate names appearing in  with terms from as arguments. A (Herbrand) interpretation for  is a subset of .

Ground Instantiation.

A substitution is a mapping from a set  of variables to the Herbrand universe  of a given program . For some object  (rule, weak constraint, query, literal, aggregate element, etc.), we denote by the object obtained by replacing each occurrence of a variable  by  in .

A variable is global in a rule, weak constraint or query  if it appears outside of aggregate elements in . A substitution from the set of global variables in  is a global substitution for ; a substitution from the set of variables in an aggregate element  is a (local) substitution for . A global substitution  for  (or substitution  for ) is well-formed if the arithmetic evaluation, performed in the standard way, of any arithmetic subterm ( or with ) appearing outside of aggregate elements in  (or appearing in ) is well-defined.

Given a collection  of aggregate elements, the instantiation of  is the following set of aggregate elements:

A ground instance of a rule, weak constraint or query  is obtained in two steps: (1) a well-formed global substitution  for  is applied to ; (2) for every aggregate atom appearing in , is replaced by .

The arithmetic evaluation of a ground instance  of some rule, weak constraint or query is obtained by replacing any maximal arithmetic subterm appearing in  by its integer value, which is calculated in the standard way.333Note that the outcomes of arithmetic evaluation are well-defined relative to well-formed substitutions. The ground instantiation of a program , denoted by , is the set of arithmetically evaluated ground instances of rules and weak constraints in .

Term Ordering and Satisfaction of Naf-Literals.

A classical atom is true w.r.t. a interpretation  if . A Naf-Literal of the form , where is a classical atom, is true w.r.t. if , and it is false otherwise.

To determine whether a built-in atom (with ) holds, we rely on a total order on terms in defined as follows:

  • for integers and if ;

  • for any integer  and any symbolic constant ;

  • for symbolic constants and if is lexicographically smaller than or equal to ;

  • for any symbolic constant  and any string constant ;

  • for string constants and if is lexicographically smaller than or equal to ;

  • for any string constant  and any functional term ;

  • for functional terms and if

    • (the arity of  is smaller than the arity of ),

    • and (the functor of  is smaller than the one of , while arities coincide) or

    • , and, for any such that , there is some such that (the tuple of arguments of  is smaller than or equal to the arguments of ).

Then, is true w.r.t.  if for ; for ; and for ; and for ; and for ; or for . A positive naf-literal is true w.r.t.  if is a classical or built-in atom that is true w.r.t. ; otherwise, is false w.r.t. . A negative naf-literal is true (or false) w.r.t.  if is false (or true) w.r.t. .

Satisfaction of Aggregate Literals.

An aggregate function is a mapping from sets of tuples of terms to terms, or . The aggregate functions associated with aggregate function names introduced in Section 2 map a set  of tuples of terms to a term, or as follows:444The special cases in which , or for an infinite set is a non-zero integer are adopted from Abstract Gringo [16].

The terms selected by and for finite sets are determined relative to the total order  on terms in . In the special cases that or , we adopt the convention that and for every term . An expression is true (or false) for , an aggregate relation and a term  if is true (or false) according to the corresponding definition for built-in atoms, given previously, extended to the values and for .

An interpretation maps a collection  of aggregate elements to the following set of tuples of terms:

A positive aggregate literal is true (or false) w.r.t.  if is true (or false) w.r.t. ; is true (or false) w.r.t.  if is false (or true) w.r.t. .

Answer Sets.

Given a program  and a (consistent) interpretation , a rule in is satisfied w.r.t.  if some is true w.r.t.  when are true w.r.t. ; is a model of  if every rule in is satisfied w.r.t. . The reduct of w.r.t. , denoted by , consists of the rules in such that are true w.r.t. ; is an answer set of  if is a -minimal model of . In other words, an answer set  of  is a model of  such that no proper subset of  is a model of .

The semantics of is given by the collection of its answer sets, denoted by .

Optimal Answer Sets.

To select optimal members of , we map an interpretation  for  to a set of tuples as follows:

For any integer , let

denote the sum of integers  over tuples with in . Then, an answer set  is dominated by if there is some integer  such that and for all integers . An answer set  is optimal if there is no such that is dominated by . Note that  has some (and possibly more than one) optimal answer sets if .


Given a ground query of a program , is true if for all . Otherwise, is false. Note that, if , all queries are true. In presence of variables one is interested in substitutions that make the query true. Given the non-ground query of a program , let be the set of all substitutions for such that is true. The set constitutes the set of answers to . Note that, if , contains all possible substitutions for .

Note that query answering, according to the definitions above, corresponds to cautious (skeptical) reasoning as defined in, e.g., [1].

4 Syntactic Shortcuts

This section specifies additional constructs by reduction to the language introduced in Section 2.

Anonymous Variables.

An anonymous variable in a rule, weak constraint or query is denoted by “” (character underscore). Each occurrence of “” stands for a fresh variable in the respective context (i.e., different occurrences of anonymous variables represent distinct variables).

Choice Rules.

A choice element has form

where is a classical atom and are naf-literals for .

A choice atom has form

where is a collection of choice elements, which are syntactically separated by “;”, is an aggregate relation (see Section 2) and is a term. The part “” can optionally be omitted if is and .

A choice rule has form

where is a choice atom and are literals for .

Intuitively, a choice rule means that, if the body of the rule is true, an arbitrary subset of the classical atoms such that are true can be chosen as true in order to comply with the aggregate relation  between and . In the following, this intuition is captured by means of a proper mapping of choice rules to rules without choice atoms (in the head).

For any predicate atom , let and , where is an (arbitrary) predicate and function name that is uniquely associated with , and the first argument (which can be or ) indicates the “polarity” or , respectively.555It is assumed that fresh predicate and function names are outside of possible program signatures and cannot be referred to within user input.

Then, a choice rule stands for the rules

for each choice element in  along with the constraint

The first group of rules expresses that the classical atom  in a choice element can be chosen as true (or false) if and are true. This “generates” all subsets of the atoms in choice elements. On the other hand, the second rule, which is an integrity constraint, requires the condition to hold if are true.666In disjunctive heads of rules of the first form, an occurrence of denotes an (auxiliary) atom that is linked to the original atom . Given the relationship between and , the latter is reused as a term in the body of a rule of the second form. That is, we overload the notation by letting it stand both for an atom (in disjunctive heads) and a term (in aggregates).

For illustration, consider the choice rule

Using the fresh predicate and function name , the choice rule is mapped to three rules as follows:

Note that the three rules are satisfied w.r.t. an interpretation  such that and . In fact, when , , and are true, the choice of none or one of the atoms and complies with the aggregate relation to .

Aggregate Relations.

An aggregate or choice atom

may be written as

where ;  ;  ;  ;  ;  .

The left and right notation of aggregate relations may be combined in expressions as follows:

Such expressions are mapped to available constructs according to the following transformations:

stands for

stands for

stands for

stands for

stands for

5 Using ASP-Core-2 in Practice – Restrictions

To promote declarative programming as well as practical system implementation, ASP-Core-2 programs are supposed to comply with the restrictions listed in this section. This particularly applies to input programs starting from the System Track of the 4th Answer Set Programming Competition [9].


Any rule, weak constraint or query is required to be safe; to this end, for a set of variables and literals , we inductively (starting from an empty set of bound variables) define as bound by if occurs outside of arithmetic terms in some for such that is

  • (i) a classical atom,

  • (ii) a built-in atom or and any member of  occurring in  is bound by or

  • (iii) an aggregate atom and any member of  occurring in  is bound by .

The entire set of variables is bound by if each is bound by .

A rule, weak constraint or query  is safe if the set  of global variables in  is bound by (taking a query  to be of form ) and, for each aggregate element in  with occurring variable set , the set of local variables is bound by . For instance, the rule

is safe because all variables are bound by , while

is not safe because the expression does not respect condition (ii) above.


Pragmatically, ASP programs solving real problems have a finite number of answer sets of finite size. As an example, a program including or along with a fact like is not an admissible input in ASP Competitions. There are pragmatic conditions that can be checked to ensure that a program admits finitely many answer sets (e.g., [6]); in alternative, finiteness can be witnessed by providing a known maximum integer and maximum function nesting level per problem instance, which correctly limit the absolute values of integers as well as the depths of functional terms occurring as arguments in the atoms of answer sets. The last option is the one adopted in ASP competitions since 2011.


For the sake of an uncontroversial semantics, we require aggregates to be non-recursive. To make this precise, for any predicate atom , let and . We further define the directed predicate dependency graph for a program  by

  • the set  of vertices for all classical atoms  appearing in  and

  • the set  of edges and for all rules in , and classical atoms  appearing in .

The aggregates in  are non-recursive if, for any classical atom appearing within aggregate elements in a rule in , there is no path from to in for .

Predicate Arities.

The arity of atoms sharing some predicate name is not assumed to be fixed. However, system implementers are encouraged to issue proper warning messages if an input program includes classical atoms with the same predicate name but different arities.

Undefined Arithmetics.

The semantics of ASP-Core-2 requires that substitutions that lead to undefined arithmetic subterms (and are thus not well-formed) are excluded by ground instantiation as specified in Section 3. In practice, this condition is not easy to meet and implement for a number of technical reasons; thus, it might cause problems to existing implementations, or even give rise to unexpected behaviors.

In order to avoid such complications, we require that a program  shall be invariant under undefined arithmetics; that is, is supposed to be equivalent to any ground program obtainable from  by freely replacing arithmetic subterms with undefined outcomes by arbitrary terms from . Intuitively, rules have to be written in such a way that the semantics of a program does not change, no matter the handling of substitutions that are not well-formed.

For instance, the program

has the (single) answer set . This program, however, is not invariant under undefined arithmetics. Indeed, a vanilla grounder that skips arithmetic evaluation (in view of no rule with atoms of predicate  in the head) might produce the (simplified) ground rule , and this would result in the wrong answer set .

In contrast to the previous program,

is invariant under undefined arithmetics, since substitutions that are not well-formed cannot yield applicable ground rules. Hence, a vanilla grounder as considered above may skip the arithmetic evaluation of ground terms obtained from without risking wrong answer sets.

6 EBNF Grammar and Lexical Table

<program>            ::= [<statements>] [<query>]

<statements>         ::= [<statements>] <statement>
<query>              ::= <classical_literal> QUERY_MARK

<statement>          ::= CONS [<body>] DOT
                       | <head> [CONS [<body>]] DOT
                       | WCONS [<body>] DOT
                           SQUARE_OPEN <weight_at_level> SQUARE_CLOSE

<head>               ::= <disjunction> | <choice>
<body>               ::= [<body> COMMA]
                           (<naf_literal> | [NAF] <aggregate>)

<disjunction>        ::= [<disjunction> OR] <classical_literal>

<choice>             ::= [<term> <binop>]
                           CURLY_OPEN [<choice_elements>]
                           CURLY_CLOSE [<binop> <term>]
<choice_elements>    ::= [<choice_elements> SEMICOLON]
<choice_element>     ::= <classical_literal> [COLON [<naf_literals>]]

<aggregate>          ::= [<term> <binop>] <aggregate function>
                           CURLY_OPEN  [<aggregate_elements>]
                           CURLY_CLOSE [<binop> <term>]
<aggregate_elements> ::= [<aggregate_elements> SEMICOLON]
<aggregate_element>  ::= [<basic_terms>] [COLON [<naf_literals>]]
<aggregate_function> ::= AGGREGATE_COUNT
                       | AGGREGATE_MAX
                       | AGGREGATE_MIN
                       | AGGREGATE_SUM

<weight_at_level>    ::= <term> [AT <term>] [COMMA <terms>]

<naf_literals>       ::= [<naf_literals> COMMA] <naf_literal>
<naf_literal>        ::= [NAF] <classical_literal> | <builtin_atom>

<classical_literal>  ::= [MINUS] ID [PAREN_OPEN [<terms>] PAREN_CLOSE]
<builtin_atom>       ::= <term> <binop> <term>

<binop>              ::= EQUAL
                       | UNEQUAL
                       | LESS
                       | GREATER
                       | LESS_OR_EQ
                       | GREATER_OR_EQ

<terms>              ::= [<terms> COMMA] <term>
<term>               ::= ID [PAREN_OPEN [<terms>] PAREN_CLOSE]
                       | NUMBER
                       | STRING
                       | VARIABLE
                       | ANONYMOUS_VARIABLE
                       | PAREN_OPEN <term> PAREN_CLOSE
                       | MINUS <term>
                       | <term> <arithop> term>

<basic_terms>        ::= [<basic_terms> COMMA] <basic_term>
<basic_term>         ::= <ground_term> |
<ground_term>        ::= SYMBOLIC_CONSTANT |
                         STRING | [MINUS] NUMBER
<variable_term>      ::= VARIABLE |
<arithop>            ::= PLUS
                       | MINUS
                       | TIMES
                       | DIV
Token Name Mathematical Notation Lexical Format
used within this document (exemplified) (Flex Notation)
ID [a-z][A-Za-z0-9_]*
VARIABLE [A-Z][A-Za-z0-9_]*
STRING”, “Peter”, … \"([^\"]|\\\")*\"
NUMBER "0"|[1-9][0-9]*
DOT "."
OR "|"
NAF "not"
CONS ":-"
WCONS ":~"
PLUS "+"
MINUS or "-"
DIV "/"
AT "@"
UNEQUAL "<>"|"!="
LESS "<"
COMMENT % this is a comment "%"([^*\n][^\n]*)?\n
MULTI_LINE_COMMENT %* this is a comment *% "%*"([^*]|\*[^%])*"*%"
BLANK [ \t\n]+

Lexical values are given in Flex777 syntax. The COMMENT, MULTI_LINE_COMMENT and BLANK tokens can be freely interspersed amidst other tokens and have no syntactic or semantic meaning.

7 Conclusions

In this document we have presented the ASP-Core-2

standard language that defines syntax and semantics of a standard language to which ASP solvers have to adhere in order to enter the ASP Competitions series, since 2013. The standardization committee is still working on the evolution of the language in order to keep it aligned with the achievements of the ASP research community. Among the features that are currently under consideration we mention here a semantics for recursive aggregates, for which several proposals are at the moment in place, e.g.,

[34, 14, 2, 23, 3], and a standard for intermediate [17] and output [4, 27] formats for ASP solvers.


  • [1] S. Abiteboul, R. Hull, and V. Vianu (1995) Foundations of Databases. Addison-Wesley. Cited by: §3.
  • [2] M. Alviano, F. Calimeri, W. Faber, N. Leone, and S. Perri (2011) Unfounded sets and well-founded semantics of answer set programs with aggregates.

    Journal of Artificial Intelligence Research

    42, pp. 487–527.
    Cited by: §7.
  • [3] M. Alviano, W. Faber, and M. Gebser (2015) Rewriting recursive aggregates in answer set programming: back to monotonicity. Theory and Practice of Logic Programming 15 (4-5), pp. 559–573. Cited by: §7.
  • [4] M. Brain, W. Faber, M. Maratea, A. Polleres, T. Schaub, and R. Schindlauer (2007) What should an asp solver output? a multiple position paper. In Proc. of the First International SEA’07 Workshop, CEUR Workshop Proceedings, Vol. 281. Cited by: §7.
  • [5] G. Brewka, T. Eiter, and M. Truszczyński (2011) Answer set programming at a glance. Communications of the ACM 54 (12), pp. 92–103. Cited by: §1.
  • [6] F. Calimeri, S. Cozza, G. Ianni, and N. Leone (2011) Finitely recursive programs: decidability and bottom-up computation. AI Commun. 24 (4), pp. 311–334. Cited by: §5.
  • [7] F. Calimeri, M. Gebser, M. Maratea, and F. Ricca (2016) Design and results of the Fifth Answer Set Programming Competition. Artificial Intelligence 231, pp. 151–181. Cited by: §1.
  • [8] F. Calimeri, G. Ianni, F. Ricca, and T. U. della Calabria Organizing Committee (2011) Third ASP Competition, File and language formats. Note: Cited by: §1.
  • [9] F. Calimeri, G. Ianni, and F. Ricca (2014) The third open answer set programming competition. TPLP 14 (1), pp. 117–135. Cited by: §1, §5.
  • [10] T. Dell’Armi, W. Faber, G. Ielpa, N. Leone, and G. Pfeifer (2003-09) Aggregate Functions in DLV. In Proceedings ASP03 - Answer Set Programming: Advances in Theory and Implementation, M. de Vos and A. Provetti (Eds.), Messina, Italy, pp. 274–288. Note: Online at Cited by: §3.
  • [11] M. Denecker, N. Pelov, and M. Bruynooghe (2001) Ultimate Well-Founded and Stable Model Semantics for Logic Programs with Aggregates. In Proceedings of the 17th International Conference on Logic Programming, P. Codognet (Ed.), pp. 212–226. Cited by: §3.
  • [12] E. Erdem, M. Gelfond, and N. Leone (2016) Applications of answer set programming. AI Magazine 37 (3), pp. 53–68. Cited by: §1.
  • [13] W. Faber, N. Leone, and G. Pfeifer (2004-09) Recursive aggregates in disjunctive logic programs: semantics and complexity. In Proceedings of the 9th European Conference on Artificial Intelligence (JELIA 2004), J. J. Alferes and J. Leite (Eds.), Lecture Notes in AI (LNAI), Vol. 3229, pp. 200–212. Cited by: §3.
  • [14] W. Faber, N. Leone, and G. Pfeifer (2011) Semantics and complexity of recursive aggregates in answer set programming. Artificial Intelligence 175 (1), pp. 278–298. Note: Special Issue: John McCarthy’s Legacy External Links: Document Cited by: §3, §7.
  • [15] P. Ferraris (2005-09-5–8) Answer Sets for Propositional Theories. In Logic Programming and Nonmonotonic Reasoning — 8th International Conference, LPNMR’05, Diamante, Italy, September 2005, Proceedings, C. Baral, G. Greco, N. Leone, and G. Terracina (Eds.), Lecture Notes in Computer Science, Vol. 3662, pp. 119–131. External Links: ISBN 3-540-28538-5 Cited by: §3.
  • [16] M. Gebser, A. Harrison, R. Kaminski, V. Lifschitz, and T. Schaub (2015) Abstract Gringo. Theory and Practice of Logic Programming 15 (4-5), pp. 449–463. Cited by: §2, footnote 4.
  • [17] M. Gebser, R. Kaminski, B. Kaufmann, M. Ostrowski, T. Schaub, and P. Wanko (2016) Theory solving made easy with clingo 5. In Technical Communications of the 32nd International Conference on Logic Programming (ICLP 2016 TCs), M. Carro, A. King, N. Saeedloei, and M. D. Vos (Eds.), OASICS, Vol. 52, pp. 2:1–2:15. Cited by: §7.
  • [18] M. Gebser, N. Leone, M. Maratea, S. Perri, F. Ricca, and T. Schaub (2018) Evaluation techniques and systems for answer set programming: a survey. In Proceedings of the Twenty-Seventh International Joint Conference on Artificial Intelligence (IJCAI 2018), J. Lang (Ed.), pp. 5450–5456. Cited by: §1.
  • [19] M. Gebser, M. Maratea, and F. Ricca (2017) The design of the seventh answer set programming competition. In Proceedings of the 14th International Conference on Logic Programming and Nonmonotonic Reasoning (LPNMR 2017), M. Balduccini and T. Janhunen (Eds.), Lecture Notes in Computer Science, Vol. 10377, pp. 3–9. Cited by: §1.
  • [20] M. Gebser, M. Maratea, and F. Ricca (2017) The sixth answer set programming competition. Journal of Artificial Intelligence Research 60, pp. 41–95. Cited by: §1.
  • [21] M. Gebser, P. Obermeier, T. Schaub, M. Ratsch-Heitmann, and M. Runge (2018) Routing driverless transport vehicles in car assembly with answer set programming. TPLP 18 (3-4), pp. 520–534. Cited by: §1.
  • [22] M. Gelfond and V. Lifschitz (1991) Classical Negation in Logic Programs and Disjunctive Databases. New Generation Computing 9, pp. 365–385. Cited by: §1, §3.
  • [23] M. Gelfond and Y. Zhang (2014) Vicious circle principle and logic programs with aggregates. Theory and Practice of Logic Programming 14 (4-5), pp. 587–601. Cited by: §7.
  • [24] M. Gelfond (2002) Representing Knowledge in A-Prolog. In Computational Logic. Logic Programming and Beyond, A. C. Kakas and F. Sadri (Eds.), LNCS, Vol. 2408, pp. 413–451. Cited by: §3.
  • [25] A. Harrison and V. Lifschitz (2019) Relating two dialects of answer set programming. Theory and Practice of Logic Programming 19 (5-6), pp. 1006–1020. External Links: Link, Document Cited by: §2.
  • [26] D. B. Kemp and P. J. Stuckey (1991) Semantics of Logic Programs with Aggregates. In Proceedings of the International Symposium on Logic Programming (ISLP’91), V. A. Saraswat and K. Ueda (Eds.), pp. 387–401. External Links: ISBN 0-262-69147-7 Cited by: §3.
  • [27] T. Krennwallner (2013) ASP Competition, output format. Note: Cited by: §7.
  • [28] N. Leone and F. Ricca (2015) Answer set programming: A tour from the basics to advanced development tools and industrial applications. In Web Logic Rules - 11th International Summer School on Reasoning Web, Tutorial Lectures, W. Faber and A. Paschke (Eds.), Lecture Notes in Computer Science, Vol. 9203, pp. 308–326. Cited by: §1.
  • [29] Y. Lierler, M. Maratea, and F. Ricca (2016) Systems, engineering environments, and competitions. AI Magazine 37 (3), pp. 45–52. Cited by: §1.
  • [30] M. Osorio and B. Jayaraman (1999) Aggregation and Negation-As-Failure. New Generation Computing 17 (3), pp. 255–284. Cited by: §3.
  • [31] N. Pelov, M. Denecker, and M. Bruynooghe (2004) Partial stable models for logic programs with aggregates. In Proceedings of the 7th International Conference on Logic Programming and Non-Monotonic Reasoning (LPNMR-7), Lecture Notes in AI (LNAI), Vol. 2923, pp. 207–219. External Links: ISBN 3-540-20721-X Cited by: §3.
  • [32] N. Pelov, M. Denecker, and M. Bruynooghe (2007) Well-founded and Stable Semantics of Logic Programs with Aggregates. Theory and Practice of Logic Programming 7 (3), pp. 301–353. Cited by: §3.
  • [33] N. Pelov and M. Truszczyński (2004) Semantics of disjunctive programs with monotone aggregates - an operator-based approach. In Proceedings of the 10th International Workshop on Non-monotonic Reasoning (NMR 2004), Whistler, BC, Canada, pp. 327–334. External Links: ISBN 92-990021-0-X Cited by: §3.
  • [34] N. Pelov (2004-04) Semantics of Logic Programs with Aggregates. Ph.D. Thesis, Katholieke Universiteit Leuven, Leuven, Belgium. Cited by: §7.
  • [35] K. A. Ross and Y. Sagiv (1997-02) Monotonic Aggregation in Deductive Databases. Journal of Computer and System Sciences 54 (1), pp. 79–97. Cited by: §3.
  • [36] P. Simons, I. Niemelä, and T. Soininen (2002-06) Extending and Implementing the Stable Model Semantics. Artificial Intelligence 138, pp. 181–234. Cited by: §3, §3.
  • [37] A. Van Gelder (1992) The Well-Founded Semantics of Aggregation. In Proceedings of the Eleventh Symposium on Principles of Database Systems (PODS’92), pp. 127–138. Cited by: §3.