From: AAAI Technical Report SS-01-01. Compilation copyright © 2001, AAAI (www.aaai.org). All rights reserved.
Tabular Constraint-Satisfaction
Problems and Answer-Set Programming
Raphael A. Finkel, Victor Marek and Miroslaw Truszczyfiski Departmentof ComputerScience University of Kentucky Lexington KY40506-0046, USA email: raphael[marek[
[email protected]
Abstract Wearguethat databasequerylanguages canbe usedto specif’y constraintsatisfactionproblems. Wedescribeonesuch language here.It is basedontuplerelationalcalculusandits sentencesare usedto defineconstraints.Fora fragment of this language wedevelop a frontend,Constraint Lingo,to facilitate programming tasks. Finally,weshowthat programs ~ and in ConstraintLingocan be compiledinto DATALOG its versionsandprocessed byASPsolverssuchas smodels. Introduction In this preliminaryreport, wetreat the class of constraintsatisfaction problemsthat can be conveniently modeled by meansof query languages developed in the area of databases. Wediscuss one such languagehere basedon tuple relational calculus (Maier1983). Wedescribe an implementationof a restricted versionthat wecall Constraint Lingo. Weshowthat answer-set programmingformalisms such as smodels(Niemelfi&Simons1997;2000), des (East &Truszczydski 2000)anddlv (Eiter et al. 1998)can be used as a processingbackendfor ConstraintLingo.Weconclude witha brief discussionof related researchproblems. DATALOG-" is a restricted version of the formalismof logic programming with stable-modelsemanticsin that it disallows function symbolsfromthe language.It has been proposedas a querylanguage;the resu-iction is motivated by the requirementof finiteness of answersto database queries (Ullman1988). A database, say D, is represented in DATALOG" by a collection of groundatomsdefining extensionsof the corresponding predicates. Theseatomicfacts are referredto as the extensionaldatabaseandtheir predicate symbolsas extensional predicates. A DATALOG" program Qsuchthat extensionalpredicatesappearonly in the bodies of its rules is called a query.All non-extensional predicates occurringin a queryare called intensional. AqueryQon an extensionaldatabaseDis a specificationofintensionalpredicates appearingin Q. Theextensionof one(distinguished) intensional predicate serves as the answerto Q. This extension is defined throughsomechosensemanticsof logic programswith negation, for instance, stable-modelsemantics. Namely,ifM is a stable modelofQU D, and answer is the intensionalpredicateof interest, the answeris given by
ak): answer(al,...,ak) 65
While DATALOG-’ has received some attention in the database community,it has never becomea mainstream query language. General DATALOG" programs are not guaranteedto havea uniquestable model,so queriesare not guaranteedto fully specifythe answer,a highlyundesirable feature fromthe databaseperspective. Weargue in (Marek & Truszcz3rfiski 1999) that DATA.LOG-" is moreappropriately viewedas a formalismto specifyconstraint-satisfactionproblemsthan as a databasequery language. (A similar argumenthas been madeby Niemeli(Niemel~i1999).) Thatis, a queryQspecifies constraints on (unknown) intensional predicates. Theseconstraints also involvesomeknownpredicates definedby the extensional database D. Stable modelsof Q t9 Ddefine solutions -- possible instantiations of unknown predicates satisfyingthe constraints.For instance,the problem of existence of a Hamilton cycle can be cast in these terms (Marek &Truszczyfiski1999). Twoextensional(and fully defined) predicates vex andedgedescribe the graph. Anintensional (unknown) predicate hc describesthe edgesof the Hamilton cycle. All the constraints on hc (and someother auxiliary intensional predicates) are given in a DATALOG-" program (query). Multiple stable modelsdo not pose a problem ~ -- they simply determinedifferent such use of DATALOG ways to satisfy constraints. Werefer to DATALOG" and other logics with similar features as answer-setprogramming(ASP)formalisms. Solutionsto constraint-satisfaction problemsdefinedby DATALOG" programsare collections of tuples. It is often convenientto think aboutthese solutions as tables. Consequently,werefer to themas tabular. In this paperwestudy tabular consWaint-satisfaction problems(tCSPs).Weare interested both in modelingtabular CSPs(programming) and ~ lacks explicit in processing (solving) them. DATALOG meansto modelhigh-level constraints that rely on a tabular structure of solutionsandthat often canbe conveniently phrasedin standarddatabaseterminology.Examplesof such constraintsincludeequalities andinequalitiesof sets of tupies definedby logical expressions(or databasequeries). this paper, westudylanguagesto allowus specifysuchconstraints. In particular, weshowthat standarddatabasequery languagescan be usedto this end, althoughqueries mustbe interpreteddifferently fromwhenthey are usedfor querying databases.
Wefocus our discussion on one database query language, based on tuple relational calculus (Maier 1983). Weshow that its sentences can be viewedas constiaints on predicates (tables). Consequently,tuple relational calculus can serve as a language to define tabular CSPs. One can show that tuple relational calculus can be regarded as a fragment of DATALOG" (the details will be included in the full version of this paper). That is, every specification of a tabular CSP given in tuple relational calculus can be translated, in polynomial time in its size, into DATALOG". For a fragment of tuple relational calculus we define a high-level language, called Constraint Lingo, that simplifies the process of defining constrains. Constraint Lingois designed to provide the user with constructs explicitly supporting commonlyoccurring constraints and using a simple and straightforward syntax. Thus, Constraint Lingo can be viewed as a high-level front end for a fragment of a constraint-definition languagebased on tuple relational calculus. Constraint Lingois not only a specification languagefor constraints; its programs can be processed. Weshow how Constraint Lingo (more generally, tuple relational calculus) can be translated into DATALOG-’. Wehave implemented this translation; DATALOG" solvers such as smode/s (Niemela & Simons 1997; 2000) can be used as backend engines for processing Constraint Lingo programs and solving (some) tabular CSPs. Webriefly commenton our computational experience with Constraint Lingo. This is a preliminary report. Our next goal is to extend Constraint Lingo so that it can support modelingall constraints that can be stated in terms of tuple relational formulas. Tuple relational
calculus and the formalization of tCSP Wefirst showhowsometabular CSPscan be specified using a version of the familiar languageof tuple relational calculus (Maler 1983). In the terminologyof mathematicallogic, this languageis typed, that is, all objects havetypes. In view of the applications we have in mind(specification oftCSPs), we focus on a languagewherethere is one type called tuple. Other types are used to describe attributes. The set of attributes is denotedby .4. Eachattribute a in the set of attributes .,4 is a type withdomain D,. Weassume that D, is finite. Weassume domainclosure axioms (DCA)for each type. The formalization of those axiomsis given below. Weassumethat for each attribute a in .,4 we have an opelation x.a defined for terms of type tuple with values in the type a. Nowwe define terms. Each term has a type. Terms of type tuple are tuple variables. Termsof type a (wherea is an attribute) are expressions of the form x.a where x is variable of type tuple and constants b from D,. Wehave built-in relation symbols (Maier calls themcomparators), including = and #1, with other built-in relation ITvclmically,weshouldhaveseparaterelations of equalityand inequalityfor eachtype. 66
symbols allowed so long as values of those are tabled or predefmed. For instance, numeric attributes have < and
