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.