Home
This section describes the RiDDLe (for Rational Domain Definition Language) domain definition language for representing physical domains. The RiDDLe language takes inspiration from the DDL.1 language. The current proposal, however, introduces a pure object-oriented approach to the definition of timeline-based domains and problem definitions and, therefore, allows an higher decomposition of the domain model and an increase of modularity with a consequent reduction of the the overall complexity at design phase. Furthermore, thanks to the object-oriented approach, UML modeling features can be naturally exploited to enhance the design phase. In addition, aspects related to first order logic are further made explicit, allowing a uniform representation of planning and scheduling concepts. Finally, although the language is based on a multi-sorted first order logic core, from which the object-oriented approach comes, it has been designed for allowing extensibility and is, hence, agnostic of complex types such as state-variables or resources.
Overall, the language is structured so that input problems can be decomposed in different compilation units (i.e. several files) which can possibly interact each other. Each compilation unit can contain, in general, several declarations of different types and/or several statements. Such units are given to the solver in different sorted groups (i.e. a list of lists of files). Furthermore, these groups can be sent to solver at different times so as to provide plan adaptation features. Although not strictly required, it is common practice to separate the type declarations from the statements in different units (e.g. a first unit for type declarations and a second unit for statements, so as to resemble classical planning problems). Furthermore, type declarations can be spread on different units so as to improve model decomposition. In this regard, we tried to facilitate the definition of the domains by internally implementing forward declaration. Specifically, types, methods and predicates can be used before of being declared, under the obvious assumption that these types (methods and predicates) are defined sooner or later within the same group of units within which the type (method or predicate) is used (or, alternatively, in a group previously send to the solver). On the contrary, both for defining problem instances and for defining rules' body, statements are always executed sequentially. It is, therefore, not allowed, for example, to use a variable which has not been previously declared.
To sum up, the suggested methodology, as summarized in the above figure, consists in providing to the solver a set of compilation units containing the definition of types, methods and predicates, so as to inform the solver of the domain model within which it will have to reason. At a later time, a new compilation unit is provided to the solver containing the statements relative to the declaration of the instances, the facts and the goals. At this point, if a solution to the proposed problem exists, the solver should be able to find it and return true or, if not, it should return false. Finally, if needed, the solution can be adapted, several times, by providing further compilation units.
An implementing solver should hence provide an object-oriented virtual environment for the definition of objects and constraints among them. Every object in the environment is an instance of a specific type. There is, as will be further clear soon, an important distinction between primitive types (i.e. bools, ints, reals, enums and strings) and user defined complex types (e.g. rovers, trucks, locations, etc.). Before going further, however, it is worth to introduce some naming conventions.