The PIF Process Interchange Format and Framework

Jintae Lee, Gregg Yost and the PIF Working Group[1]
Version 1.0
December 22, 1994

Table of Contents
1. Abstract
2. Introduction
3. History and current status
4. PIF
5. Alphabetic Class Reference
6. Extending PIF
7. Appendix A: PIF Syntax
8. Appendix B: An Example PIF File
9. References

7. Appendix A: 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 ARPA (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.

Extensive information about KIF, Ontolingua, and the Knowledge Sharing Initiative can be found in the Ontolingua World-Wide Web home page.

There are several reasons why PIF adopts KIF syntax:

There is little overhead involved in using KIF for our current purpose. Any interchange format we choose should provide a structured way of specifying classes, instances, values, and value restrictions. KIF has a relatively simple and well-developed syntax for all of these. Currently, we make little use of KIF beyond its syntax. For example, we do not currently use any of KIF's extensive provisions for describing the formal semantics of a set of object classes.
KIF is already a proposed interchange format and much effort has gone into making it a good general-purpose interchange format. In particular, KIF has a well-defined formal semantics, which helps reduce the ambiguity that might arise in translating between PIF and other process description formats.
Using KIF allows us to exploit existing resources. For example, the KIF repository of generic and domain-specific knowledge structures has been growing. These knowledge bases include formalizations of configuration design, engineering mathematics, job assignment, and bibliographic information), all of which would be accessible to any PIF translators that were extended to process the more general KIF structures that are not included in basic PIF.
There are tools available, such as Ontolingua (Gruber, 1993), that can facilitate encoding knowledge in KIF and translation to and from other representations. Ontolingua provides higher-level knowledge-description constructs than standard KIF, as well as translation services between KIF and other knowledge representations (for example, LOOM, KEE, Epikit).

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. As described later, PIF uses a simplified version of Lisp syntax that is much easier to parse than full-blown Common Lisp.

A PIF file begins with a description of the class hierarchy for objects in the file, and is followed by descriptions of all of the object instances. Figure 3 gives PIF's BNF grammar. 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, placeholders for primitive literals are in uppercase (for example, NUMBER), and everything else is a literal constant. Appendix B contains a very simple example PIF file.

PIF allows two kinds of comments:

Comments that begin with a semicolon and end at the end of the same line.
Comments that begin with #| and end with |#. This kind of comment can be nested. So, for example, #| ... #| ... |# ... |# is a valid comment.

The primitive literal types in the grammar are NUMBER, STRING, SYMBOL, and RESTRICTED-KIF-SENTENCE. NUMBER, STRING, and SYMBOL are defined very much like the corresponding concepts in the Common Lisp programming language (Steele, 1990). The PIF Working Group has not yet decided on precise definitions, so this version of the document cannot give full details. However, the intent is to provide much of the richness of Common Lisp syntax, but to exclude anything that would be significantly difficult to parse. For example, we expect to exclude most of Common Lisp's macro-character syntax from PIF, so that PIF can be easily parsed without a Lisp interpreter.

Values of type RESTRICTED-KIF-SENTENCE represent logical statements, and are a limited form of the logical sentences allowed in KIF. Figure 4 gives the BNF grammar for a RESTRICTED-KIF-SENTENCE.

Figure 3: The BNF grammar for PIF files.

   pif_file:		[ <define_hierarchy> <define_frame>* ]
   define_hierarchy:	( define-hierarchy <class_hierarchy> )
   define_frame:	( define-frame <object _id> <own_slots> )
   class_hierarchy:	<class_id >
			|  ( <class_id > <class_hierarchy> )
   own_slots:		:own-slots ( <own_slot>* )
   own_slot:		( <attribute_name> <value_spec>+ )
   value_spec:		<constant>
			|  ( setof <constant>* )
			|  ( listof <constant>* )
			|  ( quote <s_expr> )
			|  ' <s_expr>
   s_expr:		<constant>
			|  <list>
			|  ' <s_expr>
   list:			( <s_expr>* )
   constant:		STRING
			|  SYMBOL
			|  NUMBER
   object_id:		a SYMBOL identifying an object
   attribute_name:	a SYMBOL naming an attribute
   class_id:		a SYMBOL identifying an object class

Figure 4: The BNF grammar for RESTRICTED-KIF-SENTENCE.

   restricted-kif-sentence:	(quote <sentence>)
				| ` <sentence>
   sentence:			<quantsent > | <logsent > | <relsent> |
<equation >
				| <inequality >
   quantsent:			(forall <indvar> <sentence>)
				| (forall (<indvar>*) <sentence>)
				| (exists <indvar> <sentence>)
				| (exists (<indvar>*) <sentence>)
   logsent:			(not <sentence>)
				| (and <sentence>*)
				| (or <sentence>*)
				| (=> <sentence>* <sentence>)
				| (<=> <sentence> <sentence>)
   relsent:			(<relconst> <term>*)
				| (<funconst> <term>* <term>)
   equation:			(= <term> <term>)
   inequality:			(/= <term> <term>)
   term:				<indvar> | <object_id> | <funconst> |
<relconst>
   indvar:			a SYMBOL beginning with the character `?'
   object_id:			a SYMBOL identifying an object
   funconst:			+ | - | * | /
   relconst:			< | > | <pif-relconst>
   pif-relconst:			a SYMBOL denoting a PIF relation

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 4. 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. So, for example,

	(define-hierarchy
	    (A
	        B
	        (C
	            D
	            (E))
	        (F
	            G)))

defines this class tree:

A leaf class can be denoted either by a symbol or by a list with no subhierarchy definitions (for example, E in the above).