Syntax of Fact Files for IPP 3.0 to 3.3

Basic Name Conventions:

• Typenames are arbitary strings of small and capital letters, the numbers 0-9, dashes and underscores, for example 111, p-11, G09-7_b1.
• The universal quantifier is represented with "ALL", the existential quantifier with "EX", negation with "not" or "!".
• Comments start at the beginning of a line with a "#" and end with a newline.
• Variable names start with "?" and followed by an arbitrary string of small and capital letters, the numbers 0-9, dashes and brackets "[" and "]".
• Predicate names are arbitary strings of small and capital letters, the numbers 0-9 and dashes.
• Equality is represented using the distinguished predicate name "eq", for example "!eq(?x ?y)" means that the variables ?x and ?y must be different and "eq(c ?z)" means that the variable ?z must be equal to the constant c.
• Constant names can contain small and capital letters, the numbers 0-9, dashes and brackets "[" and "]".

FACTFILE     ::= [TYPELIST] "initial:" [FACTLIST] ";
                            "goal:" [GOALS] 

TYPELIST     ::= TYPE | TYPE TYPELIST

TYPE         ::= typename ":" CONSTANTLIST ";"

CONSTANTLIST ::= constantname | constantname SPC CONSTANT_LIST

FACTLIST     ::= /* empty */ 
                 | predicatename '(' CONSTANTLIST ')'   FACTLIST 
                 | NOT PREDNAME  '(' CONSTANTLIST ')'   FACTLIST 

NOT          ::= "not" |"!" 

SPC          ::= " "  {  " "  |  newline | tabulator }
  
GOALS        ::= /* empty */ 
                 | QUANT PARDEC PREDLIST '=>' PREDLIST ';' GOALS 
                 | FACTLIST '=>' FACTLIST ';' GOALS 
                 | FACTLIST ';' GOALS

QUANT        ::= "EX" | "ALL"

PARDEC       ::=   VARLIST constantname 
                 | VARLIST constantname  PARDEC

VARLIST      ::= variablename | variablename VARLIST 
 
PREDLIST     ::= /* empty */ 
                 | predicatename '(' VARLIST |CONSTANTLIST ')'   
                   VARFACTLIST
                 | NOT PREDNAME  '(' VARLIST | CONSTANTLIST ')'   
                   VARFACTLIST  

location: freiburg melbourne cairo;

FACTLIST stands for a list of ground atoms (facts): on(b1 table) arm-empty()

GOALS can be existentially and unversially quantified, and also be conditional with the semantics that the condition is evaluated in the initial state.

An example using negation and quantified goals:

# the type declaration introducing the types "room", "bin" "object"    
# and declaring constants of each type      
room: prak-room jk bn bw;      
bin: k-bin n-bin w-bin;    
object: blob1 blob2 blob3; 

# The initial state: the robot is in prakroom, several bins are in       
# various rooms and some of them are full. There are two red and one 
# blue blob in different rooms. 

initial:at-room(prak-room) at(k-bin jk) at(n-bin bn) at(w-bin bw) 
        at(blob1 jk) at(blob2 prak-room) at(blob3 bw) red(blob1) 
        blue(blob2) red(blob3) full(k-bin) full(n-bin) empty(w-bin);

# The goal specification asks the robot to look for a red object and to
# take it to the prak-room. A blue object has to be taken to the room 
# where the red object has been taken from, but no red object can be 
# taken from the room jk. Furthermore, all full trash bins have to be emptied.

goal:
EX  ?a ?b object ?c room  
    red(?a) !red(?b)  at(?a ?c) !eq(?c jk) =>  at(?a prak-room) at(?b ?c);
ALL ?a bin full(?a) =>  empty(?a);

• We have skipped the LISP-oriented representation of facts and returned to a more logic-oriented one with the difference that the parameters of a predicate are not separated by commas, but space.
• In case that you do not have any types in your planning problem, the typelist can be empty as well as the initial state and the goal specification (the latter will cause the planner to report that the empty goal is satisfied in the initial state).
• A predicate without arguments still requires to use () as in in arm-empty() for example.
• An object can have several types, i.e., it can appear in more than one TYPE definition. We do not pose any restrictions on the type hierarchy.
• Each type should only be declared ones.
• No free variables are allowed in goals.
• Negated goals containing constants that belong to several types can lead to problems since the planner assumes that the first declared type for the constant is meant.
• The same predicate name can be used with different arities of arguments and different type declarations for the arguments. We usually take care of it, but it should be used only when absolutely necessary.

object: wrench jack pump wheel1 wheel2 nuts; 
hub: the-hub; 
nut: nuts;
container: boot;
wheel: wheel1 wheel2; 

initial: 
intact(wheel2) in(jack boot) in(pump boot) have(wheel2) 
in(wrench boot) on(wheel1 the-hub) on-ground(the-hub) tight(nuts the-hub)
not-inflated(wheel2) unlocked(boot) fastened(the-hub) closed(boot);

goal:
on(wheel2 the-hub) inflated(wheel2)
in(wheel1 boot)
in(wrench boot) in(jack boot) in(pump boot) 
tight(nuts the-hub) 
closed(boot);