USERS
DEVELOPERS


see also:
BACK-END
CREATEPROJECT
EXPORT

 createproject & export versus back-end plug-ins

The intent of createproject and export plug-ins is to provide an extensible mechanism for importing and exporting standard Protégé knowledge-bases in a variety of formats, both file and database. These plug-ins are related to but distinct from back-end plug-ins (also known as storage or KnowledgeBaseFactory plug-ins). Createproject and export plug-ins are much easier to develop than a back-end plug-in and are intended to serve a somewhat different need.

The fundamental difference is that createproject and export plug-ins are meant to satisfy the needs of those who primarily wish to use Protégé as an editor and be able to occasionally export the information into another format to be used by other applications (or to import information produced by other applications). Back-ends can also be used for this purpose but they have additional requirements. These requirements may make the resulting output difficult to use directly with an external application.

A good example of this distinction is the database back-end, which stores Protégé information in a relational database. The schema used by this back-end is optimized for general Protégé performance, but it is often useless for other applications that want to use the database directly. A solution for this problem is to write a database export plug-in that exports in a reasonable schema usable by other applications. You can then occasionally "dump" your Protégé knowledge-base to that format. (One day we may even do this)!

Another example of when you may want to use this is with formats (such as OWL) that require a different editing interface for full support. For example, you may want to use the traditional Protégé interface (e.g., because you don't need the full flexibility of OWL) but need to use OWL as an interchange format with other applications or to import simple OWL files from other applications. In this case, an export plug-in would create an OWL output from your Protégé knowledge-base, possibly ignoring those parts of it that do not map cleanly into OWL.

Users should note that some of our existing back-ends (the RDF back-end, for example) in some aspects behave more like Import/Export plug-ins than like the ideal back-end described below. Over time we hope to separate out this functionality to provide cleaner implementation of the various plug-in types.


Preservation of Information

A back-end is ideally expected to preserve all information that the standard Protégé system can model. A user should be able to save a default Protégé knowledge-base with a back-end and reload the project and get back an identical model. Protégé modeling elements that are not supported by the target format should be preserved as comments or as "extra objects" in the system. These comments or objects can then be detected when the system is loaded and the original knowledge-base recreated. There is no particular requirement that the output resulting from a back-end be useable by another application, although this behavior is certainly preferable.

An exporter can, but does not have to, preserve all of the information in a Protégé model. The ideal scenario is that the export plug-in creates a "clean" file in the target format, something that another user of that format would want to use. Thus it probably should have no extra objects or comments floating around. There is no real or implied constraint that when a user exports a file to a given format and then imports it that he ends up with the original model. Some information may be lost. It is up to the developer of the export plug-in to decide whether and how to notify the user about lost information during export. There is not even a requirement that there be a matching importer for a given exporter.

A similar philosophy holds on input. The goal of the createproject plug-in is to take any file in the source format produced by another program and produce the closest possible "natural" Protégé knowledge-base. This may involve discarding information in the source that cannot be mapped cleanly to Protégé constructs. It is again up to the plug-in developer to decide whether and how to notify the user about discarded information and whether or not to allow the user to provide guidance on how source file information should be mapped to the equivalent Protégé constructs.


Editing Behavior

A back-end is allowed to and often does modify the behavior of Protégé in some way after the file loading process is complete. This modification can be as simple as the ongoing maintenance of namespaces provided by the RDF back-end or as pervasive as the modifications done by the OWL Plugin. Thus a back-end is allowed to have some ongoing behavior and interaction with the user after the project is loaded and may affect what editing operations are available and the way that they are achieved.

By contrast, a createproject plug-in should just read from its source, produce the Protégé knowledge-base, and then "get out of the way". It should not introduce menu items or make other more permanent changes to the system. While a user of a back-end may be aware that the project back-end is of a certain type (by UI or other cues), once something is imported, a user should not be able to tell what the original source format was.

A sophisticated createproject/export pair could however take "discarded information" (information in the source file that cannot be cleanly modeled in Protégé) and save it somewhere. The get/setClientInformation methods on the KnowledgeBase class provide for exactly this sort of mechanism. This information might then be used on the off chance that the user happens to export this particular knowledge-base again during the same editing session. This sort of behavior is by no means required of a createproject/export pair though. In general a user should expect information from the external source that does not map to Protégé constructs to be lost.