Interactive visualization of an ontology

Diplomarbeitzur Erlangung des Grades eines Diplom-Informatikers

im Studiengang Informatik

vorgelegt von

Daniel Dünker

Erstgutachter: Prof. Dr. Ralf LämmelInstitut für Informatik

Zweitgutachter: Msc. Marcel HeinzInstitut für Informatik

Koblenz, im September 2017

Erklärung

Hiermit bestätige ich, dass die vorliegende Arbeit von mir selbständig verfasst wurdeund ich keine anderen als die angegebenen Hilfsmittel – insbesondere keine im Quel-lenverzeichnis nicht benannten Internet–Quellen – benutzt habe und die Arbeit vonmir vorher nicht in einem anderen Prüfungsverfahren eingereicht wurde. Die ein-gereichte schriftliche Fassung entspricht der auf dem elektronischen Speichermedium(CD-Rom).

Ja Nein

Mit der Einstellung der Arbeit in die Bibliothek bin ich einverstanden. � �

Der Veröffentlichung dieser Arbeit im Internet stimme ich zu. � �

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .(Ort, Datum) (Daniel Dünker)

Zusammenfassung

Thema dieser Arbeit ist die Erweiterung eines bestehenden semantischen Wiki mittels On-

tologievisualisierung. Gewünsche Features für eine solche Visualisierung werden erfasst

und diskutiert, um schlussendlich in Form eines Prototypen implementiert zu werden. Zwei

Besonderheiten werden im Verlaufe dieser Arbeit vorgestellt. Zunächst die Verbindung von

Visualisierung und Wiki mittels bidirektionaler Verknüpfung. Zweitens ein “hot-swapping”-

Feature, um die der physikalischen Simulation zugrundeliegenden Kanten des Graphen während

der Visualisierung auszutauschen.

Abstract

This thesis explores features for usability increase of ontologies through the means of seman-

tic wikis and their integration with visualization tools. Desired features are identified and

discussed, to be finally implemented in a prototype. Throughout this work to possible contri-

butions have been made. First, the idea of bidirectional linking between visualization and the

existing wiki. Second, hot-swapping of the links for a force-directed simulation in ontology

visualization.

Acknowledgements

I’d like to thank all those, without whom this work would have been impossible: Ralf Läm-

mel, for his support and the opportunity to write this thesis, his trust in my abilities inspired

me throughout this work. I am also very thankful towards Marcel Heinz, who provided me

with much needed information and contributed valuable input. Additionally, i’d like to thank

my fellow student, Wojciech Kwasnik, who helped me to stay on track and motivated during

long hours of work.

I dedicate this work to my parents; their support and love kept me going through my studies.

Contents

1 Introduction 1

2 Background 42.1 Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 A-Box & T-Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Semantic wiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.4 Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4.1 Neighborhood . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Related work 103.1 Ontology visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Requirements 124.1 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2.1 Multiple Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2.2 View: Force Directed Graph . . . . . . . . . . . . . . . . . . . . . . . 134.2.3 View: Indented Tree List . . . . . . . . . . . . . . . . . . . . . . . . . 144.2.4 View: Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2.5 URL-Encoding of Node Selection . . . . . . . . . . . . . . . . . . . . 144.2.6 Node Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2.7 Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2.8 Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2.9 Zooming and Panning . . . . . . . . . . . . . . . . . . . . . . . . . . 184.2.10 Manipulation of Clustering . . . . . . . . . . . . . . . . . . . . . . . 184.2.11 Graph export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2.12 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2.13 Color Encoding of Namespaces . . . . . . . . . . . . . . . . . . . . . 19

i

Contents ii

5 Design 215.1 Key Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.1.1 wikiLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.1.2 graphLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.1.3 treeLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.1.4 simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.1.5 graphRenderer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.1.6 detailView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.1.7 treeView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.1.8 viewBus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6 Implementation 246.1 Selected technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.1.1 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.1.2 Visualization: D3.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.1.3 Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.1.4 UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.1.5 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.2 Data anomalies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.2.1 Relations to the ’Concept’ Namespace . . . . . . . . . . . . . . . . . . 286.2.2 Other relations to nonexistent pages . . . . . . . . . . . . . . . . . . . 296.2.3 Pages with inconclusive p-attributes . . . . . . . . . . . . . . . . . . 296.2.4 Pages with no parent candidates . . . . . . . . . . . . . . . . . . . . . 316.2.5 Pages with two and three parent candidates . . . . . . . . . . . . . . 34

6.3 Code Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.4 Showcase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.4.1 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.4.2 graphRenderer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7 Concluding remarks 427.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7.2.1 Error detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437.2.2 Information Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 437.2.3 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437.2.4 Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

List of Figures

2.1 'Namespace:Language' in the 101wiki with markup . . . . . . . . . . . . . . 5

2.2 Subgraph of the 'ReviewedBy'-Relation . . . . . . . . . . . . . . . . . . . . . . 7

2.3 The process of visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5.1 Data flow between visualization components . . . . . . . . . . . . . . . . . . . . 21

6.1 Evolved code hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.2 The interface of a prototype. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.3 All nodes and links of the 101wiki (display errors due to the conversion from

svg to pdf). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.4 All nodes and links of the 101wiki, display of all relations enabled. . . . . . . . 38

6.5 Nodes and links of the 'InstanceOf'-relation. . . . . . . . . . . . . . . . . . . 39

6.6 Nodes and links of the 'InstanceOf'-relation with the display of all relations

enabled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.7 Nodes and links of the 'InstanceOf'-relation with the display of all relations

enabled, different color scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

iii

1 Introduction

The purpose of computing is insight,

not numbers.

Richard Hamming

Ontologies are a way to express knowledge. Other, more well-known techniques include

mind maps, which are widely spread, as they are easy to use. Yet these approaches, especially

mind maps, lack semantic expressiveness [Har+17]. In terms of computer science the goal is

to represent knowledge in such a way, that a software system can apply automated reasoning

and therefore reduce human workload. The amount of formalization provided by ontologies

makes them a strong candidate for this task. As the primate brain and computers process

information in different ways, this strong point of high formalization makes ontologies hard

to use for human users. This reduces the usefulness of ontologies, as not many domain ex-

perts are willing, or able to familiarize themselves with the required ontologies. Yet this is the

obstacle one has to take, before the formalization of knowledge. Therefore the fact, that on-

tologies inherently lack ease of use, limits the amount of knowledge available for automated

reasoning.

One approach to make ontologies more accessible for humans is through the means of se-

mantic wikis. Knowledge representation in form of wikis has been popularized by the advent

of the free encyclopedia “Wikipedia”1 in 2001. Wikis allow users to edit the represented web

pages, instead of just viewing them; by this users are engaged in content creation. Traditional

wikis, like Wikipedia, are text based and lack semantic information [Fri+15]. Therefore the

extension of the wiki idiom is required, to combine their ease of use with the expressiveness

of ontologies. Semantic Wikis approach this task by supplementing the existing markup, de-

scribing structured text for human consumption, with semantic markup.

While semantic wikis reduce the deterring effect of ontologies in terms of knowledge for-

malization, the textual representation of information is not easy to grasp for the consuming

user. The human brain is mostly fit to visual processing, which is why tasks like driving cars

seem easy to the human driver. Research in computer vision and the still active development

1Wikipedias goal to “create a summary of all human knowledge” reminds of the “EncyclopediaGalactica”, envisioned in the science fiction stories of Isaac Asimov.

1

2

of autonomous cars has revealed, that these abilities are in fact very hard to acquire for soft-

ware systems. It is therefore logical to tap into this enormous capability of the human brain,

when it comes to information representation. The research field of ontology visualization is

engaged with the task to create images for human consumption out of semantic information.

As no use case is like the other, many possibilities for the construction of visualizations exist;

each applicable in different situations. They have to cater users with means of exploration,

overview and querying [Iva+15]. Visualizations can be used to analyze and enjoy informa-

tion; the latter being an important point, when it comes to the lack of user engagement in

ontologies. Users engaged in the enjoyment of visualization may be one step closer to their

future involvement in content creation.

This work is based on data retrieved from the 101wiki2, which evolved [Läm17] from a

project initially named “101companies” [Fav+12]. The 101wiki is a semantic wiki, which in

its current state describes software systems and their relation to each other. These relations

are expressed through “typed links” between wiki pages. These wiki pages are typed by

organizing them into namespaces [Läm17]. Apart from a tag cloud on the start page the

wiki lacks a meaningful visualization of its content. This task is especially challenging, since

the underlying ontology is not well documented and the content itself is still in a chaotic

state. Albeit the attempts of bringing order to chaos have taken considerable time [Läm17],

the data still contains many anomalies. These anomalies are for example the result of typing

errors by contributors to the wiki and require tweaking of the data, before it can be used for

visualization.

Many works on ontology visualization introduce new tools [MPL16]. These tools may

contain editing features, which would be redundant in case of this work, as the wiki itself

already contains such features. Less than ontology visualization alone, this work is about

utilizing the data which is generated by wiki users for visualization and combining the existingwiki technology with a visualization, to enable use of their complementing features. In terms of data,

the question has to be answered, which specific data is available and usable for visualization. Before

this data can be used, it has to be analyzed to identify possible data anomalies, which would provevisualization difficult, when ignored. As the construction of a visualization depends on the

specific needs of the users, they have to be interviewed to gain insight concerning the possible usecases. The features for the visualization will then have to be selected to fit these needs. When the kind

of data selected for visualization is known, the fitting paradigms for this type of data have to beselected from the available literature on ontology visualization and visualization in general. The datanormalization for the identified data anomalies has to be determined. Lastly, the technology fittingthe requirements has to be selected, before implementing the visualization.

2https://101wiki.softlang.org/

3

This thesis explores, how ontology visualization can be incorporated in a existing semantic

wiki. As such it makes the following contributions:

• Identification of the need for a visual language to describe namespaces in the 101wiki

in a user friendly manner.

• The idea of bidirectional linking between visualization and the wiki, to complement

their features.

• Possibly the introduction of hot swapping links of a force-directed graph in ontology

visualization.

• A prototype implementation of an ontology visualization, which can be integrated in a

semantic wiki.

The thesis is structured as follows: Concepts, which may not be well established, are de-

scribed in chapter 2. A short selection of influential related work is presented in chapter 3.

Uses cases and requirements, which were identified for the visualization, are exhibited in

chapter 4. A brief, abstracted description of the overall design of the visualization tool is

given in chapter 5. A collection of implementation choices and certain issues can be found in

chapter 6. Summary, limitations of this work and possible future research comprise the final

part of this thesis: chapter 7.

2 Background

This chapter contains descriptions and definitions of core concepts, which are used through-

out this work.

2.1 Ontologies

According to Gruber [Gru09], ontologies are used to create knowledge models about individ-

uals, their attributes and relations to other individuals. As part of the semantic web standards

of the W3C, the endorsed language to describe ontologies is OWL.

He explains the historical origin of the term “ontology” in philosophy, where it designates

a theory about the nature of existence.

Gruber mentions, that the terms entry into computer science stems from the 1980s, when it

was used in AI-development, where knowledge was modeled for automated reasoning.

2.2 A-Box & T-Box

These terms stem from the field of description logic [SS10]. “A” and “T” are therein short

forms for “Assertional” and “Terminological”. T-Boxes are used to describe concepts, and rep-

resent a set of terminological axioms. The following example states, that individuals, which

have human children have themselves to be human as well:

∃hasChild.Human v Human.

A-Boxes are sets of assertions which only describe single individuals [Rud11].

2.3 Semantic wiki

Semantic wikis are a way to raise the accessibility of the semantic web. This is managed by

extending the conventional wiki idiom by semantic capabilities. They are tailored with the

purpose to contain structured information and extend the original markup language, to allow

for formalized annotations with semantic meaning [Fri+15].

4

2.3. SEMANTIC WIKI 5

The 101wiki is such a semantic wiki, with the intent to describe software languages. In

other words: 101wiki utilizes the wiki idiom to model knowledge of the software language

domain. For the fulfillment of this aspiration, individuals of the ontology are organized as

pages in separate namespaces and relationships between individuals are represented as typed

links (see figure 2.1)1.

Namespace:LanguageBold Italic Underline Strike Headline Link External Link Source Code Code Image

Bulleted list Counted list Slideshare Youtube Fragment

== Headline ==

The namespace of [[software language]]s

== Description ==

This namespace is dedicated to [[software language]]s, e.g., programming languages such as [[Language:Java]], [[Language:Python]], and [[Language:Haskell]]. Software languages are supposed to be describedalready elsewhere on the web, e.g., on Wikipedia, and thus, 101wiki coverage can be minimalistic andthe 101wiki page for a language serves essentially as a [[linked open data]] resource. Metadata for alanguage should serve the classification of languages on 101wiki.

== Metadata ==

* [[relatesTo::Software language]]* [[hasMandatory::Section:Headline]]* [[hasOptional::Section:Details]]* [[hasOptional::Section:Quote]]

1234567

891011121314

◀ thisthis relatesTo Software languageSoftware language

◀ thisthis hasMandatory Section:HeadlineSection:Headline

◀ thisthis hasOptional Section:DetailsSection:Details

◀ thisthis hasOptional Section:QuoteSection:Quote

◀ thisthis hasOptional Section:IllustrationSection:Illustration

◀ thisthis hasMandatory Section:MetadataSection:Metadata

◀ thisthis hasMandatory Property:instanceOfProperty:instanceOf

◀ thisthis exemplifiedBy Language:HaskellLanguage:Haskell

▶ Namespace:NamespaceNamespace:Namespace exemplifiedBy thisthis

▶ Property:hasOptionalProperty:hasOptional exemplifiedBy thisthis

▶ Property:hasMandatoryProperty:hasMandatory exemplifiedBy thisthis

Metadata

HeadlineThe namespace of software languages

DescriptionThis namespace is dedicated to software languages, e.g., programming languages such as Language:Java,

Language:Python, and Language:Haskell. Software languages are supposed to be described already elsewhere on

the web, e.g., on Wikipedia, and thus, 101wiki coverage can be minimalistic and the 101wiki page for a language

serves essentially as a linked open data resource. Metadata for a language should serve the classification of

languages on 101wiki.

Namespace: Language

101wiki Help

Show Markup Script✏ PDF✏

untyped link to

'Language:Haskell'

typed link to

'Software Language'

Figure 2.1 'Namespace:Language' in the 101wiki with markup

1https://101wiki.softlang.org/Namespace:Language

2.4. NETWORKS 6

2.4 Networks

The pages in the 101wiki with their interconnecting links form a so called network. The term

’network’, as it is used in this thesis, is mathematically described as a graph [Van10]:

G = (V,E), (2.1)

where G is the graph, which is comprised of two sets:

vertices V , and

edges E.

Edges e ∈ E each join two vertices u, v ∈ V . This can be written as e = 〈u, v〉.When talking about networks, edges are often called links and vertices are known as nodes

([Van10]/[Rei05]/[Bro+00]). In the case of a semantic wiki, the nodes represent pages and

links are the hyperlinks inbetween. As links in such a network have a direction, the underly-

ing graph is called a directed graph or digraph:

D = (V,A), (2.2)

where D is the digraph, which is comprised of a set of vertices V (like in the case of graphs in

general), and a set of arcs A. Arcs are directed edges and are written as a = 〈−→u, v〉, when the

join the vertices u ∈ V and v ∈ V .

In figure 2.2 is a part of the 'ReviewedBy'-Relation used as an example for the graph no-

tation. On the left side is a graphical representation of the graph, on the right side the math-

ematical definition. This example is not only a graph, but also a directed graph. Therefore

each edge e = 〈u, v〉 of the graph G = (V,E) with e ∈ E, has a corresponding arc a = 〈−→u, v〉 in

the directed graph D = (V,A) with a ∈ A.

In this particular example the vertex v1 represents the page 'Contributor:rlaemmel',

and the vertex v2 represents the page 'Contributor:martinleinberger'. The arc a1 =

〈−−−→v4, v1〉, which is not explicitly listed in figure 2.2, is obtained by associating edge e1 = 〈v4, v1〉with a direction. The semantic behind this direction is, according to the ontology used in the

101wiki, that the individual, which is represented by v4, has the relation 'ReviewedBy' to

the contributor Ralf Lämmel.

2.5. VISUALIZATION 7

v1

v2

v3

v4

v5v6

v7

v8

v9

v10

e1

e2

e3e4e5

e6

e7 e8

e9

e10

e11

e12

V (G) = {v1, . . . , v10}E(G) = {e1, . . . , e12}

e1 = 〈v4, v1〉 e7 = 〈v5, v2〉e2 = 〈v3, v1〉 e8 = 〈v6, v2〉e3 = 〈v8, v1〉 e9 = 〈v7, v2〉e4 = 〈v7, v1〉 e10 = 〈v8, v2〉e5 = 〈v6, v1〉 e11 = 〈v9, v2〉e6 = 〈v5, v1〉 e12 = 〈v10, v2〉

Figure 2.2 Subgraph of the 'ReviewedBy'-Relation

2.4.1 Neighborhood

Neighbors of a vertex u are those, which are directly connected (adjacent) to u via an edge e.

The set of neighbors for u is written as N(v) and defined as:

N(v)def= {u ∈ V (G) | v 6= u,∃e ∈ E(G) : e = 〈u, v〉}. (2.3)

2.5 Visualization

For the purpose of creating a visualization, the term itself has first to be defined. Also the

question, why to visualize at all has to be answered. Furthermore, as this work is about

interactive visualization, interactivity will be assessed as well.

Definition and Motivation

The term ’visualization’, as used in context of this work, is defined a graphical medium to

transport information.

Ward, Grinstein, and Keim [WGK10] argue about the reason for the presence of visual-

ization in everyday life. Some of these everyday situations, where visualization may be en-

2.5. VISUALIZATION 8

countered include newspapers, marketing posters or weather charts. Their argument is based

on the fact, that sight is one of the human “key senses for information understanding”. As

such the follow up with the assumption of homo sapiens being a species of visual beings and

therefore visualization being important in decision making.

According to the authors, the field of visualization has outgrown its parent-child relation

to computer graphics and has to be regarded as a separate territory. To differentiate one from

the other, they emphasize the dependence on data. While both include the act of generat-

ing images with a computer, visualization is about creating images, which are used to help

humans understanding the underlying data.

Additionally to computer graphics, which is the foundation for the visual part of visual-

ization, human-computer interaction and perceptual psychology are mentioned to play a role

in how the data, with the goal to ease his understanding, is best represented for the human

observer. Therefore the information to be displayed and goals of the human user play the

important role in differentiating computer graphics from visualization.

According to Munzner [Mun14], the primary motivation for visualization is to enhance

human capacities. The information she mentions to be needed by the visualization designer

is displayed in figure 2.3.

She argues, that humans have to kept in the loop, when the expected information to be

gained from data is still unclear. Her reason is, that this prevents the creation of a fully

automated solution, which would require a clear outline in which way the data should be

processed. In these cases visualization takes advantage of the human effectiveness at pattern

recognition. Yet, ’visualization and a human in the loop’ has not to be the final objective in

these cases; this can act as a stepping stone toward a fully automated solution.

Her reason to include computers in this process is pretty simple: they surpass the human

capability at number crunching by far and therefore offer the ability to create visualizations

fast and with huge accuracy. Additionally, computer aided visualization can be generated

using dynamic data sources and may therefore offer interactivity features.

The argument for using the human sense of visual perception for the presentation of data

is our reliance on visual input in our everyday life, which leaves us highly adapted for optic

processing. The pathway from the eyes to the visual cortex offers high bandwidth and the

image processing is handled in a efficient, parallel way. Whereas other senses, like hearing,

offer only sequential data processing, or lack the needed bandwidth.

Interactivity

Ward, Grinstein, and Keim [WGK10] argue, the user should get as much control over the

visualization process as possible. The reason is, that users and their goals may differ in many

2.5. VISUALIZATION 9

Figure 2.3 The process of visualization

aspects and creating one visualization, which satisfies everyones goals, may prove difficult or

impossible: the effectiveness of a visualization cannot be calculated beforehand.

Munzner [Mun14] mentions resource limitations, mainly of human perception and display

size, which are displayed in figure 2.3 (coffee not mentioned in original literature), as motiva-

tion for interactivity.

Interactivity includes for example manipulations of the view, like zooming or panning,

adjusting of colors, or selection of the data, on which the visualization is based.

3 Related work

The works listed here were very influential on this thesis. Others, which are not mentioned

in this chapter, are referenced throughout this thesis where appropriate.

3.1 Ontology visualization

The ontology visualization tool envisioned in this thesis is based on open web standards; a

path which was first paved by WebVOWL; prior examples of browser based visualizations

required proprietary plugins [Loh+14a].

Overview

The authors of a scientific literature analysis, Mikhailov, Petrov, and Lantow [MPL16], re-

viewed papers, which were published in the field of ontology visualization between the years

2007 to 2015. They limited the selection of papers by only picking those, which were related

to the scientific field and offered new input. They noted, that this field of research is small but

active and analyzed a total sum of 17 papers. Only 8 of those addressed the matter of A-Box

visualization, which is the main purpose of the project described by this thesis. They note,

that the intended end user of a ontology visualization has to be taken in consideration while

creating a visualization, as the requirements may differ depending on the users skill set.

The usage of 2D graphs was noted as a “familiar and intuitive” presentation to users and

therefore most often employed by the reviewed papers. They observed different capabilities

which were added to the visualizations as means to increase user friendliness. Their list

influenced the selection of features for this thesis. According to them, an important part of

future research should focus on scalability, as the data contained in ontologies can grow very

large.

T-Box and A-Box Visualization

Hartmann et al. [Har+17] review visual languages and inspect their A-Box-Capabilities, to

compare them to their own visual language. They refer to A-Box as “Individual View” and

T-Box as “Class View”.

10

3.1. ONTOLOGY VISUALIZATION 11

Use cases and features

The use cases and features of ontology visualizations, which were identified by Dudáš, Za-

mazal, and Svátek [DZS14], were used as foundation to determine visualization requirements

of this thesis. Additionally, the framework for visualization creation established by Munzner

[Mun14] has been very helpful throughout the whole process.

4 Requirements

Here listed are the requirements, which are to be satisfied by the project created during this

thesis. They cover general use cases and the more detailed features, which are needed, to

fulfill them.

4.1 Use cases

Of the ontology visualization use case categories identified in Dudáš, Zamazal, and Svátek

[DZS14], three are within the scope of this work:

• Inspection,

• Learning and

• Sharing.

Not included is the Editing category, as it targets ontology developers and is already covered

by the editing capabilities of the wiki.

4.2 Features

The following features have been identified as desirable through literature analysis and dis-

cussion.

4.2.1 Multiple Views

The employment of multiple views helps to compensate for certain drawbacks of single view

applications; the simultaneous display lowers cognitive load [Mun14]. Fu, Noy, and Storey

[FNS17] come to the conclusion, that graph visualizations offer more value in understand-

ing, while indented lists ease the task of searching. The combination of multiple views for

ontology visualization is also explored by Aurisano, Nanavaty, and Cruz [ANC15].

12

4.2. FEATURES 13

4.2.2 View: Force Directed Graph

As explained in section 2.4 (Networks), the pages of the 101wiki represent nodes of a link

network.

For such networks, the visual encoding as a node–link diagram is an obvious choice [Mun14].

Nodes are displayed as point marks in these diagrams; the connections between those point

marks, which represent links, as line marks. While such a layout could be displayed in 3D, a

two-dimensional representation is usually preferred, as 3D has been proven to be difficult in

most cases [Mun14]. A popular idiom for such a representation is the one of force-directed

placement of nodes, where the spatial position does not encode any information, but is in-

stead based on a physical simulation. This concept is based on repelling forces between

nodes and links acting as springs [Mun14]. The simulation approach has two major draw-

backs [Mun14], which are:

1. the inherent non-deterministic behavior (also mentioned by Lohmann et al. [Loh+14a])

of the simulation, which prevents the exploitation of spatial memory, and

2. scalability; with growing networks the simulation requires more resources and visual

interpretation becomes increasingly difficult.

Force-directed graph layouts are also popular in ontology visualization [Loh+14a]. Visualiza-

tions employing this kind of layout include ProtégéVOWL [Loh+14a], WebVOWL [Loh+14b]

and OSMoSys [Psy15].

The user study conducted by Lohmann et al. [Loh+14a], came to the conclusion, that users

perceive animated force-directed layouts helpful. The display of nodes, circles with links of a

directed graph displayed with arrow heads, was noted as “aligning nicely”. As part of their

study, the following features were recognized to complement force directed graphs:

• continuous zooming (see Zooming and Panning, subsection 4.2.9),

• text search (see Free Text Search, section 4.2.7), and

• highlighting (see Highlighting, section 4.2.6).

The value of using force-directed layouts for time-varying ontologies has been discussed

by Burch and Lohmann [BL15].

An improvement to the force-directed layout it proposed by Hussain et al. [Hus+14], where

a power-law property is added to the algorithm. The implementation of this approach is not

part of this thesis, but could be used in future work.

4.2. FEATURES 14

Drag&Drop Manipulation of Nodes

The ability to manually move nodes has been proven helpful for the understanding of connec-

tions by Lohmann et al. [Loh+14a]. This feature has been employed in ProtégéVOWL [Loh+14a],

WebVOWL [Loh+14b] and others.

4.2.3 View: Indented Tree List

The idea behind this view is, to display the nodes in a hierarchy consisting of their names-

paces and relations. The relationships are encoded using indentation, as mentioned by Fu,

Noy, and Storey [FNS13]; subtrees can be expanded by clicking. Trees lack the ability to

display multiple inheritance [FNS13], which is prone to exist in networks like the 101wiki.

Screen size places limitations on the ability to display the complete tree structure [FNS13].

This feature is described as “class browser” by Katifori et al. [Kat+08]. To prevent obstruction

of the graph view, this view itself should utilize the slide-out navigation pattern, which has

been popularized by iOS1.

On demand expansion of the tree is useful for incremental exploration (see Dudáš, Za-

mazal, and Svátek [DZS14] and Herman, Melançon, and Marshall [HMM00]).

4.2.4 View: Details

When a node is selected, the details of the associated page should be displayed and include

a link to the wiki. This feature has been mentioned by Dudáš, Zamazal, and Svátek [DZS14],

Lanzenberger, Sampson, and Rester [LSR10] and Lambrix et al. [Lam+16] and follows the

visualization mantra of “overview first, zoom and filter, then details-on-demand” [Shn96].

The link to the associated page in the wiki complements the visualization with the edit-

ing feature of the wiki. Other tools employing this feature include OSMoSys [Psy15], We-

bVOWL [Loh+14b] and ProtégéVOWL [Loh+14a].

4.2.5 URL-Encoding of Node Selection

In a similar way as the detailed view can be used to navigate from a selected node to the

represented page in the wiki, the other way should work as well. Therefore, the ability to en-

code the selection of a node as URL should be provided. By this, a simple hyperlink could be

added to the wiki, which takes the user to the visualization. There the node, which represents

the page he viewed before, is already selected and highlighted. These two features combined

represent a meta-feature: a bidirectional link between wiki and visualization.

1http://kenyarmosh.com/ios-pattern-slide-out-navigation

4.2. FEATURES 15

4.2.6 Node Selection

A fundamental action of interactive visualization is the selection of displayed elements [Mun14].

The indented tree list can be used to select nodes, which are then also selected in the graph

view and vice-versa. Selecting a node by clicking triggers the detailed view (see subsec-

tion 4.2.4, View: Details), whereas shift-clicking in the graph view triggers the drag&drop-

behavior (see subsection 4.2.2, Drag&Drop Manipulation of Nodes).

The feature titled Comparing selected Nodes in this subsection below, requires the possi-

bility to select multiple nodes, which can be enabled by control-clicking.

Selected nodes should be highlighted (see this subsection: Highlighting).

This feature is also employed in AVOnEd [Har+17], where it is combined with editing fea-

tures; ProtégéVOWL, WeVOWL[Loh+14a], MEMO GRAPH [Gho+16] and LD-VOWL[WLH16],

which combine it with the display of detailed information and AlignmentVis [ANC15].

Focus on selected entity

When a node is selected, the graph view centers on it and adjusts the zoom factor, to display

the node in a meaningful manner. The view manipulation should work according to Zooming

and Panning and Zooming and Panning.

Centering a selected node is demonstrated by AVOnEd [Har+17], Jambalaya [Kat+14] and

is part of the relevant features of ontology visualization tools identified by Dudáš, Zamazal,

and Svátek [DZS14]. The mathematical foundation for the camera movement of this feature

has been established by Van Wijk and Nuij [VN03].

Comparing selected Nodes

This feature offers the capability to highlight similarities between two nodes by grouped se-

lection. The intended goal for this is to enable comparison between represented technolo-

gies. Such a feature for ontology visualization has, according to Lanzenberger, Sampson, and

Rester [LSR10], been employed by AlViz.

Highlighting

This feature is related to selection, as it offers visual feedback for the selection process, and

depends on the effect of visual pop-out [Mun14]. The desired effect can be achieved by a

change of color, hue, luminance or saturation, of either the selected node or the remaining,

unselected nodes [Mun14]. Additionally, highlighting could be accomplished by adding an

outline mark or change of size, in case of desired color preservation [Mun14]. Another, proven

way of highlighting is by the means of motion [Mun14].

4.2. FEATURES 16

Neighborhood Highlighting Additionally to the selected node, direct neighbors (see subsec-

tion 2.4.1, Neighborhood) could be highlighted to improve the in-

formation available to the user. Lohmann et al. [Loh+14a] note,

that this feature is useful to users, but the original node color should

not be completely replaced. This Feature has also been employed

by OSMoSys [Psy15] and Fenfire [CT15].

Highlight on Hover Nodes, which are hovered with the cursor should be highlighted.

Additionally, when the user has not enabled general display of

node and/or link labels, these should be displayed for the high-

lighted nodes and their links. This has been successfully com-

bined with neighborhood highlighting in OSMoSys [Psy15] and

Fenfire [CT15].

4.2.7 Filtering

Filtering is a strategy of information reduction, which helps handling convoluted visualiza-

tions [Mun14]. In the particular visualization solution of this thesis, it can be applied to nodes

(V ) and links (E) alike.

Free Text Search

This is a feature of item filtering: reducing the amount of displayed nodes by textual match-

ing [Mun14]. Text based search is mentioned as a desirable feature for ontology visualization

by Dudáš, Zamazal, and Svátek [DZS14], while Katifori et al. [Kat+14] note, that keyword

search alone cannot substitute browsing. It is a popular feature of semantic wikis like On-

toWiki [Aue+13] [Fri+15] and IkeWiki [Sch06], as well as ontology visualizations like GoP-

ubMed [DS09], IsaViz [ŽMS15] and MEMO GRAPH [Gho+16]. In the field of taxonomy visu-

alization, ProvenanceMatrix [Dan+15] makes use of a text based search feature.

Several Graph visualizations employ ranking algorithms like TF-IDF with this feature [CT15].

Dadzie and Pietriga [DP17] list the tools LODeX, EarthCube GeoLink and Linked Data

Maps to be supporting query by keywords, while it is “partially supported” by Sparql-FilterFlow,

LinkedPPI and OpenData-ZIS.

Filtering the Graph by Namespaces

This feature reduces the amount of nodes (and consequently links) which are rendered by the

graph display in total. This happens by removing all those, which are not part of selected

namespaces. Links are reduced therefore, by removing those from the view, for which not

4.2. FEATURES 17

both nodes are part of the remaining graph. Graph simplification has been proposed to in-

crease readability of graphs by Chawuthai and Takeda [CT15]. Filtering of elements in general

has, according to Hartmann et al. [Har+17] been employed by GrOWL (UVM), ’GrOWL by

Nova-Semantics’ and AVOnEd. It is part of the recommended features for ontology visualiza-

tion published by Dudáš, Zamazal, and Svátek [DZS14], who gave it the name Filter SpecificEntity Type and list usage in the following visualization tools: Jambalaya, KC-VIZ, Ontograf,

SOVA and TGVizTab.

Enabling/Disabling the Display of Relations by Type

While the amount of relations, which can be used for the simulation of the graph view, is

limited to one, the display can be extended to include every type of relation at once. Literature

on this feature is sparse, Chawuthai and Takeda [CT15] offer automated graph simplification

by removing same-as and transitive edges, but manipulation of the displayed edges has not

been employed. Furthermore, Hartmann et al. [Har+17] and Katifori et al. [Kat+07] only

mention the possibility to filter nodes. The question, whether this kind of feature has already

been employed in the field of ontology visualization and how well it fares in terms of usability

is suspended for future research.

4.2.8 Customization

The ability to customize ontology visualization has been proposed by Fu, Noy, and Storey

[FNS13].

This work splits customization into two categories: modification of display and simulation

settings.

Display Settings

Display of the annotation for links and nodes, as well as color encoding are optional. The

rationale behind this is, that the ontology designer cannot know the exact goals of the users.

In case of exporting the graph for presenting it to an audience, the specific information, which

visualization user wants to transport with the image, cannot be foreseen. In case of enjoyment,

one users preferences may differ vastly from those of others.

The visual language VOWL 2 includes for this reason the capability to change the pre-

defined color scheme[Loh+14a]. Color customization has additionally been employed by

AVOnEd [Har+17], Tree Viewer [Kat+07]. Means of visual customization are also part of

GViz [LSR10] and Haystack, the latter one using stylesheets for this feature [BS16].

4.2. FEATURES 18

Simulation Settings

The default settings of the simulation may not be appropriate for every subgraph or every

use case, therefore the visualization should offer the ability to adust settings like the repelling

force between nodes or the attracting spring force of links. This feature has also been demon-

strated in WebVOWL, where it helped to increase readability in certain cases [Loh+14a].

4.2.9 Zooming and Panning

Zooming and panning are means of navigation, which is a term for a change of view point [Mun14].

For this work they are meant to be used together with the graph view (see View: Force Di-

rected Graph). Panning is translational movement of the layout. Zooming, in the context of

this work, has to be understood as geometric zooming: increasing or decreasing the size of

the displayed graph and its elements. Zooming out can be used to obtain overview of the

graph structure, whereas zooming in helps to inspect individual elements. To prevent the

user from completely losing the graph during his exploration, the navigation should be con-

strained [Mun14]. Zooming out should be limited to a factor where the complete graph can

be seen, zooming in to a point, where no further information could be gathered by increasing

the size of the displayed elements. Additionally a button to reset the view could help the user,

in case he gets confused despite the constrained navigation.

The small questionnaire published by Ghorbel et al. [Gho+16] came to the result, that all

participants (which consisted of non-expert Alzheimer’s patients) awarded the zoom feature

for the presented graph visualization with the maximum of available scoring points in regards

to usefulness.

Zooming and panning have also been employed by WebVOWL and ProtégéVOWL [Loh+14b],

LD-VOWL [WLH16].

Geometric (graphical) zoom and the ability to zoom out for a graph overview have been

mentioned as desirable features for ontology visualization by Dudáš, Zamazal, and Svátek

[DZS14]. The creators of AVOnEd, Hartmann et al. [Har+17], name zooming to be a rele-

vant feature for effective visualization. [Kat+07] acknowledge the zoomable approach to be

beneficial for browsing.

4.2.10 Manipulation of Clustering

This feature is about selecting the relation, by which the force directed simulation is calcu-

lated. By default, this is the namespace relationship. Selecting a different relation should

result in an update of the graph view. Nodes, which do not use the selected relation, have to

be omitted from the view.

4.2. FEATURES 19

When talking about clustering, the usual approach is structure-based, whereas the ap-

proach of this work utilizes the, in general less prevalent, method of content-based cluster-

ing [HMM00]. This is attained through the knowledge of the semantic type of relationships

between nodes and therefore highly specific to the particular solution presented in this work.

If this feature of hot-swapping the links for the force-directed simulation has been em-

ployed in the field of ontology visualization before is unknown to me. Clarification of this

requires more analysis of related work in the future.

4.2.11 Graph export

This feature allows to export the graph or a subgraph as an image, which should preferably

be in a vector format like SVG.

This is part of the production goal mentioned by Munzner [Mun14], specifically the ability

to record the visualization as a graphical artifact which then can be used for presentation.

Žácek, Miarka, and Sykora [ŽMS15] mentioned the export of images as valuable for includ-

ing presentations of graphs in other forms of work.

This feature has for example been realized in the ontology visualization tool WebVOWL [Loh+14b].

Figure 2.2 is a result of the implementation of graph export used in this work; annotations

have been added by hand.

4.2.12 History

The visualization should offer the feature of recording navigational steps, i.e. switching node

selections, and equip users with the ability to undo/redo those actions.

This feature has been mentioned by Dudáš, Zamazal, and Svátek [DZS14] and employed

by AIViz[LSR10]; furthermore Katifori et al. [Kat+07] report the feature to be available in the

tools Jambalaya, Information Pyramids and CropCircles.

4.2.13 Color Encoding of Namespaces

Displaying nodes in distinct colors, depending on the namespace they belong to, has been

proven difficult, as the amount of colors, which humans can discern, is limited to the number

of roughly 12 [Mun14]; the 101wiki contains 23 different namespaces.

As color is also part of the highlighting feature (see subsection 4.2.6, Highlighting), the

difficulty is further increased.

It is therefore reasonable to allow the user customization or disabling of the namespace

color mapping, to adapt the visualization to his specific needs and use case. Nodes are drawn

as circles, consisting of outline and filling. Depending on the zoom factor, these could be

4.2. FEATURES 20

visually discerned and the combination of two different colors could increase the amount of

distinguishable color encodings.

Furthermore the feature could be enhanced by establishing a visual language to encode

namespaces, in future work.

Color encoding has also been part of the user study on VOWL 1, which influenced the cre-

ation of the visual language VOWL 2 [Loh+14a]. The tool NaviGO encodes “GO Categories”

in different colors [Wei+17]; Dasiopoulou et al. [Das+15] based their work on VOWL and used

color to encode type.

The paper published by Iv and Gomaa [IG00] offers an extensive list of dos and dont’s

when using color in graphical software modeling languages. Especially the guideline to limit

color usage to redundant information should be adhered.

5 Design

Here described is the general design of this software project and its parts. The data flow

between the key components is visualized in abstract manner in figure 5.1.

Figure 5.1 Data flow between visualization components

5.1 Key Components

Here follow descriptions for the components depicted in figure 5.1.

21

5.1. KEY COMPONENTS 22

5.1.1 wikiLib

This library is fed the raw data in the file wiki-links.json. It offers functions to normalize

this data; other parts of the software may only use the normalized data returned by this

library. Additionally, the following functions can be found here:

• retrieval of namespace identifiers,

• retrieval of relationship names,

• mapping from page keys (parent-name-pairs) to page objects and

• retrieval of relationship specific nodes and links.

5.1.2 graphLib

Functions of this library are used to create and mutate a graph object. This graph object

contains the complete namespace graph and all subgraphs for relationships. Mutation of the

graph object includes the ability to swap the links used in the simulation. The graph data is

created in the manner as it is required for consumption by the simulation code.

5.1.3 treeLib

This library is the foundation for the indented tree view. Relations and namespace have to

be transformed into a tree structure. Relations containing loops may be filtered out at the

beginning to speed up development, but should be resolved in later implementations.

5.1.4 simulation

This module should act as an abstraction layer between an existing implementation of a force-

directed graph layout and this project. Part of this module is the ability to shortly freeze the

simulation and reinitialize it with new graph data; this allows for hot-swapping of the links on

which the simulation is based. The simulation attaches positional information to the nodes,

which can be used for rendering.

5.1.5 graphRenderer

This module has to be implemented in such a way, that it can be easily replaced with another

renderer, as long as the provided interface is equal. Therefore the encapsulation paradigm has

to be adhered strictly when developing and using this module. Here contained are graph in-

teractivity features. The renderer should be able to adjust the graphical representation, when

5.1. KEY COMPONENTS 23

display settings are changed by the user. The force-directed graph view (see subsection 4.2.2,

View: Force Directed Graph) is an aggregation of the graphRenderer and the simulation mod-

ule described above.

5.1.6 detailView

This module offers the detailed view (see 4.2.4, View: Details). It should display all relations

of a selected page to its neighbors (see 2.4.1, Neighborhood). Additionally, it has to contain a

link to the wiki, which transports the user to the page, which is represented by the selected

node. An icon, which directly links to the editing feature of the named page, may be helpful

as well.

5.1.7 treeView

Herein contained is the functionality of the indented tree view feature (see 4.2.3, View: In-

dented Tree List). It should offer the ability to collapse and expand the tree and subtrees.

5.1.8 viewBus

To provide each view with information about selection changes in other views, this module

works as a communication channel between the views. This functionality is required to rep-

resent the user with a faceted view, instead of independent views without any connection to

each other.

6 Implementation

This chapter describes, which technologies where selected to implement prototype of the de-

scribed visualization. Certain Issues, like data anomalies, which were observed during the

implementation, are reported here as well. Further implementation details can be found in

the documentation, which is generated via JSDocc1 from source code.

6.1 Selected technologies

Most relevant technologies for the ontology visualization of this thesis are listed in this sec-

tion.

6.1.1 JavaScript

JavaScript is the common standard for interactive websites and modern web applications, as it

is widely supported by web browsers2. This project will employ the 6th edition of JavaScript,

which is officially named ECMAScript 20153.

6.1.2 Visualization: D3.js

D3.js4 (Data driven documents) is a widely used framework for data visualization. As such

it is also a prominent contender in the field of graph visualization. A force-driven layout

for network graphs is part of the standard set of D3.js modules5.It is in fact highly popular

with many researchers in the field of ontology visualization. While it is mainly used for it’s

features in handling SVG, its modularity makes it also possible to substitute this rendering

instrument by canvas.

1https://github.com/jsdoc3/jsdoc2https://kangax.github.io/compat-table/es5/3http://www.ecma-international.org/ecma-262/6.0/index.html4https://d3js.org/5https://github.com/d3/d3/blob/master/API.md#forces-d3-force

24

6.1. SELECTED TECHNOLOGIES 25

6.1.3 Rendering

Canvas By selecting D3 as underlying technology to create the force layout, the amount

of easily accessible rendering technologies is narrowed down to canvas and SVG.

Solutions with WebGL would require more effort, as most examples6 and the

documentation7 are mainly tailored towards using SVG, with canvas only being

the second choice.

Kirk [Tel16] argues, that SVG is the simpler technology and offers faster results.

He also admits, that canvas is “generally high performing”, in cases, where

frame rate matters. As the force layout demands for rapid redrawing of many

nodes during the simulation, canvas is the superior choice, even though this so-

lution might be arduous and in the case of interactivity “doubly so”.

canvas2svg This library8 provides a mock canvas context, which can be used to create vector

graphics from canvas code, by offering conversion to SVG. This way rendering

code written for canvas could be reused to produce images in printing quality.

6.1.4 UI

dat.gui While building this module failed initially, it could be added by importing the al-

ready built version and is used, to test out different parameters and colors for the

visualization. It allows for playful engagement with simulation internals and speeds

up prototyping, as rebuilding the project is not required to change settings.

Issue: dat.GUI

Even though this interface persuades with its ease of use for the developer, there are still

some non-trivial issues which had to be resolved during the implementation and shall be

noted here for further reference.

select all The implementation of this feature was not straightforward, as the function

GUI.listen9 did nothing to update the checkboxes, when their corresponding

value in the settings changed. This required a hack, to manually update all check-

boxes, when the user triggered the “select all”-function. For this, the call to listen

was removed (see line 14, listing 1) and code to manually update the checkboxes

was added (see lines 16-20 in listing 2).

6https://bl.ocks.org/mbostock7https://github.com/d3/d3/blob/master/API.md8https://github.com/gliffy/canvas2svg9https://github.com/dataarts/dat.gui/blob/master/src/dat/gui/GUI.js

6.1. SELECTED TECHNOLOGIES 26

1 relationDrawing.add(settings.relationDrawing, 'select all')2 .onChange(function (val) {3 /**4 * update data for all relations5 */6 Object.keys(settings.relationDrawing.relations).forEach(function

(relationName) {↪→

7 settings.relationDrawing.relations[relationName] = val8 })9 vis.rendererSettingsUpdated()

10 })11

12 relationNames.forEach(function (relationName) {13 relationDrawing.add(settings.relationDrawing.relations, relationName)14 .listen()15 .onFinishChange(vis.rendererSettingsUpdated)16 })

Listing 1 Non-working code for the “select all”-feature (works with version 0.6.3 and above ofdat.GUI).

This bug has, at the time of this writing, been resolved for 6 months, with version

0.6.3 of dat.GUI. It managed to creep into this project, as dat.GUI was installed

through the means of npm, where the version 0.6.1 was the most current one, while

the project on GitHub has currently the version. For further reference, follow up on

bug #40 in the change-log10 and issue list11 of dat.Gui.

Including the current version in the static-folder and referencing it in src/settings.js

fixed the issue. The code in listing 1 works as a fix for earlier versions nonetheless.

10https://github.com/dataarts/dat.gui/blob/master/CHANGELOG.md11https://github.com/dataarts/dat.gui/issues/40

6.1. SELECTED TECHNOLOGIES 27

1 /**2 * the function controller.listen() does not work as intended, therefore3 * this little hack, which updates the checkboxes and calls 'setValue' was

needed↪→

4 */5 relationDrawing.add(settings.relationDrawing, 'select all')6 .onChange(function (val) {7 /**8 * update data for all relations9 */

10 Object.keys(settings.relationDrawing.relations).forEach(function(relationName) {↪→

11 settings.relationDrawing.relations[relationName] = val12 })13 /**14 * update checkboxes for relations where they now differ from the

value↪→

15 */16 gui.__folders.drawing.__folders.relations.__controllers17 .filter(controller => controller.__checkbox.checked !== val)18 .forEach(function (controller) {19 controller.setValue(val) // update checkboxes20 })21 vis.rendererSettingsUpdated()22 })23

24 relationNames.forEach(function (relationName) {25 relationDrawing.add(settings.relationDrawing.relations, relationName)26 .onFinishChange(vis.rendererSettingsUpdated)27 })

Listing 2 Fixed code for the “select all”-feature, which works with version 0.6.1 of dat.GUI.

6.2. DATA ANOMALIES 28

6.1.5 Framework

Vue.js Vue was selected while prototyping, as it was first sampled because of its smaller

code size compared to other frameworks. The command line utility, which provides

the very helpful webpack template12 helped in consolidate this decision.

Issue: assetsPublicPath for build environment

In case the webapp will not run on the root directory on a web server, the variable assetsPublicPath

has to be changed from '/' to './' in the file config/index.js.

6.2 Data anomalies

Here listed are several anomalies which where noted in the data and have to be compensated

by normalization.

6.2.1 Relations to the ’Concept’ Namespace

Problem Relations to pages with the parent 'Namespace:Concept' may have

the value null in their 'p'-attribute. This happens for example in the

'IsA' relation of the page 'Concept:Static Annotation' (see List-

ing 4), which references the page

'Concept:Annotation' (see Listing 3).

Proposed solution The attribute 'p' could be assigned the value 'Concept', when such a

page exists. Otherwise it should be assumed, that the page, to which the

relation is expressed, does not exist. (see subsection 6.2.2, Other relations

to nonexistent pages)

16 "n": "Annotation",17 "p": "Concept",

Listing 3 'p' and 'n'-attributes of the page 'Concept:Annotation'

12https://github.com/vuejs-templates/webpack

6.2. DATA ANOMALIES 29

1 {2 "IsA": [3 {4 "n": "Annotation",5 "p": null6 }7 ],

Listing 4 Description of the 'IsA'-relation in 'Concept:Static Annotation'

6.2.2 Other relations to nonexistent pages

Problem Apart from relations to the page 'Namespace:Concept' there are

several relations to pages which do not exist or have null as 'p'-

attribute.

Proposed solution 1 Normalize the relations by removing all those which match the pattern

described above.

Proposed solution 2 Create dummy pages for those relations and mark them as missing, so

they can be displayed as such. For relations, where the 'p'-attribute is

null, this would also require a dummy parent page. This page could

be named 'null' and relations and dummy pages normalized, to refer

to this page.

6.2.3 Pages with inconclusive p-attributes

Through the function getParentList, which is defined in listing 5, is it possible to retrieve

an array which contains each page of the wiki accompanied by a an array of parent page

candidates, which can be identified by the 'p'-attribute of this page.

Applying the function getParentListSum (see listing 6) to this list yields the following

result:

> (4) [0, 1, 2, 3].

The desired result, which would require unique 'n'-attributes for all pages, would look

like this:

> (1) [1].

The function getParentListCount (see listing 7) identifies the amount of pages which

have a specific number of parent candidates. Applying it to the list returned by getParentList,

yields the following result:

{0: 19, 1: 177, 2: 1184, 3: 500}.

This result has the following meaning:

6.2. DATA ANOMALIES 30

0: 19 it is not possible to find a parent candidate through the 'p'-attribute of 19 pages,

1: 177 only 177 pages have the desired amount of 1 parent candidate,

2: 1184 1184 pages have two possible parent candidates and

3: 500 300 pages have even three of them.

Therefore, this anomaly can be identified like so:

Problem Parent pages can not be identified conclusively just by using the 'p'-

attribute.

Proposed solution As this has no simple solution, this problem shall be split into parts and

each part further analyzed to come up with a solution. Pages without

parent candidates are handled in subsection 6.2.4, pages with two and

three in subsection 6.2.5.

1 export function getParentList (pages) {2 return pages.map(page =>3 [4 page,5 pages.filter(parentCandidate =>6 parentCandidate.n === page.p7 )8 ]9 )

10 }

Listing 5 Retrieving an array of arrays containing each page with its possible parents using 'p'-attribute

6.2. DATA ANOMALIES 31

1 import { uniq } from 'lodash'2

3 export function getParentListSum (parentList) {4 return uniq(parentList.map(parentArray => parentArray[1].length)).sort()5 }

Listing 6 summing up the amount parent page candidates retrieved by getParentList

1 import { uniq } from 'lodash'2

3 export function getParentCount (parentList) {4 const countsObj = {}5 const counts = parentList.map(parentArray =>6 parentArray[1].length7 )8 uniq(counts).forEach(c =>9 (

10 countsObj[c] = counts.filter(i => i === c).length11 )12 )13 return countsObj14 }

Listing 7 get the amount of pages which have a specific number of parent candidates

6.2.4 Pages with no parent candidates

As mentioned in subsection 6.2.3 (Pages with inconclusive p-attributes), 19 pages have no

parent candidate, which could be identified through these pages 'p'-attribute. This means,

that no page can be found, which has the respective 'p'-attribute as their 'n'-attribute. To

gain further information about these pages, one has first to retrieve them using

see

listing 8

const orphans = filterByParentCount(parentList, 0).

Afterwards they can be used to create a list of the missing parent candidates and the pages

which reference the respective candidate, by calling

see

listing 9

getOrderedMissing(pages, orphans).

This list is displayed in listing 10. The information presented by it can be split into two

categories:

1. the parent candidate with the 'n'-attribute ' Technology' is apparently missing be-

cause of a typing mistake (the attribute begins with a space character and is referenced

6.2. DATA ANOMALIES 32

by a single page: ' Technology:Email'), as the page with the name 'Technology'

does exist13.

2. The remaining, missing parent candidates would have the 'n'-attributes 'Category',

'Internal', 'Issue' and 'Tag'.

The two underlying problems allow for the following categorizations:

Problem 1 A typo in the 'p'-attribute of the page ' Technology:Email'.

Proposed solution Delete the page from the wiki, as the page with the correct written 'p'-

attribute does exist as well14.

Problem 2 The parent for some pages has not yet been created.

Proposed solution For the visualization, the pages with missing parent candidates shall be

removed; or the data modified to include parent candidates, which would

be marked as missing and displayed as such in the visualization.

In the long term these missing pages should be added to the wiki.

1 export function filterByParentCount (parentList, parentCount) {2 return parentList.filter(parentArray =>3 parentArray[1].length === parentCount4 ).map(parentArray =>5 parentArray[0]6 )7 }

Listing 8 filter pages by a specific number of parent candidates

13https://101wiki.softlang.org/Concept:Technology14Technology:Email

6.2. DATA ANOMALIES 33

1 import { uniq } from 'lodash'2

3 export function getOrderedMissing (pages, orphans) {4 const nonExistentPages = uniq(orphans.map(orphan => orphan.p)).sort()5 const orderedMissing = (ordered => {6 nonExistentPages.forEach(pageName =>7 (8 ordered[pageName] = pages.filter(page => page.p === pageName)9 .map(page => page.p + ':' + page.n)

10 )11 )12 return ordered13 })({})14 return orderedMissing15 }

Listing 9 Get an ordered list of missing parent candidates and the pages referencing them.

1 > {" Technology": Array(1), Category: Array(2), Internal: Array(3),Issue: Array(6), Tag: Array(7)}↪→

2 > " Technology": [" Technology:Email"]3 > Category: (2) ["Category:101view", "Category:101proposer"]4 > Internal: (3) ["Internal:Courses", "Internal:FrontPage",

"Internal:Resources"]↪→

5 > Issue: (6) ["Issue:Parsing1", "Issue:Parsing2","Issue:BigFragmentErrorMessage", "Issue:ShowEqualsFalse","Issue:DiscoverFolders", "Issue:NotFound"]

↪→

↪→

6 > Tag: (7) ["Tag:Stub", "Tag:Obscurity", "Tag:Experiment","Tag:Ambiguity", "Tag:Synonym", "Tag:Abbreviation", "Tag:Legacy"]↪→

Listing 10 List of missing parent candidates and the pages referencing them

6.2. DATA ANOMALIES 34

6.2.5 Pages with two and three parent candidates

For the majority of pages (see subsection 6.2.3 (Pages with inconclusive p-attributes)) the

parent page cannot be identified by the 'p'-attribute alone. These can be retrieved through

see

listing 8

const twoParents = filterByParentCount(parentList, 2)

and

const threeParents = filterByParentCount(parentList, 3)

respectively. Narrowing down the parent candidates by filtering out those, which do not have

'Namespace' as 'p'-attribute, is done as follows:

see

listing 11

getOnlyNamespaceParentCandidates(pages, twoParents)

getOnlyNamespaceParentCandidates(pages, threeParents).

This process reveals, that for each 'p'-attribute with at least one parent candidate, exists exactlyone page, which has this as 'n'-attribute and 'Namespace' as 'p'-attribute.

Problem The 'p'-attribute is in the majority of cases not sufficient, to identify the

parent page.

Proposed solution These can all be narrowed down to one parent candidate, by filtering out

those candidates, which do not have 'Namespace' as 'p'-attribute.

1 import { uniq } from 'lodash'2

3 export function getOnlyNamespaceParentCandidates (pages, filteredPages) {4 return uniq(filteredPages.map(page => page.p))5 .map(parentCandidateName => pages6 .filter(page => page.n === parentCandidateName && page.p ===

'Namespace')↪→

7 )8 }

Listing 11 Retrieve to a list of filtered pages those parent candidates, which have 'Namespace' as'p'-attribute.

6.3. CODE HIERARCHY 35

6.3 Code Hierarchy

The actual code hierarchy of an early prototype is displayed in figure 6.1.

analysis

canvasRenderer

d3

globalSettings

graphLib

main.css

settings

simulation

treeLib

treeView

wikiLib

src/101vis.js

analysis

canvasRenderer

d3

globalSettings

graphLib

main.css

settings

simulation

treeLib

treeView

wikiLib

src/101vis.js

Slideout

ViewTemplate

globalSettings

src/App.vue

Slideout

ViewTemplate

globalSettings

src/App.vue

DebugBus

components/DebugBar.vue

DebugBus

components/DebugBar.vue

DebugBar

components/ViewTemplate.vue

DebugBar

components/ViewTemplate.vue

analysis/analysis.jsanalysis/analysis.js

remove

lodash/array.js

remove

lodash/array.js

assert/assert.jsassert/assert.js

canvas2svg/canvas2svg.jscanvas2svg/canvas2svg.jsC2S

DebugBus

ViewBus

debug.css

graphLib

src/canvasRenderer.js

C2S

DebugBus

ViewBus

debug.css

graphLib

src/canvasRenderer.js

static/dat.gui.min.jsstatic/dat.gui.min.js

static/debug.cssstatic/debug.css

DebugBus

Vue

src/debugbus.js

DebugBus

Vue

src/debugbus.js

globalSettings

src/globalSettings.js

globalSettings

src/globalSettings.js

extractRelationNames

pageIsInNamespaces

remove

wikiLib

src/graphLib.js

extractRelationNames

pageIsInNamespaces

remove

wikiLib

src/graphLib.js

vue/.../index.d.tsvue/.../index.d.ts

d3/index.jsd3/index.js

lodash/lodash.jslodash/lodash.js

static/main.cssstatic/main.css

App

Vue

vis

src/main.js

App

Vue

vis

src/main.js

static/presets.jsonstatic/presets.json

dat

extractRelationNames

presets

src/settings.js

dat

extractRelationNames

presets

src/settings.js

graphLib

src/simulation.js

graphLib

src/simulation.js

_

wl

src/treeLib.js

_

wl

src/treeLib.js

assert

tl

src/treeLib.test.js

assert

tl

src/treeLib.test.js

static/treeview.cssstatic/treeview.css

ViewBus

treeLib

treeview.css

wikiLib

src/treeview.js

ViewBus

treeLib

treeview.css

wikiLib

src/treeview.js

ViewBus

Vue

src/viewbus.js

ViewBus

Vue

src/viewbus.js

vue-slideout/.../vue-slideout.jsvue-slideout/.../vue-slideout.js

_

extractRelationNames

pageIsInNamespaces

src/wikiLib.js

_

extractRelationNames

pageIsInNamespaces

src/wikiLib.js

Figure 6.1 Evolved code hierarchy

6.4 Showcase

This subsection presents visual impression of a prototype of the visualization, which has been

created for this thesis.

6.4. SHOWCASE 36

6.4.1 Interface

Figure 6.2 is a screenshot of the interface, with the graph drawn on the left, the tree view on

the right and settings in the same slide-out-panel as the tree view.

Figure 6.2 The interface of a prototype.

6.4.2 graphRenderer

Here are some examples of graphs, created with the visualization and customized colors.

Figure 6.3 displays the complete namespace graph of the 101wiki. Figure 6.4 shows the

same graph, with the display of all relations enabled.

In figure 6.5 is the subgraph consisting of the 'InstanceOf'-relation displayed. fig-

ure 6.6 shows the same subgraph, again, with the display of all relations enabled. Finally,

figure 6.7 still shows the same subgraph with all relations enabled, this time with a different

color scheme.

6.4. SHOWCASE 37

Figure 6.3 All nodes and links of the 101wiki (display errors due to the conversion from svg to pdf).

6.4. SHOWCASE 38

Figure 6.4 All nodes and links of the 101wiki, display of all relations enabled.

6.4. SHOWCASE 39

Figure 6.5 Nodes and links of the 'InstanceOf'-relation.

6.4. SHOWCASE 40

Figure 6.6 Nodes and links of the 'InstanceOf'-relation with the display of all relations enabled.

6.4. SHOWCASE 41

Figure 6.7 Nodes and links of the 'InstanceOf'-relation with the display of all relations enabled,different color scheme.

7 Concluding remarks

Throughout this work, the integration of an ontology visualization into a semantic wiki has

been outlined by identifying desired key features. Two features, which were not mentioned

in the reviewed related work have, been introduced:

• The idea of bidirectional linking between visualization and the wiki, to complement

their features.

• Possibly the introduction of hot swapping links of a force-directed graph in ontology

visualization.

The described visualization tool has been implemented as a prototype, which can be incorpo-

rated into the 101wiki, without requiring any additional server-side installation apart from a

standard web server.

7.1 Limitations

In terms of the wiki integration this solution lacks the ability to display live data. The visual-

ization is based on a dump, to changes applied to the wiki will not update the visualization

itself. Instead the user will have to wait, until a new dump has been created and completely

reload the visualization.

Bidirectional linking between visualization and wiki, as well as hot-swapping links of a

force-directed graph in ontology visualizations have been listed as possible contributions of

this work. Selected literature and search terms may have been insufficient to obtain existing

research of these points.

Additionally, the ability to enable and disable the display of relations by type has not been

found in the literature. If this constitutes another contribution to ontology visualization, has

to be examined.

7.2 Future work

Apart from the limitations mentioned above, the following possibilities have been noted for

future research.

42

7.2. FUTURE WORK 43

7.2.1 Error detection

The 101wiki follows the wiki paradigm of “making it easy to correct mistakes, rather than

making it hard to make them”. Through the creation of this work, several inconsistencies in

the semantic data have been noticed, which would be easy to correct. Therefore the 101wiki

should incorporate means to display a list of automatically recognizable, possible mistakes

for human review. As handling these anomalies is part of the normalization process of the

visualization, it could also be included in the visualization itself.

7.2.2 Information Encoding

While everything in the visualization can be encoded with textual description, it is not easy

to grasp these annotations through a quick look. Color does help with this, but has certain

limitations for color-blind users and the amount of humanly distinguishably colors in general.

Therefore a symbolic language using icons for namespaces could be established, which then

would be used in the wiki and visualization. The paper “What is a visual language?” by

Erwig, Smeltzer, and Wang [ESW17] can be used as a starting point on visual languages.

7.2.3 Simulation

MathBox2 could probably be used to calculate the force layout on the gpu, as has been pro-

posed by its author in a presentation1.

7.2.4 Rendering

Presentation rendering could be much faster if it used WebGL instead of canvas. Possible

libraries for this include three.js, pixi.js and maybe MathBox2 as well.

1http://acko.net/files/pres/siggraph-2014-bof/online.html

Bibliography

[ANC15] Jillian Aurisano, Amruta Nanavaty, and Isabel F Cruz. “Visual Analyticsfor Ontology Matching Using Multi-linked Views.” In: VOILA@ ISWC.2015, p. 25.

[Aue+13] Sören Auer et al. “Introduction to linked data and its lifecycle on theweb”. In: Reasoning Web. Semantic technologies for intelligent data access.Springer, 2013, pp. 1–90.

[BL15] Michael Burch and Steffen Lohmann. “Visualizing the Evolution of On-tologies: A Dynamic Graph Perspective.” In: VOILA@ ISWC. 2015, p. 69.

[Bro+00] Andrei Broder et al. “Graph structure in the web”. In: Computer networks33.1 (2000), pp. 309–320.

[BS16] Nikos Bikakis and Timos Sellis. “Exploration and visualization in theweb of big linked data: A survey of the state of the art”. In: arXiv preprintarXiv:1601.08059 (2016).

[CT15] Rathachai Chawuthai and Hideaki Takeda. “RDF Graph Visualization byInterpreting Linked Data as Knowledge”. In: Joint International SemanticTechnology Conference. Springer. 2015, pp. 23–39.

[Dan+15] Tuan Dang et al. “ProvenanceMatrix: A Visualization Tool for Multi-taxonomy Alignments.” In: VOILA@ ISWC. 2015, p. 13.

[Das+15] Stamatia Dasiopoulou et al. “Representing and Visualizing Text as On-tologies: A Case from the Patent Domain.” In: VOILA@ ISWC. 2015, p. 83.

[DP17] Aba-Sah Dadzie and Emmanuel Pietriga. “Visualisation of Linked Data–Reprise”. In: Semantic Web 8.1 (2017), pp. 1–21.

[DS09] Andreas Doms and Michael Schroeder. Semantic Search with GoPubMed.2009.

44

Bibliography 45

[DZS14] Marek Dudáš, Ondrej Zamazal, and Vojtech Svátek. “Roadmapping andnavigating in the ontology visualization landscape”. In: International Con-ference on Knowledge Engineering and Knowledge Management. Springer.2014, pp. 137–152.

[ESW17] Martin Erwig, Karl Smeltzer, and Xiangyu Wang. “What is a visual lan-guage?” In: Journal of Visual Languages & Computing 38 (2017), pp. 9–17.

[Fav+12] Jean-Marie Favre et al. “101companies: a community project on softwaretechnologies and software languages”. In: Objects, Models, Components,Patterns (2012), pp. 58–74.

[FNS13] Bo Fu, Natalya F Noy, and Margaret-Anne Storey. “Indented tree orgraph? A usability study of ontology visualization techniques in the con-text of class mapping evaluation”. In: International Semantic Web Confer-ence. Springer. 2013, pp. 117–134.

[FNS17] Bo Fu, Natalya F Noy, and Margaret-Anne Storey. “Eye tracking the userexperience–An evaluation of ontology visualization techniques”. In: Se-mantic Web 8.1 (2017), pp. 23–41.

[Fri+15] Philipp Frischmuth et al. “Ontowiki–an authoring, publication and visu-alization interface for the data web”. In: Semantic Web 6.3 (2015), pp. 215–240.

[Gho+16] Fatma Ghorbel et al. “MEMO GRAPH: An Ontology Visualization Toolfor Everyone”. In: Procedia Computer Science 96 (2016), pp. 265–274.

[Gru09] Tom Gruber. “Ontology”. In: Encyclopedia of database systems (2009), pp. 1963–1965. URL: http://tomgruber.org/writing/ontology-definition-2007.htm.

[Har+17] Stefan Hartmann et al. “Aspect-Oriented Visual Ontology Editor (AVOnEd):Visual Language, Aspect-Oriented Editing Concept and Implementation”.In: International Journal of Semantic Computing 11.02 (2017), pp. 229–274.

[HMM00] Ivan Herman, Guy Melançon, and M Scott Marshall. “Graph visualiza-tion and navigation in information visualization: A survey”. In: IEEETransactions on visualization and computer graphics 6.1 (2000), pp. 24–43.

[Hus+14] Ajaz Hussain et al. “Scalable visualization of semantic nets using power-law graphs”. In: Applied Mathematics & Information Sciences 8.1 (2014),p. 355.

Bibliography 46

[IG00] Robert G Pettit Iv and Hassan Gomaa. “Validation of dynamic behav-ior in UML using colored Petri nets”. In: Proc. of UMLt’2000 Workshop-Dynamic Behavior in UML Models: Semantic Questions. Vol. 1939. 2000,pp. 295–302.

[Iva+15] Valentina Ivanova et al. “Proceedings of the International Workshop onVisualizations and User Interfaces for Ontologies and Linked Data”. In:International Workshop on Visualizations and User Interfaces for Ontologiesand Linked Data, October 11, Bethlehem, Pennsylvania, USA. CEUR Work-shop Proceedings. 2015.

[Kat+07] Akrivi Katifori et al. “Ontology visualization methods—a survey”. In:ACM Computing Surveys (CSUR) 39.4 (2007), p. 10.

[Kat+08] Akrivi Katifori et al. “Selected results of a comparative study of fourontology visualization methods for information retrieval tasks”. In: Re-search Challenges in Information Science, 2008. RCIS 2008. Second Interna-tional Conference on. IEEE. 2008, pp. 133–140.

[Kat+14] Akrivi Katifori et al. “Visualization method effectiveness in ontology-based information retrieval tasks involving entity evolution”. In: Seman-tic and Social Media Adaptation and Personalization (SMAP), 2014 9th Inter-national Workshop on. IEEE. 2014, pp. 14–19.

[Lam+16] Patrick Lambrix et al. “Visualization for Ontology Evolution”. In: 2ndInternational Workshop on Visualization and Interaction for Ontologies andLinked Data. 2016, pp. 54–67.

[Läm17] Ralf Lämmel. Thoughts on a very semantic wiki. https://professor-fish.blogspot.de/2017/07/thoughts-on-very-semantic-

wiki.html. 2017.

[Loh+14a] Steffen Lohmann et al. “VOWL 2: User-oriented visualization of ontolo-gies”. In: International Conference on Knowledge Engineering and KnowledgeManagement. Springer. 2014, pp. 266–281.

[Loh+14b] Steffen Lohmann et al. “WebVOWL: Web-based visualization of ontolo-gies”. In: International Conference on Knowledge Engineering and KnowledgeManagement. Springer. 2014, pp. 154–158.

Bibliography 47

[LSR10] Monika Lanzenberger, Jennifer Sampson, and Markus Rester. “OntologyVisualization: Tools and Techniques for Visual Representation of Semi-Structured Meta-Data.” In: J. UCS 16.7 (2010), pp. 1036–1054.

[MPL16] Sergey Mikhailov, Mikhail Petrov, and Birger Lantow. “Ontology Visu-alization: A Systematic Literature Analysis.” In: BIR Workshops. 2016.

[Mun14] Tamara Munzner. Visualization analysis and design. CRC press, 2014.

[Psy15] Achilleas Psyllidis. “OSMoSys: a web interface for graph-based rdf datavisualization and ontology browsing”. In: International Conference on WebEngineering. Springer. 2015, pp. 679–682.

[Rei05] D Reinhard. Graph Theory III. 2005.

[Rud11] Sebastian Rudolph. “Foundations of description logics”. In: ReasoningWeb. Semantic Technologies for the Web of Data. Springer, 2011, pp. 76–136.

[Sch06] Sebastian Schaffert. “IkeWiki: A semantic wiki for collaborative knowl-edge management”. In: Enabling Technologies: Infrastructure for Collabora-tive Enterprises, 2006. WETICE’06. 15th IEEE International Workshops on.IEEE. 2006, pp. 388–396.

[Shn96] Ben Shneiderman. “The eyes have it: A task by data type taxonomy forinformation visualizations”. In: Visual Languages, 1996. Proceedings., IEEESymposium on. IEEE. 1996, pp. 336–343.

[SS10] Steffen Staab and Rudi Studer. Handbook on ontologies. Springer Science& Business Media, 2010.

[Tel16] Andy Kirk & Simon Timms & Andrew Rininsland & Swizec Teller. DataVisualization: Representing Information on Modern Web. #sep# 2016.

[Van10] Maarten Van Steen. “An Introduction to Graph Theory and ComplexNetworks”. In: Copyrighted material (2010).

[VN03] Jarke J Van Wijk and Wim AA Nuij. “Smooth and efficient zooming andpanning”. In: Information Visualization, 2003. INFOVIS 2003. IEEE Sympo-sium on. IEEE. 2003, pp. 15–23.

[Wei+17] Qing Wei et al. “NaviGO: interactive tool for visualization and functionalsimilarity and coherence analysis with gene ontology”. In: BMC bioinfor-matics 18.1 (2017), p. 177.

Bibliography 48

[WGK10] Matthew O Ward, Georges Grinstein, and Daniel Keim. Interactive datavisualization: foundations, techniques, and applications. CRC Press, 2010.

[WLH16] Marc Weise, Steffen Lohmann, and Florian Haag. “LD-VOWL: Extract-ing and Visualizing Schema Information for Linked Data”. In: Visualiza-tion and Interaction for Ontologies and Linked Data (VOILA! 2016) (2016),p. 120.

[ŽMS15] Martin Žácek, Rostislav Miarka, and Ondrej Sykora. “Visualization of Se-mantic Data”. In: Artificial Intelligence Perspectives and Applications. Springer,2015, pp. 277–285.