PIF 1.1 Language Notes

Notes extracted from PIF 1.1 Document
Jintae Lee (editor).

A PIF process description consists of a set of frame definitions ( cf. Appendix I and II), which are typically contained in a file. Each frame definition refers to an entity instance and is typed (e.g. ACTIVITY, OBJECT, TIMEPOINT) and they form a class hierarchy (see Figure 1). A frame definition has a particular set of attributes defined for it. Each of the attributes describes some aspect of the entity. For example, a PERFORMS definition has an Actor and an Activity attributes that specifies who is performing which activity. The instance of a frame 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 frame has a value that refers to another frame, the attribute represents a relationship between the two instances that the two frames refer to. For example, if the Begin attribute of ACTIVITY-1 takes TIMEPOINT-32 as its value, then the Begin attribute represents a relationship between the ACTIVITY-1 and TIMEPOINT-32 instances. The value of a given attribute in a PIF file holds independent of time. Figure 2 depicts the relationships among the PIF classes. Section 5 describes all of the current PIF classes. When an attribute of one frame has a value that refers to another frame, the attribute represents a relationship between the two instances that the two frames refer to. For example, if the Begin attribute of ACTIVITY-1 takes TIMEPOINT-32 as its value, then the Begin attribute represents a relationship between the ACTIVITY-1 and TIMEPOINT-32 instances. The value of a given attribute in a PIF file holds independent of time. Figure 2 depicts the relationships among the PIF classes. Section 5 describes all of the current PIF classes. A PIF process description consists of a set of frame definitions ( cf. Appendix I and II), which are typically contained in a file. Each frame definition refers to an entity instance and is typed (e.g. ACTIVITY, OBJECT, TIMEPOINT) and they form a class hierarchy (see Figure 1). A frame definition has a particular set of attributes defined for it. Each of the attributes describes some aspect of the entity. For example, a PERFORMS definition has an Actor and an Activity attributes that specifies who is performing which activity. The instance of a frame 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 frame has a value that refers to another frame, the attribute represents a relationship between the two instances that the two frames refer to. For example, if the Begin attribute of ACTIVITY-1 takes TIMEPOINT-32 as its value, then the Begin attribute represents a relationship between the ACTIVITY-1 and TIMEPOINT-32 instances. The value of a given attribute in a PIF file holds independent of time. Figure 2 depicts the relationships among the PIF classes. Section 5 describes all of the current PIF classes.

Appendix I: PIF Syntax

The syntax of PIF adopts that of KIF (Knowledge Interchange Format, see (Genesereth and Fikes, 1992)). KIF is a language that has been developed by the Interlingua Working Group, under the DARPA (Defense Advanced Research Projects Agency) Knowledge Sharing Initiative (Neches et al., 1991), to facilitate knowledge sharing. Its features include: formally defined declarative semantics, expressive power to represent knowledge required for a typical application knowledge base, and a structure that enables semi-automatic translation into and out of typical representation languages. PIF also adopts the frame syntax, which is an extension of the KIF syntax for representing object-based knowledge. Figure 5 shows the BNF for the frame syntax.

There are several reasons why PIF adopts KIF syntax:

KIF syntax is based on Lisp (Steele, 1990), but little in KIF requires subscription to the Lisp philosophy. We could view the KIF syntax simply as a standard way of specifying a structured list of information. PIF uses a simplified version of the KIF syntax (Cf. Appendix I) .

A PIF file begins with a version number of the PIF being used, followed by a description of the class hierarchy for objects in the file, and then by descriptions of all of the object instances. Figure 5 shows the BNF grammar for PIF expressions. The grammar uses the common conventions that non-terminals are enclosed in angle brackets, * denotes zero or more repetitions, + denotes one or more repetitions, optional items are enclosed in square brackets, vertical bars separate alternatives, place holders for primitive literals are in uppercase (for example, NUMBER), and everything else is a literal constant. A PIF expression is case-insensitive. Appendix C contains a very simple example PIF file.

(define-frame 
      :own-slots (()*)
      :template-slots (()*)
      )

    :== ( +)
    :== ( +)
    :== 
    
  :==  |  |  |  |  
    :== ({ ( )}+)
    :== cf. Figure 6.

 :== symbol naming a class, relation, function, or object
 :== symbol naming a binary relation or unary function 
 :== symbol naming a slot constraint relation, such as SLOT-VALUE-TYPE

Figure 5.  The BNF for the PIF Frame Syntax (taken and modified from
           the Ontolingua Frame Syntax)
:OWN-SLOTS - slots on the object itself, as opposed to the instances of a class. If the object is a class, then own slots describe relationships and properties of the class as a whole, such as its superclasses and documentation. If the object is an instance, then own slots describe properties of the object, including the relation instance-of.

Own slots are binary relations applied to frames, with the frame inserted as a first argument. For example,

    (define-frame frame-1
      :own-slots ((instance-of class-2)))
translates to the KIF sentence
     (instance-of frame-1 class-2)
:TEMPLATE-SLOTS - only make sense if the frame is an instance of CLASS, because template slots describe properties of instances of the class. For example, the template slot spec

     (slot-2 (SLOT-VALUE-TYPE type-3))
for the frame class-1 translates to the KIF sentence
     (slot-value-type class-1 slot-2 type-3)
which is a second-order way of saying
     (forall ?c (=> (and (instance-of ?c class-1)
                         (defined (slot-2 ?c)))
                    (instance-of (slot-2 ?c) type-3)))
A value of a template slot is a downward inherited value (it is a slot value for all instances of the class). For frame class-1, the template slot spec
     (slot-2 value-3) translates into the KIF sentence
     (inherited-slot-value class-1 slot-2 value-3)
The following set of facets are recognized by PIF: SLOT-CARDINALITY SLOT-VALUE-TYPE. PIF allows two kinds of comments: The primitive literal types in the grammar are NUMBER, STRING, SYMBOL, and PIF-SENTENCE. NUMBER, STRING, and SYMBOL are defined very much like the corresponding concepts in the Common Lisp programming language (Steele, 1990).

An object variable is of the form, OBJECT[.SLOT*]. If there is no slot specified, i.e. OBJECT, then it refers to the object by that name. If there is a single slot specified, i.e. OBJECT.SLOT, then it denotes the slot value of the object. If there are two slots specified, i.e. OBJECT.SLOT-1.SLOT-2, then it denotes the slot value of an object which is the slot value of the object if there are two slots specified. And so on with multiple slots specified. If the object is SELF, it refers to the object within which the object variable is used.

A PIF-SENTENCE is a logical expression for representing different constraints for PIF objects and relations. Within the PIF-CORE, a PIF-SENTENCE is used in the following ways:

For the PIF-CORE, this class is restricted to sentences composed of terms with variables and logical connectives. Syntactically, a PIF-SENTENCE is a restricted class of KIF sentences. Figure 6 shows the BNF specification of PIF-SENTENCE:
 ::=   |
                
  ::= ( *) |
               ( * )
 ::=   (not ) |
                (and *) |
                (or *) |
                (=> * ) |
                (<=>  )
     ::=  | 
 ::= ? | [.]*
 ::= SYMBOL 
::= SYMBOL 
 ::= ; There is no function constant in the PIF-CORE but
                 extensions of the PIF-CORE are expected to introduce
                 their own constants.  
 ::= + | - | = | <> | > | < | <= | <=  ;
                 These eight symbols exhaust the relation constants
                 in the PIF-CORE but extensions of the PIF-CORE are
                 expected to introduce their own constants.

 ::=  |  |  | 

Figure 6.  BNF Specification of PIF-SENTENCE
The PIF-CORE makes a specific assumption about the quantifiers and the scope of variables in a PIF-SENTENCE. This assumption is characterized below along three dimensions in the treatment of variables. Each of these dimensions can be considered to be a set of design choices that are adopted within The PIF-CORE or some PSV module. The class of KIF sentences corresponding to PIF-SENTENCE within a given PSV module is defined by the particular design choices adopted within the module.

  1. All variables within a PIF-SENTENCE must be quantified either universally (in which case the sentence must be satisfied for all values of the variable) or existentially (in which case the sentence must be satisfied for some value of the variable). The issue to be addressed in the syntactic specification of PIF-SENTENCE is whether or not to explicitly include quantifiers, since many process ontologies do not include explicit quantifiers. In addition, the presence of quantifiers within an expression would require more sophisticated translators for parsing arbitrary KIF sentences.

    Within the PIF-CORE, we adopt conventions for the use of quantifiers in a PIF-SENTENCE. Variables that appear in the Precondition and Postcondition slots of ACTIVITY or in the If slot of a DECISION activity are assumed to be implicitly existentially quantified. Variables that appear in the Constraints slot of an ENTITY are assumed to be implicitly universally quantified.

    Additional PSV modules can allow for explicit quantification and richer expressiveness.

  2. The second dimension defines the scope of the variable within the PIF-SENTENCE. For example, three options along this dimension are: i) the scope of a variable is restricted to the object in whose slot it appears; ii) the scope of the variable is (syntactically) specified; iii) the scope of the variable is global over the set of objects in a PIF file.

    Within the PIF-CORE, we assume that the scope of a variable is the object, that is, that the variables of the same name within a frame definition are bound to the same values, whereas variables of the same name may be bound to different values if they appear in different frames.

  3. The third dimension defines how variables are allowed to be used:
    1. variables only refer to slot values;
    2. variables can refer to arbitrary objects in the PIF file; examples of this is a constraint such as "All agents must clean their work area after completing their activities," and "All purchase orders must be approved by the finance supervisor before being sent out."
Within the PIF-CORE, a PIF-SENTENCE is a constraint that is local to the frame definition in which it appears.

The define-hierarchy construct that appears at the beginning of every PIF file is used by the Partially Shared Views (PSV) translation scheme described in Section 6. The PSV scheme must be able to determine the parent classes of any classes that a given translator does not know how to translate. A define-hierarchy construct has the form (define-hierarchy LIST) where LIST is a nested list of class ids. The first id in the list is the id of the root class (ENTITY, in PIF). The remaining elements are sub-hierarchy definitions, in the same form.

A leaf class can be denoted either by a symbol or by a list with no subhierarchy definitions.