DARPA Rome Lab. Planning Initiative
Shared Planning and Activity Representation - SPAR

Part of the DARPA/Rome Laboratory Planning Initiative (ARPI)
This is an initial draft of the SPAR Document.
"Getting as far as we can is the best that we can do"
(Edward Witten, Princeton University, investigator of superstring theory as an explanation of everything)

Version: 0.1
Date: 30-Oct-97
Status: Released to SPAR Review Panels
Request for Comments by: 25-Nov-97
E-mail: spar-core@isi.edu
WWW: http://www.aiai.ed.ac.uk/~arpi/spar

Requirements | Model | Presentations | Discussion | Participants | References | Appendices

Introduction and Aims

It is important that information about processes, plans and activities are sharable within and across organisations. Cooperation and coordination of the planning, monitoring and workflows of the organisations can be assisted by having a clear shared model of what comprises plans, processes and activities. The Shared Planning and Activity Representation (SPAR) is intended to contribute to a range of purposes including domain modelling, plan generation, plan analysis, plan case capture, plan communication, behaviour modelling, etc. By having a shared model of what constitutes a plan, process or activity, organisational knowledge can be harnessed and used effectively. SPAR goes beyond process and and plan interchange formats (such as PIF [Lee et. al., 1996]) in that it is also meant to be a basis for actual representations used in systems for reasoning or computational purposes.

Program Manager perspective on need for SPAR [TG]

The design of SPAR provides structure where there is a consensus on the key entities and relationships amongst those creating and using planning and activity representations. It specifies the structure to a level of detail judged to relate to the needs of the majority of potential users of the representation. However, planning and activity representations are the subject of active research. Some of the current approaches are conceptually simpler or more uniform than SPAR - e.g., using pure logic [Gruninger & Fox, 1994] or all constraint [Etherington, ??; Joslin, 1996; Tate, 1996a] bases. Even where the structure of SPAR itself is not suitable as a basis for novel research or applications, the intention is that the semantics of the SPAR Representation should be clearly defined such that it can be translated to alternative representations. This also provides the important capability that SPAR-represented information will be able to be communicated to future representational frameworks as and when those are adopted in a widespread way.

It is intended that a process for sharing experiences of using SPAR will be established and continuing design issues tracked. A collected volume of papers describing SPAR and relating experience in using, adapting or extending the representation is planned in the medium term.

History

The AI planning community has used explicit domain description languages and plan definitions for more than 25 years [Tate et. al., 1990; Allen et. al., 1990]. As long ago as the late 1960s, work on the STRIPS operator representation of actions [Fikes & Nilsson, 1971] was used to practical effect for planning and control of the SRI Shakey robot. This early application was based upon more theoretical roots in the QA3 theorem prover [Green, 1969] and situation calculus [McCarthy & Hayes, 1969]. There is now a wealth of experience of defining plan representations from both theoretical studies and practical planning. In 1992, under the DARPA/Rome Laboratory Planning Initiative (ARPI) [Fowler et. al., 1995], a number of participants created the KRSL plan language [Lehrer, 1993]. Although this has been used for some transfers of information between planning components within the ARPI (in particular an Integrated Feasibility Demonstration called IFD-2 [Burstein et. al., 1995]), it has not had the widespread impact desired. Its structure was too rigid and KRSL excluded much that was already being done within AI planning research. However, it did establish a range of entities which needed to be in a plan representation and was an influence on subsequent work.

In 1994, a group was formed to create an ontology for plans, using new insights gained over the last few years in the knowledge-sharing community in the US [Neches et. al., 1991; Genesereth & Fikes, 1992; Gruber, 1993] and Europe [Uschold et. al., 1998a; Breuker & van de Velde, 1994]. This led to an outline plan model [Tate, 1996b]. However, this work was not brought to a conclusion.

Since 1995, there have been a number of initiatives to standardise terminology in the subject area of activities and plans. These include enterprise processes in PIF (the Process Interchange Format [Lee et. al., 1996]); workflow (International Workflow Management Coalition [WfMC, 1994]); CASE systems data modelling exchange in CDIF [Ernst, 1997; Navarro, 1996]; manufacturing processes (NIST's Process Specification Language [Schlenoff et. al., 1996]); the Object Model Working Group's CPR (Core Plan Representation - [Pease & Carrico, 1997]); and in the US military planning research community [Kingston et. al., 1997; Valente et. al., 1996]. These initiatives have involved academic, government and industry participants.

In August 1997, DARPA and Rome Laboratory Programme Managers for ARPI proposed a renewed effort to tap into this accumulated expertise, and to create a shared plan representation suitable for use in ARPI and on applied research programmes in their communities. This effort is called the Shared Planning and Activity Representation (SPAR).

SPAR Roots

SPAR is drawing on a wide range of previous work. Plan ontologies and representations created by participants of ARPI-related projects include:

  1. ARPI KRSL 2.0.2 [Lehrer, 1993] as noted above.
  2. ARPI KRSL-Plans ontology [Tate, 1996b] as noted above.
  3. SRI International ACT language from the Cypress project [Wilkins & Myers, 1995] and SIPE's domain description language [Wilkins, 1988].
  4. Edinburgh O-Plan Task Formalism [Tate et. al., 1994;Tate, 1995] and the related <I-N-OVA> constraint model of activity [Tate, 1994; Tate, 1996a].
  5. CMU OZONE scheduling ontology [Smith & Becker, 1997].
  6. CMU Prodigy [Carbonell et. al., 1992] work on decisions made in planning.
  7. ISTI'S IDEON™ Object-Oriented Enterprise Ontology [Madni & Mi, 1997].
  8. The Planning Domain Definition Language (PDDL) [McDermott et. al., 1997] created by a community of researchers wanting to exchange planning challenge problems. PDDL draws on work on expressive planner operator languages in ADL [Pednault, 1989] and hierarchical task network planning [Erol et. al., 1994].
  9. Process Interchange Format (PIF) standard being worked on by a number of projects interested in exchanging process information [Lee et. al., 1996].
  10. USC/ISI work on EXPECT regarding the representation of goals and tasks [Swartout and Gil, 1995], its recent application to structured representations of air campaign objectives [Valente et al., 1996] as well as USC/ISI work on the SENSUS ontology and lexicon [Sensus, ??]. This is work for DARPA to support the Joint Forces Air Component Commander (JFACC) plan representation.
  11. Edinburgh and ISX Corporation work on process models and grammars for describing the actions and products flowing for US JFACC Air Campaign Planning [Kingston et. al., 1997].
It has drawn on the ontologies created on collaborative projects related to Enterprise Modelling and Integration including:
  1. Enterprise Ontology (Edinburgh, Lloyds Register, Logica, IBM UK and Unilever) [Fraser & Tate, 1995; Uschold et. al., 1998b] and the report of the Enterprise Project workshop on "Content, Form and Methods for Ontologies" in May 1994 [Moralee, 1994]. that were provided to the KRSL-Plans, PIF and other communities.
  2. TOronto Virtual Enterprise (TOVE) ontology [Fox et. al., 1993].
In addition, there is relevant work on Structured Analysis and Design Techniques (e.g., SADT [Marca & McGowan, 1988]), Issue-Based Design Methods (e.g., IBIS [Conklin & Burgess-Yakamovic, 1995]), Process Management Models and Methods (e.g., IDEF [NIST, 1993]), Entity-Relationship Modelling [Chen, 1976], Object-Role Modelling (e.g., Nijssen's Information Analysis Method (NIAM) [Nijssen, 1989]), Process Workflow Support, etc.

Since 1994, work within ARPI on plan representations has proceeded in parallel with pre-standards work on process interchange and representation. ARPI researchers have been involved in these activities, and others have supported the continuing ARPI work - including helping in the development and review of SPAR. The relevant standards activities that have been jointly pursued are:

  1. Object Model Working Group (OMWG) Core Plan Representation (CPR) [Pease & Carrico, 1997].
  2. National Institute of Standards and Technology (NIST) Process Specification Language (PSL) [Schlenoff et. al., 1996].
  3. Workflow Management Coalition work in standardising workflow systems and process terminology via their Glossary of Workflow terms [WfMC, 1994] and their interface 1 - the Workflow Process Definition Language (WPDL).
  4. CASE Data Interchange Format (CDIF [Ernst, 1997]) group of the Electrical Industries Association who are standardising data model exchanges between CASE systems in a number of areas including the Project Management, Planning and Scheduling Subject Area [Navarro, 1996].

A common model of processes and activity has emerged from this work and has been used as the basis for SPAR.

Development, Refinement and Review Process

SPAR is being developed in the following way:
  1. The SPAR Core Group has merged existing plan ontology work into a solid core representation as a starting point and will present this at the November 1997 ARPI Workshop.
  2. Via three panels, the Core Group will seek input to the SPAR work, reviews of the representation proposed, and issues raised by it. The panels are:
  3. The Core Group will take the lessons learned in 2 to refine 1, and repeat the process.
  4. The Core Group and others will communicate the work in progress and then promote the availability of the representation to the potential user, technical and standards communities.
  5. The research community will collect experience in the use of SPAR and use lessons learned to refine the representation.
  6. The research community will publish a report on the representation and experience gained.

The Core Group has decided to prioritise the areas of planning and activity representation which it will seek to address in SPAR during its initial development and request for comment review cycles:

  1. Key Plan, Objective, Activity and Agent relationships.
  2. World state or situation descriptions and state of activity execution.
  3. Detailed temporal, resource and actor constraints for scheduling support.
  4. Planning process, workflow, planning capability and problem solving methods representation (sometimes referred to as the "meta-level").
  5. Plan, Plan/Activity Library and Case Library annotations for human and system communication and indexing for retrieval in systems.
  6. Explicit representation of uncertainty.
  7. Soft constraints or preferences, advice and non-boolean evaluation criteria.
  8. Design rationale, issues, argumentation, and decision recording in plans.
  9. Other factors.

[Comments on this prioritisation are sought from reviewers.] [AT]

Requirements

An initial set of representational and functional requirements has been assembled for the SPAR development process. These requirements reflect a wide-ranging set of sources. This set may be used to: help determine the scope and priorities of the project; elicit concepts and constructs; and gauge the adequacy of the SPAR representation.

One of the sources for these requirements includes the results from recent work on process representation. During phase 1 of the development of the National Institute of Standards and Technology's (NIST) Process Specification Language (PSL), a set of requirements were developed that were expected to be satisfied by the end-product language [Schlenoff et. al., 1996; Gruninger et. al., 1997]. These requirements were produced by analysing existing process-centred manufacturing software applications such as scheduling, process planning, and workflow. The approach for phase 2 of the NIST project was to identify existing representations that were believed to address these requirements to some degree. Each representation was then assessed by assigning an evaluation of its coverage for each requirement. A summary of results for a number of DARPA/Rome Laboratory Planning Initiative (ARPI) plan/process and schedule representations (ACT, CPR, <I-N-OVA>, O-Plan TF, OZONE Scheduling Ontology, PIF) has been produced [Polyak & Tate, 97]. Requirements appropriate for SPAR development have emerged from this work.

Requirements were also extracted directly from several of the existing DARPA/Rome Laboratory Planning Initiative (ARPI) plan/process and schedule representations mentioned above as well as from past ARPI shared plan efforts (i.e. KRSL, KRSL-Plans). ARPI member input (e.g. researchers, program managers, etc.) has also played a role in creating the initial set. This input included direct comments on concepts and constructs desired for SPAR, as well as past comments on experience in the design and use of earlier representations (e.g. CPR, KRSL, etc.).

Once the set had been pulled together from these sources, the elements were partitioned into representational and functional categories. Requirements in each category were then clustered into various groupings. The representational requirements define the elements that are needed to express information centred around plan representations, either explicitly or implicitly. The representational groupings are:

The functional requirements define some of the intended uses of a rich, shared plan representation. These uses have been clustered into various categories. Many of these categories overlap in their functionalities but they have been listed separately in order to provide a more balanced presentation of the requirements. These categories are: Additional work on structuring the requirements and refining the list is still required. Core group members are currently evaluating the set with an emphasis on prioritising the elements. The initial, online set of requirements can be found at:

SPAR Model

Scope and Design Principles

The principal scope of SPAR is to represent past, present and possible future activity and the command, planning and control processes that create and execute plans meant to guide or constrain future activity. It can be used descriptively for past and present activity and prescriptively for possible future activity.

The SPAR design has adopted a small number of guiding principles. It seeks to use these principles in a consistent manner.

SPAR Extensions

  1. SPAR allows for extensions:

  2. Concurrent use of multiple such extensions is allowed for to achieve the objective of SPAR to support large scale, distributed representation of plans at multiple levels of detail. These can be used for:

  3. Within the SPAR structure it is possible to specialise the representation through the provision of application, domain or technology specific extensions via Plug-in Grammars with their associated Lexicons of the terms used. This is the level at which current and novel representations of activity and the constraints on activity will be attached. The plug in grammars may draw on standard representations being adopted in the AI planning research community such as PDDL [McDermott et. al., 1997] or more constrained grammars may be specified for practical use in today's applications.

  4. Where further shared structure can be agreed in future within a sufficiently broad community, it could be included in a future revision of SPAR. Where more limited communities representing vendors, specific sector users or research interest groups agree on a shared representation, it is possible to create an extension used within that community using a mechanism such as the PIF "Partially Shared Views" (PSVs) [Lee & Malone, 1990].

    It is possible that a process for communicating and registering Partially Shared View extensions to a broader community could be provided by a suitable standards body (as is intended for PIF [Lee et. al., 1996]).

  5. Any practical use of a planning and activity representation naturally will relate to more detailed models of the objects involved or the organisational relationships between the people or agents included. It is not intended that SPAR itself prescribes structure for detailed object models or for detailed organisation or agent relationship models.

    SPAR can co-exist with one or more such models which can therefore be chosen to reflect standards established elsewhere. An example of a detailed object description standard is that established by International Standards Organisation's STEP [ISO, 1995] or EXPRESS [Express, 1995] for product interchange in manufacturing. Examples of organisational and agent relationships models can be found in the Enterprise Models [Uschold et. al., 1998b; Fox et. al., 1993], the ORDIT Organisational Model [Blyth et. al., 1993], and the work on classifications of agents and their relationships by Doyle at MIT [Doyle, 94].

  6. Conceptually, entities contain properties or attributes of the single entity. Relationships are separate entities in their own right rather than being incorporated into attributes of the entities related. For efficiency of reasoning, an implementation may choose to represent some roles played by entities in common relationships into the attributes of the entities playing those roles.

  7. A number of conceptual entities are provided which cluster other entities into classes. These are convenient for explanation of the model, to improve its communication and translatability to other standards, to improve its modularity, and to allow for some measure of flexibility should detailed parts of the representation be amended in future. An implementation may choose to leave out these conceptual entities.

  8. SPAR may be expressed or represented in a wide variety of ways. This document provides reference designs and implementations for a number of those which will be mostly commonly useful. KIF [Genesereth & Fikes, 1992], Conceptual Graphs [Sowa, 1984], LOOM [Brill, 1993], CDIF [Ernst, 1997] or other representations of SPAR are possible.

  9. SPAR allows for change in its own structure by using nominated environments for models which are tied to SPAR version numbers.

Entities, Relationships, Functions, Attributes, Values and Roles

Entity is a fundamental thing in the domain being modelled. An Entity may participate in Relationships with other entities. A Relationship is an association between two or more entities. It has a specialisation Function, and in turn that can be specialised to Attribute. An attribute of an entity is also referred to as a Property of that entity. An entity that participates in a relationship plays a "role" in that relationship. E.g., the object or agent that participates in the relationship performs (activity, agent) plays the role of being the "performing actor".

World and Environment

The "Real World" is "the domain in which activity takes place". The "World Model" describes, in more or less detail and with more or less accuracy, the "Real World". Part of the space of real world activity is modelled more or less accurately by "Processes" which themselves are specifications of activity. A specification of the activity possible in the real world may or may not be included in the model - with more or less accuracy if included.

An "Environment" contains the world model, including the descriptions of the processes or activity that model includes whether that activity can be planned for or not (i.e. the domain modelled may contain agents whose activity is not directly specifiable). Plans are contained within an environment.

SPAR Model Overview

Activity and State

Activity is an important building block in SPAR. A Plan contains a specification of activity but also has a specification of objectives (themselves related to the agents which hold those objectives).

Activity takes place across an interval defined by its begin and end time points (which may be underspecified) and involving a number of activity-related "objects" (which may be physical or more abstract). A Plan (or plan templates, plan cases, etc.) is defined as a specification of activity associated with one or more objectives. An agent may hold objectives and/or perform activities.

Primitive activity is defined from the perspective of any agent to be an activity whose specification in the model available to that agent does not contain any sub-activities. This allows for more detailed models to be available to some agents than others.

For modelling purposes, an activity may be differentiated into actions and events. An action is an activity which has or could have (in the domain model) an actor. An event is any other activity (which could not have an actor described in the domain model). Events can therefore be thought of as activities which take place in the environment but which are not able to be affected by agents who can intervene in the environment through the performance of actions.

The terminology used to describe past, present and future activity and world state is as follows:

Past StatePresent StatePossible Future State
Past ActivityPresent ActivityPossible Future Activity

Model Overview

A set of statements called the KRSL-Plans description (version dated 20-Sep-96) was used as a starting point for the SPAR model of planning and activity. These were created by the Plan Ontology Construction Group within ARPI. These statements were a refinement of an earlier version dated 2-Feb-95 (published in [Tate, 1996b]). The later version of these statements was also used to provide ARPI participants input to the development of OMWG's Core Plan Representation (CPR). [square brackets are used to indicate phrases or options that were not fully agreed]. The top level statements are:
  1. A PLAN is a SPECIFICATION of ACTIVITY to meet one or more OBJECTIVES.
  2. A SPECIFICATION of ACTIVITY denotes or describes one or more ACTIVITIES.
  3. An ACTIVITY may change the STATES-OF-AFFAIRS.
  4. STATES-OF-AFFAIRS is something that can be evaluated as holding or not. [They can refer to an individual world state (such as NOW), or may refer to world histories, changes between world states, etc.]
  5. An AGENT can perform ACTIVITIES and/or hold OBJECTIVES.
  6. An OBJECTIVE may have one or more EVALUATION-CRITERIA.

    Then at a second level of detail, the statements are:

  7. An EVALUATION-CRITERIA is an ASPECT of [past, present or possible future] STATES-OF-AFFAIRS or an ASPECT of [one or more] PLANS.
  8. An EVALUATION is a predicate (holds/does not hold) or a preference ranking on [one or more] EVALUATION-CRITERIA.
  9. An ACTIVITY takes place over a TIME-INTERVAL identified by its two ends, the BEGIN-TIME-POINT and the END-TIME-POINT. The BEGIN-TIME-POINT is temporally before the END-TIME-POINT.
  10. An ACTIVITY-SPECIFICATION may have CONSTRAINTS associated with it [and its TIME-INTERVAL].
  11. An ACTIVITY-SPECIFICATION may be decomposed into one or more ACTIVITY-DECOMPOSITIONS.
  12. ACTIVITY-DECOMPOSITION: The specification of how an ACTIVITY is decomposed into one or more SUB-ACTIVITIES; this may include the specification of constraints on and between the SUB-ACTIVITIES [and their TIME-INTERVALs].
  13. SUB-ACTIVITY: Sub-activities are the constituent activities designated in any ACTIVITY-DECOMPOSITION.
  14. PRIMITIVE-ACTIVITY is an ACTIVITY with no (further) ACTIVITY-DECOMPOSITION.
  15. CONSTRAINTS can be stated with respect to none, one or more than one time point. They express things which are required to hold. They are able to be evaluated with respect to a specific PLAN as holding or not holding. Such constraints may refer to world statements (conditions and effects), resource requirements and usage, authority requirements or provision, etc.

    Sentences added over and above KRSL-Plans (20-Sep-97): [AT]

  16. An ACTION is an ACTIVITY which has or could have (in the domain model) an ACTOR. An EVENT is any other ACTIVITY (which does not have and could not have an ACTOR described in the domain model).

    Sentences added from OMWG CPR work: [AP]

  17. An AGENT which is the motive force behind an ACTIVITY is called an ACTOR.
  18. An ENTITY which is used, modified, consumed or destroyed during an ACTIVITY is called a RESOURCE.

    Sentences added from NIST PSL work: [AT]

  19. Any TIMEPOINT may be associated with one or more CALENDARS.
  20. A CALENDAR has a nominated begin point and a time unit and may have a nominated end point.

Ontology

The following top level model for SPAR reflects the statements above.

SPAR Model

[Invite panel members comments - Are self referents desirable for Objective, ActivitySpecification, ActivityConstraint and WorldModelSpecification? See issues 0018 and 0021] [AT]

Entity Types

The top level types in SPAR are Activity, TimePoint, Object (and its special sub-type Agent) and Relationship (and its special sub-type Constraint).

SPAR Types Overview

In more detail the SPAR types are as follows (leaving out the basic types needed for values of attributes of the SPAR entities for the moment):

SPAR Types

Value Types

The basic types used to specify values of attributes of SPAR entities are:

SPAR Basic Types

The following framework is adapted from the PIF 1.1 Document [Lee et. al., 1996] with the permission of Jintae Lee, University of Hawaii (jl@hawaii.edu).

A SPAR description consists of a set of entity definitions which may be described in a variety of ways - including in an object-oriented style or in an ASCII language.

Each entity definition refers to an entity instance and is typed (e.g. ACTIVITY, OBJECT, TIMEPOINT) and they form a class hierarchy. An entity definition has a particular set of attributes defined for it. Each of the attributes describes some aspect or property of the entity. For example, a PERFORMS definition has Actor and Activity attributes that specify which Object (or its specialization Agent) is performing which activity. The instance of an entity definition has all the attributes of all of its superclasses, in addition to its own attributes. For example, all the instances of ACTIVITY have the Name attribute, since ENTITY, which is a superclass of ACTIVITY, has the Name attribute.

When an attribute of one entity has a value that refers to another entity, the attribute represents a relationship between the two instances that the two entities refer to. For example, if the BeginTimePoint attribute of ACTIVITY-1 takes TIMEPOINT-32 as its value, then the BeginTimePoint attribute represents a relationship between the ACTIVITY-1 and TIMEPOINT-32 instances. The value of a given attribute in SPAR holds independent of time.

An attribute in a SPAR entity can have as its value the following, and only the following: a literal value of a SPAR basic value type; or an expression that represents such a value type. The SPAR basic value types are primitive or composite value types.

The SPAR primitive value types consist of:

The SPAR composite value types consist of: The attribute value of a SPAR entity holds independent of time (i.e. no temporal scope is associated with an attribute value in SPAR). Any property of an entity which can change over time, should be represented by a RELATION that links the property to a TimePoint (perhaps indirectly).

An EXPRESSION may include variables, quantifiers, and the Boolean operators for expressing conditions or constraints. A STATEMENT (specialization of EXPRESSION) is used in the Constraint attribute of ENTITY, and in a range of ActivityConstraint attributes of ACTIVITY.

An entity variable is a sub-type of expression of the form: entity-name[.attribute-name]*, which refers to either the entity named or the entity which is the value of the named attribute of that entity (recursively).

A variable in an expression may have several different scopes. All such variables with the same name within the same scope are bound to a single entity, whereas that is not necessarily so if the variables occur in different scopes.

  1. An entity.
  2. An ActivitySpecification
  3. A Plan or Process
  4. A World Model
  5. An Environment
NumericSpecification is provided as a predefined STRUCTURE to assist in the specification of uncertain quantities (including the important special case of TimePoint relationship to Calendars).

FieldValueDefault
SpecificationUsually an expression which defines the number or its range. That would be computed as a projected value which is usually derived from the specification by inference. It is separated from the specification in order that the "givens" are maintained separately from the derived values. 
Projected  
MinimumA lower bound on the numeric value. This may be the constant -Omega.-Omega
MaximumAn upper bound on the numeric value. This may be the constant +Omega.+Omega

It is intended that a NumericSpecification structure be allowed as a SPAR value in any place where a numeric expression is allowed.

The Reference Language BNF Language Appendix describes SPAR's recommended syntax, including the syntax of the SPAR basic value type primitive literals as well as the composite value types.

Plug-in Domain Grammars and Lexicons

The specification of a number of entities within the SPAR model are dependent on the application domain within which the model is used. A variety of decisions can be taken as to the level of modelling of the domain, what is to be included and excluded, and the level of accuracy to be built into the model. SPAR provides the ability to define the domain dependent aspects via a number of syntaxes (or grammars) which specify the restrictions on legal statements for a number of SPAR value types (of the attributes of entities). The terminal tokens of the syntax or grammar must be legitimate symbols understood in the domain, or they may be symbols further defined (unambiguously) in any one of a number of domain lexicons associated with a grammar.

SPAR provides a framework for sub-types of a number of the items defined by plug-in syntaxes. In particular those for a set of predefined object types (which are defined in ObjectSpecificationSyntax), and those for sub-types of ActivityConstraint (which are defined in ActivityConstraintSyntax). These recommended sub-types are introduced to provide a higher level of sharing of information. However, in all cases, it is possible to remain at the general level to introduce new ways to describe Objects and ActyivityConstraints.

The SPAR entities which can be defined by one or more domain specific grammars which can be plugged into SPAR are:

  1. ActivityPattern of an Activity - The grammar specifying legal activity-expressions has the following top level structure: (verb [noun phrase]* ).

  2. IssuePattern of an Issue - The grammar specifying legal issues. It is likely that this will be like ActivityPattern but relating to verbs in the planning "process" or meta-level.

  3. ObjectSpecificationSyntax - including specialisations for 3 predefined objects in SPAR:

    SPAR Object Sub-types

  4. ActivityConstraintSyntax - including specialisations for a number of SPAR predefined sub-types of ActivityConstraint.

    SPAR ActivityConstraints

  5. TimeSpecificationSyntax - which has no minimum requirements and may be an empty definition. It could define ways in which probabilistic time specifications, or other time specifications were to be handled.

  6. EvaluationCriterionSyntax - which has no minimum requirements and may be an empty definition. It could define evaluations and their boolean (holds/does not hold) or preference ranking (measures of merit for soft constraints).

  7. AnnotationSyntax - which will have a small minimum set of requirements still to be decided. It could define annotations such as the 20 or so required headers for process descriptions in the Workflow Management Coalition's WPDL (interface 1).See Issue 0005 on a possible Plan-usage annotation minimum requirement.

  8. WorldModelSpecificationSyntax - which has no minimum requirements and may be an empty definition. It can allow atemporal facts (always true), proposition true at a particular time, domain axioms, descriptions of impossible states, etc.

Concurrent Use of Multiple Domain Terminologies

The shared planning and activity representation provides a generic framework in which one or more specific application domain syntax and lexicons can be used for defined items.. It is intended that SPAR support concurrent use of any number of several different disjoint or partially overlapping domain models while still allowing simple models to be created. It will do this by having a single default for each specified syntax associated with the "Environment" entity that encloses all information within the SPAR model or for the "Specification" entities ("ActivitySpecification" and "WorldModel").

To simply exposition in early versions of SPAR and to ensure its adoption in today's simpler applications requiring SPAR, this feature will not be fully elaborated. This will mean that the enclosing "Environment" (or an override via any "ActivitySpecification" or "WorldModel") will define the legal domain syntax and lexicon for enclosed entities. However, in future versions (hopefully in an upward compatible way), any named syntax (and associated lexicons) will be able to be specified for use in the value type of any entity which allows <type>Syntax entries.

Presentations

A number of alternative presentations are envisaged for SPAR. These will include a Reference Object Model and at least one textual Reference Language.

Object Model

As an example of the level at which the Reference Object Model for SPAR will be described, the OMWG Core Plan Representation [Pease & Carrico, 1997] Object Model is shown here. Note that no attempt has been made to rationalise the CPR terminology with that used in SPAR in this diagram.

CPR OO Model

OMGW CPR Meta-model Diagram with Methods

Language

See related issue 0020

Other Presentations

Other presentations planned to be available for SPAR include: KIF [Genesereth & Fikes, 1992], CommonKADS CML [Schreiber et. al., 1994], CORBA IDL [Corba, ??], LOOM [MacGregor et. al., 1997], and Java [Java, ??]. Others have been suggested for CDIF [Ernst, 1997], WWW Consortium's RDF [WWW, 1997], CycL [CycL, ??], etc.

Discussion, Clarification and Issues

Previous and Current Issues

The previous and current issues for SPAR are listed at http://www.aiai.ed.ac.uk/~arpi/spar/#issu. A summary of those outstanding at a specific date are included in each published version of the SPAR document. See Appendix of Issues for Issues Addressed in this Version and Current Issues in this Version. An initial SPAR model version 0.0 was created on 25-Sep-97 at the initial meeting of the SPAR Core Group. It was created using the common elements from the ARPI Plan Ontology Constructor Group (POCG) work on KRSL-Plans (20-Sep-96 version), PIF 1.1, and recent discussions on NIST PSL. Details were added using experience from SRI's ACT, the Edinburgh <I-N-OVA> constraint model of activity and O-Plan TF; the CMU OZONE scheduling ontology; OMWG's CPR version 2 and recent experience of applying it to the JFACC C2 Schema requirements; and USC/ISI work on grammars to describe actions for the JFACC domain.

Subsequent discussions have led to the current version which is open for comment and for issues to be raised.

IDEF Models

IDEF (Integration DEFinition) methods were originally created in the early 1980s at the Wright-Patterson Air Force Base for system modelling purposes. The IDEF family of methods [NIST, 1993] are now widely used within business and government organisations internationally. Therefore, in some organisations, there exist IDEF process models created in the IDEF-0 function modelling method or in the more appropriate IDEF-3 method which was specifically design for process modelling. There are advantages to be gained in terms of capturing planing and process knowledge for organisations, if it is possible to translate in a straightforward way IDEF models into SPAR.

SPAR provides the framework for doing this. As in IDEF-0, SPAR activities have decompositions through the ability to give each an activity specification in terms of sub-activities and the constraints on those activities. IDEF-0 inputs and outputs can be modelled as Objects in SPAR or more sophisticated input and output models can use the WorldStateConstraints in SPAR. The mechanisms of IDEF-0 map directly to the Resources (through ResourceConstraints) and the Objects (normally of subtype Agent which play the role of Performing the Activity (through ActorConstraints). The controls of IDEF are modelled in SPAR as AuthorityConstraints.

Workflow Management Coalition - Workflow Process Description Language (WPDL)

The Workflow Management Coalition's WPDL specifies interface 1 of a range of standards being established by this international consortium of workflow vendors, consultants, users and researchers. It is intended to allow today's workflow tools to interoperate through exchanging information close to that used in current technology workflow support systems. A workshop held by the PIF Group and attended by a representative of Working Group 1 of the Workflow Management Coalition Coalition in July 1996 compared PIF to the WPDL [Tate et. al., 1996]. This showed that although different terminology was used, the basic Activity, Object, Agent, Temporal Constraint, and other Relationships model in PIF (and SPAR) mapped straightforwardly to the draft WPDL available at that time. Some changes in the details of WPDL have taken place since that date.

The main area in which PIF and WPDL differed was the level of specified documentation annotations for processes and other WPDL structures. WPDL has a small number of required annotations and a long list of optional ones. These reflect the documentation attributes used in current workflow tools on the market.

It is anticipated that SPAR will provide a sample WPDL compliant AnnotationSyntax base to be used for expansion for specific uses - called WPDLAnnotationSyntax.

Acknowledgements

The SPAR Project is a part of the Defense Advanced Research Projects Agency (DARPA) and U.S. Air Force Rome Laboratory Planning Initiative (ARPI). The work is supported by ARPI and other participants, and by their host organizations.

The U.S. Government is authorised to reproduce and distribute reprints for governmental purposes notwithstanding any copyright notation hereon. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of DARPA, Rome Laboratory or the U.S. Government.

Credits for Text

Some parts of this document have been derived from existing specifications or ontologies. References are given to the major sources of the design of SPAR in the References section of this document. Extracts from documents of the SPAR Core Group Members are extensive and are not specifically credited.

The description of value types in SPAR is adapted from the PIF 1.1 Document [Lee et. al., 1996] with the permission of Jintae Lee, University of Hawaii (jl@hawaii.edu). A section of the draft NIST PSL's core theory is included in the Formal Theory Appendix with the permission of Christopher Menzel, Texas A&M University (cmenzel@tamu.edu) and KBSI (cmenzel@kbsi.com).

Participants

Participants have been chosen to be familiar with the issues of plan representation and to be able to reflect specific concerns for their "constituency".

Note that an individual's initials is used to track issues relating to SPAR.

Initials Name Organization Representing
Core Group - e-mail spar-core@isi.edu
ATAustin TateAIAI, University of EdinburghTechnical Lead
BSBill SwartoutUSC/ISI 
KMKaren MyersSRI International 
TCTodd CarricoStanford University 
Core Group Support - e-mail spar-core@isi.edu
TGTom GarveyDARPAGovernment Representative
APAdam PeaseTeknowledgeCoordination with User Requirements Panel and Reference Object Model
SPSteve PolyakDAI, University of EdinburghCoordination with Specialism Experts Panel, Formalization Review Panel and Other Commentators
YGYolanda GilUSC/ISI 
User Requirements Panel - e-mail spar-users@isi.edu
BSBill SwartoutUSC/ISIJFACC
KMKaren MyersSRI InternationalJFACC
TCTodd CarricoStanford UniversityAITS, ALP
TGTom GarveyDARPAACCM
YGYolanda GilUSC/ISIJFACC
CEChristopher ElsaesserMitreCOAA
 TBD GENOA
Specialism Experts Panel - e-mail spar-special@isi.edu
APAdam PeaseTeknowledgeRelationship to OMWG CPR
BDBrian DrabbleCIRL, University of OregonQualitative Process Models
DLDDenise L. DraperRockwellUncertainty
DWDarrell WoelkMCCCollaborative Process Management and Workflow
JAJames AllenUniversity of RochesterMulti-modal user dialogue, planning in complex temporal and uncertain worlds
JLJintae LeeUniversity of HawaiiPIF and Process Handbook
LLLarry Laffertyvia ISX CorporationPerformance Issues
MVManuela VelosoCMUCase-based Plans
SPSteve PolyakDAI, University of EdinburghNIST PSL and Plan Design Rationale
SSSteve SmithCMUConstraint-based Scheduling
Formalization Review Panel - e-mail spar-formal@isi.edu
CMChris MenzelKBSI and Texas A& UniversityMFormal Models and IDEF Methods
DEDavid EtheringtonCIRL, University of OregonFormal Models wrt Scheduling and Constraints
JDJon DoyleMITFormal Models and Problem Solving Methods Representation
MGMicheal GruningerUniversity of TorontoFormal Models and TOVE Ontology
MUMike UscholdBoeingFormal Models and Enterprise Ontology
PHPat HayesUniversity of West FloridaFormal Models and Temporal Aspects
Extra Commentators - e-mail spar-interest@isi.edu
AMAzad MadniISTI 
DDDoug DyerDARPA 
DMDrew McDermottYale University 
GWGerhard WicklerDAI, University of Edinburgh 
JFLJohn F. LemmerRome Laboratory 
NFNort FowlerRome Laboratory 
SAStuart AitkenAIAI, University of Edinburgh 
SKSubbarao KhambhampatiArizona State University 
All Participants - e-mail spar-all@isi.edu

The current list of participants is available at http://www.aiai.ed.ac.uk/~arpi/spar/#part.

References

Allen, J.F., 1984. "Towards a General Theory of Action and Time" Artificial Intelligence 23 123-154.

Allen, J.F., Hendler, J. and Tate, A. (eds.), 1990. Readings in Planning Morgan Kaufmann, Palo Alto, CA.

Blyth A.J.C., Chudge, J., Dobson, J.E. and Strens, M.R., 1993. "ORDIT: A new methodology to assist in the process of eliciting and modelling organisational requirements" In Proceedings on the Conference on Organisational Computing Systems, November, 1993, San Jose, CA, USA. http://www.twente.research.ec.org/esp-syn/text/2301.html

Brill, D., 1993. "LOOM Reference Manual v.2.0", Information Sciences Institute, University of Southern California. http://www.isi.edu/isd/LOOM/LOOM-HOME.html

Breuker, J., van de Velde, W., 1994. The CommonKADS Library for Expertise Modelling: Reusable Components for Artificial Problem Solving, IOS Press. http://www.swi.psy.uva.nl/projects/CommonKADS/home.html.

Burstein, M.H., Schantz, R., Bienkowski, M.A., desJardins, M.E. and Smith, S.F., 1995. "The Common Prototyping Environment -- A Framework for Software Technology Integration, Evaluation and Transition" IEEE Expert 10(1) February 17-26, 1995, IEEE Comp. Soc. http://arpi.isx.com

Carbonell, J.G., Blythe, J., Etzioni, O., Gil, Y., Joseph, R., Kahn, D., Knoblock, C., Minton, S., Perez, A., Reilly, S., Veloso, M., and Wang, X., 1992. "PRODIGY4.0: The Manual and Tutorial", Technical Report CMU-CS-92-150, Department of Computer Science, Carnegie Mellon University.

Chen, P.P., 1976. "The Entity-Relationship Model - Toward a Unified View of Data" ACM Transactions on Database Systems 1(1) March 9-36.

Conklin, J. and Burgess-Yakamovic, K., 1995. "A Process-Oriented Approach to Design Rationale" In T. Moran and J. Carroll (eds.) Design Rationale Concepts, Techniques, and Use, Lawrence Erlbaum Associates, Mahwah, N.J., pp. 393-428.

Doyle, J., 1994. Draft Plan Ontology - 11-Oct-94. Unpublished contribution to KRSL-Plans and ARPI POCG. http://isx.com/pub/ARPI/ARPI-pub/krsl/revised-ontology-hierarchy.txt

Ernst, J., 1997. Introduction to CDIF, CASE Data Interchange Format Division Electronic Industries Association. http://www.cdif.org

Erol, K., Hendler, J. and Nau, D., 1994. "UMCP: A Sound and Complete Procedure for Hierarchical Task Network Planning" In Proceedings of the Second International Conference on AI Planning Systems (AIPS-94), Chicago, IL, USA, pp. 249-254.

Etherington, D., 19??. CSP Constraint Representations for Scheduling, Paper and URL to be nominated as a reference. [DE].

EXPRESS Information Modelling Language, 1995. ISO WD 10303-11. http://www.eurpc2.demon.co.uk/part11.html

Fikes, R.E. and Nilsson, N., 1971. "STRIPS: A New Approach to the Application of Theorem Proving to Problem Solving" Artificial Intelligence 5(2).

Fowler, N., Cross, S.E. and Owens, C., 1995. "The ARPA-Rome Knowledge-Based Planning and Scheduling Initiative" IEEE Expert, 10(1) February 4-9, 1995, IEEE Comp. Soc. http://arpi.isx.com

Fraser, J. and Tate, A., 1995. "The Enterprise Tool Set -- An Open Enterprise Architecture" In Proceedings of the Workshop on Intelligent Manufacturing Systems, International Joint Conference on Artificial Intelligence (IJCAI-95), Montreal, Canada. http://www.aiai.ed.ac.uk/project/enterprise/ontology.html

Fox, M.S., Chionglo, J.F. and Fadel, F.G., 1993. "A Common-Sense Model of the Enterprise" In Proceedings of the Second Industrial Engineers Research Conference (IERC) Norcross, GA, Institute for Industrial Engineers. http://www.ie.utoronto.ca/EIL/tove/toveont.html

Genesereth, M.R. and Fikes, R.E., 1992. "Knowledge Interchange Format, Version 3.0 Reference Manual", Knowledge Systems Laboratory, KSL-92-86. http://ksl-web.stanford.edu/KSL_Abstracts/KSL-92-86.html.

Green, C., 1969. "Applications of Theorem Proving to Problem Solving" In Proceedings of the First International Joint Conference on Artificial Intelligence (IJCAI-69), Morgan Kaufmann, pp. 741-747.

Gruber, T., 1993. "Ontolingua: A Translation Approach to Providing Portable Ontology Specifications" Knowledge Acquisition 5(2) 199-200. http://ksl-web.stanford.edu/KSL_Abstracts/KSL-92-71.html.

Gruninger, M., Fox, M.S., 1994. "An Activity Ontology for Enterprise Modelling", Workshop on Enabling Technologies - Infrastructures for Collaborative Enterprises, West Virginia University. http://www.ie.utoronto.ca/EIL/papers/sense.html

Gruninger, M., Schlenoff, C., Knutilla, A. and Ray, S., 1997. "Using Process Requirements as the Basis for the Creation and Evaluation of Process Ontologies for Enterprise Modeling" ACM SIGGROUP Bulletin Special Issue on Enterprise Modelling 3(18).

ISO, 1995. "Product Data Representation and Exchange: Part 49: Integrated Generic Resources: Process Structure and Properties", ISO Standard 10303-49, International Standards Organization. http://www.nist.gov/sc4/www/stepdocs.htm

Joslin, D., 1996. "Planner/Scheduler Interface Proposal", Draft, CIRL, University of Oregon, 17-May-96. http://www.cirl.uoregon.edu/reports/psi.ps.

Khambhampati, S, 1997. "Refinement Planning" AI Magazine, 18(2), pp. 67-97, Summer 1997.

Kingston, J.K., Griffiths, A. and Lydiard, T.J., 1997. "Multi-Perspective Modelling of the Air Campaign Planning Process" In Proceedings of the Fifteenth International Joint Conference on Artificial Intelligence (IJCAI-97), Nagoya, Japan. http://www.aiai.ed.ac.uk/~arpi

Lee, J. and Malone, T., 1990. "Partially Shared Views: A Scheme for Communicating between Groups Using Different Type Hierarchies" ACM Transactions on Information Systems 8(1) 1-26. http://soa.cba.hawaii.edu/pif/

Lee, J. (ed.), Gruninger, M., Jin, Y., Malone, T., Tate, A., Yost. G., and other members of the PIF Working Group, 1996. "Process Interchange Format and Framework, Version 1.1", MIT Center for Coordination Science, Working Paper No. 194. http://soa.cba.hawaii.edu/pif/

Lehrer, N. (ed.), 1993. "ARPI KRSL Reference Manual 2.0.2", ISX Corporation. http://isx.com/pub/ARPI/ARPI-pub/krsl/krsl-info.html

Madni, A. and Mi, P., 1997. "IDEON™ Specification in CORBA IDL", Technical Memo ISTI-TM-7/97, July 17, 1997, Intelligent Systems Technology, Inc., Santa Monica, CA. http://www.intelsystech.com

Marca, D.A. and McGowan C.L., 1988. SADT: Structured Analysis and Design Techniques, McGraw-Hill, New York.

McCarthy, J. and Hayes, P.J., 1969. "Some Philosophical Problems from the Standpoint of Artificial Intelligence" In B. Meltzer and D. Michie (eds.) Machine Intelligence 4, Edinburgh University Press, 463-502.

McDermott, D., 1997. "PDDL - The Plan Domain Definition Language", Computer Science, Yale University. http://www.cs.yale.edu/HTML/YALE/CS/HyPlans/mcdermott.html

MacLean, A., Young, R., Bellotti, V., and Moran, T., 1991. "Design Space Analysis: Bridging from Theory to Practice Via Design Rationale" In Proceedings of Esprit '91}, Brussels, November 1991, pp. 720-730. Moralee, S., 1994. "Notes from Enterprise Project Workshop on Content, Form and Methods for Ontologies", IBM(UK) Offices, Nottingham, UK, Dated 25-Nov-94. http://www.aiai.ed.ac.uk/~bat/ontology-may94.html.

Navarro, T., 1996. "CDIF - Integrated Meta-model - Project Management Planning and Scheduling Subject Area", Report EIA-PN3239, CDIF-DRAFT-PMPS-V04, CASE Data Interchange Format Division, Electronic Industries Association. http://www.cdif.org/overview/ProjectManagement.html

Neches, R., Fikes, R., Finin, T., Gruber, T.R., Patil, R., Senator, T. and Swartout, W.R., 1991. "Enabling Technology for Knowledge Sharing" AI Magazine 12(3) 36-56. http://ksl-web.stanford.edu/KSL_Abstracts/KSL-93-23.html.

Nijssen, G.M. and Halpin, T.A., 1989. Conceptual Schema and Relational Database Design: A Fact-Based Approach, Prentice Hall.

NIST, 1993. "Integrated Definition for Function Modeling (IDEF0)", Federal Information Processing Standards (FIPS) Publication 183, National Institute of Standards and Technology, December 21, 1993. http://www.idef.com

Pease, R.A. and Carrico, T.M., 1997. "Object Model Working Group (OMWG) Core Plan Representation - Request for Comment", version 2, 24 January 1997, Defense Advanced Research Projects Agency. http://www.teknowledge.com/CPR2/

Pednault, E, 1989. "ADL: Exploring the Middle Ground between STRIPS and the Situation Calculus" In Proceedings of the First International Conference on the Principles of Knowledge Representation and Reasoning, pp. 324-332.

Polyak, S. and Tate, A., 1997. "Analysis of Candidate PSL Process/Plan Representations", Artificial Intelligence Applications Institute, AIAI-PR-66, Edinburgh, Scotland. http://www.aiai.ed.ac.uk/publications

Polyak, S. and Tate, A., 1998. "Rationale in Planning: Causality, Dependencies and Decisions" Knowledge Engineering Review To appear, Cambridge University Press.

Rosenbloom, P.S., Laird, J.E., and Newell, A., 1993. The Soar Papers: Readings on Integrated Intelligence, MIT Press, Cambridge, MA. http://www.isi.edu/soar/soar.html

Schlenoff, C. (ed.), Knutilla, A., and Ray, S., 1996. "Unified Process Specification Language: Functional Requirements for Modeling Processes", National Institute of Standards and Technology, Gaithersburg, Maryland. http://www.nist.gov/psl/

Schreiber, G., Weilinga, B., Akkermans, H. and Van de Velde, W., 1994. "CML: The CommonKADS Conceptual Modelling Language" In L. Steels, G. Schreiber and W. Van de Velde (eds.) A future for knowledge acquisition: Proceedings of EKAW-94, Hoegaarden, Belgium, Springer-Verlag. http://www.swi.psy.uva.nl/projects/Kactus/toolkit/cml.html

Smith, S.F. and Becker, M., 1997. "An Ontology for Constructing Scheduling Systems" In Working Notes from 1997 AAAI Spring Symposium on Ontological Engineering, Stanford, CA, AAAI Press. http://www.cs.cmu.edu/afs/cs/project/ozone/www/AAAI_Symp_On_Ontol_97/abstract.html

Sowa, J.F., 1984. Conceptual Structures: Information Processing In Mind and Machine, Reading, MA., Addison-Wesley.

Swartout, B. and Gil, Y., 1995. "EXPECT: Explicit Representations for Flexible Acquisition" In Proceedings of the Ninth Knowledge Acquisition for Knowledge-Based Systems Workshop, February 26-March 3, 1995. http://www.isi.edu/expect/expect-homepage.html

Tate, A., 1994. "A Plan Ontology - a Working Document - October 31, 1994" In Proceedings of the Workshop on Ontology Development and Use, 2nd - 4th November, 1994, La Jolle, CA. ftp://ftp.aiai.ed.ac.uk/pub/documents/1994/94-ont-plan-ontology.ps

Tate, A., 1995. "O-Plan Task Formalism Manual", Version 2.3, July 12, 1995. Artificial Intelligence Applications Institute, University of Edinburgh. ftp://ftp.aiai.ed.ac.uk/pub/documents/ANY/oplan-tf-manual.ps

Tate, A., 1996a. "Representing Plans as a Set of Constraints -- the <I-N-OVA> Model" In Proceedings of the Third International Conference on Planning Systems (AIPS-96), Edinburgh, Scotland, May 1996, AAAI Press, pp. 221-228. http://www.aiai.ed.ac.uk/~oplan/inova.html

Tate, A. (ed.), 1996b. "KRSL-Plans", Appendix of Tate, A, "Towards a Plan Ontology" AI*IA Notizie (Quarterly Publication of the Associazione Italiana per l'Intelligenza Artificiale), Special Issue on "Aspects of Planning Research" 9(1), pp. 19-26. A shorter version of [Tate, 1994]. ftp://ftp.aiai.ed.ac.uk/pub/documents/1996/96-aiia-plan-ontology.ps

Tate, A (reporter) and the PIF Working Group, 1996. "PIF and the Workflow Management Coalition WPDL, Report of Session at the PIF Workshop", Stanford University, 11-Jul-96. http://soa.cba.hawaii.edu/pif/

Tate, A., Drabble, B. and Kirby, R.B., 1994. "O-Plan2: an Open Architecture for Command, Planning and Control" In M. Fox and M. Zweben (eds.) Intelligent Scheduling, Morgan Kaufmann. http://www.aiai.ed.ac.uk/~oplan/

Tate, A., Hendler, J. and Drummond, M., 1990. A Review of AI Planning Techniques, In J. Allen, J. Hendler and A. Tate (eds.) Readings in Planning Morgan Kaufmann, pp. 26-49.

Uschold, M.F., Filby, I.M. and Georges, M., 1998a. "Concepts and Terminology for Knowledge Sharing" Knowledge Engineering Review, Special Issue on Ontologies, To appear, Cambridge University Press. http://www.aiai.ed.ac.uk/project/euroknow

Uschold, M.F., Moralee, S., King, M. and Ziorgios, Y., 1998b. "The Enterprise Ontology" Knowledge Engineering Review, Special Issue on Ontologies, To appear, Cambridge University Press. http://www.aiai.ed.ac.uk/project/enterprise/ontology.html

Valente, A., Swartout, W. R. and Gil, Y., 1996. "A Representation and Library for Objectives in Air Campaign Plans". http://www.isi.edu/expect/inspect.html

Wilkins, D.E., 1988. Practical Planning Morgan Kaufmann. http://www.ai.sri.com/~sipe

Wilkins, D.E. and Myers, K.L., 1995. "A Common Knowledge Representation for Plan Generation and Reactive Execution" Journal of Logic and Computation 5(6) 731-761. http://www.ai.sri.com/~act/act-formalism.html

World Wide Web Consortium, 1997. RDF Metadata Format, Draft 3-Oct-97. http://www.w3.org/Press/RDF

Workflow Management Coalition, 1994. "Workflow Management Coalition Glossary", A Workflow Management Coalition Specification, November, 1994. http://www.wfmc.org

CORBA IDL Reference and URL. To be completed [AP].

Java Reference and URL. To be completed [AP]. http://java.sun.com

CycL Reference. To be completed [AP]. http://www.cycorp.com

Sensus Reference. To be completed [BS]. http://www.isi.edu

Entities | Language | KIF | KADS CML | Object Model | CORBA IDL | LOOM | Java | Formal Theory | Issues | Acronyms | Revision History | Top of Document

Appendices

Detailed Entity Definitions

The SPAR model as presented here is at the conceptual modelling level used in PIF [Lee et. al., 1996] which is typical of ontology description languages such as KIF [Genesereth & Fikes, 1992] and CommonKADS [Breuker & van de Velde, 1994]. CommonKADS Conceptual Modelling Language[Schreiber et. al., 1994] for example has the following structures which correspond to the SPAR model description level used here. Actual KIF, CommonKADS CML and other presentations for SPAR are planned to be available. See the appendices.

ENTITY

Parent Classes: None
Attribute NameValue TypeNo. of ValuesDefaults
NameSymbol0..1Inaccessible Unique Name
AnnotationAnnotationSyntax0..N 
EntityConstraintEntityConstraintExpression0..N 

Attribute Descriptions:

Notes on Usage:
  1. Entity is the root of the all types. It provides the ability to specify Name, Annotations and Constraints for any entity in SPAR.
  2. EntityConstraints: If more than one Constraint expression is provided it is treated as a conjunct of the expressions. [Issue 0007 relates to this]
Efficiency and Implementation Issues:
  1. There can be 0..N constraints. An implementation could insist that there was always a single EntityConstraintExpression which could be a logical expression where a conjunct was required. This might regularise handling of entity constraints in suitable constraint manager implementations.
  2. An implementation may impose limitations on which attributes may contain expressions, or be defined in a general way. If so, there could be a restriction in an implementation that all constraints on and between attributes within the entity are collected in the EntityConstraint attribute.
  3. An implementation could choose to provide both an EntityConstraints and AdditionalAttributes or Properties attribute. The AdditionalAttributes or Property attribute would be restricted to attribute value pairs representing <additional-attribute>(self)=<value>. While EntityConstraints would be restricted to intra-entity constraints.

ENVIRONMENT

Parent Classes: Entity
Attribute NameValue TypeNo. of ValuesDefault
SPARVersionString0..1"Current Version"**
ActivityPatternSyntaxGrammar0..1MinimumActivityPatternSyntax**
IssuePatternSyntaxGrammar0..1MinimumIssuePatternSyntax**
ObjectSpecificationSyntaxGrammar0..1MinimumObjectSpecificationSyntax**
ActivityConstraintSyntaxGrammar0..1MinimumActivityConstraintSyntax**
TimeSpecificationSyntaxGrammar0..1MinimumTimeSpecificationSyntax**
EvaluationCriterionSyntaxGrammar0..1MinimumEvaluationCriterionSyntax**
AnnotationSyntaxGrammar0..1MinimumAnnotationSyntax**
WorldModelSpecificationSyntaxGrammar0..1MinimumWorldModel SpecificationSyntax**
DefaultCalendarCalendar0..1StandardCalendar**
OtherCalendarCalendar0..NNone**

Attribute Descriptions:

Notes on Usage:
Efficiency and Implementation Issues:
  1. Note that all entity attributes are optional. In an implementation which uses fixed syntaxes for the various plug-ins, the environment entity could be omitted.
  2. It is possible to create additional entity structures in an implementation for some of the attributes of existing SPAR entities which are specified by a grammar, rather than processing them internally as an expression in the defined syntax.

ACTIVITY

Parent Classes: Entity
Attribute NameValue TypeNo. of ValuesDefaults
ActivityPatternActivityPatternSyntax1 
BeginTimePointTimePoint0..1A notional TimePoint
EndTimePointTimePoint0..1A notional TimePoint
ActivitySpecificationActivitySpecification0..1 

Attribute Descriptions:

Notes on Usage:
  1. ActivitySpecification may be absent for primitive activities, but if present for a primitive activity, no sub-activities may be included in that specification.
Efficiency and Implementation Issues:
ACTION

Parent Classes: Activity -> Entity
Attribute NameValue TypeNo. of ValuesDefaults

Attribute Descriptions:

Notes on Usage:
  1. Action is an abstract class to differentiate activity where the performing agent can be planned for (action) and activity where it cannot (event). It is provided to assist in clarity of modelling.

Efficiency and Implementation Issues:

  1. An implementation could conjoin activity, action and event.

EVENT

Parent Classes: Activity -> Entity
Attribute NameValue TypeNo. of ValuesDefaults

Attribute Descriptions:

Notes on Usage:
  1. Event is an abstract class to differentiate activity where the performing agent can be planned for (action) and activity where it cannot (event). It is provided to assist in clarity of modelling.

Efficiency and Implementation Issues:

  1. An implementation could conjoin activity, action and event.

TIMEPOINT

Parent Classes: Entity
Attribute NameValue TypeNo. of ValuesDefaults

Attribute Descriptions:

Notes on Usage:
  1. It is possible to specify metric, timeline or calendar dates and times for any given TimePoint using the CalendarTimeConstraint under the plug-in CalendarConstraint facilities. CalendarTimeConstraint provides a relationship between a TimePoint, a Calendar and a specific CalendarTime. The CalendarTime may itself be specified by a NumericSpecification structure with specified, projected, minimum and maximum values.
  2. Relative temporal constraints (such as Before) may be stated via TimeConstraints.

Efficiency and Implementation Issues:

  1. There has been much work on the efficient engineering of time constraint handling in AI planners and beyond. An implementation could insist that the CalendarTimeConstraint Minimum and Maximum are always present such that a real bounding values are always available even where an expression defines the metric time.
  2. Note that CalendarTimeConstraint minumum and maximum times are usually maintained as TimeUnits (integers). They cannot be directly related to a calendar time token or string, but these are not used in the entity attributes themselves. It is normal to convert to a TimeUnit on input and to a CalendarTime token or string only on output to a user.

OBJECT

Parent Classes: Entity
Attribute NameValue TypeNo. of ValuesDefaults

Attribute Descriptions:

Notes on Usage:
  1. A primitive of the representation. Its attributes if defined are outside of the scope of SPAR. They may for example be defined by a product interchange specification such as ISO STEP [Step, ??].
  2. Specific types of defined object are Agent, Location and Calendar.

Efficiency and Implementation Issues:

AGENT

Parent Classes: Object -> Entity
Attribute NameValue TypeNo. of ValuesDefaults
CapabilityAgentCapabilitySyntax0..N 

Attribute Descriptions:

Notes on Usage:
  1. An object may be used anywhere where a perform(activity,object) relationship may be specified. Agent only specialises object in that a capability description is available for agent.

Efficiency and Implementation Issues:

LOCATION

Parent Classes: Object -> Entity
Attribute NameValue TypeNo. of ValuesDefaults
LocationSpecificationLocationSpecificationSyntax1Universe

Attribute Descriptions:

Notes on Usage:
  1. Location entities would normally be used along with an "AtLocation" SpatialConstraint, itself a specialisation of ObjectConstraint.
  2. Note that its attribute is optional, but that the default of "Universe" has the not specifying any SpatialConstraint on the object.

Efficiency and Implementation Issues:

CALENDAR

Parent Classes: Object -> Entity
Attribute NameValue TypeNo. of ValuesDefault
CalendarNameSymbol1 
UnitsOfTimeSymbol0..1Second
BeginTimeCalendarTimeSyntax0..1"BeginOfTime"
EndTimeCalendarTimeSyntax0..1"EndOfTime"

Attribute Descriptions:

Notes on Usage:
  1. [Note that defined structure is provided for Calendars. Instead, we could define its form in a plug in syntax, and not make a shared commitment to any form of Calendar. Comments from reviewers invited.] See Issue 0034. [AT]
  2. TimeUnit are considered as integers. CalendarTimes are strings. Either representation may be used to specify calendar times for TimePoints or other metric time quantities in SPAR.
  3. A number of conversion routines are provided for calendars:
  4. Standard calendars will usually provided for calendar dates set to a particular start date (year, date and time relative to year 0, day 0, 00:00hrs) and times down to the level of a chosen time unit (days, hours, minutes, seconds or some decimal fraction of a second).
  5. As well as the StandardCalendar, other Calendars can be provided for project periods, calendar months from project start time (as date zero), shift periods, etc. A syntax convention will be adopted that allows the StandardCalendar times to be given simply with specific Calendars being able to be named in an upward compatible syntax.
  6. Concurrent use of more than one Calendar is supported in SPAR.
Efficiency and Implementation Issues:
  1. It would be usual to limit the internal representation of a plan or activity in a computer system to use only the integer TimeUnit representation throughout. Conversion to the string form being done on entry to the system, or when an external representation was needed, e.g. for human communication.
RELATIONSHIP

Parent Classes: Entity
Attribute NameValue TypeNo. of ValuesDefaults

Attribute Descriptions:

Notes on Usage:
  1. Relationship is an abstract parent class for more specific relationships such as Plan, Calendar, etc.

Efficiency and Implementation Issues:

  1. An implementation could omit the abstract class.

ACTIVITYCONSTRAINT

Parent Classes: Relationship -> Entity
Attribute NameValue TypeNo. of ValuesDefaults
ConstraintSpecification<constraint-type>ConstraintSyntax1 

Attribute Descriptions:

Notes on Usage:
  1. ConstraintSpecification: states the constraint in a form that is compatible with the appropriate syntax. The cardinality of the attribute is 1 indicating that a single expression is the value of the attribute. It could easily be 1..N meaning that the constraints were a conjunction of the set given. But there are other mechanisms to specify this. It cannot be cardinality 0 as that would negate the reason to have the entity present at all.
  2. Note that Constraint Managers and Domain Description language compilers used in planning systems may be able to use the grammars provided.

Efficiency and Implementation Issues:

  1. An implementation could provide further structure by way of relationships to implement specific syntaxes provided for the constraints.
  2. An implementation might choose not to provide the entity at all, since the expression of the constraint could be added to the higher level entities which add these constraints.

WORLDMODEL

Parent Classes: Entity
Attribute NameValue TypeNo. of ValuesDefaults
HasEnvironmentEnvironment0..N 
SubWorldModelWorldModel0..N 
HasProcessProcess0..N 
HasWorldModelWorldModelSpecification0..N 

Attribute Descriptions:

Notes on Usage:
Efficiency and Implementation Issues:
  1. WorldModelSpecification: HasWorldModelSpecification is TBD. See Issue 0013 & 0014. This could be used to express: domain axioms, always true facts, world state constraints, etc.

WORLDMODELSPECIFICATION

Parent Classes: Entity
Attribute NameValue TypeNo. of ValuesDefaults
HasSpecificationWorldModelSpecificationSyntax0..N 

Attribute Descriptions:

Notes on Usage:

Efficiency and Implementation Issues:

PLAN

Parent Classes: Entity
Attribute NameValue TypeNo. of ValuesDefaults
HasEnvironmentEnvironment0..1Environment nearest in scope
HasObjectivesObjective1..N 
HasIssuesIssue0..N 
HasActivitySpecificationActivitySpecification1..N 

Attribute Descriptions:

Notes on Usage:
  1. Plan is a relationship between one or more objectives and one or more (conjunctive) specification(s) of activity.

Efficiency and Implementation Issues:

PROCESS

Parent Classes: Entity
Attribute NameValue TypeNo. of ValuesDefaults
HasEnvironmentEnvironment0..1Environment nearest in scope
HasActivitySpecificationActivitySpecification1..N 

Attribute Descriptions:

Notes on Usage:

Efficiency and Implementation Issues:

  1. An implementation could conjoin ActivitySpecification and Process, so long as annotation and indexing facilities were provided in the way expected of a process.

OBJECTIVE

Parent Classes: Entity
Attribute NameValue TypeNo. of ValuesDefaults
HasEnvironmentEnvironment0..1Environment nearest in scope
HasEvaluationCriteriaEvaluationCriterion0..N 
HasObjectiveSpecificationActivitySpecification1..N 

Attribute Descriptions:

Notes on Usage:
  1. SPAR is deliberately designed such that the specification of objectives and the specification of activity (including the storage of case plans) is uniform.

Efficiency and Implementation Issues:

ISSUE

Parent Classes: Entity
Attribute NameValue TypeNo. of ValuesDefaults
HasEnvironmentEnvironment0..1Environment nearest in scope
IssuePatternIssuePatternSyntax1 
OptionsTBD0..N 
CriteriaTBD0..N 

Attribute Descriptions:

Notes on Usage:
  1. Issues can be used to store the issues considered and handled and those which still remain to be handled or decided. (if several options exist).
  2. It is likely that plug-in syntax for describing issues, options, criteria (pros, and cons) and decisions will be used.
  3. Design rationale, issues, argumentation, and decision recording in plans [Polyak & Tate, 1998].
  4. Issues are likely to be composed of activities and/or world state and other constraints at a "meta-level" (or process) level. The ActivityPatternSyntax and ActivityConstraintSyntax for a "process" level is likely to specify ways to handle the issues.
  5. Note similarity to SOAR's "Impasse". [Rosenbloom et. al., 1993].
  6. Prodigy [Carbonell et. al., 1992] proposes a number of defined decision or selection mechanisms such as prefer (ordering on options), select (one option) or reject (constrain options).
  7. Can support QOC (Questions, Options, and Criteria) [MacLean et. al., 1991] or IBIS-style [Conklin & Burgess-Yakamovic, 1995] reasoning using argumentation about issue options, pros (arguments for options), cons (arguments against options) and decisions.

Efficiency and Implementation Issues:

EVALUATIONCRITERION

Parent Classes: Entity
Attribute NameValue TypeNo. of ValuesDefaults
EvaluationCriterionSpecificationEvaluationCriterionSyntax0..N 

Attribute Descriptions:

Notes on Usage:

Efficiency and Implementation Issues:

ACTIVITYSPECIFICATION

Parent Classes: Entity
Attribute NameValue TypeNo. of ValuesDefaults
HasEnvironmentEnvironment0..1Environment nearest in scope
SubActivities:Activity0..N 
HasConstraintsActivityConstraint0..N 

Attribute Descriptions:

Notes on Usage:
  1. ActivitySpecification is an important entity since it is the common point at which descriptions of processes, the activity related to a plan, the description of plan cases, plan library schemas and operators, etc is provided.

Efficiency and Implementation Issues:

  1. An implementation could omit the abstract class.

Presentations

Reference Object Model

As an example of the level at which the Reference Object Model will be provided, see the current OMWG Core Plan Representation Request For Comment document [Pease & Carrico, 1997].

OMWG Core Plan Representation - Request for Comment
(http://www.teknowledge.com/CPR2/)

Reference Language BNF

BNF convention used elsewhere in the document is:

The SPAR Language Design has not yet been started. However, some notes from the PIF 1.1 language description [Lee et. al., 1996] are available to provide some initial ideas.

PIF 1.1 Language Notes
(http://www.aiai.ed.ac.uk/~spar/DOCS/pif-language-notes.html)

A number of domain specific grammars can be plugged into SPAR. The language design for these grammars has yet to be defined. However, a set of standard and minimum grammars for the definition of entities are provided (as defaults if no specific syntax is given), and to act as a basis for the development of domain specific grammars. These resources could be made available on-line for developers.

There are some predefined entity instances and constants of the basic types:

TypeStandard InstanceDefinition
ActivityPatternSyntaxMinimumActivity PatternSyntax DefaultActivity PatternSyntax to be determined.
IssuePatternSyntaxMinimumIssue PatternSyntax DefaultIssue PatternSyntax is empty.
ActivityConstraintSyntaxMinimumActivity ConstraintSyntax A description of the <constraint-type> specific syntaxes included. By default this is the MinimumTimeConstraintSyntax and the MinimumObjectConstraintSyntax.
TimeConstraintSyntaxMinimumTimeConstraintSyntax Default TimeConstraintSyntax includes Before (TimePoint, TimePoint) and Duration (Timepoint, Timepoint, TimeUnit). PIF Successor (activity-1, activity-2) can be stated as Before (activity-1.EndTime, activity-2.BeginTime).
TimeConstraintSyntaxAllenTimeConstraintSyntax Allen temporal logic relationships [Allen, 1984]
ObjectConstraintSyntaxMinimumObjectConstraintSyntax Default Object ConstraintSyntax includes equal, not-equal, MinimumAgentCapability ConstraintSyntax, MinimumLocation ConstraintSyntax and MinimumCalendar ConstraintSyntax.
LocationConstraintSyntaxMinimumLocation ConstraintSyntax Default MinimumLocation ConstraintSyntax is empty.
CalendarConstraintSyntaxMinimumCalendarConstraintSyntax Default MinimumCalendarConstraintSyntax includes CalendarTimeConstraint (CalendarTime, TimePoint [,Calendar])
ActorConstraintSyntaxMinimumActorConstraintSyntax Default ActorConstraintSyntax includes perform
ResourceConstraintSyntaxMinimumResourceConstraintSyntax Default ResourceConstraintSyntax is empty
<other-constraint-type>SyntaxMinimum
<other-constraint-type>Syntax
Defaults for other <constraint-type>Syntaxes are empty
AgentCapabilitySyntaxMinimumAgentCapabilitySyntax Default AgentCapabilitySyntax is empty.
Time
SpecificationSyntax
MinimumTime
SpecificationSyntax
Default TimeSpecificationSyntax is empty.
EvaluationCriterionSyntaxMinimum
EvaluationCriterionSyntax
Default EvaluationCriterionSyntax is empty.
AnnotationSyntaxMinimumAnnotationSyntax Default AnnotationSyntax includes MinimumPlanUsage AnnotationSyntax
AnnotationSyntaxWPDLAnnotationSyntax A Syntax for entity annotations which is compatible with the required and optional Workflow Management Coalition WPDL documentation structures [WfMC, 1994]
AnnotationSyntaxWWWRDFAnnotationSyntax A Syntax for entity annotations which is compatible with the metadata descriptors from the WWW Consortium RDF Metadata format. [WWW, 1997]
AnnotationSyntaxMinimumPlanUsage AnnotationSyntax A syntax for a usage annotation for entities including Plan, Plan-Core, Plan-Template, and other standard usage annotations.
WorldModelSpecificationSyntaxMinimumWorldModel SpecificationSyntax Default WorldModel SpecificationSyntax is empty.
CalendarStandardCalendar Default Calendar
TimeUnitEpsilon Smaller than any possible TimeUnit in any possible Calendar
TimeUnitOmega Larger than any possible TimeUnit in any possible Calendar (infinity)
SymbolYearTo specify a time unit of one year
SymbolMonthTo specify a time unit of one month
SymbolWeekTo specify a time unit of one week
SymbolDayTo specify a time unit of one day
SymbolHourTo specify a time unit of one hour
SymbolMinuteTo specify a time unit of one minute
SymbolSecondTo specify a time unit of one second
SymbolMillisecondTo specify a time unit of one millisecond
SymbolNanosecondTo specify a time unit of one nanosecond
Symbol...To specify a time unit of one ...
SymbolUniverseTo specify a Location that has no SpatialConstraints (yet)

Reference KIF

Not included in the current version of the SPAR Document.

Reference CommonKADS CML

Not included in the current version of the SPAR Document.

Reference CORBA IDL

Not included in the current version of the SPAR Document.

Reference LOOM Implementation

Not included in the current version of the SPAR Document.

Reference Java Implementation

Not included in the current version of the SPAR Document.

Formal Theory

As an example of the level at which the formal theory and semantics of SPAR may be expressed, a section of the draft NIST PSL's core theory is available. It is provided by Christopher Menzel, Texas A&M University (cmenzel@tamu.edu) and KBSI (cmenzel@kbsi.com)

Part of the NIST PSL Core - Draft Theory
(http://www.aiai.ed.ac.uk/~arpi/spar/DOCS/psl-core-semantics.html)

Issues

The previous and current issues for SPAR are listed at http://www.aiai.ed.ac.uk/~arpi/spar/#issu. Issues addressed in this revision and current issues are included in the appendices here.

  • Issues Addressed in this Version
  • Issues Remaining in this Version

    Source:

    Issues Addressed in this Version

    Issue No. Version Date Source Raised By Core Handler Others Involved Aim to Resolve Resolved Version
    00010.097-09-25CATATAP,BS,KM,SP,TC0.0a0.0a

    Topic: Initial SPAR model
    Related Issues: None
    Further Details: None

    An initial SPAR model version 0.0 for discussion at meeting 1 of the SPAR Core Group on 25-Sep-97 was created using the common elements from the ARPI Plan Ontology Constructor Group (POCG) work on KRSL-Plans (20-Sep-96 version), PIF 1.1, and recent discussions on NIST PSL. Details were added using experience from SRI's ACT, the Edinburgh <I-N-OVA> constraint model of activity and O-Plan TF; the CMU OZONE scheduling ontology; OMWG's CPR version 2 and recent experience of applying it to the JFACC C2 Schema requirements; and USC/ISI work on grammars to describe actions for the JFACC domain. A number of immediate points were made that needed changing to create an initial model. These changes have been made in version 0.0a.

    The initial diagram created on 25-Sep-97 is available at http://www.aiai.ed.ac/uk/~arpi/spar/IMG/spar-0.0-25sep97.gif

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00020.097-09-25CATATAP,BS,KM,SP,TC0.0a0.0a

    Topic: Explicit inclusion of Resource, Actor/Agent, Space/Location
    Related Issues: 0008, 0035
    Further Details: None

    The subtypes of ActivityConstraint for space/location, resource and actor/agent are ontologically unnecessary as these three are specialized types of the fundamental entities in SPAR. All refer to "objects" in the domain. However, they are considered useful to aid modellers.

    Recommendation: This ontological relationship will be preserved by making spatial, resource and actor constraints be specialisations of ObjectConstraint.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00030.0a97-09-30CATATAP,BS,YG0.20.1

    Topic: Explicit inclusion of issues remaining in a plan
    Related Issues: 0009
    Further Details: None

    Issues remaining in plans and process descriptions are not explicitly included in version 0.0a. They could be available as a separate entity, an attribute of the Plan entity or could be contained in the execution record of the "meta-plan" - the plan which describes the planning process.

    At least include Issues as an attribute of plan with a plug in syntax definition IssueSyntax. Note that if agreement can be reached, it would be possible to include additional structure for Issues as an Issue or IssueSpecification entity instead.

    YG and BS argue that some initial structure for issues or decision points, their options and preferences, selections and rejections should be included in early versions of SPAR to allow the planning decision space to be adequately modelled.

    In many applications, objectives are simply stated. However, to allow for the greatest scope, it is likely that the definition of an Issue would be the same as or similar to that for Objective. Issues are likely to be composed of activities and/or world state and other constraints at a "meta-level" (or process) level. The ActivityPatternSyntax and ActivityConstraintSyntax for a "process" level is likely to specify the issue.

    YG says: I mentioned that a better name may be "impasse", a term taken from the Soar architecture which in turn I believe is taken from the Psychology literature. In Soar you can specify similar things to what you find in PRODIGY (accept, reject, and prefer) and you can also specify indifference.

    Recommendation: Include a new entity Issues with simple initial attributes whose structure will be determined in later versions (perhaps via plug in syntax). Add an extra attribute to Plan for HasIssues.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00050.0a97-09-30CATATKM,TC,AP0.10.1

    Topic: Better term for Plan to reflect range of uses
    Related Issues: None
    Further Details: None

    Is there a better term for "Plan" in the ontology to reflect that it is used for storing partial-plans, fully worked out plans, case-library plans, sub-plan templates, primitive activity descriptions, etc. All relate objectives to an activity-specification.

    We need some appropriate labeling of plans:

    AP adds - I agree for the need to minimize creating new concepts but think that this might be necessary. For example, I believe that plans have imprecision but not uncertainty. The execution record of a plan may have uncertainty. Plan templates have constraints on slot fillers. The difference is not so much in the definition of the different types of plans themselves but rather on the information which fills out the different types of plans. How that is modeled however is an open question.

    AT suggested that we retain the simple term Plan for as the name of the sole entity that associates objectives or purposes with activity specifications or descriptions. The context of use can vary even when a plan is created or maintained for some earlier identified purpose or objective. We do need to associate indexing and intended usage information with the plan description though. AT recommends that any special intended usage is maintained as a nominated "standard" annotation that can be used with the plan entity (and perhaps other entities depending on the final structure adopted in SPAR).

    Recommendation: Retain the entity name Plan. Define a Usage annotation with possible values plan, plan-template, plan-case and other standard uses. A syntax extension as part of AnnotationSyntax could make this a plug-in extendible facility.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00070.0a97-09-30CATATAP0.2 

    Topic: Restriction on use of EntityConstraint attribute of Entities
    Related Issues: None
    Further Details: None

    To reflect the design principle of attributes of entities only relating to properties/attributes of those entities and using separate entities to represent relationships between entities, it is desirable to clearly separate EntityConstraintExpression from a Constraint relationship expression (limited to expressions in the ActivityConstraintSyntax).

    One possibility if to rename EntityConstraint to be Properties. But intra-entity attribute constraints can also be specified.

    Another possibility is to include both Properties and EntityConstraints for each entity to separate additional attributes of form <additional-attribute>(self)=<value> from intra-entity constraints.

    Recommendation: Leave the EntityConstraint name, allow its use for both additional attributes and intra-entity constraints. Note that an implementation could for efficiency separate additional attributes from other entity constraints. Ensure that the design principle is followed, and that this attribute is not misused to state entity relationships of a more general form.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00080.097-09-25CATAT 0.0a0.0a

    Topic: Explicit inclusion of Authority/Control Constraints
    Related Issues: 0002, 0035
    Further Details: None

    A constraint for authority (or a control in IDEF-0 parlance) to perform an action is not included in SPAR 0.0. A direct mapping from IDEF process descriptions to SPAR ones would be facilitated by the explicit inclusion of authority specifications.

    Recommendation: SPAR 0.0a includes AuthorityConstraint as a specialisation of ActivityConstraint.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00160.097-09-25CKMATKM,BS0.2 

    Topic: Should an activity specification have at least one activity included
    Related Issues: None
    Further Details: None

    Should it be mandatory to include at least one activity in an activity specification (1..N rather than the current 0..N in SPAR version 0.0a).

    Recommendation: O..N is necessary to be able to represent specification of activities which do not have any (verb defined) specific activity. (e.g. at a stage of planning or in a final specification of activity.)
    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00170.097-09-25CKMATAP,KM,BS0.0a0.0a

    Topic: Exclusion of Generic Node Type
    Related Issues: None
    Further Details: None

    It was suggested that we only allow activities to be stated in an activity specification rather than allowing a more general class of nodes (activities and a range of "non-activity related" entities such as dummy nodes, and control nodes for split/join, etc). It was also suggested that DummyNode may be able to be handled by constraints among Activities where there are arbitrary hierarchies of Activities.

    A dummy node as used in project management systems and so on is effectively a "do nothing" which is a perfectly valid "verb ..." expression anyway. Special version of these like "start" and "finish" are already in a verb like form "start the execution", "finish the execution".

    Dropping Node does make the explanation of SPAR easier - which will be a good thing for earlier versions anyway. If we find problems later with node like objects we can always come back with a node based scheme. There are some consequences for other related design decisions. It would be wise to allow an activity pattern to be just a verb with no parameters - so "start" would be a legal action, as would "split", "join", "finish". a dummy would be "do nothing".

    Recommendation: The 0.0a model drops Node.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00190.0b97-09-25CATAT 0.10.0b

    Topic: Calendar should be of type object rather than a top level entity
    Related Issues: None
    Further Details: None

    Calendar should probably just be a sub-type of object rather than being directly a sub-type of entity. It is simply another "process-related object". This could allow greater uniformity of handling of SPAR for those implementations that do not require Calendars.

    Recommendation: Include Calendar as a subtype of Object.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00350.0b97-10-15CAPATAP,KM0.0c 

    Topic: Do not make entity commitments for sub-types of constraint
    Related Issues: 0002, 0008
    Further Details: None

    SPAR versions up to 0.0b included specific entities within the SPAR entity type diagram for sub-types of ActivityConstraint (such as time, object, location, agent, resource, authority and other constraint types). This is not in line with the design rationale or the definition of plug in syntaxes for ActivityConstraint. It would limit the flexibility intended for constraint specification in SPAR.

    The sub-types are meant to provide a structure that can be shared and is commonplace in activity modelling. However, the sub-types provided for in SPAR are meant to be included as minimum requirements on some of the default syntaxes provided. The intention is that novel representations can extend these or replace them entirely by defining new sub-types at the more generic level of ActivityConstrait itself.

    Recommendation: Do not include the sub-types of ActivityConstraint as entities. That was a mistake. Amend the diagram for SPAR type appropriately. Include more detail of the SPAR defined sub-types for ActivityConstraint in the definition of the plug in syntax for ActivityConstraint. Include a diagram of the sub-types there.

    Issues Remaining in this Version

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00040.0a97-09-30CAPBSAP,AT0.3 

    Topic: Representing evaluation criteria
    Related Issues: 0003, 0009
    Further Details: None

    Evaluation criteria can be boolean (holds/does not hold) or provide a (preference) ranking (better/worse). Suitable ways to represent such criteria in SPAR are needed. Not sure that we need anything in the object model beyond the notion of Objective, EvaluationCriterion (a function on an Objective) and an Evaluation (which is the relation of a WorldState to an EvaluationCriterion), where the Evaluation may yield an arbitrary result from boolean to partial order to total order.

    YG says: I have some problems with the way that evaluation criteria is defined, same problems I had with the CPR spec of evaluation (not surprisingly, since they have same origin). One of the problems is that "evaluation" may mean different things (validity, measure of achievement or progress during execution), and the document mixes up these meanings and even sometimes takes it to mean comparison (evaluation is different from comparison, where you are considering alternatives and how their individual evaluations compare.)

    YG: I think all these things are evaluations, we just need to be clear on when we talk about which one. I think that seeing them, as the document says, as "boolean or preference rankings" is a very shallow and unnecessarily limited. Also, the current document associates evaluation with an objective. Evaluation criteria may be associated to an objective, a group of objectives, or the overall plan. It can also be associated with activities. You can evaluate a plan and any of its components from all kinds of viewpoints, granularities, and criteria. Evaluations should be tied to choice points where each alternative is evaluated and compared to others before a decision is made.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00060.0a97-09-30CAPAPAT0.2 

    Topic: Explicit inclusion of structure for uncertainty
    Related Issues: None
    Further Details: here

    Uncertainty needs to be represented explicitly within the model. AP suggests that we need a base structure which gives "possible worlds" or consistent hypothesis sets. We'll also need a structure that coexists with the less formal structure. The more formal model will be Bayes Nets that can update the hypotheses according to a mathematical model.

    The 4-tuple NumericSpecification structure is intended to support a wide range of requirements for representations of uncertainty while allowing for a high level of shared meaning to be communicated.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00090.0a97-09-25CTCATTC,BS,AP0.2 

    Topic: Planning process level representation - meta-level or workflow level
    Related Issues: 0003, 0004
    Further Details: None

    How Evaluation (and other planning tasks/functions) fit into the model needs to be explained. These are actions in the "planning process". As well as the more usual representation of a specific plan domain in which actions take place as directed by the plan itself, SPAR can represent the planning process (either generically or for some specific domain planning specialization). It then uses suitable planning process activity verbs (such as "evaluation", "generate", "review", "execute", "schedule") and planning domain objects (such as an "air tasking order", a "plan document", etc). Different domain grammars for activity-expression are in use concurrently in such cases. SPAR must support multiple concurrent use for different domain grammars for activity-expression to allow for process vs. product level uses, and for multiple modelling levels, and structured use of non-shared or partially-shared models.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00100.097-09-25CSPSPAT,KM,BS,AP0.3 

    Topic: Explicit representation of Plan (or Operator) Design or Decision Rationale
    Related Issues: None
    Further Details: None

    Plan design or decision rationale is not allowed for directly in SPAR - other than the hook of allowing annotations on plans and issues. At least structured or semi-structured use of such annotations will be necessary. See [Polyak & Tate, 1998] for a review of the issues.

    YG says: One of the issues that we discussed is how to specify decision points, alternatives, and choices. My suggestion was to use the control language of the PRODIGY planner [Carbonell et. al., 1992], which is quite detailed and useful and has been adopted by other systems. You can specify alternatives for operator choices, bindings, goals to subgoal on, and nodes to expand (there are others but they may not be as generally applicable as these). For each of these choice points, you can specify rejection, selection, and preferences.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00110.0a97-09-25CKMKMSP,AT,BS0.3 

    Topic: Selection criteria and indexing of Plans (also Cases and Operators)
    Related Issues: None
    Further Details: None

    Selection criteria, applicability information, indexing information and advice for retrieval or use of activity templates, cases, plans, etc are not allowed for directly in SPAR - other than the hook of allowing annotations. At least structured use of such annotations will be necessary.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00120.0a97-09-25CKMKMAT0.2 

    Topic: Clearer description of how activity hierarchies are represented
    Related Issues: None
    Further Details: None

    Better explanation is needed of how hierarchies of activities and their parental derivation are visible in the plan representation.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00130.0a97-09-25CKMKMAT0.3 

    Topic: World State descriptions and constraints - open and closed world semantics
    Related Issues: 0014
    Further Details: None

    Need to be clear whether certain types of world state descriptions (and the conditions and effects that utilize those) use close or open world assumptions. See also PDDL's specification of requirements for closed world or open world assumptions. [McDermott et. al., 1997]

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00140.097-09-25CAPAPAT0.3 

    Topic: Details needed for World Model description and States-of-Affairs
    Related Issues: 0013
    Further Details: None

    The issue of world model specification and past, present and future state (static, dynamic and domain events/processes, etc). is underdeveloped in the work to date. Need to represent facts which are always true (as timeless or static), temporal facts (dynamic), domain rules, constraints or axioms, etc.

    KM has pointed out that there is a need to consider the nature of States-of-Affairs, the more specific world model entity, and WorldStateConstraints. World State in AI planners is often narrowly interpreted as state at a specific point in time. States-of-Affairs is intended to be much broader.

    It remains to be established what entities are actually needed and their relationship to States-of-Affairs and to more specific WorldStateConstraints.

    KM states: The distinction between open and closed world state descriptions really applies only to the world state descriptions, not the "conditions and effects that utilize them" (whatever that means). The use of open vs. closed world semantics is really an issue of expediency; similarly, we should include with this issue the notion of `functionality' for predicates (ie, whether a predicate is functionally defined by some subset of its arguments), which is a similar kind of expediency declaration.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00150.0a97-09-25CATBSAT0.2 

    Topic: Explicit inclusion of variables as an attribute of relevant entities
    Related Issues: None
    Further Details: None

    Variables can be used at entity level (by being used inexpressions in attributes, including the Properties extension attribute. Variables may also be associated with any Environment. Variables lists including variable names, restrictions and values may be stated. Should these be separate entities, declared only in plug in syntaxes that use variables (for flexibility), or included as fixed attributes of entity (EntityVariables 0..N) and the environment entity (EnvironmentVariables 0..N).

    Note that not all SPAR uses will include expressions that allow variables. hence it needs to be possible to have simple presentations of SPAR that allow for no variables. It is possible that variables will only appear as an aspect of the plug in syntax for expressions.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00180.0a97-09-25CAPATAP0.2 

    Topic: ActivitySpecification and/or Process may be superfluous
    Related Issues: 0032
    Further Details: None

    ActivitySpecification may be superfluous.

    A possible suggestion is that a definition of (sub-)activities and activity constraints can be added directly as 2 fields of any entity that needs them (such as plan, process, objective, etc) or that the definition of an activity decomposition or specification could be given as two fields of the Activity entity.

    AP believes that Plans have Activities. Those Activities can be decomposed to arbitrary levels. We needn't have any Activities and any Activity that does exist need not be elaborated beyond its name, although it often will be. Objectives point to the Activities which satisfy them and vice versa. Constraints are a separate issue. AP believes that any information in the plan can have constraints. So having a specific Objective might be predicated on the fact that Col Smith was successful in bombing the Basra airfield (an Activity). Specification of the use of a certain Resource might be predicated on the end TimePoint of an Activity being before a certain time.

    SPAR currently treats Activity Specification as a conceptual entity. Some such specifications of activity involve no activities at all, but just impose constraints. Do nothing is a valid activity specification. This allows the specification to be given as the value of the specification or decomposition attribute of the various entities that require it (such as Plan, Process, Objective and Activity).

    The Process entity has as its defining attribute ActivitySpecification. It is possible to combine Process and ActivitySpecification so long as annotation/documentation and indexing facilities are provided on the conjoined entity.

    We would have to accept that a "process" may involve no activities at all, just constraints of various kinds perhaps. We would also have to allow for indexing and annotations of the process/activity-spec combination that were appropriate to all uses. Process would thus become the specification of activity (purposeless) and Plan the relationship of objectives (purposes) to such processes.

    Recommendation for comment by Review Panels:
    Combine Process and ActivitySpecification into a single entity called Process.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00200.0a97-09-25CATBSAT0.2 

    Topic: SPAR Language Presentations
    Related Issues: None
    Further Details: None

    There are two possible routes (at least) for the SPAR language. One would be to take the object/attribute/relation style structure and to simply flatten it. This has some merits for systems that use internal data structures (say an object model) that is close to the SPAR entity definition. The disadvantage of this approach is that reified structures are created which do not structure things in any natural way for human consumption. It also can lead to very large descriptions to say very simple things. KRSL 2.0.2 has such an approach.

    An alternative is to use the the main semantic entities themselves as a basis for the language structure. Things like activity, process, plan, objective, world model, agent, etc. This has the advantage that the descriptions are much more meaningful to humans, and can be readily used in (constraint supporting) editors and the like. This approach is taken in O-Plan TF and SRI's ACT.

    A possibility is to allow for both of these languages in SPAR. This would be compatible with the NIST PSL and CDIF standards notion that multiple "presentations" are possible to communicate a single underlying model.

    AT notes that some communities (e.g. the Workflow Management Coalition) have criticised languages that make heavy use of the Lisp notation (e.g. PIF). Others have criticised C-like languages. Many alternative presentations are possible to meet the preferences of specific communities. However, a keyword based syntax much like Pascal is often used as pseudo-code as it is easily readable. The SPAR Reference Language could perhaps use such a format. It could have major semantic entities defined with a keyword (such as activity, agent, object, plan) and ended by a bracketing end-keyword. It could then have sub-fields (its attributes) defined with a minor key-word with appropriate separators such as "," and ended by ";" for the attributes or sub-fields of the major semantic entity's definition.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00210.0a97-10-01CATATAP0.2 

    Topic: Possible sub-structures for a range of SPAR entities
    Related Issues: None
    Further Details: None

    Should Objective, ActivitySpecification, ActivityConstraint and WorldModelSpecification have an attribute Sub-XXX to themselves. This would allow very simple merging of such specifications and constraint descriptions. The semantics is simple (conjunction of all the constraints in the specifications). But there are other ways to describe this conjunction in the representation already. Is such redundancy desirable?

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00220.0a97-10-03CATAT 0.20.1

    Topic: Clarification of relationship, function, property, attribute and role
    Related Issues: None
    Further Details: None

    A detailed description of suitable the same thing is available in the Enterprise Ontology if alternative text is required [Uschold et. al., 1998b].

    Some means to regularise the terminology used to associate functional or truth values with some relationships may also be required. Recommendation: Do not add this extra detail to the SPAR document.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00230.0a97-10-03CATBSKM,AT,AP0.3 

    Topic: Temporally Scoped Relationships - such as Activity Status
    Related Issues: None
    Further Details: None

    It is possible to add temporally scoped versions of some relevant static attributes to SPAR as new RELATIONSHIPS. In this case, the original static attributes specified in SPAR still hold true for all time.

    An example of one such RELATIONSHIP in SPAR might be ACTIVITY-STATUS which may be used to represent the status (e.g. COMPLETED, DELAYED, PENDING) of an ACTIVITY at different times. ACTIVITY-STATUS is one example of a dynamic property of those entities commonly used in process modeling and workflow systems and modelled in SPAR.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00240.0a97-10-03CATBSKM,AT,AP0.3 

    Topic: Soft Constraints
    Related Issues: None
    Further Details: None

    Soft constraints are yet to be explicitly provided for.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00250.0a97-10-04CATAT 0.3 

    Topic: Extension Mechanism and Registration Process
    Related Issues: None
    Further Details: None

    A mechanism for creating extensions of the SPAR structure beyond the plug-in grammars should be considered. This could use the PIF [Lee et. al., 1996] Partial Shared Views (PSV [Lee and Malone, 1990]) mechanism.

    A mechanism (probably web-based) to propose, accept or register such extensions and have them made available should be considered.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00260.0a97-10-05CATAT 0.3 

    Topic: AuxiliaryConstraints
    Related Issues: None
    Further Details: None

    An entity type called AuxiliaryConstraints could be introduced to cluster all the ActivityConstraints other than Object and TimePoint Constraints which are more fundamental to the model, and which have an influence on the other constraints through object correspondences and temporal relationships. There are specific minimum requirements on Object and TimePoint Constraints whereas the other constraints have no minimum requirements. Clustering them under a single type could make modularity of the structure more easily preserved as advances take place in the unification of approaches to handling constraints in planners and schedulers.

    The terminology of Auxiliary Constraints arises from the treatment of constraints in refinement style planners [Khambhampati, 1997]

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00270.0a97-10-05CATAP 1.0 

    Topic: Translatability to CDIF
    Related Issues: None
    Further Details: None

    It could be worth ensuring that SPAR language syntax can be represented in and communicated through CDIF (http://www.cdif.org).

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00280.0a97-10-05XOLAP 1.0 

    Topic: WWW Consortium RDF for metadata description for publishing SPAR plans on the WWW
    Related Issues: None
    Further Details: None

    OL = Ora Lassila of the WWW Consortium

    Relating to the actual (physical) distribution of plans, ontologies etc., we (the World Wide Web Consortium) have on 3-Oct-97 released the first public draft of a standard proposal for distributed WWW-based metadata [WWW, 1997]. The system could be a basis for building actual knowledge representation systems for the web.

    This could be relevant to SPAR in two ways:

    1. The linearization is very concise and also human-readable - a good model for the SPAR language.
    2. It is relevant for how we might want to think about presenting plans to people and putting plans on web pages. The issue then would be how to aggregate plan information in meaningful ways for web presentation. AP believes that translating a SPAR plan description into RDF itself wouldn't be that hard. He will consider a "publishing" service for the design of the SPAR reference implementation which would present plans as web pages and tag the pages with RDF.

    SPAR could provide a plug in grammar for annotations that allows for markup of a plan for publishing in WWW RDF format (WWWRDFAnnotatonSyntax).

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00290.0a97-10-05CSK,DWBSAT0.3 

    Topic: Use of PDDL as a base for detailed activity and world state models
    Related Issues: None
    Further Details: None

    The SPAR framework may be able to use PDDL [McDermott et. al., 1997] to provide the recommended detailed models for actions constraints (based on HTN - UMCP [Erol, Hendler, and Nau, 1994]) and for situations/state (based on ADL [Pednault, 1989]).

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00300.0a97-10-06CAPAP 1.0 

    Topic: Possible presentation in UML
    Related Issues: None
    Further Details: None

    It could be an advantage to have a clear mapping to the Unified Modelling Language (UML).

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00310.0a97-10-06CBSBSAT0.3 

    Topic: More detailed model for SPAR Object entity
    Related Issues: None
    Further Details: None

    It may be an advantage to use a more expressive object representation in SPAR. There could be benefits in using more sophisticated KR systems, and a lot could be gained by closer coupling between the KR and planning communities. Candidates we should consider would include KIF, Ontolingua, Loom and PowerLoom. All of these are well-documented and widely used representations, so they would providing an existing basis to build upon. Furthermore, using any one of them would help make the SPAR effort more connected with the various ontology efforts that DARPA is supporting. We need to think through what the tradeoffs are in using a more sophisticated representation.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00320.0b97-10-10CAPATAP0.2 

    Topic: Modification to KRSL-Plans 20-Sep-96 Definition in 15 Sentences
    Related Issues: 0018, 0038
    Further Details: None

      The top level KRSL-Plans statements are:

    1. A PLAN is a SPECIFICATION of ACTIVITY to meet one or more OBJECTIVES.
    2. A SPECIFICATION of ACTIVITY denotes or describes one or more ACTIVITIES.
    3. An ACTIVITY may change the STATES-OF-AFFAIRS.
    4. STATES-OF-AFFAIRS is something that can be evaluated as holding or not. They can refer to an individual world state (such as NOW), or may refer to world histories, changes between world states, etc.
    5. An AGENT can perform ACTIVITIES and/or hold OBJECTIVES.
    6. An OBJECTIVE may have one or more EVALUATION-CRITERIA.

      Then at a second level of detail, the statements are:

    7. An EVALUATION-CRITERIA is an ASPECT of [past, present or possible future] STATES-OF-AFFAIRS or an ASPECT of [one or more] PLANS.
    8. An EVALUATION is a predicate (holds/does not hold) or a preference ranking on [one or more] EVALUATION-CRITERIA.
    9. An ACTIVITY takes place over a TIME-INTERVAL identified by its two ends, the BEGIN-TIME-POINT and the END-TIME-POINT. The BEGIN-TIME-POINT is temporally before the END-TIME-POINT.
    10. An ACTIVITY-SPECIFICATION may have CONSTRAINTS associated with it [and its TIME-INTERVAL].
    11. An ACTIVITY-SPECIFICATION may be decomposed into one or more ACTIVITY-DECOMPOSITIONS.
    12. ACTIVITY-DECOMPOSITION: The specification of how an ACTIVITY is decomposed into one or more SUB-ACTIVITIES; this may include the specification of constraints on and between the SUB-ACTIVITIES [and their TIME-INTERVALs].
    13. SUB-ACTIVITY: Sub-activities are the constituent activities designated in any ACTIVITY-DECOMPOSITION.
    14. PRIMITIVE-ACTIVITY is an ACTIVITY with no (further) ACTIVITY-DECOMPOSITION.
    15. CONSTRAINTS can be stated with respect to none, one or more than one time point. They express things which are required to hold. They are evaluable with respect to a specific PLAN as holding or not holding. Such constraints may refer to world statements (conditions and effects), resource requirements and usage, authority requirements or provision, etc.
    KM pointed out that additional structuring may be required.

    AP proposes a set of modifications to the original 15 KRSL-Plans sentences:

    1. A PLAN is a specification of ACTIVITY to meet one or more OBJECTIVES.
    2. [deleted]
    3. EXECUTION of an ACTIVITY may change the WORLD-STATE. (KM had submitted this as #4 but I believe it corresponds more directly to the #3 in the original KRSL sentences)
    4. A STATE-DESCRIPTION is a set of relations that partially describe the WORLD-STATE at some actual or hypothetical point in time. (submitted by KM and renumber as per #3)
    5. An AGENT is an ENTITY which can perform ACTIVITIES and/or hold OBJECTIVES.
    6. An OBJECTIVE may have one or more EVALUATION-CRITERION(s).
    7. An EVALUATION-CRITERION may be applied to WORLD-STATE to create an EVALUATION
    8. An EVALUATION may be a predicate (holds/does not hold) or a partial order
    9. An ACTIVITY takes place over a TIME-INTERVAL identified by its two ends, the BEGIN-TIME-POINT and the END-TIME-POINT. The BEGIN-TIME-POINT is temporally before the END-TIME-POINT. The TIME-INTERVAL, BEGIN-TIME-POINT and END-TIME-POINT need not be specified however. - modified as per KM's
    10. Any PLAN-OBJECT may have CONSTRAINTS associated with it.
    11. An ACTIVITY may include one or more sub-activities.
    12. [deleted]
    13. [deleted]
    14. [deleted]
    15. EVENTs may be specified as required or prohibited in CONSTRAINTS

    AT feels that STATES-OF-AFFAIRS is a more general concept than WORLD-STATE as it is usually interpreted in AI planners.

    Note from AT: The PLAN-OBJECT replacement in sentence 10 is not defined. AP meant that any Entity can have constraints associated with it as in OMWG CPR. The current SPAR model (0.0b) does not recommend using EntityConstraint for relationships such as the type of ActivityConstraint envisaged here.

    AT notes that suggestion 15 isn't consistent with the current SPAR model, but could be if EVENTs is replaced with ACTIVITYs. This raises the more general point in which AP feels that an event is more general than an activity.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00330.0b97-10-11CATAT 0.3 

    Topic: Calendars defined by syntax or by a structure
    Related Issues: None
    Further Details: None

    Calendar is defined in 0.0b as an entity with some attribute structure. It may be desirable to define Calendar (as for location) with a single attribute which is defined by a plug in syntax. The Standard Calendar could then provide the equivalent of the structure currently defined in the Calendar attributes.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00340.0b97-10-12CATAT 0.2 

    Topic: Agenty Capability should be defined as structure or by plug in syntax
    Related Issues: None
    Further Details: None

    The entity for an Agent has specified structure in having a Capability attribute. Is this an overcommitment or is this generally useful to standardise some structure for this? A more general definition would drop the capability attribute and leave the definition of this to a plug in syntax for agent specification which had no minimum requirements.

    Recommendation for consideration by review panel: Retain Capability attribute to provide a minimum shared structure for agent models.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00360.0b97-10-20CBSBSAT,YG0.2 

    Topic: Generalise plug-in to be a conceptual model or ontology rather than grammars
    Related Issues:
    Further Details: None

    The initial SPAR models assumed a BNF-style syntax for plug-in descriptions of various kinds. This could be an inappropriate restriction and reflects just one possible "presentation" of the extension. It may be better to define the plug-ins as being "ontologies", "conceptual models", "descriptions", or "definitions" in a more general way that admits a more appropriate method of communication of their contents.

    Note that a textual BNF-style grammar may still be appropriate. Another possibility is to communicate the plug-in via a BNF-style syntax while requiring that this be based on a well-formed ontology of terms (i.e. the syntax is just a compiled version of the conceptualisation available as a to the meaning of the grammar).

    This will be explored for later versions of SPAR.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00370.0c97-10-17CATAT 0.3 

    Topic: Is a Scalar Type Needed in SPAR Basic Value Types?
    Related Issues: None
    Further Details: None

    It is possible that a scalar type will be needed. Scalars can be used to communicate tight value restrictions in the values for attributes of entities in activity models, e.g. for symbol defined agent capability values perhaps.

    Issue No. Version Date Source Raised By Core Handler Others Involved Target to Resolve Resolved Version
    00380.0c97-10-30CKMKMAT0.2 

    Topic: Are sentences 20 and 21 too detailed for this level of presentation?
    Related Issues: 0032
    Further Details: None

    KM would prefer not to include sentences 20-21 in the description as they are considered too detailed for this level of presentation.

    Acronyms and Abbreviations

    Acronym and ReferenceMeaning
    ACPAir Campaign Planning
    ADLAction Description Language
    AIAIArtificial Intelligence Applications Institute
    ARPIDARPA/Rome Laboratory Planning Initiative
    BNFBackus-Naur Form
    CDIFCASE Data Interchange Format
    CMLConceptual Modelling Language
    CMUCarnegie Mellon University
    CORBACommon Object Request Broker Architecture
    CPRCore Plan Representation
    DARPADefense Advanced Research Projects Agency
    DoDDepartment of Defense
    HTNHierarchical Task Networks
    IBISIssue-Based Information Systems
    IDEFIntegrated DEFinition
    IDEON™ISTI Distributed Enterprise Ontology
    IDLInterface Definition Language
    <I-N-OVA>Issues, Nodes, Orderings/Variables/Auxiliary Constraint Model of Activity
    ISIInformation Sciences Institute
    ISOInternational Standards Organization
    ISTIIntelligent Systems Technology, Inc.
    JFACCJoint Forces Air Component Commander
    JTF ATDJoint Task Force Advanced Technology Demonstration
    KADSKnowledge Analysis and Documentation System
    KBSIKnowledge Based Systems, Inc.
    KIFKnowledge Interchange Format
    KRSLKnowledge Representation Source Language
    MITMassachusets Institute of Technology
    NIAMNijssen's Information Analysis Method
    NISTNational Institute for Standards and Technology
    O-PlanOpen Planning Architecture
    OMWGObject Model Working Group
    PDDLPlanning Domain Definition Language
    PIFProcess Interchange Format
    POCGPlan Ontology Construction Group (of ARPI)
    PSLProcess Specification Language
    PSVPartially Shared Views
    QOCQuestions, Options, and Criteria
    RDFResource Description Framework
    SADTStructured Analysis and Design Techniques
    SIPESystem for Interactive Planning and Execution Monitoring
    SPARShared Planning and Activity Representation
    SRIStanford Research Institute
    STEPSTandard for the Exchange of Product model data
    STRIPSSTanford Research Institute Problem Solver
    TOVETOronto Virtual Enterprise
    UMCPUniversal Method Composition Planner
    USCUniversity of Southern California
    WfMCWorkflow Management Coalition
    WPDLWorkflow Process Definition Language

    Revision History

    Version NumberVersion DateDocument
    0.025-Sep-97 Initial model diagram from SPAR Core Group Meeting 1
    0.0a06-Oct-97 Initial SPAR document prepared by Austin Tate
    0.0b17-Oct-97 Included requirements section from Steve Polyak
    0.130-Oct-97 First RFC to Review Panels

    ARPI Home Page | SPAR Home Page | Top of Document
    AIAI Page maintained by Austin Tate (a.tate@ed.ac.uk) and Steve Polyak (Steve_Polyak@ed.ac.uk),
    Last updated: Fri Apr 28 14:17:48 2000
    Please make contact if you have any comments on these pages or the SPAR Project.