Usage Scenario: Generic Planning Services
Author(s): Austin Tate, AIAI, University of Edinburgh
Domain: Planning
This is an example of a service to support the selection or generation of plans and their reliable execution. There can be a range progressively richer planning services in a single application domain or suitable for many domains, and propvidong services to a single or multiple users.
At its simplest, a planning service can be given a task description in the form of a set of goals, objectives or an outline initial plan, a library of standard operating procedures, process descriptions or "primitive" activities that may be incorporated into the plan and can refine that into a single plan that meets the given requirements within the knowledge available to the planner.
A much richer scenario would involve multiple users in various locations on the Internet collaborating to refine their task specification and requirements, generating multiple options for the plan at different levels of detail, partially executing chosen plans win parallel with their development, and assisting in the repair of plans as circumstances require it.
The language in which the task specification, process library and plans are described can vary but some standards are available such as PDDL and NIST PSL and some projects have well described languages that have been used for many years. A range of simple and more comprehensive content standards for planning services and their inputs and outputs on the web can be expected to appear, but these can be expected to develop considerably in coming years.
URL(s) or other references:
URL(s) or other references:
Automated plan refinement or generation.
Environments in which a goal can be clearly stated and the result can be a single plan to achieve the goal using available services or primitive activities. Examples might be:
Inputs and output formats agreed.
Simple planning use case is a single shot provision of input requirements and constraints and receipt of a single suitable output plan (or indication of failure to find a plan within the constraints specified).
Richer scenarios may involve multiple human and (semi-)automated planners, constraint checkers and simulators working together possibly over prolonged periods to explore multiple options to perform some emerging task and carry out agreed plans to meet the objectives set in the fact of a changing environment.
Other Use Cases will show richer planning scenarios with more users, more automated planning components linked together, multiple options being generated and concurrent partial plan refinement and execution.
Links to other plan related services, such as deconflicting two or more plans using the same resources, could be provided.
Initial task specification, process library and plan representation in some form that can be understod by a domain independent planning service. Examples include PDDL and the <I-N-C-A> ontology used in O-Plan/I-X.
A generic planning service must be able to take inputs and resources which specialise it to a specific domain and specific problem... so the characterisation of the service needs to allow for this type of genericity of I/O. Its not just a specific planer for some tasks in a specific domain where the domain model and its ontology could be assumed. Here we have to use upper ontologies to restrict the input formats that the service can understand and add domain ontologies, gammars and lexicons so that the I/O makes sense between the the client's domain terminaology and the services planning related upper ontology.