The PIF Process Interchange Format and Framework

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:

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:

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

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

Appendix B: An Example PIF File