Protégé uses the CLIPS text file format as its default save/load file format for both classes and instances. If you look at the .pont and .pins files (containing respectively domain classes and instances) in a text editor, you will see that these are basically CLIPS files. Protégé itself does not make use of CLIPS; it merely uses CLIPS file formats.

You should be able to read Protégé files directly into CLIPS. If you can't, please report the bug so that we can fix it. We have a number of users that use (or at least have used) this feature. There are, however, two sorts of things that you need to be aware of.

Compatible CLIPS Extensions

As Protégé has evolved, we have found it useful to introduce concepts which do not map directly to CLIPS, but are not really inconsistent with the CLIPS view of the world. An example is the Protégé idea of "allowed-classes" for slots of type Instance. This information is stored in the CLIPS file as "CLIPS extensions", following the convention that these extension lines begin with the character sequence ";+". Since ";" is the CLIPS comment character, when CLIPS parses the file it ignores the extra information. When Protégé parses the file, it uses the extra information.

Protégé extensions that fall into this category typically do not cause any really problems for CLIPS users. The "compatible" extensions are: "allowed-classes" facet, "slot-documentation" facet, and project inclusion.

Incompatible CLIPS Extensions

Protégé has evolved away somewhat from the CLIPS OO model, so that some features that we support can no longer be mapped cleanly into CLIPS. The biggest example of this is that Protégé now supports metaclasses (classes whose instances are themselves classes). If you choose to use metaclasses in your Protégé model, then the resulting classes and instances may not be usable in CLIPS in any real fashion. (The files can still be parsed as CLIPS, but the interpretation of the contents of the files is necessarily different.)

Another incompatibility, though one which is quite tractable, is the issue of slot name scope. Consider two completely unrelated classes Foo and Bar. Both classes have a slot A. In CLIPS, these slots are not the same slot and their facets are unrelated. In Protégé there is only one A slot (though the facets may be overridden in one so that they don't have the same facets). This slot is considered to be attached to both classes Foo and Bar. In addition, in Protégé slot names and class names are in the same "namespace", so they must be unique. CLIPS allows a class and a slot to have the same name.

Protégé allows frame names which are not valid CLIPS names.  If you want to CLIPS to be able to parse the files, you will need to restrict your choice of frame names to those allowed by CLIPS.

CLIPS/COOL Feature	Protégé	Workaround
modules	not supported
class/slot names	see above	follow both CLIPS and Protégé requirements (no blank in names, distinct names for classes and slots)
multiple inheritance	yes
abstract/concrete	yes
reactive/non-reactive	not supported	post-processing to add reactive specification to those classes that need it
single-field/multifield slot	yes
default value facet	no dynamic default
storage facet	local
access facet	read-write
inheritance propagation facet	inherit
source facet	exclusive
pattern-match reactivity facet	not supported
visibility facet	public
create-accessor facet	read-write
override-message facet	not supported
message handler	not supported	write message handlers in separate files
definstance	not supported	post-processing to wrap "definstance" around instances