In this paper we present a methodology for introducing customizable metalogic features in logic-based knowledge representation and reasoning languages. The proposed approach is based on concepts of introspection and re ection previously introduced and discussed by various authors in relevant literature. This allows a knowledge engineer to specify enhanced reasoning engines by de ning properties and meta-properties of relations as expressible for instance in OWL. We employ meta-level axiom schemata based upon a naming (rei cation) device. We propose general principles for extending the semantics of \host" formalisms accordingly. Suitable pre-de ned libraries of properties can be made available, while user-de ned new schemata are also allowed. We make the speci c case of Answer Set Programming (ASP), where such features may be part of software engineering toolkits for this programming paradigm. We show how to extend the Answer Set Programming principles and practice to accommodate the proposed methodology, so as to perform meta-reasoning within the plain ASP semantics (where we mention and discuss approaches where signi cant extensions are required).
Meta-reasoning
Answer Set
ProgramThe OWL ontology language [
Such features have widely demonstrated their usefulness in the de nition and use of ontologies in the Semantic Web, and in our opinion they would nd useful application in many knowledge engineering and automated reasoning languages. In fact, ontologies are pervading many areas of knowledge and data representation and management, and a lot of e ort has been spent on the development of su ciently expressive languages for the representation and querying of ontologies.
In this paper we present a methodology for introducing OWL-like features
in logic-based knowledge engineering, representation and reasoning languages.
In fact, ontology languages such as OWL have been devised in the context of
the Semantic Web to help automated processes (\intelligent agents") to access
information in a uniform and principled way [
As a proof of concept we consider Answer Set Programming (ASP, cf. [
The possibility of improving knowledge engineering capabilities by means of
metaprogramming and metareasoning has been explored in the past [
The mechanisms that we propose allow programmers to de ne relations (also) in terms of their properties and meta-properties; this on the basis of metalevel de nitions that should be part of any program using them. Many such de nitions (namely, those concerning the most commonly-used properties) might be prede ned and imported by a program upon need, e.g. via libraries. However, the approach also allows programmers to de ne their own new (meta) properties. So, the average programmer does not de ne and does not need to see the de nition of properties of relations, but rather just uses prede ned ones though the skilled programmer may optionally de ne new properties.
So, a given knowledge representation language becomes in fact extensible,
where an extension nds an immediate semantic and computational counterpart.
We stay within the realm of knowledge representation languages based upon
computational logic and logic programming [
The paper is organized as follows. We rst shortly summarize the basic principles of the OWL language in Section 2, and we recall the concept of rei cation (naming) of rst-order terms and atoms (Section 3). Then, we present our approach in Sections 4-5. Later, after shortly recalling ASP (Section 6), in Section 7 we show (also by exploiting signi cant examples) how the approach can be customized to the case of ASP. Finally, in Section 8 we discuss related work on meta-reasoning in ASP and draw conclusions. 2
OWL is a language for the de nition of ontologies (the reader may refer to www.w3.org/TR/2012/REC-owl2-primer for an introduction). The term ontology has a complex history in Philosophy, and recently in Computer Science. In Knowledge Representation, an ontology is a set of formal statements aimed to describe some part of the world (often referred to as the \domain of interest" or the \subject matter" of the ontology). Precise descriptions satisfy several purposes, among which: they prevent misunderstandings in human communication and they ensure a better software behavior, especially when di erent software modules interact.
In order to precisely describe a domain of interest, the OWL language is based upon a vocabulary. The meanings of terms is established by stating how each term is interrelated to the other terms (and similarly for classes, properties, and individuals). A terminology, providing a vocabulary together with such interrelation information constitutes an essential part of an OWL ontology. Besides this \terminological" knowledge, usually called TBOX, an ontology might also contain so called \assertional knowledge" (ABOX) that introduces concrete objects of the considered domain. The TBOX part is the analogous of the set of rules of a Prolog program, while the ABOX is the analogous of the set of facts.
OWL 2 is not a programming language, rather it provides a declarative way to describe knowledge in a logical way. For the decidable fragments of OWL, appropriate tools (so-called reasoners ) can then be used to infer further information from a given TBOX+ABOX description. How these inferences are realized algorithmically depends on the speci c implementations and on the fragments of OWL considered. Still, the correct answer to any of such question is predetermined by the OWL formal semantics.
In OWL it is possible to de ne classes of objects/individuals, membership to classes, class inclusion, equivalence and disjointness, class hierarchies. Concerning object properties, they correspond to binary predicates, i.e., to relations, and are expressed concerning speci c objects which are related by each property. It is also possible to express negative assertions, concerning individuals not enjoying some property. It is possible to specify hierarchies of properties (e.g., to state that some properties are sub-properties of other ones) and to de ne domain and range of each property. Among the \Advanced Use of Properties", one can state that certain properties are re exive or irre exive, symmetric or asymmetric, transitive, equivalent to some other properties, or disjoint from them. It can be stated that a property is functional, or that its inverse is functional. 3
A rei cation mechanism, also known as \naming relation", is a method for representing within a rst-order language expressions of the language itself, without resorting to higher-order features. Naming relations can be introduced in several manners. For a discussion of di erent possibilities, with their advantages and disadvantages, see, e.g., [20{23]. However, all of them are based upon introducing distinguished constants, function symbols (if available) and predicates, devised to construct names. For instance, given atom p(a; b; c) a name might be atom(pred (p0); args([a0; b0; c0]) where p0 and a0; b0; c0 are new constants intended as names for the syntactic elements p and a; b; c and notice that: p is a predicate symbol (which is not a rst-class object in rst-order settings), atom is a distinguished predicate symbol, args a distinguished function symbol and [: : :] is a list.
More formally, let us consider a standard rst-order language L including sets of predicate, constant and (possibly) function symbols, and a (possibly denumerable) set of symbols of variables. As usual, well-formed formulas have atoms as their basic constituents, where an atom is built via the application of a predicate to a number n (according to the predicate arity) of terms. The latter can be variables, constants, or compound terms built by using function symbols (if available). We augment L with new symbols, namely a new constant (say of the form p0) for each predicate symbol p, a new constant (say f 0) for each function symbol f , a new constant (say c0) for each constant symbol c, and a denumerable set of meta-variables, that we assume to have the form X0 so as to distinguish them syntactically from \plain" variables X. The new constants are intended to act as names, where we will say that, syntactically, p0 denotes p, f 0 denotes f and c0 denotes c, respectively. The new variables can be instantiated to meta-level formulas, i.e., to terms involving names, where we assume that plain variables can be instantiated only to terms not involving names. We assume an underlying mechanism managing the naming relation (however de ned), so we can indicate the name of, e.g., atom p(a; b; c) as p0(a0; b0; c0) and the name of a generic atom A as "A. 4
In this paper we mainly consider rule-based languages, where rules are typically represented in the form Head Body where indicates implication; other notations for this connective can alternatively be employed. In Prolog-like languages, is indicated as : , and Body is intended as a conjunction of literals (atoms or negated atoms) where ^ is conventionally indicated by a comma.
We will represent properties of relations in OWL style by means of metalevel rules. To de ne such rules, we assume to augment the language L at hand not only with names, but with the introduction of two distinguished predicates, solve and solve not . An atom A is a base atom if it does not involve names and its predicate is neither solve nor solve not . Distinguished predicates will allow us to respectively extend/restrict the meaning of the other predicates in a declarative way. In fact, solve and solve not take as arguments (names of) atoms (involving any predicate excluding themselves), and thus they are able to express sentences about relations. Names of atoms, in particular, are allowed only as arguments of solve and solve not . Also, solve and solve not can occur in the body of a metarule only if the predicate of its head is in turn either solve or solve not .
So, metalevel rules in general allow arguments of predicates to be names of predicates, function symbols and constants. A particular kind of metarules, that we call metaevaluation rules, have distinguished predicates solve and solve not in their head, and possibly also in their body, taking as argument names of atoms.
Below is a simple example of the use of solve to specify which properties a re exive predicate meets. Namely that p(a; a) can be derived for any element a belonging to the predicate domain; here, this is elicited from a occurring in the extensional de nition of p. The rst rule is a metaevaluation rule, featuring predicate solve in its head, taking as argument the name of an atom; the latter two rules are `simple' metalevel rules not involving either solve or solve not , and taking as arguments metalevel constants.
solve(P 0(X0; X0)) : re exive(P 0); in domain(P 0; X 0): in domain(P 0; X 0) : solve(P 0(X 0; Y 0)): in domain(P 0; X 0) : solve(P 0(Y 0; X 0)):
Our objective is to make it automatic to derive p(a; a) whenever a program includes this de nition, a fact re exive(p0) occurs in the program, and a is in the domain of p. Vice versa, we can de ne:
solve not (P 0(X0; X0)) : irre exive(P 0): with the aim to prevent the derivation of p(a; a) for any predicate p which have been declared to be irre exive (i.e., for which a fact irre exive(p0) occurs in the program).
Following [
We start with the following restriction on sets of atoms that should be
considered for the application of SEM . First, as customary, we only consider sets of
atoms I composed of atoms occurring in the ground version of . The ground
version of program is obtained by substituting in all possible ways variables
occurring in by constants also occurring in . In our case, metavariables
occurring in an atom must be substituted by metaconstants, with the
following obvious restrictions: a metavariable occurring in the predicate position must
be substituted by a metaconstant denoting a predicate; a metavariable
occurring in the function position must be substituted by a metaconstant denoting a
function; a metavariable occurring in the position corresponding to a constant
must be substituted by a metaconstant denoting a constant. According to
wellestablished terminology [
De nition 1 Let be a program. I B is a potentially acceptable set of atoms i for every base atom A which belongs to I, solve("A) also belongs to I.
We restrict SEM to determine acceptable sets of atoms only, modulo bijection: i.e., SEM can be allowed to produce sets of atoms which are in one-to-one correspondence with acceptable sets of atoms. In this way, we obtain the implementation of properties of relations that have been de ned via solve and solve not rules without modi cations to SEM for any formalism at hand. For clarity however, it is convenient to lter away solve and solve not atoms from acceptable sets. Thus, given a program and an acceptable set of atoms I for , the Base version IB of I is obtained by omitting from I all atoms of the form solve("A) and solve not ("A).
Procedural semantics and the speci c naming relation that one intends to use remain to be de ned. In fact, it is easy to see that the above-introduced semantics is independent of the naming mechanism. For approaches based upon (variants of) Resolution (like, e.g., Prolog) one can extend the procedure so as to be allowed to use rules with conclusion solve("A) to resolve a goal A and, vice versa, rules with conclusion A to resolve solve("A); if a goal G succeeds in this way with computed answer , then solve not ("G ) should be attempted: if it succeeds, then G should be forced to fail; otherwise, success of G can be con rmed. 5
In the previous section we have shown the use of metalevel de nitions involving solve and solve not to de ne what it means of a predicate to be re exive or, vice versa, irre exive. These metalevel de nitions are declarative yet executable, in that they suitably enlarge or restrict the involved predicates' extension. In this section we show the metalevel representation of other properties of relations that can be expressed in OWL. We concentrate in particular on properties which are relevant and widely used. The objective is to convince the reader that most such properties can be represented in our approach without resorting to the powerful though complex Description Logics.
Symmetry can be simply de ned as follows: solve(P 0(X0; Y 0)) : symmetric(P 0); solve(P 0(Y 0; X0)): symmetric(friend 0):
This rule speci es in fact the meaning of symmetry for any predicate, stating (via the predicate solve applied over a generic atom name) that p(X; Y ) can be derived if p(Y; X) holds; notice that in this rule predicate solve occurs not only in the head but also in the body of the rule. The fact symmetric(friend 0) speci es that predicate friend is symmetric, via its name.
So, a programmer/knowledge designer behaves very much like in OWL, save that properties of relations must be speci ed on the names of the predicates. Notice that di erent metaevaluation rules (with their auxiliary metalevel rules) can be de ned and expressed in a modular way, and they naturally interact and compose with each other.
Below we consider transitivity, that can be simply expressed in the following way: solve(P 0(X0; Y 0)) : transitive(P 0); solve(P 0(X0; Z0)); solve(P 0(Z0; Y 0)): This rule speci es the meaning of transitivity for any predicate, where a fact of the form transitive(P 0) declares that the predicate p0 is transitive. The de nition actually allows new facts to be derived. For example, if we have the following facts: transitive(same age0): same age(ann; alice): same age(alice; chris): via the previous rule we can derive same age(ann; chris). A possible variation is the transitive closure.
Another very useful feature, that increases exibility to a great extent, is equivalence between properties, obtained by the following de nition.
solve(P 0(X0; Y 0)) : equivalent (P 0; R0); solve(R0(X0; Y 0)):
This rule de nes two relations as equivalent if they have the same extension. For example, stating that predicate friend is equivalent to predicate amico (the latter is the translation into Italian of the former): equivalent (friend 0; amico0): friend (ann; alice): symmetric(equivalent 0): we can easily see that it becomes possible to derive amico(ann; alice). The metameta statement symmetric(equivalent 0) allows the translation to be applied in both ways. The concept of equivalence can be customized via other meta-rules.
Focusing the attention on the concept of inheritance, we may have the following: solve(P 0(X0; Y 0)) : hereditary (P 0; R0);
solve(R0(X0; Z0)); solve(P 0(Z0; Y 0)): meaning that property P 0 is hereditary with respect to a relation R0 if whenever an element of the domain of R0 has property P 0 then also all the other elements have the same property. For example: hereditary (polygon0; kind of 0): polygon(quadrilateral ; four ): kind of (square; quadrilateral ): Where polygon(quadrilateral ; four ) indicates that a quadrilateral is a kind of polygon that has the property of having four sides; instead, kind of (square; quadrilateral ) indicates that a square is a kind of quadrilateral. Thanks to the hereditary rule we can derive polygon(square; four ). Other OWL properties, e.g., subclasses etc., can be represented in a similar way.
It is important to notice that in the present setting new properties of relations can be de ned upon need and immediately employed, in combination with already existing ones, and meta-meta properties can be also expressed.
Answer Set Programming (ASP), is a well-known successful logic programming
paradigm (cf. [
An answer set program (or simply \program") is a nite collection of rules of the form H L1; : : : ; Ln: where H is an atom, n 0 and each literal Li is either an atom Ai or its default negation not Ai. The left-hand side and the right-hand side of rules are called head and body, respectively. A rule can be rephrased as H A1; : : : ; Am; not Am+1; : : : ; not An: where A1; : : : ; Am can be called positive body and not Am+1; : : : ; not An can be called negative body. Analogously to Prolog, practical programming environments often o er : as a glyph for the symbol . A rule with empty body (n = 0) is called a unit rule, or fact (vs. non-unit rules). A rule with empty head, of the form L1; : : : ; Ln:, is a constraint. It states that the literals L1; : : : ; Ln cannot be simultaneously true. A rule head can be a disjunction and a \classical negation" is provided; for lack of space we do not consider here such improvements to the basic paradigm.
A program may have several answer sets or may have no answer set (while in many semantics for logic programming a program admits exactly one \model", however de ned). Whenever a program has no answer sets, we say that the program is inconsistent; so, checking for consistency means checking for the existence of answer sets. Answer sets of , if any exists, are consistently supported minimal classical models of the program (interpreted in the obvious way as a rst-order theory).
In practice, answer sets can be found via inference engines called ASP solvers
[
The ASP programming methodology can be called GCO, for \Guess & Check & Optimize", where: (i) Guess implies generating potential solutions via rules and cycles (ii) Check implies selecting admissible ones by de ning suitable constraints; (iii) Optimize implies specifying preference criteria by exploiting weak constraints, indicated by connective : , that select among the admissible solutions those that satisfy such constraints at best.
ASP has been equipped in time with several additional features, representable via non-trivial ASP subprograms, and implemented directly in ASP solvers. One of these is the so-called Cardinality Constraints of the form (that we show for simplicity for the case of binary predicates, though it can be extended to predicates of any arity):
nfp(X; Y ) : d(X)gm : q(Y ) meaning that for every (constant value of) Y for which q(Y ) holds, every answer set must include no less than n and no more than m (where n m) atoms of the form p(X; Y ) where d(X) holds (of the constant value assigned to X). Given the possible answer sets originating from the basic de nition, those that do not meet such a constraint are discarded. Below is an example of use, stating that every person takes residence in exactly one municipality:
Cardinality constraints can be seen as special cases of aggregates, which have the form
n op [L1 = w1; : : : ; Ln = wn] m where the Li's are literals, the wis are numerical weights, op is an operator (e.g. sum, average, min, max) to be applied to the weights of literals that are true in given set of atoms; in any answer set, the result of the application of the operator must stay within the bounds. For cardinality constraints, the weight of literals is implicitly set to 1 and the operator is implicitly set to sum. Cardinality constraints can reproduce some of the cardinality features of OWL; in particular they can represent the functional property of a predicate, basically (like in the above example) by enforcing the predicate to assume only one value by setting both n and m to 1. However, ASP has virtually no software engineering construct beyond such constraints; in particular other properties of relations should be speci ed, if needed, in an \ad hoc" manner, according to the skills of a programmer.
In the rest of the paper, we will discuss how to incorporate into ASP the mechanisms for de nition and use of properties of relations that we have outlined before. In this way, prede ned de nitions are available to every ASP user, while the skilled one can represent her/his favorite new properties. 7
In order to be able to represent knowledge in ASP more easily and in a more understandable and exible way, the methodology introduced in Sections 4-5 can be usefully employed. However, since ASP is not resolution-based, the methodology must be applied in a di erent way. In this section, we propose in particular, to compile a set S of metalevel and metaevaluation rules into a form that can be seamlessly added to a given ASP program , whose rules can also undergo some easy modi cations; we thus obtain an augmented program S where the requirements of De nitions 1 and 2 are satis ed in the answer sets of S , which means that properties of relations speci ed in S are properly applied. The procedure is de ned as follows.
De nition 3 Given ASP program and a set of metalevel and metaevaluation rules S, and assuming that the metalevel constants occurring in S refer to (are names of ) predicates and constants occurring in , we obtain a new ASP program S from and S via the following steps (transformation S ). (i) For every atom of the form solve (P 0(Args)) or solve(p0(Args)), where Args denotes the set of arguments according to the cardinality of the predicate(s) the atom refers to, such atoms must be transformed into the form solve (P 0; Args) or solve(p0; Args) respectively. The same is done for solve not , where we obtain solve not (P 0; Args) or solve not (p0; Args). (ii) All metavariables are substituted with plain variables, and all metaconstants which are names of constants with the corresponding constants. Metaconstants which are names of predicates are kept untouched. All metarules and solve rules thus obtained are added to S . (iii) For every predicate p di erent from solve and solve not occurring in such that p0 also occurs in , the following pair of rules is added to S : p(X1; : : : ; Xn) : solve(p0; X1; : : : ; Xn);
not solve not (p0; X1; : : : ; Xn): (1) solve(p0; X1; : : : ; Xn) : p(X1; : : : ; Xn);
not solve not (p0; X1; : : : ; Xn): (2) where X1; : : : ; Xn are variables, n being the arity of predicate p. (iv) All facts (unit rules) of are added to S . For every non-unit rule in of the form
p(X1; : : : ; Xn) : Body : the rule is replaced in
S by the modi ed version: p(X1; : : : ; Xn) : Body ; not solve not (p0; X1; : : : ; Xn): Remark 1. The above transformation may need to add auxiliary predicates to ensure safety of rules, which is a technical condition required by ASP solvers in order to make the grounding of programs easier. This aspect presents no conceptual or practical problems and so, for the sake of simplicity, is not treated here.
We are able to prove the following:
S .
Proof (sketch): All rules in S occur in S , though in a format suitably modi ed so as to be compatible with ASP syntax and semantics. Apart from the modi ed notation, the addition of rules (1) guarantees the satisfaction, in every answer set, of the condition speci ed in De nition 1; the addition of rules (2) and of the additional condition solve not (p0; X1; : : : ; Xn) in all the other rules enforce the satisfaction, in every answer set, of the conditions speci ed in De nition 2.
S correspond to acceptable sets of atoms for
For the sake of clarity let us apply the above de nition to the previous example (also considering symmetry). To summarize, the set S is the following: solve(P 0(X0; X0)) : re exive(P 0); in domain(P 0; X 0): in domain(P 0; X 0) : solve(P 0(X 0; Y 0)): in domain(P 0; X 0) : solve(P 0(Y 0; X 0)): solve(P 0(X0; Y 0)) : symmetric(P 0); solve(P 0(Y 0; X0)): solve not (P 0(X0; X0)) : irre exive(P 0): re exive(same age0): irre exive(friend 0): symmetric(friend 0): Program
is simply the following: friend (george; ann): same age(ann; alice): From steps (i) and (ii) we obtain the following S0: solve(P; X; X) : re exive(P ); in domain(P ; X ): in domain(P ; X ) : solve(P ; X ; Y ): in domain(P ; X ) : solve(P ; Y ; X ): solve(P; X; Y ) : symmetric(P ); solve(P; Y; X): solve not (P; X; X) : irre exive(P ): re exive(same age0): irre exive(friend 0): symmetric(friend 0): Finally, we obtain S00 by adding the following rules to S0: same age(X ; Y ) : solve(same age0; X ; Y );
not solve not (same age0; X ; Y ): solve(same age0; X ; Y ) : same age(X ; Y );
not solve not (same age0; X ; Y ): friend (X ; Y ) : solve(friend 0; X ; Y );
not solve not (friend 0; X ; Y ): solve(friend 0; X ; Y ) : friend (X ; Y );
not solve not (friend 0; X ; Y ):
S is obtained by adding the rules in S00 to the given program , that in this case does not need modi cations, as it is composed of facts only. It can be veri ed, by running S via any ASP solver, that its answer sets bring the desired results (to perform experiments, metaconstants of the form p0 must be given a syntax compatible with ASP solver, for instance p1). The resulting (in this case unique) answer set is: fin domain(same age0; alice); in domain(friend 0; ann); in domain(same age0; ann); in domain(friend 0; george); symmetric(friend 0); irre exive(friend 0); re exive(same age0); solve(friend 0; george; ann); solve(same age0; ann; alice); solve(friend 0; ann; george); solve(same age0; ann; ann); solve(same age0; alice; alice); same age(ann; alice); same age(alice; alice); same age(ann; ann); friend (george; ann); friend (ann; george)g
Let us notice explicitly that the above formulation is applicable to every program , not just to programs composed of facts only, but to any program, even including cycles, and thus featuring several answer sets. For example, if we add to the above sample program the rules and facts: friend (X ; Y ) : nice(Y ); not enemy (X ; Y ): enemy (X ; Y ) : not friend (X ; Y ): nice(alice): irre exive(enemy 0):
The resulting program, as it is easy to verify, has several answer sets, where george, ann and alice are either mutual enemies or friends of alice, the only one declared to be nice; however, due to the stated irre exivity of predicate enemy (in addition of what already done for friend ) none of them three is either friend or enemy of her/himself.
We introduce a simpli ed version for the answer sets of S :
tion rules (meta-de nitions) S and the program S obtained from the former according to De nition 3, the Base version IB of an answer set I is obtained by omitting from I all atoms of the form solve(p0; Args) or solve not (p0; Args).
As for the modality of use of the approach, a user should write program , and declare the desired properties of relations to exploit (in the previous example, facts re exive(same age0), irre exive(friend 0), and symmetric(friend 0)) that by abuse of notation might be expressed directly on predicate names, with a pre-processor to be responsible of re-arranging the notation. A smart programmer/knowledge engineer might enrich the prede ned set S by writing new metalevel and metaevaluation rules, in the user-friendly form illustrated in previous sections, where S would then be generated by a pre-processor. Remark 2. Transformation S over program and set S of meta-de nitions adds two new rules for each predicate p occurring in such that p0 occurs in S. This would at worst multiply by three the size of when computing S00, and consequently also the size of the corresponding grounded program. This is however a pessimistic esteem, because an \ad hoc" de nition of properties such as symmetry, transitivity, etc. for speci c predicates would in any case imply adding at least one additional rule per property per predicate. Thus, there is indeed an increase in size w.r.t. given program, but it is not dramatic and can be considered as a reasonable drawback in exchange for the extra expressiveness. Complexity remains the same, so there is no additional computational burden due to the approach. 8
It is worth considering if the metaevaluation part S of given program, or more
precisely the ASP transposition S0 obtained according to De nition 3, might
be encapsulated within either a template [
The HEX framework [
Moreover, in all the above-mentioned frameworks it would be required to know in advance if some properties can be applicable to a predicate, so as to invoke the relative module(s) or to write the related HEX rule. Instead, if S0 is imported as a library and an associated pre-processor generates S00, metalevel properties smoothly enlarge/restrict the extension of each predicate to which they are applicable. Di erent properties are combined automatically with no e ort required to the programmer.
In conclusion, we have introduced a methodology based on naming and metareasoning for enriching logic-based formalisms with the possibility of expressing and using metalevel properties of relations similarly to what done in the OWL ontology language. Computationally, the methodology has the advantage of not requiring higher-order features. From the knowledge representation point of view, it allows the introduction of both prede ned and user-de ned properties, so it can increase the usability and exibility of virtually any knowledge representation and reasoning architecture at very little cost for implementation, and little burden for knowledge engineers. We have shown that the methodology is usable in both resolution-based frameworks but also in formalisms such as ASP which are based on a very di erent computational engine.
Related work exists about ontologies and ASP. [
C (X ) : subClassOf (D ; C ); D (X ):
Although we are not able to query external ontologies (so far, as we might adopt
for instance the method of [