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.READ FULL TEXT VIEW PDF
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) 
, a well-known approach to knowledge representation and reasoning with roots in the areas of logic programming and non-monotonic reasoning, through the development of the ASP-Core language . 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”111https://www.dagstuhl.de/en/program/calendar/semhp/?semnr=02381.. 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.
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 .
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.
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  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 , 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.
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.
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 , extended to aggregates according to [13, 14]. Choice atoms  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].
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 .
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 .
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. .
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 .
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. .
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 .
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., .
This section specifies additional constructs by reduction to the language introduced in Section 2.
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).
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 .
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:
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 .
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., ); 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 .
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.
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.
|Token Name||Mathematical Notation||Lexical Format|
|used within this document (exemplified)||(Flex Notation)|
|STRING||“http://bit.ly/cw6lDS”, “Peter”, …||\"([^\"]|\\\")*\"|
|COMMENT||% this is a comment||"%"([^*\n][^\n]*)?\n|
|MULTI_LINE_COMMENT||%* this is a comment *%||"%*"([^*]|\*[^%])*"*%"|
Lexical values are given in Flex777http://flex.sourceforge.net/ syntax. The COMMENT, MULTI_LINE_COMMENT and BLANK tokens can be freely interspersed amidst other tokens and have no syntactic or semantic meaning.
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  and output [4, 27] formats for ASP solvers.
Journal of Artificial Intelligence Research42, pp. 487–527. Cited by: §7.