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.
Some parts of this document are not yet complete.
Responsibility for parts under development are indicated by [...].
"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)

Sections remaining to complete for version 0.1 by 22-Oct-97:

1. TG - Program manager perspective on SPAR for introduction.
2. BS - Suitable "placeholder" text for the language appendix.
3. AP - Suitable "placeholder" text for 3 appendices.
4. SP - Complete References.
5. SP - Complete Abbreviations and Acronym appendix.

Version: 0.0b Date: 17-Oct-97 Status: Draft Request for Comments by: not set

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 [AT,TG]
• History [AT,AP]
• Development, Refinement and Review Process [AT]
• Requirements [SP]
• SPAR Model [All]
  • Scope [AT,All]
  • Design Principles [AT]
  • Terminology [AT,All]
  • Model Overview [AP,AT]
  • Ontology [AT]
  • Plug-in Domain Grammars and Lexicons [BS,AT]
  • Entity Types [AT]
  • Value Types [AT]
• Presentations [AT]
  • Object Model [AP]
  • Language [BS]
  • Other Presentations [AT]
• Discussion, Clarification and Issues [KM]
• Acknowledgements [AT]
• Participants [AT]
• References [AT]
• Appendices
  • Detailed Entity Definitions
    
  • Presentations
    • Reference Object Model
    • Reference Language BNF
    • Reference KIF
    • Reference CommonKADS CML
    • Reference CORBA IDL
    • Reference LOOM Implementation
    • Reference Java Implementation
  • Formal Theory
  • Issues
    • Previous Issues
    • Current Issues
  • Abbreviations and Acronyms
  • Revision History

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, ??] 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

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., 1998; 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; Swartout et. al., ??]. 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 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].
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. 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].
7. Process Interchange Format (PIF) standard being worked on by a number of projects interested in exchanging process information [Lee et. al., 1996].
8. USC/ISI work on the SENSUS ontology and lexicon, and its recent application to the Joint Forces Air Component Commander (JFACC) plan representation at DARPA [Sensus, ??].
9. Edinburgh and ISX Corporation work on process models and grammars for describing the actions and products flowing for US Air Campaign Planning [Kingston et. al., 1997].

1. Enterprise Ontology (Edinburgh, Lloyds Register, Logica, IBM UK and Unilever) [Fraser & Tate, 1995; Uschold et. al., 1998] 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].

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

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:
   • User Requirements Panel.
   • Specialism Experts Panel.
   • Formalization Review Panel.
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 the 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 probabilistic uncertainty.
7. Soft constraints or preferences, non-boolean evaluation criteria.
8. Design rationale, issues, argumentation, and decision recording in plans [Polyak & Tate, 1998].
9. Other factors.

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

Requirements

One of the sources for these requirements includes the results from recent project 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 this 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 from this work have been incorporated.

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 what was required for other 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:

• Activities
• Agents
• Control Structures/Execution/Simulation
• Domain Knowledge
• Evaluations
• General Structures
• Goals, Requirements, Objectives, Mission, Tasks
• Organisational
• Plans/Schedule
• Rationale
• Resources/Objects
• States
• Time/Space
• Uncertainty/Ambiguity

• Communicating Plan
• Domain Building
• Organisational Support
• Plan Editing/Browsing
• Plan Execution
• Plan/Schedule Generation
• Plan Evaluation/Critique
• Planning System Synthesis
• Task Assignment

• Requirements for a Rich, Shared Plan Representation

SPAR Model

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

1. SPAR allows for extensions:
   • syntax defined values for most of the detail of the model.
   • additional attributes of any entity via EntityConstraints.
   • addition of annotations and attachments to any entity via Annotations.
   • addition of new entities (and relationships) via:
     • addition of arbitrary entities for single application requirements.
     • new entities, relationships and defined additional attributes and annotations via agreements within a nominated community as Partial Shared Views [Lee & Malone, 1990].
     • agreements to incorporate new entities, relationships and defined additional attributes and annotations agreed in the whole community as revisions of the SPAR model (to a new version number).

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:
   • incrementally defined environments (e.g., for distributed handling of abstraction levels). For the avoidance of doubt, note that a single environment's syntax could define any number of abstraction and hierarchical levels for handling in a single model.
   • concurrent environments (e.g. a process and domain level model being used at the same time).
   • concurrent partially overlapping environments (e.g., for functional or spatial specialisation of manipulating the information).

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 [Fraser & Tate, 1995; 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, ??].

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 (Such as Constraint, ActivityConstraint, etc.) 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.

Entities, Relationships, Functions, Attributes, Values and Roles

World and Environment

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.

Activity and State

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 both 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:

Model Overview

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.
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.
16. STATES-OF-AFFAIRS is broadly defined to mean things can be evaluats as holding or not in the [model of the] world. They can refer to an individual world state (such as NOW), or may refer to world histories, changes between world states, etc.

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

17. 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).

    Sentences added from OMWG CPR: [AP]

18. An AGENT which is the motive force behind an ACTIVITY is called an ACTOR.
19. An ENTITY which is used or consumed during an ACTIVITY is called a RESOURCE.
    "used or consumed" needs generalising as these are just two possible relationships that may be stated on objects that are resource role related.

    Sentences added from NIST PSL: [AT]

20. Any TIMEPOINT may be associated with one or more CALENDARS.
21. A CALENDAR has a nominated start point and a timeunit and may have a nominated finish point.

Entity Types

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

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):

Value 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 of 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:

• BOOLEAN: Two possible tokens: true or false.
• NUMBER: A numeric value. The NUMBER type is subdivided into INTEGER and REAL types.
• STRING: A sequence of characters.
• SYMBOL: Symbols are denoted by character sequences, but have different properties than strings. Symbols have referents (e.g. variables and constants) and are not case-sensitive, whereas strings are always case-sensitive.

• STRUCTURE: used to conveying structured information (e.g. for use in the Annotation field of a SPAR entity).
• SET: ?? [AT]
• EXPRESSION: ?? [specialisation is STATEMENT - A logical expression that evaluates to TRUE or FALSE.] [AT]

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

Plug-in Domain Grammars and Lexicons

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 predfined 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 remian 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]* [qualifier]* ).

2. ObjectSecificationSyntax - including specialisations for 3 predefined objects in SPAR:
   
   • AgentCapabilitySyntax - which is required at minimum to contain a definition of an agent's capabilities. See Issue 0034. [Comments sought from Reviewers.] [AT]
   • LocationSpecificationSyntax - which has no minimum requirements and may be an empty definition. It could define ways to define spatial regions, points in space, geographical locations (GEOLOCS), etc.
   • CalendarSpecificationSyntax - not included at present. See Issue 0033. [Comments on this are sought from Reviewers.] [AT]

3. ActivityConstraintSyntax - including specialisations for a number of SPAR predefined sub-types of ActivityConstraint.
   
   • TimeConstraint - which is required, at minimum, to contain definitions of Before and Duration.
   • ObjectConstraint - which is required, at minimum, to contain definitions of equals (codesignation) and not equals (non-codesignation) on two objects. It must also contain the minimum requirements (if any) of all SPAR defined sub-types for object and two sets of nominated role-related object constraints (actor and resource).

     Three sub-types of Object are predefined in SPAR, and thus can have their own nominated constraint sub-syntaxes of ObjectConstraint:

     • AgentConstraint - is a specialised type of ObjectConstraint - which is required, at minimum, to contain a definition of a constraint for specifying agent capability required of the performer of an activity (specified in an ActorConstraint)
     • SpatialConstraint - is a specialised type of ObjectConstraint - which has no minimum requirements and may be an empty definition.
     • CalendarConstraint - is a specialised type of ObjectConstraint - which is required, at minimum, to contain a definition of a CalendarDate constraint between a TimePoint and a Calendar. There will be a default StandardCalendar available which may be referred to in a the CalendarConstraints.

     Two role-related object constraint types are provided in SPAR. An object can act in the role or being an actor or a resource by being brought into certain nominated relationships with an activity. Hence, these two role-related object constraints are defined by sub-syntaxes of ObjectConstraint:

     • ResourceConstraint - which has no minimum requirements and may be an empty definition. It could define constraints such as Resource [Creates,] Uses, Modifies and Destroys for PIF 1.1 compatibility.
     • ActorConstraint - - which is required, at minimum, to contain a definition of perform for an object (normally an agent but not necessarily so) performing an activity.

     It is possible that the ability to specify a domain type (from a domain lexicon) for an underspecified object entity may also be required for high levels of SPAR compliancy.

   • WorldStateConstraint - which has no minimum requirements and may be an empty definition. It can be used to specify legitimate statements to use as (pre-)conditions and /or effects on Activities. Each legitimate entry must contain a statement evaluable in the real world by an evaluation function (holds or not, or in a preference ranking to other plan or real world evaluations).

   • AuthorityConstraint - which has no minimum requirements and may be an empty definition. It could define constraints such as Control or Authority for IDEF-0 model [NIST, 1993] compatibility.

4. 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).
5. 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 extension.

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

Concurrent Use of Multiple Domain Terminologies

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

Object Model

Object Model introduction [AP]
Detail in Appendix.

OMGW CPR Meta-model Diagram with Methods

Language

Other Presentations

Discussion, Clarification and Issues

Previous and Current Issues

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

IDEF Models

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 (IDEF)

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 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

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

Note that an individual's initials are used in SPAR documents to track issues relating to the development of SPAR.

The list of active participants will be included in published versions of this document. [AT]

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

References

Other World Wide Web accessible references and resources can be accessed through the SPAR Resources Area at http://www.aiai.ed.ac.uk/~arpi/spar/#reso

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, 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, IEEE Comp. Soc. http://arpi.isx.com

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., 19??. Rich agent models Reference, MIT. Reference and URL to include. To be completed [AT].

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, 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., Situation Calculus Descriptions of Processes and Activity in TOVE. Paper and URL to be nominated as a reference. [MG].

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/joslin/Papers/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

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

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 te 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.

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/

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

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, W.R., Valente, A. and Gil, Y., 19??. Reference for work on JFACC Objectives and Activity Grammar. Not yet correct [BS]. http://www.isi.edu

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, 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., 1998. "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., 1998. "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

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, 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. http://www.aiai.ed.ac.uk/WfMC/

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 [AP]. http://www.cycorp.com

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

• Detailed Entity Definitions
  
• Presentations
  • Reference Object Model
  • Reference Language BNF
  • Reference KIF
  • Reference CommonKADS CML
  • Reference CORBA IDL
  • Reference LOOM Implementation
  • Reference Java Implementation
• Formal Theory
• Issues
  • Previous Issues
  • Current Issues
• Abbreviations and Acronyms
• Revision History

Detailed Entity Definitions

Entity
Activity
Action
Event
TimePoint
Object
Agent
Location
Calendar
Relationship
ActivityConstraint

Environment
WorldModel
Plan
Process
Objective
EvaluationCriterion
ActivitySpecification
Grammar

The SPAR model as presented here is at the conceptual modelling level 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.

concept <name>
sub-type-of <concept>
properties <name> <value> <default>
...
instance <name>
instance-of <concept>
properties <name> <value>
...
relation <name>
arguments <name> role: <role-name> cardinality: <min>..<max>
...

ENTITY

Parent Classes: None

Attribute Name	Value Type	No. of Values	Defaults
Name	Symbol	0..1	Inaccessible Unique Name
Annotation	AnnotationSyntax	0..N
EntityConstraint	EntityConstraintExpression	0..N

Attribute Descriptions:

• Name: A unique symbol. If not specified, the name can be assumed to be unique within the closest Environment but is not accessible.
• Annotations:
• EntityConstraint: Zero, one or more expressions for constraints on and between attributes of the entity. It can be used for
  • Intra-entity attribute constraints.
  • Attribute constraints (for convenience only as they can also be stated in the expression defining any attribute.
  • Additional attributes (i.e., additional properties of the entity). These can be thought of as being of form <additional-attribute>(self)=<value>. This might link to SPAR structure extensions for example in Partial Shared View structure extensions.

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. Entity Constraints: No reference to other entities is allowed - that is done through specific relationships - including the specialisation to Constraint and ActivityConstraint in particular. If more than one Constraint expression is provided it is treated as a conjunct of the expressions. [Issue 0007 relates to this]

1. There can be 0..N constraints. An implementation could insist that there was always a single EntityConstraintExpression which could be a logical expression wheer a conjunct was required. This might regularise handling of entity constraints in suitable constraint manager implementations.
2. An implementation may impose limtations on which attributes may contain expressions, or be defined in a general way. If so, there could be a restriction in an implementationthat 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 restrictied to intra-entity constraints.

ACTIVITY

Parent Classes: Entity

Attribute Name	Value Type	No. of Values	Defaults
ActivityPattern	ActivityPatternSyntax	1
BeginTimePoint	TimePoint	0..1	A notional TimePoint
EndTimePoint	TimePoint	0..1	A notional TimePoint
ActivitySpecification	ActivitySpecification	0..1

Attribute Descriptions:

• ActivityPattern: as specified by the syntax in use (from the nearest Environment).
• BeginTimePoint: If not specified, a notional TimePoint is associated with this attribute and this may be referred to as <activity>.BeginTimePoint.
• EndTimePoint: If not specified, a notional TimePoint is associated with this attribute and this may be referred to as <activity>.EndTimePoint.
• AcitivitySpecification:
• Annotation: See Issue 0005. A Usage attribute with values plan, plan-template, plan-case, and other standard uses may be defined. A syntax extension as part of AnnotationSyntax could make this a plug-in extendible facility.

1. ActivitySpecification may be absent for primitive activities, but if present for a primitive activity, no sub-activities may be included in that specification.

Attribute Descriptions:

• No attributes.

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 Name	Value Type	No. of Values	Defaults

Attribute Descriptions:

• No attributes.

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 Name	Value Type	No. of Values	Defaults
UsesCalendar	Calendar	0..1	Calendar nearest in scope
MinimumTime	TimeUnit	0..1	-Omega
ProjectedTime	Expression in ProjectedTimeSpecificationSyntax	0..1
MaximumTime	TimeUnit	0..1	+Omega

Attribute Descriptions:

• UsesCalendar: if not specified, the calendar that is nearest in scope is used. This can be set at the ActivitySpecification, Plan/Process or Environment entities.
• MinimumTime: a lower bound on the TimeSpecification in TimeUnits (integers). May use the constant -Omega.
• ProjectedTime: a hook for a wide range of time related information attachment - provided to offer more structure rather than using the Annotations of the entity. The plug-in grammar for ProjectedTimeSpecificationSyntax allows the structure used to be made explicit and controlled. This may be used for probablistic time representations, for statistical or mathematically defined likely time forecasts, for discrete time/probability histograms, etc. It may be used in simpler applications as a mean or expected time for the TimeSpecification.
• MaximumTime: an upper bound on the TimeSpecification in TimeUnits (integers). May use the constant +Omega.

Efficiency and Implementation Issues:

1. Note that minumum and maximum times are maintained as TimeUnits (integers). They are directly relatable 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.
2. There has been much work on the efficient engineering of time constraint handling in AI planners and beyond. An implementation could insist that the MinimumTime and the MaximumTime are always present (cardinality 1) and that a real value is always available even where an expression defines time. Such implementations could add another two attributes for the IntegerMinimumTime and IntegerMaximumTime, or use the ProjectedTime for the expression bearing attributes.

OBJECT

Parent Classes: Entity

Attribute Name	Value Type	No. of Values	Defaults

Attribute Descriptions:

• No attributes defined.

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 Name	Value Type	No. of Values	Defaults
Capability	AgentCapabilitySyntax	0..N

Attribute Descriptions:

• Capability: is used to represent capabilities or skills of the agent in a format specified by the plug in syntax.

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 Name	Value Type	No. of Values	Defaults
LocationSpecification	LocationSpecificationSyntax	1	Universe

Attribute Descriptions:

• LocationSpecification: is used to represent a location or spatial region in a format specified by the plug in syntax for LocationSpecification. This is a specialised part of the ObjectSpecificationSyntax.

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 Name	Value Type	No. of Values	Default
CalendarName	Symbol	1
UnitsOfTime	Symbol	0..1	Second
BeginTime	CalendarTimeSyntax	0..1	"BeginOfTime"
EndTime	CalendarTimeSyntax	0..1	"EndOfTime"

Attribute Descriptions:

• CalendarName: symbol
• TimeUnit: symbol from Year, Month, Week, Day, Hour, Minute, Second, Millisecond, Nanosecond, ...
• BeginTime: string in format "yyyy-mm-dd hh:mm[:ss[.d[d]*]]" or the special strings "BeginOfTime" or "EndOfTime".
• EndTime: string in format "yyyy-mm-dd hh:mm[:ss[.d[d]*]]" or the special strings "BeginOfTime" or "EndOfTime".

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:
   • CalendarTimeToTimeUnit conversion function: string -> integer
   • TimeUnitToCalendarTime conversion function: integer ->string
   • IntervalTimeUnitToCalendarTime conversion function: integer,integer -> string
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.

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.

Attribute Descriptions:

• No attributes.

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 Name	Value Type	No. of Values	Defaults
ConstraintSpecification	<constraint-type>ConstraintSyntax	1

Attribute Descriptions:

• ConstraintSpecification: Normally an expression in <constraint-type>Syntax.

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 struture 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.

ENVIRONMENT

Parent Classes: Relationship -> Entity

Attribute Name	Value Type	No. of Values	Default
SPARVersion	String	0..1	"Current Version"**
ActivityPatternSyntax	Grammar	0..1	MinimumActivityPatternSyntax**
LocationSpecificationSyntax	Grammar	0..1	MinimumLocationSpecificationSyntax**
AgentCapabilitySyntax	Grammar	0..1	MinimumAgentCapabilitySyntax**
ActivityConstraintSyntax	Grammar	0..1	MinimumActivityConstraintSyntax**
EvaluationCriterionSyntax	Grammar	0..1	MinimumEvaluation CriterionSyntax**
AnnotationSyntax	Grammar	0..1	MinimumAnnotationSyntax**
ProjectedTime SpecificationSyntax	Grammar	0..1	MinimumProjectedTimeSpecificationSyntax**
DefaultCalendar	Calendar	0..1	StandardCalendar**
OtherCalendar	Calendar	0..N	**

Attribute Descriptions:

• ** Note that the default is the last value in any defined slot in the Environment which is nearest in scope, unless this is the top environment in which case the default shown applies.
• SPARVersion: a string representing the version of SPAR assumed by the entities within the scope of the environment. This allows for variations in the representation in future, including radical reorganisation should that prove necessary.

  It may be necessary to include declaration of additional SPAR add-on structures (though not grammars) if these are allowed (e.g., by a mechanism such as PIF's Partial Shared Views). If so the cardinality of the slot may be O..N rather than 0..1, or the string may be given a defined syntax to allow for optional PSV lists.

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.

WORLDMODEL

Parent Classes: Relationship -> Entity

Attribute Name	Value Type	No. of Values	Defaults
SubWorldModel	WorldModel	0..N
HasProcess	Process	0..N
WorldStateConstraint	WorldStateConstraintSyntax	0..N

Attribute Descriptions:

• SubWorldModel: is provided to allow for a whole set of world model "libraries" to be built up and combined as needed:
  • separate domain models that can be handled concurrently (e.g. a process level and domain level model in use at the same time).
  • libraries of processes can be separately built and composed as needed.
  • Past activity descriptions can be maintained and incorporated as necessary (e.g., for situation assessment or temporal question answering).
• HasProcess:
• WorldStateConstraint:

PLAN

Parent Classes: Relationship -> Entity

Attribute Name	Value Type	No. of Values	Defaults
HasEnvironment	Environment	0..1	Environment nearest in scope
HasObjectives	Objective	1..N
HasActivitySpecification	ActivitySpecification	1..N

Attribute Descriptions:

• HasEnvironment: May provide one or more local syntaxes/grammars to override the previous outer scope.

1. Plan is a relationship between one or more objectives and one or more (conjunctively) specification(s) of activity.

Efficiency and Implementation Issues:

PROCESS

Parent Classes: Relationship -> Entity

Attribute Name	Value Type	No. of Values	Defaults
HasEnvironment	Environment	0..1	Environment nearest in scope
HasActivitySpecification	ActivitySpecification	1..N

Attribute Descriptions:

• HasEnvironment: May provide one or more local syntaxes/grammars to override the previous outer scope.
• HasActivitySpecification:

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: Relationship -> Entity

Attribute Name	Value Type	No. of Values	Defaults
HasEnvironment	Environment	0..1	Environment nearest in scope
HasEvaluationCriteria	EvaluationCriterion	0..N
HasObjectiveSpecification	ActivitySpecification	1..N

Attribute Descriptions:

• HasEnvironment: May provide one or more local syntaxes/grammars to override the previous outer scope.
• ObjectiveSpecification: is done using one or more ActivitySpecification(s) which may specify activities to be performed or constraints to be satisfied, or any combination of these in as complex a manner as desired.

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:

EVALUATIONCRITERION

Parent Classes: Relationship -> Entity

Attribute Name	Value Type	No. of Values	Defaults
EvaluationCriterionSpecification	EvaluationCriterionSyntax	0..N

Attribute Descriptions:

• EvaluationCriterionSpecification: an expression in the plug in syntax describing evaluations and their measures of merit.

Efficiency and Implementation Issues:

ACTIVITYSPECIFICATION

Parent Classes: Relationship -> Entity

Attribute Name	Value Type	No. of Values	Defaults
HasEnvironment	Environment	0..1	Environment nearest in scope
SubActivities:	Activity	0..N
HasConstraints	ActivityConstraint	0..N

Attribute Descriptions:

• HasEnvironment: May provide one or more local syntaxes/grammars to override the previous outer scope.
• SubActivities:
• HasConstraints:

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.

GRAMMAR

Parent Classes: Entity

Attribute Name	Value Type	No. of Values	Defaults
BNFSyntax	Structure?	1

Attribute Descriptions:

• BNFSyntax: type and structure to be defined

Efficiency and Implementation Issues:

Presentations

Reference Object Model

Reference Language BNF

• [...]   0 or 1 occurrences.
• [...]* 0, 1 or more recurrences.

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

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:

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

Previous and Current Issues