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.
There are several reasons why PIF adopts KIF syntax:
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 - 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 (( )*) :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 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:
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:
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.::= | ::= ( *) | ( * ) ::= (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
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.
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.
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.