USERS
DEVELOPERS


see also:
BACK-END
CREATEPROJECT
PROJECT
SLOT WIDGET
TAB WIDGET
 how to write an export plug-in

The goal of an export plug-in is to provide an extensible mechanism for exporting standard Protégé knowledge bases in a variety of formats, both file and database. This plug-in type is related to, but distinct from a back-end plug-in (also known as a storage or KnowledgeBaseFactory plug-in). Export plug-ins are much easier to develop than a back-end plug-in and are intended to serve a somewhat different need. We offer a much more detailed explanation of the differences between the two plug-in types elsewhere.

An export plug-in 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 and 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.

[ Description of what example plug-in does here. ]

Follow these steps to compile and run the createproject plug-in example:
  1. Download the source code. (Please make sure to preserve the path information in the ZIP file).
  2. Set up your Java development environment:
    • Use JDK 1.4 or higher for your compiler.
    • Configure the compiler to write output classes to <protege_install_dir>/plugins (replacing protege_install_dir with your Protégé installation directory).
    • Add the following JAR files to your classpath: protege.jar, looks.jar, unicode_panel.jar.
    • Pass the JVM the following parameter -Dprotege.dir=<protege_install_dir>.
  3. Compile the source code. Check that your compiler has indeed put the "FooExporter.class" file into the "plugins/examples/exportplugin" directory. Also, please make sure that your development environment copies the meta-inf directory with the manifest file to your output directory. Some development environments do this by default, others require you to specify that MF files should be copied to the output directory. The following is an example of what your directory structure should look like after properly downloading and compiling the example code:
    
    <protege_install_dir>
        plugins
            examples
                backend
                createprojectplugin
                exportplugin
                projectplugin
                slotwidget
                tabwidget
            meta-inf
    
  4. Run the example from your development environment, specifying edu.stanford.smi.protege.Application as the main class. Any "Duplicate plugin" warnings are benign and can be ignored. You may also wish to specify the name of a project as an application parameter so that when Protégé starts up, a project will automatically be loaded. Select File | Export to Format and notice that the example "FooFile" appears as a new menu item.