PDDL: A Language with a Purpose? Lee McCluskey Department of Computing and Mathematical Sciences, The University of Huddersfield

Take Home Slide Generally, language designers must be clear for what PUROSE their language is to be put. When a “standard” language is proposed, this is even more important! This makes it easier to assess their quality, to make design decisions more transparent, and to allow competing languages to be compared against each other.

Representation languages in planning: SCOPE WHAT KNOWLEDGE + WHAT PART OF PLANNING?: There are several kinds of knowledge that may be represented explicitly: = Domain objects, invariants, actions etc = Planning heuristics = Task (input)  Plans (output) – networks of actions/activities = Execution architecture

Representation languages in planning: USERS of the language WHO ARE THE USERS? Planning Researchers? Knowledge Engineers? Domain Experts? End Users? Machines (communication language) ?

Representation languages in planning: Precise purpose Given the answer to the above question is Domain objects, invariants, actions + Planning Researchers, a more precise purpose could be: = for use in theoretical arguments eg computational complexity = for use by knowledge engineers for practical domain model building = for use as a communication language between research groups

Theoretical Languages in Computing Eg Lambda-calculus, Turing Machines.. QUALITIES: = Simple, clear syntax and well-researched semantics = Adequate expressiveness for the desired application range = Clear mechanisms for reasoning For communication language, substitute reasoning with ‘close to existing languages’

Practical Languages in Computing = Eg Java in the field of programming, Z in formal specification of software, RML in requirements modelling or ML^2 in knowledge-based systems. = Criteria for practical formal languages are based around the idea that the structure of the language should support initial model acquisition and debugging, and subsequent model maintenance and re-use. = The criteria for theoretical languages are often desirable for practical languages also.

Some Qualities of Practical Languages in Computing (I’m sure they are not exhaustive) = maintenance (sometimes evaluated by considering hidden dependencies or locality of change) = closeness of mapping / customisation = error-proneness = reusability = guidelines and tool support = structure = support for operational aspects

What is PDDL’s Purpose? Is PDDL a languages for theoretical investigation of planners, a domain modelling language, or a communication language??? = it appears that the language was designed to represent the syntax and semantics of domain models that were currently available to the authors, and that were used as input languages to many of the published planners of the time.

Quick PDDL evaluation using theoretical + practical criteria Clear syntax and semantics = + The syntax is clear and tool support is available for those writing interpreters = - The semantics (v1.2) aren’t precisely defined in the manual but are dispersed.. Adequate expressiveness = very expressive language wrt competitions and in benchmark sets, although plenty of scope for improvement as shown by this many of the workshop’s papers which seem aimed at this aspect!

Quick PDDL evaluation using theoretical + practical criteria Clear mechanisms for reasoning = yes - achieved by the logical, declarative features of the notation (pre- and post- conditions, predicate logic expressions etc) structure and error-proneness = +ve at a macro level domain models can have different requirements and can be built on top of other domain models = -ve little or no structure for states + objects

Quick PDDL evaluation using theoretical + practical criteria maintenance and re-usability = +ve: ‘:extends’ is good re-use = -ve: it is easy to introduce errors when updating a model. guidelines and tool support = +ve there are parsers, solution checkers and domain analysis tools available publically = -ve PDDL was not designed to be associated with a method for model building.

Quick PDDL evaluation using theoretical + practical criteria closeness of mapping / customisation = +ve: (i)`high level' aspects of propositional encodings (ii) domain axioms and ‘requirements:’ feature = -ve: refleccting domain structre eg by composite objects is not possible support for operational aspects = The PDDL manual makes it clear that PDDL was not design to capture these aspects.

Conclusions PDDL has worked as a theoretical/communication language but is over-stretched as a modelling language. + in standardising a form of PDDL for theoretical purposes, more attention needs to be devoted to precisely defining its semantics, and that of any of its extensions; + in standardising a form of PDDL for practical domain model building, then more structure, guidelines and tool support is required. = We need to settle on the purpose of PDDL, decide on the criteria that can be used to evaluate PDDL's quality, and perform a thorough evaluation using the language's most recent version. This will lead, I believe, to a sound path for its future development.