The OWLGrEd ontology editor allows graphical visualization and authoring of OWL 2.0 ontologies using a compact yet intuitive presentation that combines UML class diagram notation with textual OWL Manchester syntax for expressions. We describe here the approaches available for ontology presentation fine tuning within the OWLGrEd editor, namely the ontology visualization option framework and the editor plug-in mechanism together with concrete plugins aimed to enhance the ontology presenting and editing experience.
Presenting OWL ontologies [
The real strength of ontology presentation in an editor like OWLGrEd comes from the user’s ability to fine-tune the ontology diagram after its automated rendering to obtain documentation-ready ontology presentations. Such a fine tuning may involve the diagram object repositioning, as well as its re-structuring up to full ontology editing facilities available in the tool (including e.g. manual deletion of irrelevant information).
In order to achieve a high quality ontology presentation in the tool, even in the presence of manual fine tuning options available, the quality of first ontology diagram created upon the import of the ontology into the tool still remains very important. Since the UML diagrams, as well as the OWLGrEd notation allow for different presentations of the same semantic elements (e.g. a graphical and textual one), and different ontologies may correspond to different desirable ontology presentation options, we describe here a re-factored ontology visualization option framework offering a number of choices that the user can make already before importing the ontology into the tool.
We describe here also a number of OWLGrEd plugins that can be used for diagram refactoring services, as well as its structural and semantics extensions. This part of work extends the earlier authors’ work on domain specific ontology visualizations [7,8] (this paper describes new re-factoring services plug-in, as well as reviews the plug-in mechanism and concrete plugin architecture from the ontology visual presentation perspective). The editor plugins described here are included in the OWLGrEd tool download and can be activated on-demand for concrete projects. The OWLGrEd editor with preinstalled configuration, as described here, is available at http://owlgred.lumii.lv/pp. 2
OWLGrEd (http://owlgred.lumii.lv/) provides a graphical notation for OWL 2 [
{disjoint}
personID:string dateOfBirth:dateTime traumaPatient cancerPatient {<patient} {<patient}
"Trauma illness case" treatedIllnessCase only treatedIllnessCase IllnessCase patient diabPatient {<patient} <<comment>> "Illness case and patient ontology fragment"
"Cancer illness case" treatedIllnessCase only <<disjoint>>
"Diabetes ilness case" treatedIllnessCase only The UML notation provides several options for presenting its semantic elements in different visual ways. This principle is kept also in OWLGrEd by including both graphical and textual notations for such semantic elements as subclass relations, object property relations, annotations and object properties as association roles or as attributes.
The automatic ontology visualization in OWLGrEd by default shall use the graphical notation, if there is no clear reason for switching to textual one. Fig. 2 shows a larger fragment of Medicine Registries Ontology in a graphical notation for all object properties and object property restrictions, and with separate disjoint classes axiom rendering.
Person treatingDoctor pdeatresOonfBI Dir:tsht:rdinatgeTime ddooccttoorrCND<oa<odmEcene:tus:osmtrrtCirnilnaggss>> idllinaebsRseRgeDgoDctoocrto{r<illness RetrgaDuom{c<taopPra}atiteiennt}t canc{e<rpPaatiteiennt}t cancerRegDoctor {<illness RegDoctor} traumaRegDoctor {<illness RegDoctor} workplace MedicalEsta<<bElinsuhmeCmlases>n>t treatedIllnessCase only Trauma estNam e:string estType:string treatmentPlace IllnessTreatment TraumaTreatment
<<disjoint>>
CancerTreatment DiabetesTreatment patient diabPatient {<patient}
Cancer treatedIllnessCase only treatedIllnessCase
IllnessCase
Diabetes treatedIllnessCase
only <<disjoint>> diagnCode:string diagnDescr:string cancerTrDiagnosis diabTrDiagnosis {<treatedDiagnosis} {<treatedDiagnosis}
traumaDiagnosis cancerDiagnosis treatedDiagnosis {<illness Diagnosis} {<illness Diagnosis}
Diagnosis <<EnumClass>> idllinaebsDsiaDgiangonsoissi{s<illness Diagnosis} traumaTrDiagnosis {<treatedDiagnosis} For different ontologies and their parts, the appropriate element visualization methods may differ depending on the ontology content, e.g. if the ontology contains a small number of object property restrictions, a better way to display object property restrictions would be graphical. However, it would not carry much information to display graphically object property restrictions that are based on owl:Thing as the target class. A textual form object property restriction visualization may be favorable also in the presence of a large number of these restrictions in the ontology.
The ontology visualization parameter framework offers parameters for inclusion / not inclusion of different object types in ontology visualization (e.g. one can choose to visualize ontology without data property annotations or without disjoint class axioms). Most of the framework parameters, however, refer to different ways (e.g. a graphical, or a textual form) of different type entity and axiom information visualization.
Figure 3 illustrates parameter setting interface including the option to represent subclass relations as text or graphically. In graphical mode there is a possibility to draw subclass relations as lines or combine them through forks, if there are more than one subclass for a given class.
There are also parameters for disjoint class axiom rendering in Fig. 3. Along with disjoint classes representation as text or graphically (in a separate graphical node), there is a possibility to group disjointness relations, into boxes if there are more than two disjoint classes, and it is possible to hide information if it is not presented graphically.
An important option in UML is a possibility to mark the generalization sets as disjoint. This notation is brought also over to OWLGrEd since it can greatly simplify the graphical diagram appearance, if the disjointness axiom matches a level within the class hierarchy. If the ‘Use Disjoint mark at forks’ box is checked in the import parameter form, the ontology importer is able to identify the cases when all class subclasses are disjoint and add specific {disjoint} mark to the generalization element (cf. the generalization set notation for the subclasses of the IllnessTreatment class in Fig. 1).
Figure 3 also shows possible extra choices that can be made for the subclass relations, such as “Mark top-level named classes as subclasses of ‘Thing’”, “Draw subclass relations to named class A from expression ‘A and ...’”, “Draw subclass relations from named classes to their union”, “Hide subclass information, if not presented graphically” and an option to choose whether to create anonymous subclasses as boxes, or not. The extra parameters are left unchecked by default to obtain less loaded graphical presentation, however they can be turned on to show more clear class hierarchy, if desired. To enhance the ontology visualization fine tuning experience after the ontology initial loading into the tool, as well as to support different custom ontology visualization means and the ontology editing work in general, the OWLGrEd ontology editor can be extended by means of plugins. The ontology editor plugins offer editor notation and environment extension means, in a similar manner, as profiles do for UML class diagrams [11,12]. A plugin to the ontology editor, may include structural editor symbol extensions with fields and visual effects, as well as editor behavior extensions.
The OLWGrEd plugin for ontology re-structuring includes transformations for adjusting the ontology visual presentation after its automatic visual rendering. It allows switching between the textual and graphical presentation form for concrete object property and object property restriction presentations within the ontology diagram, as well as re-factoring individual disjoint classes axiom presentation (e.g. from a separate disjoint-box to the ‘disjoint’ mark at the sub-class form symbol). The plugin can be used to transform e.g. the ontology diagram of Fig. 2 or Fig. 4 into the one of Fig. 5, where certain object properties (in the concrete example – the ones not having super-properties) are displayed in a graphical form to balance the structure presentation and compactness requirements. For an experienced OWLGrEd user it should take about 5 minutes to change manually the ontology diagram of e.g. Fig. 2 into the one of Fig. 5.
The ontology presentation in Fig. 5, as well as the presentation in Fig. 2 and Fig. 4 uses also a custom “enumerated class” boolean user field presentation.
In general, the editor extensions with symbol fields and graphical effects enhance the ontology presentation options by introducing domain-specific notations into the ontology presentation (the extensions can be configured to take into account the domain specific notations also during the ontology import); they are handled by a generic User Fields plugin [8] that is currently part of the default OWLGrEd editor configuration.
The available editor enhancements, supported by the User Fields plugin [8] include: custom fields, together with their semantics mappings (e.g. “enumerated class”); custom visual effects for text and choice fields and symbols dependent on concrete text or choice field values (e.g. a brown/darker enumerated class color); views applying certain visual effects to the entire diagram (e.g. hiding certain information from the presentation). The default OWLGrEd configuration includes views for horizontal and vertical alignment, and hiding all annotations.
An example of ontology editor plugin that involves both the user fields and custom functionality definition is the data ontology support plugin [13]; it contains the above considered “enumerated class” field definition. It also adds extra maximum cardinality 1 axioms to all data and object properties that are rendered in the editor in the textual form and do not have explicit cardinality specification. The plugin also records the class attribute ordering into an annotation so that this ordering could be further used in automated user interface generation for ontology-conformant data browsing (cf. [13]).
The other currently maintained OWLGrEd editor plugins are: (i) Controlled Natural Language (CNL) interface support plugin (used to augment the ontology with lexical information in [14]) and (ii) database to ontology mapping support plugin DBExpr [13]. 5
The UML style visualization and authoring of OWL ontologies has been proven to be a successful alternative to other ontology visualization and authoring means. The OWLGrEd editor is able to offer a compact ontology notation by using OWL Manchester syntax [5] for textual presentation of advanced ontology constructs.
We have described three mechanisms that can be applied to enhance the ontology visual presentation and editing experience: (i) ontology visualization parameters; (ii) ontology profiles that may enhance the user experience in creating comprehensible and visually appealing ontology presentations; (iii) ontology visualization transformation means. Each of them can be further developed and enhanced to reflect new ontology rendering patterns, as well as to respond to the needs of concreate use cases.
A future work direction is also to move the OWLGrEd editor to the web environment, this depends on suitable tool definition framework availability providing the necessary editor definition infrastructure; this is work in progress in itself, as well. 5. OWL 2
Manchester Syntax, htp:/w.3orgTRl2
m-ances
Ontology Visualization with OWLGrEd. In: ESWC 2012 Satellite Events, Springer LNCS,