Export and Import
The ontology created in the diagram can be exported into several ontology serialization formats.
- In the ontology diagram, right-click on an empty area of the diagram.
- Open the context menu.
- Choose the desired ontology format.
The ontology will be saved in the selected format.
An existing ontology can be imported into the system from a file.
- To import an ontology:
- Open the Projects screen.
- Click the Load Ontology button.
- Select the ontology file from your computer.
- Press the Upload button.
After the upload is completed, the ontology will be loaded into the project and its structure will be available for visualization and editing in the ontology diagram.
Ontology visualization parameters define how ontology elements are shown in an OWLGrEd diagram. Their purpose is to make automatically generated ontology views more understandable, more compact, and better suited to the ontology content. The same ontology semantics can often be displayed in several ways, so these parameters let the user choose the most appropriate presentation before import.
In OWLGrEd, visualization settings mainly control whether information is shown:
- graphically,
- textually,
- grouped in a compact form, or
- hidden when it would overload the diagram.
OWLGrEd prefers graphical notation by default, unless there is a clear reason to switch to textual notation.
Some parameters define whether specific ontology elements should be included in the visualization at all.
Examples mentioned in the paper include the ability to visualize the ontology:
- without data property annotations,
- without disjoint class axioms,
- or without other selected types of information that may not be important for a particular diagram.
This helps create diagrams that are focused on the intended use case, for example documentation, analysis, or editing.
Most parameters define how ontology information is shown rather than whether it is shown.
OWLGrEd allows users to choose between:
- graphical notation — using diagram connectors, lines, boxes, and forks,
- textual notation — embedding ontology information directly in class or property fields.
This is especially important for:
- subclass relations,
- disjointness,
- object properties,
- object property restrictions.
Users can choose to represent subclass relations:
- as text, or
- graphically.
When graphical mode is selected, there is an additional option to:
- draw subclass relations as individual lines, or
- combine them through forks when a class has multiple subclasses.
Disjoint classes can be rendered:
- as text, or
- graphically in a separate node.
Additional options include:
- grouping disjointness relations into boxes when more than two classes are disjoint,
- hiding disjointness information when it is not shown graphically.
A particularly important UML-inspired option is:
- Use Disjoint mark at forks
When this option is enabled during import, OWLGrEd detects cases where all subclasses of a class are mutually disjoint and adds a {disjoint} mark to the generalization element.
The object properties and object property restrictions can also be shown either graphically or textually.
Graphical form is useful when:
- the number of properties or restrictions is relatively small,
- the structure between classes should be visually emphasized,
- users want the ontology relations to be easy to trace in the diagram.
Textual form is useful when:
- the ontology contains many object properties or restrictions,
- graphical presentation would overload the diagram,
- compactness is more important than full structural visibility.