Table of Contents
The current version of TMTab does not read in XTM files, nor does it maintain the ontology in XTM format. However it is possible to export the TMTab topic map ontology as an XTM file for further processing by topic map tools (such as loading into a topic map viewer application like TMNav). The export process is controlled from the tab labelled "Topic Map!.
To export a file, simply specify the name of the file to be written (you can use the Browse button to locate a file using a standard Java File Save dialog), then click "Export".
If the file you specify already exists, it will be overwritten.
You can create an store one or more Export Configuration records as part of your Protégé project. These configurations control certain aspects of how TMTab creates the XTM file. Export Configuration records are simply created and manipulated like any other object in Protégé. To create a new Export Configuration record, go to the Instances tab of Protégé and create a new instance of the class TMTAB-EXPORT-CONFIGURATION. The following form may be used to set the confguration options:
Enter a name for the configuration in the field labelled
"Configuration Name". Currently, the only
configuration options available control how the contents of the Model Name slot
are treated by TMTab during export, and what level of additional information
will be exported by the reification of the topic map constructs created during
The value specified in the field labelled
"Base URI" must be a valid URI. This value will be
written as the xml:base attribute value of the exported XTM file. Typically,
this will cause a topic map processor to resolve any links to other documents
contained in the topic map to be resolved relative to this base URI rather than
resolving them relative to the address of the topic map file itself. This
option is especially useful when creating topic maps which are to be modules of
a larger integrated set.
"Export Model Name" drop-down list you may choose
"As Base Name",
"As ID" and
"As Base Name" will result in the value of the Model
Name string being used to generate a Base Name for the object. If the object is
not itself a topic (i.e. not an instance of the TOPIC class), a new topic may
be created that reifies the object (see the details for the Reification Option
discussed below) and that topic will be assigned the Base Name. You can specify
a scope for this generated Base Name by adding TOPIC instances to the list box
"Model Name Scope".
"As ID" will result in the value of the Model Name
string being used to generate the value of the ID attribute of the XTM element
which represents that object.
Use this option with caution, as TMTab does not ensure the required uniqueness constraint of ID attribute values. If you have duplicate Model Name values for different objects you may find that TMTab will either generate errors or else will silently combine Topics with the same ID. Ideally, if using this option, you should encode some additional Protégé constraints to ensure uniqueness of this slot value.
"Encode ID". Additionally, ID attribute values which
begin with a digit will have an additional underscore ('_') character prepended
to ensure that they are valid XML/SGML ID values.
"No" simply ignores the Model Name slot value
completely and its value is not used in generating the XTM file at all.
The drop-down list labelled
"Reification Options" can be used to control how the
export process will represent additional information specified in the
Protégé project which is not directly representable in the export
of a topic map object. In the Protégé model all topic map
constructs are subclasses of topic, this means that any topic map construct may
be named, given occurrences, participate in an association and so on. In XTM
syntax, for anything other than a topic, this is achieved by creating another
topic which "reifies" the construct. It is this additional topic which gets the
names and occurrences and which plays the role in associations - it is
essentially used as a stand-in for the construct that it reifies.
TMTab allows four different levels of reification:
"Never" - no reifying topics are ever
created, if you have specified additional names, or occurrences for a construct
or you have put it as a member in one or more associations in the
Protégé model, that information will be lost in the exported
"If Necessary" - if you have specified names
or occurrences for the object, or if you have specified more than one type for
the object, then the reifying topic will be exported to carry all of the
additional information. Note, however that with this level, the Model Name slot
will never be treated as providing an additional name.
"If Has Model Name" - exports a reifying
topic in all of the cases specified for the
"If Necessary" case and also will treat the Model
Name slot as providing an additional name if the
"As BaseName" option is selected in the
"Export Model Name" selection list.
"Always" - will always result in a reifying
topic for the object, even if there is no additional information provided by
thie topic. This option is unlikely to be very much use, but is provided for