Content uploaded by Boi Faltings
Author content
All content in this area was uploaded by Boi Faltings on Mar 14, 2014
Content may be subject to copyright.
Constraint Choice Language (CCL),
Language Specification v2.01
S. Willmott, B. Faltings, M. Calisti, S. Macho-Gonzalez,
O. Belakhdar and M. Torrens.
Technical report 99/320
Abstract
This document gives the specification of version 2.01 of the
Constraint Choice Language (CCL). CCL is designed as a
language to be used for agent communication which directly
supports the expression of choice and choice problems in the
content of agent messages. This version of CCL has been
adopted by FIPA as a standard FIPA-compliant content
language named FIPA-CCL.
LIA-DI-EPFL CCL Language Specification v2.01
Page 2
1 Introduction
This document gives the specification of version 2.01 of the Constraint Choice Language (CCL) which is
designed as a language to be used for agent communication, and more specifically as a content language to be
used with FIPA ACL.
The language is primarily intended to enable agent communication for applications which involve exchanges
about multiple interrelated choices. FIPA-CCL is based on the representation of choice problems as Constraint
Satisfaction Problems (CSPs) and supports:
• Problem representation,
• Information gathering,
• Information fusion,
• Access to problem solution techniques.
Section 2 outlines the CSP model the language is based on, gives an introduction to modelling choice problems
using CSP and discusses properties of the language. Section 4, defines the semantics of the individual language
constructs and gives and abstract syntax. Section 4.3.1 also includes an outline of FIPA-CCL’s use of
ontologies. Section 5 and the Appendices provide pointers to supporting information, with Appendix D describing
usage of the language.
2 FIPA-CCL Semantic Underpinnings
As already indicated, the FIPA-CCL language is based on the representation of choice problems as CSPs. The
CSP formalisms can therefore be used as a framework for defining the properties of the language and as a
support for defining its semantics. Section 3 gives standard definitions of a CSP and briefly outlines how to
model choice problems as CSPs. Section 3.4 gives some of the properties of the language which can be derived
from the CSP framework.
3 CSP Definitions
3.1 Standard Definition of a CSP
Constraint Satisfaction Problems have been an intensive area study for some 30 years now and the basic
definition of a CSP has remained unchanged since the early 1970s (see [Waltz75] for example). A finite binary
discrete Constraint Satisfaction Problem (CSP) is defined by:
• A finite set of variables V,
• A finite domain Di of possible discrete values for each variable vi∈V,
• A finite set of constraints C between any pairs of variables in V.
A solution to the CSP is defined as:
An assignment of values to variables such that: each variable vi ∈ V is assigned a value d ∈ Di, and none of the
constraints c∈ C are violated.
LIA-DI-EPFL CCL Language Specification v2.01
Page 3
A solution therefore consists of finding consistent legal to assignment of values to each variable such that all the
constraints posted for the problem are respected.
More formal definitions can be found in [Mackorth77] and [Dechter92] amongst others. The basic definition has
previously been extended in many ways, for example:
• Allowing dynamic sets of variables,
• Allowing dynamic, continuous or infinite variable domains,
• Allowing constraints of up to arity N where N = |V|.
These extensions are in general well defined and each has its own body of literature discussing appropriate
solution techniques and application areas. There is also an extensive literature on transformations and
equivalence of various CSP types and representations (see Section 3.3 for more on this).
3.2 Expressing Choices and Choice Problems
Having defined CSPs, a choice problem can be defined as a CSP in the following way:
• Variables are choices to be made - such as which brand of shampoo to hire or how many roses to buy for
a date. The set of variables V is the set of interrelated choices which all need to be made to have a
complete solution to the current problem.
• Domains are the available options for each choice (variable). Thus the number of roses may be anywhere
between 1 and 30 and the brands of shampoo one of X, Y and Z. The assignment of one of the values
from a domain Di to a variable vi corresponds to making a choice for vi. The set of all possible combinations
of assignments of domain values to variables define the problem search space.
• Finally Constraints are relationships between choices which express valid or invalid combinations. The set
of constraints C therefore restricts the set of all possible combinations of choices to a smaller set of
desirable assignments which meet the requirements of a solution to the choice problem.
The aim of the FIPA-CCL language is therefore to leverage this formulation of a choice problem for use in agent
communication. CSP techniques have been successfully applied to domains as diverse as configuration,
planning, scheduling, design, diagnosis, truth maintenance, spatial reasoning logic programming and resource
allocation. Using such a flexible problem representation as the basis for FIPA-CCL will hopefully make it useful
for a wide range of agent applications. Appendix D gives a more detailed guide to how FIPA-CCL can be used to
model, communicate about and solve choice problems.
3.3 CSP Model used in FIPA-CCL
The CSP model which underlies FIPA-CCL follows the standard version given in Section 3.1 in almost all
respects. However, three restrictions on the CSP representation have been made to make the model minimal
and more suitable for a communication language:
1. Binary Constraints: All constraints expressed must have an arity of no more than 2 (i.e. constraints are
only ever between two variables. This restriction is often made in the CSP field, since most powerful
solving techniques only apply to CSPs with arity 2 constraints. Furthermore, for discrete CSPs, any CSP
represented in a form using n-ary constraints can be transformed into an equivalent CSP using only
binary (2-ary) constraints. The language therefore looses none of its expressive power with this
restriction.
LIA-DI-EPFL CCL Language Specification v2.01
Page 4
2. Discrete Variable Domains: CSPs with only discrete sets of values in each variable domain are by far
the best understood in the literature. Solving CSPs with ranges of continuous real values for value
domains requires specialised solving techniques, therefore they are excluded in this version of the
language1. In practice, CSPs requiring continuous values are often be formulated by discretizing the
continuous domain (so that discrete CSP solving techniques can be applied) [Sam-Haroud and
Faltings96].
3. Intensional Relations: There are two main ways of representing constraints for CSPs – as extensional
relations (consisting of a list of the valid combinations of values for a pair or tuple of variables) and as
intensional relations (consisting of relations such as equals, greater-than etc. which do not rely on an
explicit list). FIPA-CCL excludes the use of extensional relations – this makes CSPs expressed in FIPA-
CCL much easier to compose (merge) when fusing information from several sources. Once again, no
expressive power is lost since it can be shown that for discrete CSPs every formulation using
extensional constraints has an equivalent formulation using only intensional constraints.
There are also several implicit constraints which arise out of the fact that that CSPs represented in FIPA-CCL
must be contained in a single message:
• The number of variables must be finite (since they must be encapsulated in a single message).
• The number of constraints must be finite (since they must be encapsulated in a single message).
3.4 Language Properties
Given the CSP representation in Section 3, the following sections make statements about the formal properties
of FIPA-CCL.
3.4.1 Search Termination and Complexity
The basic underlying representation used in FIPA-CCL is that of a Constraint Satisfaction problem. In a sense
most messages in FIPA-CCL will define a problem (a CSP) which acts as an, as yet, unexplored solution space.
This allows us to make definitive statements about when these problems have solutions, when search is
guaranteed to terminate and how long the search might take.
Questions of termination depend upon the type of CSP represented and on the state of the variable domains as
follows:
• If all variable domains are discrete (as they must be given the restrictions in Section 3.3) and finite, then
the solution and search spaces are both finite and search is guaranteed to terminate.
• Although the search for a solution can be shown to terminate, solving the problem is in general NP-
complete. This is to be expected since the choice problems agents using FIPA-CCL are trying solve are by
their very nature combinatorially explosive.
• It has been shown that for some restricted types of CSP problem the complexity of finding a solution may
be less than NP-complete: linear or polynomial for example (see [Freuder82] and [van Beek and
Dechter97] for example).
An important advantage gained by using the underlying CSP representation is that problem solving can leverage
the powerful techniques which have been developed for CSP solving (there is extensive literature on this subject
1 If applications demand these could be added in a future version.
LIA-DI-EPFL CCL Language Specification v2.01
Page 5
– [Tsang94] provides a good starting point). Techniques exist which routinely solve problems of over 1000
variables and most problems of 10-20 variables can be solved using very simple search algorithms.
4 FIPA-CCL Language Ontology and Abstract Syntax
This section gives the semantics of all the constructs in the FIPA-CCL language as definitions in an ontology,
these semantics are then tied together by the abstract grammar given in Section 4.3. Section 4.1 gives
definitions for the key constructs in the language – the available objects, actions and propositions.
4.1 Language Ontology: Semantics of Key Constructs
This section outlines the semantics of each of the main constructs in the language. The constructs are grouped
into sections to reflect three different types of entities: Objects, Actions and Propositions.
4.1.1 Objects
A FIPA-CCL object represents either a whole CSP or part of a CSP such as a Variable, Domain, Relation etc.
These objects therefore describe the fundamental components of choices and choice problems.
4.1.1.1 CSP Object
Object: CSP
Parameter Description Value Type Presence
CSP-ref This references a CSP object. CSP-identifier M
Variables Represents the choices which need
to be taken in the choice problem.
The variables listed in this slot must
all have unique names. The
Variables listed in this slot should
have unique Role/Type
combinations (see definition of
CSP-variable in Section 4.2.2.4).
Set {CSP-variable} O
Relations Represent the relationships between
the choices to be made. Set {CSP-relation} O
Exclusions Represents a list of unary relations
on single variables which exclude
certain values from variable
domains
Set {CSP-exclusion} O
A CSP object represents a choice problem (see Section 3.2). For a CSP object to be well defined, the items in
the Exclusion and Relations slots must only refer to variables which are present in the Variables slot. If the CSP-
ref field is not filled (i.e. it is not null) then the CSP referenced in this field is taken to be the object of the CSP-
object construct and the items in the Variables, Relations and Exclusions fields are ignored. A CSP which
contains no variables, relations or exclusions (directly or by reference) is known as a null CSP.
4.1.1.2 CSP-solution Object
Object: CSP-solution
LIA-DI-EPFL CCL Language Specification v2.01
Page 6
Parameter Description Value Ty pe Presence
CSP-ref This references the CSP object this
object is a solution for. CSP-identifier M
Assignments A list of variable assignments such
that:
• The list contains one and only
one assignment for each and
every variable defined in the
CSP reference in the CSP-ref
slot.
• The assignment of these
values violates none of the
constraints posted for the
CSP in the CSP-ref slot. That
is, the variable assignment
must be consistent
Set {CSP-variable-
assignment} M
This object captures the notion of a solution to a choice problem. Here all the choices are assigned an
appropriate value (one of the options) and the assignment violates none of the posted constraints.
4.1.1.3 CSP-solution-list Object
Object: CSP-solution-list
Parameter Description Value Type Presence
CSP-ref This references the CSP object this
object lists solutions for. CSP-identifier M
Solutions A list of possible solutions to the
choice problem. The list must
contain at least one such solution
and may contain any subset of the
whole set of solutions for the CSP.
Set {CSP-solution} M
This object captures the notion of a list of solutions to a choice problem.
4.1.2 Actions
Actions in FIPA-CCL are operations which may be performed on objects expressed in the language. The types
of actions currently allowed include constructs for information gathering, information fusion and problem
resolution. Actions are defined in terms of the action construction itself, the preconditions which must hold before
the action can be carried out and the intended result of the action.
4.1.2.1 CSP-give -constraints Action (Information Gathering)
Action: CSP-give-constraints
Parameter Description Value Type Presence
LIA-DI-EPFL CCL Language Specification v2.01
Page 7
Target Specifies a choice problem: a set of
variables and constraints whose
types and roles identify the problem
being solved.
CSP | CSP-identifier M
Action Result: CSP-give-constraints
Expected Effect:
The expected effect of this action is the creation of a new CSP (CSPINF) containing information the agent carrying out
the action (the actor) wishes to express about the choice problem defined by the CSP given in target of the action
(CSPT). CSPINF consists of:
• A complete copy of CSPT , including: all the variables originally present in CSPT (with their original roles and
types), all the values in the variable domains of these variables and all the constraints present in CSPT.
• New information in the form of constraints between variables vi specified in CSPT, i.e.:
- Relations between variables vi,
- Exclusions on variable domains of vi.
• CSPINF may also include new variables (with associated domain values) which are added as part of the expression of
constraints (when expressing ternary constraints in their binary representation for example – see Appendix B1).
Result Type Description
CSP Object If the action could be successfully performed, a CSP object representing the new CSPINF is
generated.
Additional points:
• All new elements (those not present in CSPT ), including constraints, domain values and
variables in CSPINF must include a tag in their Tags field. This tag should be: the same
for each element (this identifies all added information as being the result of a single
information gathering action) and not present as a tag in the CSPT (ensuring that the
information does not become mixed with existing information).
CSP-unknown
Proposition If the CSP-give-constraints action contains a CSP-identifier referring to a CSP which the
receiving agent has no knowledge of, this CSP-unknown proposition is the result of the
action.
This action is used to collect constraints on a given set of variables and domains (i.e. those specified in the
CSPT). The information is captured in a new CSP – CSPINF which is a copy of CSPT containing new constraints
(and potentially new variables which are required for expressing these new constraints). The two CSPs (CSPT
and CSPINF) could now be composed using one of the two main composition operations (conjunctive or
disjunctive composition – see Appendix B.1.3). However it should be noted that this composition is not part of
the CSP-give-constraints action.
• Using CSP-give-constraints followed by a conjunctive composition of CSPT and CSPINF creates a CSP
whose solutions satisfy both the actor’s constraints and the constraints originally present in CSPT.
• Using CSP-give-constraints followed by a disjunctive composition of CSPT and CSPINF creates a CSP
whose solutions satisfy either the original constraints in CSPT or the constraints of the actor or both.
An agent can perform the CSP-give-constraints iff it knows all variables v
i and all constraints ci identifying the
problem P to solve (either by understanding the CSP sent in the message or having access to the CSP referred
to in the CSP-ref reference).
LIA-DI-EPFL CCL Language Specification v2.01
Page 8
4.1.2.2 CSP-give-values Action (Information Gathering)
Action: CSP-give-values
Parameter Description Value Type Presence
Target Specifies a set of variables and
constraints whose types and roles
identify the problem being solved.
CSP | CSP-identifier M
Action Result: CSP-give-values
Expected Effect:
The expected effect of this action is the creation of a new CSP (CSPINF) containing information the agent carrying out
the action (the actor) wishes to express about the choice problem defined by the CSP given in target of the action
(CSPT). CSPINF consists of:
• A copy of all the variables vi in CSPT including their original roles and types but not including the values in their
domains,
• New information in the form of values added to the domains of variables vi in CSPINF :
- A new value is added to the domain of variable v iff the actor considers this value suitable as an assignment for
variable v in a solution to the choice problem defined by CSPT. Values may be taken from the original domains
of the variables in CSPT o r be obtained from other sources,
- If the actor knows of no suitable values for the domain of a particular variable – the domain is left empty.
• CSPINF may also include new constraints (exclusions and relations) between the variables since these new
constraints apply to the values being given as information by the execution of the action. New variables may be
added as part of the expression of these constraints (when expressing ternary constraints for example).
Result Type Description
CSP Object If the action could be successfully performed, a CSP object representing the new CSPINF is
generated.
Additional points:
• All elements including constraints, domain values and variables in CSPINF must
included a tag in their Tags field. This tag should be: the same for each element (this
identifies all added information as being the result of a single information gathering
action) and not present as a tag in the CSPT (ensuring that during a future composition
operation the information does not become mixed with existing information).
CSP-unknown
Proposition If the CSP-give-values action contains a CSP-identifier which the receiving agent has no
knowledge of, a CSP-unknown proposition is the result of the action.
This action is used to collect suitable options for a certain problem solving context. The CSP given as argument
specifies a list of variables whose types, roles and relations identify the requested values. The two CSPs (CSPT
and CSPINF) could now be composed using one of the two main composition operations (conjunctive or
disjunctive composition – see Appendix B.1.3). However it should be noted that this composition is not part of
the CSP-give-constraints action.
• Using CSP-give-values followed by a conjunctive composition of CSPT and CSPINF creates a CSP whose
solutions only contain value assignments which are acceptable to both the actor and the agent(s) creating
the original CSPT.
• Using CSP-give-values followed by a disjunctive composition of CSPT and CSPINF creates a CSP which
includes an extended set of options (and possibly solutions) beyond those available in the original CSPT..
LIA-DI-EPFL CCL Language Specification v2.01
Page 9
An agent can perform the CSP-give-values iff he knows all variables v
i and all constraints c
i identifying the
problem P to solve.
4.1.2.3 CSP-solve Action (Generating Solutions)
Action: CSP-solve
Parameter Description Value Type Presence
Target The choice problem that requires a
solution to be found. CSP | CSP-identifier M
Action Result: CSP-solve
Expected Effect:
The expected effect of having performed this action is to find an assignment of values to the variables vi in the CSP
specified as the target of the action CSPT such that none of the constraints ci specified in CSPT are violated.
Result Type Description
CSP-solution
Object If a solution to the problem given in the target slot of the CSP-solve action (CSPT) exists then it
is represented by this resulting CSP-solution object.
CSP-insoluble
Proposition If there exist no solutions to the CSP identified or provided in the Target slot of the CSP-solve
action, a CSP-insoluble proposition is the result of the action.
CSP-unknown
Proposition If the CSP-solve action contains a CSP-identifier which the receiving agent has no knowledge
of, a CSP-unknown proposition is the result of the action.
This is the action of solving a CSP (the CSP specified as the Subject slot of the action). In order to perform this
action an agent must be able to understand the CSP problem representation, i.e., all the variables and the
constraints.
4.1.2.4 CSP-solve-list Action (Generating Solutions)
Action: CSP-solve-list
Parameter Description Value Type Presence
Target The choice problem that requires
solutions to be found. CSP | CSP-identifier M
Action Result: CSP-solve-list
Expected Effect:
The expected effect of having performed this action is to find one or several sets of assignments of values to the
variables vi in the CSP specified as the target of the action CSPT such that none of the constraints ci specified in CSPT
are violated.
Result Type Description
CSP-solution-
list Object This list of CSP solution should contain all the possible solutions to the CSP identified or
provided in the Target slot of the CSP-solve-list action.
LIA-DI-EPFL CCL Language Specification v2.01
Page 10
CSP-insoluble
Proposition If there exist no solutions to the CSP identified or provided in the Target slot of the CSP-solve-
list action a CSP-insoluble proposition is the result of the action.
CSP-unknown
Proposition If the CSP-solve-list action contains a CSP-identifier which the receiving agent has no
knowledge of, a CSP-unknown proposition is the result of the action.
This action is similar to the CSP-solve action above but is defined as solving the CSP given in the subject slot to
return all of its solutions and collating these into a list of solutions.
4.1.3 Propositions
A proposition makes a statement about the truth or falsity of a property of a CSP object. Note that the definitions
given in this section are effectively proposition schemas expressed as predicates. However, once the variables
in the schemas are instantiated the ensemble is treated as a proposition.
4.1.3.1 CSP-insoluble
Proposition: CSP-insoluble
True IFF:
CSP-insoluble is true iff ¬∃ X such that X is an assignment of values to the variables of the given CSP consistent with
the given constraints.
Parameter Description Value Type Presence
Target The CSP which is the subject of the
statement made by the proposition. CSP | CSP-identifier M
This states that the CSP given in the Subject slot has no solutions.
4.1.3.2 CSP-soluble
Proposition: CSP-soluble
True IFF:
CSP-soluble is true iff ∃ at least an X such that X is an assignment of values to the variables of the given CSP
consistent with the given constraints.
Parameter Description Value Type Presence
Target The CSP which is the subject of the
statement made by the proposition. CSP | CSP-identifier M
This states that the CSP given in the Subject slot has at least one solution.
4.1.3.3 CSP-unknown
Proposition: CSP-unknown
True IFF
CSP-unknown is true iff the referred CSP is unknown to the agent making the statement.
Parameter Description Value Type Presence
LIA-DI-EPFL CCL Language Specification v2.01
Page 11
CSP-ref A CSP reference which is the
subject of the statement made by
the proposition.
CSP-identifier M
This states that the CSP referred to by the reference in the CSP-ref slot is unknown to an agent.
4.1.3.4 Is-csp
Proposition: Is-csp
True IFF
Is-csp is true iff the object referred to in the Target Parameter is a well formed CSP object.
Parameter Description Value Type Presence
Target The CSP which is the subject of the
statement made by the proposition CSP ¦CSP-identifier M
This proposition can be used to wrap CSPs in a proposition construct for general information passing. The
semantic meaning of the message containing such a proposition may be derived from the conversation context.
4.1.3.5 Is-action-result
Proposition: Is-action-result
True IFF
Is-action-result is true iff the object referred to in the Result Parameter is the result of an action which is either given in
the optional Action parameter, or is well defined in the context of the agent conversation.
Parameter Description Value Type Presence
Result The object or proposition which is
the result of the action given in the
Action parameter (or which is well
defined in the context of the agent
conversation).
CCL-Object ¦CCL-
Proposition M
Action The Action which generated the
proposition or object given in the
Result parameter.
CSP-Action O
The Action parameter is not mandatory since in some cases it may be unnecessary to repeat the specification of
the action that led to the result since the action is being referred to may be clear form the context.
4.2 Language Ontology: Semantics of Supporting Items
Apart from the three main types of items listed above (Actions, Objects and Propositions) there are also other
constructs in the CL which form part of the main objects but cannot form valid sentences by themselves.
4.2.1 CSP Object related Items
4.2.1.1 CSP- identifier
LIA-DI-EPFL CCL Language Specification v2.01
Page 12
Item: CSP-identifier
Parameter Description Value Type Presence
Identifier-body
The unique name of a CSP. symbol M
A CSP-identifier is a terminal and represents the name of a CSP and is a symbol (see Section 4.2.4.5). The
identifier should be unique.
4.2.2 Variable Related Items
4.2.2.1 CSP-range
Item: CSP-range
Parameter Description Value Type Presence
Range Defines complete domains such as
ordered lists of number numbers,
world-airports, etc., which must be
part of a common ontology.
domain-range O
Tuple-range Defines a combination of all the
legal values in a tuple. A range is
given for each slot in the tuple and
this parameter specifies that all
combinations of values from the
given ranges in each slot in the
tuple are legal.
List {domain-range} O
This object represents a complete domain, to be used when explicit enumeration of values would be too
inefficient. The two items Range and Tuple-range are optional however one or the other must be present.
4.2.2.2 CSP-value
Item: CSP-value
Parameter Description Value Type Presence
Npart A value is a tuple of several
elements. The Npart parameter
identifies the number of elements
that the tuple value. (Must be
identical to the number of items in
the Elements parameter.)
number M
Elements Gives a list of values: one for each
of the elements in the tuple. List {domain-term} M
Tags Contains a list of symbols that
allow selective constraints. Set {symbol} O
This object represents an option. In general this can be a tuple – hence the variable is an ordered list of domain
terms.
LIA-DI-EPFL CCL Language Specification v2.01
Page 13
4.2.2.3 CSP-value-list
Item: CSP-value-list
Parameter Description Value Type Presence
Npart Identifies the number of elements
that the tuple values in the list have.
(Must be identical to the number of
items in the Elements parameter.)
number M
Value-list Gives a list of tuples: one for each
value represented in the list. List {List {domain-term}} M
Tags Contains a list of symbols that
allow selective constraints. These
tags apply to all the values in the
list.
Set {symbol} O
This object represents a list of options. Each option is a tuple and each of the values in the list must have the
same number of elements in the tuple (the number of elements must in turn be equal to the value of the Npart
slot).
4.2.2.4 CSP-variable
Item: CSP-variable
Parameter Description Value Type Presence
Name Gives a unique symbol that is used
to make references to the variable
within the context of a single CSP.
symbol M
Type Specifies the type of values that the
variable takes; this includes
granularity. The ordered list is
given since the variable might take
tuple values – in this case the first
type refers to the type of the first
element in the tuple etc.
List {domain-variable-
type} M
Role Identifies the position of the
variable within the problem-solving
context.
Set {domain-role-term} O
Domain Lists the possible values this
Variable may take (the available
options). These options must be
consistent with the types of values
given in the Type slot.
CSP-range | List {CSP-
value} O
This Object represents a single choice to be made, along with a set of possible options for that choice. The Type
and Role slots enable the Variable to be situated within the problem solving context.
4.2.2.5 CSP-variable-assignment
LIA-DI-EPFL CCL Language Specification v2.01
Page 14
Item: CSP-variable-assignment
Parameter Description Value Type Presence
Name The name of the variable having a
value assigned to it. CSP-variable-name M
Value The value being assigned. The
value assigned must match with the
type of the variable
CSP-value M
The variable named in the Variable-name slot is assigned the value given in the Variable-value slot. This
represents a variable instantiation – a choice being made.
4.2.2.6 CSP- variable-name
Item: CSP-variable-name
Parameter Description Value Type Presence
Name The name of a variable (choice). symbol M
A CSP-variable-name is a terminal and represents the name of a variable in a CSP.
4.2.3 Constraint Related Items
4.2.3.1 CSP-exclusion Object
Item: CSP-exclusion
Parameter Description Value Type Presence
Variable The name of the variable being
constrained CSP-variable-name M
Excluded-Values
Gives an explicit list of disallowed
values. (These values must be
compatible with the type of the
variable mentioned in the Variable
slot.)
Set {CSP-value} M
Tags Contains a list of symbols that
allow selective constraints. Set {symbol} O
This object represents a constraint on a single variable by specifying a set of values that is explicitly disallowed
for this variable.
4.2.3.2 CSP-relation
Item: CSP-relation
Parameter Description Value Type Presence
LIA-DI-EPFL CCL Language Specification v2.01
Page 15
Variables Contains two CSP-variable-names
such that the named variables are
defined in the current CSP. This is
an ordered list.2
List {CSP-variable-name} M
Relation-type The type of the relation being
applied. String (one of the restricted set
given below) M
Indices Specifies what sub-fields of
variable values the relation refers
to.
Set {index-pair} M
Tags Contains a list of symbols that
allow selective constraints. Set {symbol} O
This object represents a relation between two variables. Any variables named in the Relation-body must appear
in the set of Variables of the relation. The set of index-pairs identifies which slots in a tuple valued variable
are covered by the relation. For example, for an equality relation between two variables with 3 tuples as values
(e.g. (x, y, z)), setting the set of indices to {(2,2), (3,3)} indicates that only the 2nd and 3rd slot of the value
tuples need ever be equal – the constraint is not violated even if the values in the 1st slots are unequal.
The following table describes the allowed relations.
Relation-type description
Intentional-equality This specifies that all the variables listed in the Variables list of the relevant CSP-
constraint object must take equal values in any instantiation.
Intentional-inequality This specifies that all the variables listed in the Variables list of the relevant CSP-
constraint object must take strictly different values in any instantiation.
Intensional-
greaterThan This specifies that the variables in the Variables list of the relevant CSP-constraint
object are related by a “greater than” relationship (“>”) such that the order of the
tuple defines the order in the relationship – the first variable in the list is strictly
greater than the second, which is strictly greater than the third, etc. (n is the number
of CSP-variables named in the Variables slot of the relevant CSP-constraint object.)
NOTE: This relation is only valid for variable types which have an ordering relation
defined in the domain ontology (integers for example).
Intensional-lessThan This specifies that the variables in the Variables list of the relevant CSP-constraint
object are related by a “less than” relationship (“<”) such that the order of the tuple
defines the order in the relationship – the first variable in the list is strictly less than
the second, which is strictly less than the third, etc. (n is the number of CSP-
variables named in the Variables slot of the relevant CSP-constraint object.) NOTE:
This relation is only valid for variable types which have an ordering relation defined
in the domain ontology (integers for example).
Intensional-
greaterThanEqual Similar to greaterThan above but using a “greater than or equals” relation.
Intensional-
lessThanEqual Similar to lessThan above but using a “less than or equals” relation.
Intensional-Empty This specifies that there are no allowed combinations of values for these values.
2 Note: the restriction to two variables here (rather than 2 or more) corresponds to the restriction of FIPA-CCL to binary
relations only (see Section 3.3).
LIA-DI-EPFL CCL Language Specification v2.01
Page 16
4.2.4 Ontology Related Items and Terminals
To make usage of an ontology easier with FIPA-CCL, different types of objects which can be found in the
Ontology are specified. A description can be found in Section 4.3.1.
4.2.4.1 domain-range
Item: domain-range
Parameter Description Value Type Presence
Domain-range-
body These are terminals and defined in
the ontology - see Section 4.3.1 String M
4.2.4.2 domain-role-term
Item: domain-role-term
Parameter Description Value Type Presence
Domain-role-
term-body These are terminals and defined in
the ontology - see Section 4.3.1 String M
4.2.4.3 domain-term
Item: domain-term
Parameter Description Value Type Presence
Domain-term-
body These are terminals and defined in
the ontology - see Section 4.3.1 String M
4.2.4.4 domain-variable-type
Item: domain-variable-type
Parameter Description Value Type Presence
Domain-
variable-type-
body
These are terminals and defined in
the ontology - see Section 4.3.1 String M
4.2.4.5 symbol
Item: symbol
Parameter Description Value Type Presence
Symbol-body A unique word used to identify a
particular instance of an object. String M
LIA-DI-EPFL CCL Language Specification v2.01
Page 17
Symbols are terminals and used to identify particular instances of objects. Symbols should be unique in their
context of use.
4.2.4.6 Index-pair
Item: index
Parameter Description Value Type Presence
index-body A pair of numeric values used to
particular field in a tuple which are
related.
(Integer, Integer) M
Indices are used in relations to reference the individual fields in tuples. Given two variables with tuple valued
variables, the index-pair indicates a field in the first and a field in the second which are somehow related.
4.3 Abstract Syntax
The abstract grammar uses an EBNF style notation and is intended to define which top level entities form valid
sentences in the language. A full syntax can be constructed from the Language Ontology description in Section
4.1. A full concrete syntax for FIPA-CCL is given in Section 6.
CCLExpression = CCLObject
| CCLAction
| CCLProposition
CCLObject = CSP
| CSP-solution
| CSP-solution-list
CCLAction = CSP-give-constraints
| CSP-give-values
| CSP-solve
| CSP-solve-list
CCLProposition = CSP-insoluble
| CSP-soluble
| CSP-unknown
| Is-csp
| Is-action-result
4.3.1 Ontology Requirements
To ensure that domain ontologies can be easily bound into the content language, CCL imposes some minimal
restrictions on the form of an ontology that is used with it. In particular the ontologies must define items of the
following types:
• Types of variables: these correspond to the domain-variable-type terminals defined in Section 4.2.4.4.
Variable types define the form of information which variables of that type can express, e.g. times, dates,
places, airlines etc.
LIA-DI-EPFL CCL Language Specification v2.01
Page 18
• Roles of variables: these correspond to the domain-role-term terminals defined in Section 4.2.4.2. A
variable role corresponds to the variable’s function in the current problem solving context – examples include
“flight”, “outbound”, “meeting-location” etc.. Agents can attach roles to variables to keep track of the semantic
interpretation of the choice problem.
• Values: these are the available options for choices and correspond to the domain-term terminals defined
in Section 4.2.4.3. This can be any usefully defined term in the domain ontology.
• Variable domain ranges: these correspond the allowed range expressions in the domain, where a range is a
well defined set or continum of domain terms. Domain ranges correspond to the domain-range terminals
defined in Section 4.2.4.1. Since some variable domains are often best compactly expressed as ranges
(rather than enumerated) an ontology may define the legal types of ranges available. Examples include:
ranges of time (“working-day” = 8.00am – 5.00pm), ranges of sizes (shoe size = 3 – 12) etc. For some
ontologies, domain ranges may be parameterised expressions. For example a time ontology may include a
expression for a range such as hours(start, end) indicating the range of hours between the start and end
hours given.
Effectively these restrictions impose typing requirements on the domain ontology to be used with FIPA-CCL.
How the types are expressed in any particular ontology is application and ontology dependent (and hence not
addressed in this specification).
5 FIPA-CCL Related Resources
Since this document is intended as a language specification it contains only outline explanation of the usage of
FIPA-CCL. To remedy this, additional explanation and resources are available on the web at:
http://liawww.epfl.ch/CCL/. The resources soon to be made available include:
• The electronic form of the XML DTD for the concrete FIPA-CCL syntax given in Section A.1 (the direct
link is http://liawww.epfl.ch/Fipa-activities/CCL/CCL1.dtd).
• Web pages and papers with supporting language documentation such as the original proposal document
(which contains usage examples and describes the possible utility of the language) and a guide to
modelling application problem in FIPA-CCL.
• Details of the demonstration application shown at the FIPA Kawasaki meeting. Including components
(such as a CSP solver) which will be made available for access on line in January 2000.
6 References
[van Beek and Dechter95] “On the Minimality and Global Consistency of Row-Convex Constraint Networks”, P.
van Beek and R. Dechter. Journal of the ACM, 42(3), pp. 543-561, May 1995.
[van Beek and Dechter97] “Constraint Tightness and Looseness versus Local and Global Consistency”, P. van
Beek and R. Dechter. Journal of the ACM, 44(4), pp. 549-566, July 1997.
[Dechter92] “Constraint Networks”, R. Dechter. Encyclopedia of Artificial Intelligence, pp. 276-285, Wiley, 1992.
[FIPA97-part2] “FIPA 1997 specification, part 2: Agent Communication Language”, Issued by the Foundation for
Intelligence Physical Agents, October 1997. Available on-line at: http://www.fipa.org/ .
LIA-DI-EPFL CCL Language Specification v2.01
Page 19
[Freuder82] “A Sufficient Condition of Backtrack-Free Search”, E. C. Freuder. Journal of the ACM, 29(1), pp. 24-
32, January 1982.
[Freuder85] “A Sufficient Condition for Backtrack-Bounded Search”, E. C. Freuder. Journal of the ACM, 32(4),
pp. 755-761, October 1985.
[Mackworth77] “Consistency in networks of constraints”, A. Mackworth. Artificial Intelligence, Vol. 8, 1977.
[Sam-Haroud and Faltings96] “Consistency Techniques for Continuous Constraints”, D. Sam-Haroud and B.
Faltings. Constraints 1(1), 1996, pp. 85-118.
[Tsang94] “Foundations of Constraint Satisfaction”, E. Tsang. Academic Press, 1994.
[Willmott and Faltings 98] “Explicit Representation of Choice in a Content Language”, S. Willmott and B. Faltings.
LIA-EPFL Lausanne, FIPA input document, response to FIPA - CFP5. Available on-line at:
http://liawww.epfl.ch/-willmott/FIPA/CFP5_001.html.
[Waltz 75] “Generating Semantic Descriptions from Drawings of Scenes with Shadows”, D. I. Waltz. In “The
Psychology of Computer Vision”, McGraw-Hill, 1975.
LIA-DI-EPFL CCL Language Specification v2.01
Page 20
A.1 Normative Appendix: FIPA-CCL XML Based Concrete Syntax
This appendix gives a concrete syntax for the FIPA-CCL language as an XML DTD. This syntax is the default
syntax for FIPA-CCL and the only one currently defined. Any agent sending an ACL message with the :content
parameter set to FIPA-CCL is assumed to have used this syntax.
A.1.1 XML DTD
<?xml version="1.0" encoding="UTF-8"?>
<!--=== DTD of the Choice Content Language (CLL). This definition is based in the
document "A FIPA Content Language for Expressing Agent Choice: Constraint Choice
Language (FIPA-CCL)" ===-->
<!ELEMENT Expression (Object | Action | Proposition)>
<!--Definition of an Object in FIPA-CCL-->
<!ENTITY % objects "CSP | CSP-solution | CSP-solution-list">
<!ELEMENT Object (CSP | CSP-solution | CSP-solution-list)>
<!ATTLIST Object Name ( %objects; ) #REQUIRED>
<!--== CSP ===-->
<!ELEMENT CSP (CSP-variable*, CSP-relation*,CSP-exclusion*)>
<!ATTLIST CSP CSP-ref ID #IMPLIED>
<!--=== CSP-solution ===-->
<!ELEMENT CSP-solution (CSP-variable-assignment*)>
<!ATTLIST CSP-solution href CDATA #REQUIRED>
<!--=== CSP-solution-list ===-->
<!ELEMENT CSP-solution-list (CSP-solution+)>
LIA-DI-EPFL CCL Language Specification v2.01
Page 21
<!ATTLIST CSP-solution-list href CDATA #REQUIRED>
<!--Definition of an Action in FIPA-CCL-->
<!ENTITY % actions "CSP-give-constraints | CSP-give-values | CSP-solve | CSP-solve-
list">
<!ELEMENT Action (CSP-give-constraints | CSP-give-values | CSP-solve | CSP-solve-
list)>
<!ATTLIST Action Name (%actions;) #REQUIRED>
<!--=== CSP-give-constraints ===-->
<!ELEMENT CSP-give-constraints (CSP | CSP-identifier)>
<!--=== CSP-give-values ===-->
<!ELEMENT CSP-give-values (CSP | CSP-identifier)>
<!--=== CSP-solve ===-->
<!ELEMENT CSP-solve (CSP | CSP-identifier)>
<!--ENTITY % result-values "CSP-solution | CSP-insoluble | CSP-solution-list"-->
<!--=== CSP-solve-list ===-->
<!ELEMENT CSP-solve-list (CSP | CSP-identifier)>
<!--Definition of a Proposition in FIPA-CCL-->
<!ENTITY % propositions "CSP-insoluble | CSP-soluble | CSP-unknown">
<!ELEMENT Proposition (CSP-insoluble | CSP-soluble | CSP-unknown)>
<!ATTLIST Proposition Name ( %propositions; ) #REQUIRED>
LIA-DI-EPFL CCL Language Specification v2.01
Page 22
<!--=== CSP-insoluble ===-->
<!ELEMENT CSP-insoluble (CSP | CSP-identifier)>
<!--=== CSP-soluble ===-->
<!ELEMENT CSP-soluble (CSP | CSP-identifier)>
<!--=== CSP-unknown ===-->
<!ELEMENT CSP-unknown EMPTY>
<!ATTLIST CSP-unknown href CDATA #REQUIRED>
<!--=== IS-csp ===-->
<!ELEMENT IS-csp (CSP | CSP-identifier)>
<!--=== IS-action-result ===-->
<!ELEMENT IS-action-result (Action-performed?, Result-obtained)>
<!ELEMENT Result-obtained (Object | Proposition)>
<!ELEMENT Action-performed (Action)>
<!--Apart from the three main types of items listed above (Actions, Objects and
Propositions) there are also other constructs in the CL which form part of the main
objects but cannot form valid sentences by themselves.-->
<!--=== CSP-identifier ===-->
<!ELEMENT CSP-Identifier EMPTY>
<!ATTLIST CSP-Identifier href CDATA #REQUIRED>
<!--=== CSP-domain ===-->
<!ELEMENT CSP-domain (Tags*)>
<!ATTLIST CSP-domain Range CDATA #REQUIRED>
<!ELEMENT Tags EMPTY>
<!ATTLIST Tags Name CDATA #REQUIRED>
LIA-DI-EPFL CCL Language Specification v2.01
Page 23
<!--=== CSP-value ===-->
<!ELEMENT CSP-value (Elements+, Tags*)>
<!ATTLIST CSP-value Npart CDATA #REQUIRED>
<!ELEMENT Elements EMPTY>
<!ATTLIST Elements Value CDATA #REQUIRED>
<!--=== CSP-variable ===-->
<!ELEMENT CSP-variable (Role*,Domain*)>
<!ATTLIST CSP-variable Name CDATA #REQUIRED
Type CDATA #REQUIRED>
<!ELEMENT Role (#PCDATA)>
<!ELEMENT Domain (CSP-range | CSP-value+ | CSP-value-list)>
<!--=== CSP-range ===-->
<!ELEMENT CSP-range (Tuple-range) >
<!ATTLIST CSP-range Range CDATA #REQUIRED>
<!ELEMENT Tuple-range EMPTY>
<!ATTLIST Tuple-range Values CDATA #REQUIRED>
<!--=== CSP-variable-assignment ===-->
<!ELEMENT CSP-variable-assignment (CSP-value)>
<!ATTLIST CSP-variable-assignment Name CDATA #REQUIRED>
<!--=== CSP-value-list===-->
<!ELEMENT CSP-value-list (List-values,Tags*) >
<!ATTLIST CSP-value-list Npart CDATA #REQUIRED>
<!ELEMENT List-values EMPTY>
LIA-DI-EPFL CCL Language Specification v2.01
Page 24
<!ATTLIST List-values Values CDATA #REQUIRED>
<!--Constraint Related Items-->
<!--=== CSP-exclusion ===-->
<!ELEMENT CSP-exclusion (Excluded-Values+, Tags*)>
<!ATTLIST CSP-exclusion Variable-name CDATA #REQUIRED>
<!ELEMENT Excluded-Values (CSP-value)>
<!--=== CSP-relation ===-->
<!ENTITY % relation "intentional-equality | intentional-inequality | Intensional-
greatherThan | Intensional-lessThan | Intensional-greatherThanEqual | Intensional-
lessThanEqual | Intensional-Empty">
<!ELEMENT CSP-relation (Tags*)>
<!ATTLIST CSP-relation Variables CDATA #REQUIRED
Relation-type (%relation;) #REQUIRED
Indices CDATA #REQUIRED>
LIA-DI-EPFL CCL Language Specification v2.01
Page 25
Annex B Informative Appendix: Language Usage
FIPA-CCL is primarily intended for information gathering and problem solving for tasks involving multiple
interrelated choices. In general information gathering and problem solving tasks can be broken down into four
steps:
1. Problem modelling,
2. Information gathering,
3. Information fusion,
4. Problem solution.
This section gives a brief overview of using FIPA-CCL in each of these steps.
B.1.1 Step 1: Problem Modelling
As described in Section 2, modelling a choice problem in the FIPA-CCL language requires the problem to be
formulated as a CSP – that is:
• Identifying what the choices are – these become the variables in the problem formulation,
• Identifying which options are available for each of the choices – this generates the domains of values for
each of the variables,
• Specifying how choices are related – generating the constraints (relations and exclusions) which apply to
problem solutions.
This process is exactly what would be required when formulating problems so that they can be expressed in
FIPA-CCL messages. The process is in general intuitive, although there may also exist multiple formulations of
a particular problem all of which are equivalent in the solution space they describe (although they may be easier
or harder to solve depending upon the solution techniques applied).
B.1.1.1 FIPA-CCLs Constraint Representations
As described in Section 3.3, FIPA-CCL uses a particular style of representation for constraints – allowing only
two types of constraints:
• Exclusions: These act on a single variable and are specified as a no-good list (a list of values which this
variable may not take).
• Binary intensional relations: These act on two variables and are restricted to a closed set of eight general
types of relations (the set {=,≠,<,>,≤,≥,⊥,null} - see Section 4.2.3.2).
The use of tuple-valued variables allows the language to handle arbitrary n-ary constraints by introducing
variables whose values represent the tuples allowed by the constraint and then linking the n variables involved in
the n-ary constraints to the tuple valued variable using binary relations. The advantage of this implementation is
that solving or consistency engines can be restricted to unary and binary constraints.
As an example of representing n-ary constraints in terms of binary constraints consider a ternary constraint over
three variables – Hotel, City and Room-Type:
• Variable: Hotel, values {Marriot, Intercontinental, Hyatt-Regency}.
LIA-DI-EPFL CCL Language Specification v2.01
Page 26
• Variable: City, values {New York, Washington, Chicago}.
• Variable: Room-Type, values {standard, suite}
• Constraint: Good-list: {(Hotel: Marriot, City: New-York, Room-Type: suite), (Hotel: Intercontinental, City:
Washington, Room-Type: standard)}.
This can be converted into the following binary CSP by adding a tuple valued variable which represents the
good-list:
• Variable: Hotel, values {Marriot, Intercontinental, Hyatt-Regency}.
• Variable: City, values {New York, Washington, Chicago}.
• Variable: Room-Type, values {standard, suite}
• Variable: Constraint-1, values {(Marriot, New-York, suite), (Intercontinental, Washington, standard)}.
• Constraint: (Intensional-equality, Variable 1: Hotel, Variable 2: Constraint-1, Indices {(1, 1)})
• Constraint: (Intensional-equality, Variable 1: City, Variable 2: Constraint-1, Indices {(1, 2)})
• Constraint: (Intensional-equality, Variable 1: Room-Type, Variable 2: Constraint-1, Indices {(1, 3)})
The same mechanism of using a tuple-valued variable can be used to express constraints which might normally
be expressed using an extensional constraint (such as a good list or no-good list –lists of allowed or excluded
combinations).
Giving a list of all the allowed combinations of values between a set of variables defines an extensional relation,
such as for clothing for example:
• Variable: Hat, values {green, red, brown, black}.
• Variable: Shirt, values {white, red, pink}.
• Constraint: Good-list: {(hat: green, shirt: white), (hat: red, shirt: white), (hat: black, shirt: red)}.
This relates the two variables Hat and Shirt by giving a list of the allowed combinations (the same type of
representation could be used to express combinations which are not allowed – giving a no-good list). In FIPA-
CCL (using only intensional relations) this would be expressed using three variables:
• Variable: Hat, values {green, red, brown, black}.
• Variable: Shirt, values {white, red, pink}.
• Variable: Constraint-Hat-Shirt, values {(green, white), (red, white), (black, red)}
• Constraint-Hat: (Intensional-equality, Variable 1: Hat, Variable 2: Constraint-Hat-Shirt, Indices {(1, 1)}).
• Constraint-Shirt: (Intensional-equality, Variable 1: Shirt, Variable 2: Constraint-Hat-Shirt, Indices {(1,
2)}).
The two intensional constraints therefore link the Shirt and Hat variables to a new third variable which contains
the list of allowed tuples. This removes any need for lists of valid combinations to be represented as constraints.
B.1.1.2 More Information on Problem Modelling
[Dechter92] and [Tsang94] provide good introductions to modelling problems as CSPs. More information on
problem modelling in FIPA-CCL in particular (using the intentional representation only) can be found from the
FIPA-CCL web pages (see Section 5).
LIA-DI-EPFL CCL Language Specification v2.01
Page 27
B.1.2 Step 2: Information Gathering
Once a choice problem had been modelled as a CSP, problem information can be added to the CSP
representation to constrain or expand the range of options available. This information can be obtained from other
agents by sending requests for CSP-give-constraints and CSP-give-values actions defined in Sections
4.1.2.1, and 4.1.2.2 respectively.
• Requesting CSP-give-constraints results in a CSP with more constraints (exclusions or relations)
posted on the set of possible combinations,
• Requesting CSP-give-values results in a CSP with more possible options being added to the CSP
variables (choices).
The results of both these actions is a new CSP which can be composed with the original CSP (in the fusion step
– see Section B.1.3) to create a new CSP with more information about the problem being solved. An agent may
request information from several sources by:
• Sending the complete CSP to several agents and asking for constraints or values. This case would be most
useful if the agents being queried have similar roles in the scenario – e.g. they are all airline flight databases
but for different companies. The agent trying to solve the choice problem would receive several sets of
information for the same problem.
• Dividing up the whole problem into smaller pieces (each containing a – not necessarily disjoint - subset of
variables and constraints) and sending requests about each piece to different information agents. This would
be most useful when communicating with agents which have different specialties – i.e. one hotel database
agent, one airline agent and one ticket booking agent. In each communication the interaction concerns only
the part of the problem related to the queried agent’s speciality.
Once information has been gathered the agent solving the problem can pass on to the information fusion step.
B.1.2.1 Using Tags to Separate Information from Different Sources
FIPA-CCL includes a way of tagging values and constraints uniquely which allows problems to include a
representation of where information came from. In the results of both the CSP-give-constraints and CSP-
give-values actions the domain values and constraints returned can be grouped together using a tag (a
unique symbol). The tags are given in the Tags fields of the CSP-value, CSP-exclusion and CSP-relation
items.
B.1.3 Step 3: Information Fusion
There are two ways of combining CSPs which contain identical sets of variables:
• So that the resulting solution space is the intersection of the solutions of each of the participant CSPs.
Hence all solutions to the new CSP satisfy all the participant CSPs. In this document this is referred to as a
conjunctive combination.
• So that the resulting solution space is the union of the solutions of each participant CSPs. Here each
solution to the new CSP satisfies at least one of the participant CSPs. In this document this is referred to as
a disjunctive combination.
These are the basic operations required for compositions. Both operations can be carried out by straightforward
algorithms as long as CSPs have the same variables, but may be require transformations to the participant
CSPs beforehand. (See Section B.1.3.2 for extensions to the non-identical variable sets case.)
LIA-DI-EPFL CCL Language Specification v2.01
Page 28
B.1.3.1 Using Tags for Information Fusion
The mechanism for combining relations relies on the use of tags to achieve the correct semantics. This is best
understood by considering an example. In CSP1, variables X1 and X2 are linked with an equality constraint and
tag T1, the solution space is therefore ((a,a),(b,b)).
CSP1:
In CSP2, the same variables are connected by a ≥ constraint3, but with a different tag T2. Its solution space is
((b,b),(c,b),(c,c)).
CSP2:
Hence the tags define two sets of information for the two variables X1 and X2. The information associated with
Tag T1 gives on set of possibilities for the variable domains and a constraint. The information associated with
Tag T2 gives a second set of domains and a different constraint. Some information (such as the value b in both
domains) is common to both information sets.
Exclusions are handled in the same manner simply by treating them as constraints on a single variable. It should
also be noted that when relations have the same tags, they can be combined directly by combining their types
(i.e. ,≤ and ≥ combined give =).
Conjunctive Combination
Given the two example CSPs in the previous section we can now consider forming the intersection of the two
solution spaces decribed by tags T1 and T2. This intersection would give only the solution ((b,b)) as valid. To do
this, we need to intersect the domains for each variable. We then make sure that both constraints apply to the
remaining values simultaneously by letting the tags of the remaining values be the union of the tags they had in
the original problems, thus making all their constraints applicable:
3 Defined over the alphabetical order with a/A as the largest.
a
T1
b
T1
Variable X1
=
T1
Variable X2
a
T1
b
T1
Constraint
b
T2
c
T2
Varia
ble X1
≥
T2
Variable X2
b
T2
c T2
Constraint
LIA-DI-EPFL CCL Language Specification v2.01
Page 29
CSP3:
Disjunctive Combination
For the same example we can also form the union of the two solution spaces: a new CSP that has the solution
space ((a,a),(b,b),(c,b),(c,c)). To do this, we need take the union of the domains for each variable. We also take
the union of the constraints but constraints only apply to the values which have the appropriate tags – i.e.
constraints only apply to the values they applied to in the original problems:
CSP4:
B.1.3.2 Information Fusion for CSPs with Non-identical Variable Sets
If two CSPs to be composed do not have exactly the same variables, the two composition operations need to be
extended.
Conjunctive Composition
This composition is a straightforward extension of the conjunctive composition for the case where variable sets
were identical. when composing two CSPs CSP1 and CSP2 (to form CSPResult):
• All constraints from both CSP1 and CSP2 hold in CSPResult (as defined for the standard composition
operation),
• All variables from both CSP1 and CSP2 are present in CSPResult ,
• All variables in CSPResult must be instantiated s.t. both participant CSPs are satisfied by any solution to the
whole CSPResult.
b
T1,T2
Variable X1
=
T1
Variable X2
Constraints
b
T1,T2
≥
T2
=
T1
Constraint
Variable X1
a
T1
b
T1,T2
c
T2
Constraint
≥
T2
Variable X2
a
T1
b
T1,T2
c
T2
LIA-DI-EPFL CCL Language Specification v2.01
Page 30
Disjunctive Composition
The disjunctive case is a little more complex. When composing two CSPs CSP1 and CSP2 (to form CSPResult ),
variables are treated as follows:
• Variables in the intersection CSP1 CSP2 (set I): for the variables which exist in both CSPs the required
disjunctive composition operation can be directly applied and all variables and constraints between them
appear in CSPResult.
• Variables outside the intersection CSP1 CSP2 (set NI): these variables exist in only one of the
participant CSPs. All these variables are also added to CSPResult but are modified in the process - by
adding a special value “*” to each of their domains, where “*” stands for “unused”.
To add the variables in CSP1 which do not appear in CSP1 (I.e. are in the intersection of CSP1 and NI – call this
set NI1):
1) Generate a new unique tag T1,
2) For each variable v in NI1:
a) Add the “*” value (or a tuple of “*” values, depending on its type) into the domain of v like any other value
(unless the domain of v already contains such a value),
b) Add the tag T
1 to the “*” value, to the relations which involve v and to all values in the domain of
variables that participate in these relations (if v already contained the “*” value – add the tag to the
previous “*” value).
3) Add all the variables in IN1, their related relations and relations between variables in IN1 and I to CSPResult.
The same process is performed for the variables in CSP2 and not in CSP1 (set IN2) but with a different tag
generated in step 1 of the algorithm.
Finally, all the “*” values are considered compatible with any relation, this makes it possible to distinguish
solutions to the problem which assign a value to the variable in question and those that do not. The algorithm
uses the tag mechanism to distinguish the new variables and relations from the existing ones: since the “*” value
is compatible with any relation, the set of solutions of the revised CSP is exactly the solutions of the original CSP
with the “*” value added for the new variable. Furthermore, the unique tag ensures that this same property
continues to hold when the new CSP is combined with another one.
B.1.4 Step 4: Problem Solving
Once a problem has been modelled, information gathered and composed to form a single choice problem, then
this can be solved. The semantic meaning behind the variables and constraints in the task model can be
stripped away during the solution process and the problem can be solved as a generic CSP (such as the one
defined in Section 3.1). This allows powerful CSP problem solving algorithms to be applied.
In the context of the FIPA-CCL language there are two main ways to solve a constructed CSP problem:
• Implementation of one (or several) solution algorithms in the problem solving Agent. Solution algorithms
range from very simple compact approaches to elaborate specialised techniques. Section B.1.4.1 gives an
example of a simple search algorithm which would suffice for most small CSP problems. More advanced
algorithms can be found in, among others; [Tsang94], the proceedings of major Artificial Intelligence
conferences and the proceedings of specialist constraints conferences such as CP (Constraint
Programming).
LIA-DI-EPFL CCL Language Specification v2.01
Page 31
• Usage of a dedicated CSP solving agent which implements a suite of algorithms for solving algorithms for
generic CSPs. Such solver agents can be requested to solve choice problems using the FIPA-CCL
language actions CSP-solve and CSP-solve-list.
B.1.4.1 Simple CSP Search Algorithm
This section gives a basic solution algorithm for CSP problems to provide the minimum for problem solving using
FIPA-CCL. The backtracking search algorithm given here instantiates variables in some fixed order and is
perhaps the most commonly used CSP search techniques -many advanced methods are derived from it. The
following gives the general idea (refer to the CSP definition in Section 3):
Choose some fixed order for the variables in the set of variables V. Choose some fixed order for
each of the variable domains Di. Using these orderings repeat the following:
1. Choose the next uninstantiated variable vi in the order of V.
i. If all the variables in V have been assigned values then a solution has been found and
the procedure terminates.
ii. Otherwise proceed to step 2.
2. Assign to vi the next available value d from its domain Di.
i. IF Di is empty (there are no remaining values for vi) then backtrack – undo the previous
variable assignment made (vi-1), mark vi-1 as unassigned and continue from step 1.
ii. Otherwise continue to step 3.
3. Check that none of the constraints in C which involve variable vi are violated by assigning d to vi.
i. IF no such constraint in C is violated, mark vi as instantiated with value d and proceed to
the next variable (go to step 1).
ii. IF a constraint is violated the by this assignment then backtrack - keep vi as
uninstantiated, remove the value d from the domain Di and go back to step 2.
The procedure also terminates if it backtracks to step 2 and the first variable in the sequence has no remaining
possible values in its domain – this indicates that all value combinations are invalid and the CSP has no solution.
This procedure is sound and complete since the backtracking procedure essentially explores the search tree of
possible variable assignment combinations. Constraints are checked at each step (ensuring a non-valid
combination is never allowed) and the backtracking step is eventually forced to explore the whole search tree.
