El Bien: la contestación maligna del arte

First, we briefly introduce each visualisation approach we examined. In Sect. 4.1.2, we then compare all of them in detail by several criteria.

Microsoft Excel

The focus of Microsoft Excel is on data calculation. It can be considered a foremost manual visualisation tool. Although the software offers a wide range of diagram types and shall be mentioned here due to its popularity, MS Excel does not guide the user when choosing one of these types. Also, it is not possible to state the scale of measurement for a variable. Since these are features that Tableau and SPSS Viz Designer add, we rather have a closer look at these products in the following sections.

Polaris and Tableau

Tableau is a comprehensive tool for designing visualisations from tabular data. It is a commer- cialisation of Polaris, described in [STH02].

The philosophy of Polaris and Tableau is to extend the declarative principle of SQL by visualisation, inspired by the fact that SQL already offers some abilities to structure, sort and group data. In order to find a compromise between ease of use and flexibility, Tableau concentrates on tabular data and uses the familiarity of users to spreadsheets. Queries are defined in VizQL (cf. Sect. 4.2.1), a visual query language to visually construct queries to relational databases and OLAP servers, generating SQL. Via drag-and-drop, columns can be selected as input to the visualisation process. By adding fields from the database to either columns or rows of a metaphorical table representation, the user can influence how these fields are nested. This allows, for example, for the description of small multiple1 _{views of data.}

Unlike Tableau, our focus is not on tabular data, but on heterogeneous ontological data. SPSS Viz Designer

In Sect. 4.2.1 we discuss Wilkinson’s formal Grammar of Graphics. A commercial Java system based on Wilkinson’s grammar is nViZn. It is described as »based on the mathematical definition of the graph of a function« [WRRN01]. As opposed to Tableau or Polaris, it is not bound to relational data and can generate new graphics more flexibly. Since it was developed for the web, heterogeneous and distributed data sources are supported and network data can be processed. Unlike Tableau or Polaris, the available types of graphics include node-link diagrams. Also interaction can be specified: Filtering, sorting, linking and brushing between multiple views, zooming, and coordinate transformations (lenses) can be employed. While viewing data, the views can be interactively manipulated via widgets such as sliders.

Another software based on Wilkinson’s algebra is SPSS Viz Designer. It was added as a visualisation component to SPSS, a statistic analysis and visualisation tool by IBM, which is

4.1. RELATED VISUALISATION APPROACHES

mainly focused on quantitative data. Viz Designer uses a tabular representation of data where the rows are the cases and the columns are the variables. In contrast to Microsoft Excel, SPSS Viz Designer allows the assignment of additional information to variables, including the scale of measurement. In cases where the settings that can be specified via the user interface are not sufficient, the user can write more complex configurations using one of the languages ViZml and GPL (cf. Sect. 4.2.1).

Although not only tabular data is supported, neither nViZn nor Viz Designer considers the specifics of ontological data.

TopBraid Composer + UISPIN

TopBraid Composer is a Semantic Web development environment and part of the TopBraid technology stack2_{. It supports an ontology-aware node-link view of RDF-graphs. Beyond this,}

RDF-data can be rendered to document shape (HTML and SVG) using UISPIN3_{, which we}

introduce in the languages part (Sect. 4.3.1). UISPIN builds on SPIN, which we introduced in Sect. 2.2.7.

While TopBraid Composer + UISPIN covers many of our requirements and brings reusable components, it has only basic visualisation capabilities, particularly with respect to the compos- ability of graphics.

Cytoscape

Cytoscape [SMO+03] is an open-source plug-in environment for biological network visualisation and analysis actively used in bioinformatics. Layouting and data filtering are core functionalities the framework offers. Many analysis plug-ins have been developed for it, including RDFScape, a plug-in for RDF visualisation (described below).

The most interesting part of the framework with respect to our work is the Vizmap- per (cf. Fig. 4.1). The Vizmapper allows for the advanced mapping of network attributes to visual attributes via visual mappers. These mappers come in the variants: continuous mappers, discrete mappers and continuous to discrete mappers. It is also possible to define some visual attributes to depend on the values of other attributes, e. g., width = height, node colour = text colour, arrow colour = line colour. Legends can be automatically generated. Further features are filters for data customisation and some basic editing functionality (creating, deleting nodes). RDFScape

RDFScape [Spl08] is a plug-in for Cytoscape that enables the display of RDF graphs. Since RDFScape is intended for use in the field of biotechnology, it concentrates, like Cytoscape, on node-link representations that are a seemingly obvious choice for interaction networks and similar data.

Mapping features are the following: In addition to the node-link representation, datatype properties can be displayed like UML-attributes (a table contained in a node), and properties such as rdfs:label or URIs can be displayed as labels of nodes. Furthermore, different namespaces can be mapped to different colours. All mapping settings can conveniently be specified using the Cytoscape Vismappers. Other features include querying ontologies with SPARQL and RDQL, incrementally extending (»navigating«) the graph visualisation based on the ontology, and using the graph visualisation to define visual queries. The system supports (customisable) reasoning and the inferred knowledge can be filtered and visualised as well.

RDFScape does not offer guidance functionality for the visual mapping. Also, the mappings themselves cannot be stored as RDF for inter-tool exchange.

2 _{TopBraid. http://www.topquadrant.com/technology/topbraid-platform-overview/, accessed: 09.11.2015.} 3 _{UISPIN was renamed to SPARQL Web Pages (SWP).}

CHAPTER 4. ANALYSIS OF THE STATE OF THE ART

4.1. RELATED VISUALISATION APPROACHES

Model-Driven Visualisation – Bull, 2008

In the Model-Driven Visualisation approach (MDV) [Bul08], Bull uses a model transformation language (ATL4_{) to build view (visualisation) models from domain models, both represented in}

Ecore (cf. Sect. 2.2.6). The view model is realised with the ZEST5 _{toolkit the author initiated.}

ZEST generalises the principle of using the Model View Controller (MVC) pattern [Bur92] and content providers (interface IContentProvider), which has been used before in SWT/JFace widgets such as trees and lists, and transfers it to other graphics such as node-link represen- tations (cf. Fig. 4.2). Both the view model and the controllers (the content providers) for the MVC pattern are generated by MDV.

However, MDV alone does not provide an approach to visually support the configuration of visual mappings and can only be used for the visualisation of ontologies with the extensions described in the next subsection.

Figure 4.2: ZEST – Static Graph Viewer showing Eclipse plug-in dependency graph. Taken from http://www.eclipse.org/gef/zest/.

CogZ + MDV

An approach for using MDV for ontologies as well was developed by Falconer and Bull et al. at the interdisciplinary CHISEL group (University of Victoria) [FBGS09], extending the existing, Protégé-based ontology mapping tool CogZ [FS07]. Thereby, they gained a visual mapping interface for defining a visual mapping of ontology terms to terms of a visual model, which is also defined as an ontology and which describes one of the models that the MDV approach can handle (cf. Fig. 4.4). It is then possible to generate a visualisation of the domain instance data. CogZ stores mappings explicitly, but only rather simple value mappings are possible. Although instances could be mapped directly (e. g., »water« mapped to »blue«, »location« mapped to »square« . . . ), problems arise, when mapping to continuous ranges. These mappings cannot be

4 _{Atlas Transformation Language. http://www.eclipse.org/atl/, accessed: 11.11.2015.}

CHAPTER 4. ANALYSIS OF THE STATE OF THE ART

easily defined with the CogZ plug-in. Furthermore, no guidance is offered on which visualisation options are most appropriate.

Figure 4.3: CogZ+MDV – Mapping View. Taken from [FBGS09].

Generative Software Visualization – Müller et al., 2011

Müller et al. suggest an approach to generative software visualization [MKSE11] that is related to the work of Bull. Both are based on model-driven technologies located in the EMF technical space and introduce platform-independent intermediate models. However, for our detailed tabular comparison, we chose the approach from Bull. We consider it closer to ours, because it is domain-independent and not specifically about visualising software. Having said this, the approach of Müller et al. has also similarities with the OGVIC approach: Unlike Bull, they use a DSL to avoid writing transformations in multi-purpose (transformation) languages. Similarly, we introduce the (domain specific) language RVL to simplify the mapping definition (Chapter 7). Besides that we do not focus on the domain of software visualisation and exclude the aspect of 3D visualisation in this work, the OGVIC approach differs in the way that mappings are defined. Although Müller et al. employ clear mapping rules (e. g., represent attributes as nodes shaped as a blue cone) they do not distinguish the mappings of relations (in the domain data) from the mapping of values as we do. Neither the approach of Bull, nor the one of Müller et al. store general visualisation knowledge and rules externally in standard formalism (to allow for reuse). Instead, this configuration knowledge is part of the generators.

Protovis

Protovis, developed at the Stanford Visualization Group, is a JavaScript visualisation toolkit with a declarative visualisation language also being referred to as Protovis [BH09]. Since

4.1. RELATED VISUALISATION APPROACHES

implementations in JavaScript (JS) and Java are offered, we do not only discuss it as a language but included it in the list of visualisation approaches (cf. Sect. 4.2.1 for details on Protovis as a language). Fig. 4.6 gives an example of a declarative visualisation definition of a bar chart in Protovis (Java version) and also shows the corresponding rendered SVG+HTML result on the right.

The development of Protovis was stopped in the meantime in favour of the follow-up project D36 _{[BOH11]. While the declarative approach and the support of interactivity and incremental}

updates are close to our needs, neither Protovis nor D3 support ontological data.

Figure 4.4: Protovis (Java version) – Bar chart example. Taken from [HB10].

SemViz

The approach of Gilson et al., called SemViz [GSGC08], aims at automation for ontology visualisation. The authors tried to achieve this by combining an existing mapping algorithm with probabilistic reasoning techniques.

Within the mapping process, the system uses three ontologies: The first is a Domain Ontology (DO) to describe the domain data semantically. Second, a Visual Representation Ontology (VRO) captures a description of a visual representation (2D Graphs, TreeMaps, and Parallel Coordinates are shown in the examples). And third, a Semantic Bridging Ontology (SBO) stores expert knowledge on the appropriateness of mapping a domain concept to some visual attribute. In a first step, for each domain, a DO has to be created by a system (not a domain) expert and is then mapped automatically to tabulated data that has been extracted from semi-structured webpages. Since we assume to have structured data as a starting point for visualisation, we do not further discuss this step. In a second step, a »controlled set of relationships and attributes« has to be defined and used in the DO. These are very general and include statements on the scale type (qualitative, quantitative, informational), information concerning primary keys, priority and complementation. The VROs describe the properties of the visual representation, e. g., X, Y, Width, Height, Text Label, Shape Colour. Again, relations between these properties are

given such as priority, complementation and statements on the (accepted) scale type of data. There is an attribute isQuantitative that is used to describe domain concepts in the DO and a »semantically equivalent« attribute that is used to describe »visual artefacts« (visual means) of the VRO. For example, the concept Weeks in Chart7has the value 0.75 for isQuantitative in the DO and, in the VRO, Y is assigned a value of 0.99 for isQuantitative. Similarly, complements is used in the DO and in the VRO. For example, the concept Weeks in Chart only complements

6 _{D3.js (Data Driven Documents). http://d3js.org/, accessed: 02.07.2015.}

7 _{We are referring here to the example domain ontology used by the authors, which is about music charts, songs}

CHAPTER 4. ANALYSIS OF THE STATE OF THE ART

Last Week Chart Position with a value of 0.6 (DO), while Y complements X with a value of 0.9, making Last Week Chart Position not a perfect match for Y. Finally, based on the »semantically equivalent« relations, a matching of DO and VRO concepts is then performed, leading to a set of recommended permutations. To reduce the number of permutations, additional expert knowledge can be represented in the SBO by weighting some of the so called »semantic bridges« between DO and VRO concepts with higher appropriateness values than others (cf. Fig. 4.5).

Although Gilson et al. even aim at »automatic generation of visualizations« [GSGC08], they as well offer automation only to some extent. For example, a specific domain ontology has to be created manually for every new domain. Also, expert knowledge has to be formalised manually in a SBO for each new combination of a new DO with a VRO. As opposed to this, we aim at semi-automation for arbitrary domains, leaving the actual mapping to the user, but trying to support her as much as possible inspecting characteristics of the existing domain ontologies. Another difference between our approach and SemViz is that we do not (directly) match domain relations and visual means by scale types, but take into account what is the expressiveness and effectiveness of a visual means for a given scale type.

Figure 4.5: SemViz – Semantic Bridging Ontology. Taken from [GSGC08].

Less + LeTl

Less [ADD10] is a collaborative, template-based system, mainly for presenting RDF from SPARQL-query results. The authors of LESS want to offer an end-to-end-approach and focus on community aspects. They, therefore, aim at a simple user-interface-based creation of templates

4.1. RELATED VISUALISATION APPROACHES

and offer features such as dereferencing URIs, or caching to avoid dead links. Templates are described with the language LeTl , which we discuss separately in Sect. 4.3.1.

As opposed to the OGVIC approach, Less does not aim at visualisation but on presentation of data, i. e., visual mappings cannot explicitly be specified.

Vispedia

Cammarano et al. [CDC+07] describe a system that automatically matches RDF properties with attributes that visualisations offer. They see this problem from a schema matching perspective and try to find data variables that can be associated with the visual attributes of visualisation templates considering both structural matching and type matching. As templates, ready-to-use widgets such as the SIMILE timeline component are used.

Vispedia [CTW+_{09, CWT}+_{08] builds on the work from Cammarano et al., presented above.}

Attributes of a visualisation are annotated with XML data types. Additionally, for each visual attribute, the user can provide a keyword. Based on this information, schema matching is used to match visualisation attributes with table columns of Wikipedia data tables and associated RDF data. The system provides multiple matching solutions (also following links in the RDF graph), from which the user can interactively choose the most appropriate one (cf. Fig. 4.6). Compared to our bottom-up (cf. Sect. 2.1.5) approach, which supports the synthesis of graphics, Vispedia could be referred to as a top-down approach, since only ready-to-use templates, i. e., complete graphic representations, may be used. The drawback of this approach is the lack of flexibility and composability.

CHAPTER 4. ANALYSIS OF THE STATE OF THE ART