owlgred ontology visualizer - lu...

OWLGrEd Ontology Visualizer

Renars Liepins, Mikus Grasmanis, and Uldis Bojars

Institute of Mathematics and Computer Science, University of Latvia,Raina bulvaris 29, Riga, LV-1459, Latvia

{renars.liepins,mikus.grasmanis}@lumii.lv,[email protected]

Abstract. The OWLGrEd Ontology Visualizer is an online tool for vi-sualizing OWL ontologies using a compact UML-based notation. This pa-per describes the implementation of the OWLGrEd Ontology Visualizerwhich consists of a web-based user interface, the graph (visualization)generation component, the layout component and the graph renderingand sharing component. The paper concludes with a list of future devel-opment ideas including switching from HTML canvas to vector graphicsand extending the visualization with an ontology verbalization layer.

Keywords: Ontologies, Semantic Web, Visualization, OWL

1 Introduction

Visualizations are an important tool for working with ontologies. They canprovide a “bird’s eye view” of the ontology, enrich the documentation andhelp debug ontologies by letting developers spot mismatches between what theyintended and what is defined in the actual ontology.

OWL ontologies can be represented in RDF and visualized as RDF graphs(e.g., using the W3C RDF validator). However, such visualizations are low-leveland work at the conceptual level of triples instead of ontology building blockssuch as classes and properties. For ontology graphical representation to be usefulit needs to be at the level of ontology language concepts and, in order to providea good overview, it needs to be as clear and as compact as possible.

This paper describes the OWLGrEd Ontology Visualizer1 – an online toolfor visualizing OWL 2 ontologies. It is based on a desktop application – theOWLGrEd graphical OWL editor [1]. Both applications employ the same com-pact UML-based notation for representing OWL ontologies described in the nextsection.

2 Background

The OWLGrEd notation2 is based on UML class diagrams that software devel-opers may already be familiar with. Most OWL features have a 1:1 mapping

1 http://owlgred.lumii.lv/online_visualization2 http://owlgred.lumii.lv/notation

ISWC 2014 Developers Workshop Copyright held by the authors 37

2 Renars Liepins, Mikus Grasmanis, and Uldis Bojars

to UML concepts (OWL classes to UML classes, datatype properties to classattributes, ...). New graphical and text elements are introduced for OWL featuresthat do not have UML equivalents. Classes and other elements have text fieldswhere OWL expressions may be added if needed (e.g. to indicate an equivalentclass). The notation is further described in [1].

Fig. 1. Options for representing class hierarchy relationships in OWLGrEd.

The notation supports OWLGrEd’s aim to make visualizations as compactas possible. For example, Figure 1 shows alternative ways for representing gen-eralization (a subclass-of relation). The naive representation – a line for everygeneralization relation (shown on the left) – can be expressed more compactlywith the fork notation where multiple incoming lines are merged into one (shownin the middle). A text notation is also available for cases where it is moreappropriate (e.g. to refer to a superclass that is defined using an OWL classexpression and is not referenced anywhere else).

These and other notation features allow us to create cleaner visualizationsbut make the application more complex because it has to consider the alter-native ways for representing OWL axioms. This impacts the graph generationcomponent described in Section 3.2.

OWLGrEd diagrams use the orthogonal layout where the inheritance-definingrelations (i.e. subclass-of relations between classes and instance-of relationsbetween classes and instances) are presented in a hierarchical layout (i.e. they“flow” from one side of the diagram to the opposite side) and all other relations“flow” in the direction perpendicular to it. We have observed that for a typicalOWL diagram the horizontal direction (left-to-right) seems to be the morereadable and the one which leads to more compact diagrams. The generationof diagram layout is described in Section 3.3.

Figure 2 shows a visualization of the Koala ontology from the Protege ontol-ogy library3. Visualizations are assigned custom URLs that allow to share themwith others4.3 http://protegewiki.stanford.edu/wiki/Protege_Ontology_Library4 Koala ontology: http://owlgred.lumii.lv/online_visualization/koala.owl


OWLGrEd Ontology Visualizer 3

Fig. 2. Visualization of the Koala ontology.

3 System Architecture

This section describes the implementation of the OWLGrEd Ontology Visualizer.It is a client-server type application where the client-side accepts user requestsand contains the visualization component while most of the work is done server-side. The server side is implemented as a data transformation pipeline and con-sists of a file upload service, pipeline manager, and individual pipeline modulesdescribed in detail later in the paper. This modular architecture provides sepa-ration of concerns, permitting easier application updates and enabling scalablesolutions that can run transformations in parallel.

The server side of the application runs inside JVM and is written in Java andClojure. Communication between the client and the server uses asynchronousHTTP requests with JSON payload.

3.1 Ontology Upload and Parsing

Users can either (a) upload and visualize their ontology; or (b) explore examplevisualizations. In order to start the process a user uploads the ontology file tobe visualized. The application saves the file and passes it to subsequent steps -ontology parsing and graph generation (“graphization”).

The application parses the ontology using OWL API5 [2]. By using an es-tablished API for parsing OWL we can avoid having to deal with multiple waysfor representing OWL ontologies. As a result users can upload ontologies inany format as long as it is recognized by the OWL API. The “graphization”component that is next in the pipeline makes OWL API calls in order to retrieveall the information necessary for visualization.

5 https://github.com/owlcs/OWLAPI



3.2 Graph Generation (“Graphization”)

Graph generation is a core step of the ontology visualization process. It trans-forms the parsed set of ontology axioms into a graphical form that is laid outand sent to the browser. The OWLGrEd notation attempts to summarize theontology by showing it in the most compact form depending on the context.Thus there can be more than one way to display the same information (see Sec-tion 2) associated with a set of rules that define how to choose the visualizationapproach in each particular case. For each type of axioms and entities there is avisualization function that transforms them to a graph representation.

The whole transformation is implemented as a pipeline that starts with twosets: (a) items to transform; and (b) item renderings generated. Initially thefirst set (items to transform) contains all entities and axioms from the ontology;the second set (item renderings) is empty. The result set is a collection of ob-jects: Nodes and Edges. They both have a type (OWLClassBox, SublassOfLine,etc.) and a list of text labels. Text labels have a text value and type (e.g.ClassNameLabel, PropertyNameLabel).

The pipeline proceeds through an ordered list of transformation steps eachconsisting of a selector function and a transformation function. The selectorfunction selects items from the “items to transform” set that are suitable for thegiven step. The selected items are then passed to the transformation functionthat renders them. The result is added to the rendered items set and the pro-cessed items are removed from the “items to process” set. The remaining itemsare passed to the next select / transform step. The resulting JSON structure ispassed to the layout step described in the next section.

The transformation component is written in Clojure and consists of ∼70transformation rules (corresponding to the total number of [node, edge, la-bel] types in the notation) and ∼1500 lines of code. We chose a functionalprogramming language because it fits well with the transformation pipelineapproach where each transformation can be defined as a function. Other benefitsof choosing Closure are the interactive interpreter that makes testing easier andnatively access to Java objects which enables interoperation with the OWL API.

The last step performed by the “graphization” component is styling whichwalks through the set of graph elements (nodes, edges, labels) and applies stylinginformation according to their type and properties. The styling configurationthat determines the appearance of visualization elements (colors, label positions,etc.) is stored in a separate file for easy customisation.

3.3 Layout Generation

The layout generation module, written in Java, walks the graph (provided as aJSON structure) generated by the “graphization” component, enriches it withlayout information (element coordinates and dimensions) and sends the result tothe rendering component. Having a custom layout generation engine allows usto fully support the chosen notation and to fine-tune the visualization as needed.OWLGrEd uses the orthogonal diagram layout described in Section 2.

Initially, the dimensions of all text items (textual inside nodes and edgelabels) are calculated taking into account the text and its style. For each node


OWLGrEd Ontology Visualizer 5

minimum possible dimensions are calculated that will enclose all text itemsrelated to the node. As the next step, we enrich the original graph with ge-ometric constraints (minimum sizes, spacings, edge orientation, label anchors)and calculate a graph layout satisfying these constraints. The resulting layoutinformation is injected into the JSON file describing the graph.

The completed JSON file describing the graph and its layout is sent to abrowser-side rendering component which draws the diagram. As a conveniencefeature the JSON file is also saved under a short name in order to enable diagramsharing.

3.4 Rendering, Presentation & Sharing

The Rendering component displays the resulting visualization in the browserwhere users can navigate it (zoom, pan, select) and share it with others viacustom URIs generated for each new visualization.

The graph is shown in an HTML5 canvas element using a custom render-ing library built on top of the KineticJS library6. This component draws thevisualization according to the diagram structure, element coordinates and stylescontained in the supplied JSON structure.

The user interface also contains some visualization examples that can beaccessed via their URIs or by pressing the “Enjoy our examples” button whichwill cycle through the examples.

4 Experience Using the Application

The usage of the application can be characterized by the number of ontologiessubmitted to it. We analyzed the weekly statistics of the upload button hitsfrom international locations (according to Google Analytics). In the time periodfrom 2014-04-01 till 2014-07-18 there were 512 upload button hits from locationsoutside Latvia. There were 368 successful file uploads most of which were OWLontologies that were visualized by the application.

The size of ontology files uploaded varied from 412 bytes (for a small ontologyin Turtle RDF) to ∼1.7 Mb (for larger ontologies expressed in RDF/XML) withaverage size ∼103 Kb and a median of ∼24 Kb.

Ontologies were expressed in multiple formats including various RDF rep-resentations and the OWL XML syntax. Thanks to OWL API the applicationcan work with all these formats without requiring us to write additional code.Sometimes “real-life” ontologies uploaded for visualization may be contain “sur-prises” that prevent us from parsing them. For example, we identified a bug inOWL API which prevents an ontology containing the BOM (byte-order markthat may be present at the start of text files) from being parsed. The bug wasreported to OWL API developers who promptly resolved it resulting in OWLAPI improvement that anyone can benefit from7.6 http://kineticjs.com/7 https://github.com/owlcs/OWLAPI/issues/187



5 Future Work

This section lists future development ideas for the OWLGrEd Ontology Visu-alizer. The implementation details, a current state of which is recorded in thispaper, may change as a result of these developments.

Moving from canvas to vector graphics - we plan to change the ontologypresentation component by switching ontology display from HTML5 canvas toSVG. This may also allow users to save resulting visualizations and work onthem further using graphic editing software.

Visualization publication and sharing - the sharing feature (where vi-sualizations get their own URIs) was added recently and we intend to furtherdevelop it. It would be useful to publish visualizations along with metadata (e.g.,schema.org) asserting that this is a visualization of an ontology and providinginformation about it.

Ontology editing - currently the application provides a read-only view ofthe ontology. Our medium-term plan is to extend the application with the editingfunctionality, converting it into an online version of the OWLGrEd editor. Thiswill involve substantial changes to the application described in this paper.

Ontology verbalization - a visualization of an ontology is a good way forgetting an overview of the ontology but, if viewers do not know semantics of thenotation, they cannot just come to the picture and instantly “understand” it. Weplan to mitigate this by integrating controlled natural language verbalizationsinto the visualization so that user can click on any element and see a naturallanguage representation of this element.

6 Conclusion

This paper described the implementation of the OWLGrEd Ontology Visualizer– an online application for creating and sharing visualizations of OWL ontolo-gies. The main activities performed by the application are ontology parsing,generation of the visualization graph, layout calculations and displaying thevisualization to the user. The visualizer benefits from using OWL API thattakes care of parsing various OWL ontology formats.

We believe ontology visualizations are a valuable resource with many usessuch as ontology exploration and debugging and are looking forward to furtherdevelopments in this area.

References

1. Barzdins, J., Barzdins, G., Cerans, K., Liepins, R., Sprogis, A. (2010). UML StyleGraphical Notation and Editor for OWL 2. Perspectives in Business InformaticsResearch, Lecture Notes in Business Information Processing, Volume 64, Part 2,pages 102-114, 2010

2. Horridge, M., Bechhofer, S. (2011). The OWL API: A Java API for OWL ontologies.Semantic Web, 2(1), 2011, 11-21

Acknowledgments. This work was partially supported by ESF project2013/0005/1DP/1.1.1.2.0/13/APIA/VIAA/049.


owlgred ontology visualizer - lu...

Documents