Proceedings of the Second Workshop

September 6th and 7th, 1999 at the University of Durham, UK.

General KE Issues | Representation Issues

Discussion on General KE Issues

To Improve the Take up of Planning Technology

What mechanisms can we explore to improve the take-up?

People are simply not aware of the technology. We need to promote to increase its visibility. For example, publicize success stories, technology magazine cover disks, and events to report success stories. We need to consider that industrialists may not be interested in "domain-independent" technology. We must demonstrate that the technology works in his or her domain before they will consider it. Good user-interfaces to planning systems were also considered essential.

Which application domains should we focus upon?

E-commerce applications were proposed as a domain potentially ripe for exploitation without many of the pragmatic challenges in traditional domains.

Technical Issues

Improved Formalism?

We should consider developing a tool-supported representation language oriented to the needs of users. While formalisms such as PDDL are considered sufficiently expressive, it is difficult for users to build domain descriptions within them.

Role of Pre-Processing?

Recent work has demonstrated how pre-processing techniques can significantly speed up reasoning in planning systems. We need to exploit such techniques further if we are to build planning systems that can operate in a reasonable time.

Lack of "Real" Benchmarks

We have not developed benchmark problems that are representative of real-world planning applications. In the absence of such test sets it is difficult to asses the readiness of technology for industrial take up.

Discussion on Representation Issues

Reporter: Lee McCluskey, Huddersfield University, UK.

What are the REQUIREMENTS for a fairly `standard'planning domain modelling language?

This was preceded by a brief discussion about which user group would the language be aimed at - non-computer-experts, computer scientists OR computer scientists with a PhD in planning. The `computer scientist' category was probably the one to be aiming at: the language should not assume that the user had an intimate knowledge of the likely planning programs that would input a model encoded in the language; on the other hand, someone with the background of a computer scientist might be needed to have the experience to be able to use a (precise) modelling language to capture a domain.

The general requirements seemed to be

There was a feeling in the meeting that there should be well-defined limits to this expressiveness (perhaps a good analogy is the way that the Description Logics are nicely structured and `user-oriented', yet have expressive limitations
that help with their reasoning mechanisms). Extensibility would be useful - if the language was made more expressive in some way we wouldn't want to have to re-write the whole of the defintition/tools/ environment etc. For example, you could extend an object-centred language like OCL to be non-deterministic by changing a state to be a mapping
between object names and sets of substates. This would have knock-on effects but you wouldn't have to redesign everything to incorporate it.

- planning-oriented
Certain fundamental assumptions about the kinds of planning domains to be encoded in the language can be
built in to the language design - in addition to the obvious need for structures to represent actions. For example, building in structures to allow the declarative specification of the range of behaviours of classes of dynamic objects.
Or again, building in structures to allow the posing or deduction of state invariants that constrain the set of possible states of objects (this helps the modeller create a more accurate model of the domain).

- methodology
A systematic method for the engineering of the model. It should cover phases such as initial knowledge acquisition,
validation and maintenance, pre-processing and/or compilation. It should take into account the needs of the modellers
and provide useful abstractions, opportunities for measuring and classifying the evolving model, and opportunities for error removal (e.g. via the discharging of proof obligations).

- tool support environment
The commitment to a `language framework' would allow the development of powerful tools that were essential to
the engineering process. Apart from a parser, one would need tools to visualise, cross-check, measure and categorise
all or parts of the evolving model. Tools which partially translate to and from other formalisms would be needed to allow easy access/interface to the environment. Tools for pre-processing or compiling models are required. This may include tools that configure a planning system - using the characteristics of the model a tool could choose appropriate planner components to fit into the final system.

What is wrong with the STRIPS/PDDL language as a planning domain modelling language?

The answer seemed to be that it was not equipped with a methodology or language structure that helped the planning domain modeller. STRIPS/PDDL was likened to a ``low level'' language - theoretically expressive but not pragmatically expressive enough. Also, the underlying STRIPS-assumptions were thought to restrict the usefulness of the language.

[Welcome] [Road Map] [Activities] [Archive] [Membership]