The LOD (Linked Open Data) cloud currently contains thousands of published datasets. Existing visualizations, like the Linking Open Data cloud diagram, are useful for getting an overview of its size, the datasets and their connectivity. An interesting question is whether we could come up with more informative and more interactive visualizations that could make evident more features of the datasets for aiding the inspection and the discovery of related datasets. To this end we propose an interactive 3D visualization that adopts the metaphor of urban area. In brief, each dataset is visualized as a building, whose features (e.g. volume) re ect various dataset's features (e.g. numb er of triples), while the proximity of the buildings (and other features) indicates the commonalities of the datasets. The introduced approach supports various shapes of buildings and various placement algorithms: mountainside, orthogonal spiral, concentric spiral, and similarityb-ased adaptations of forced-irected a lgorithms. The visualization is interactive, i.e. it allows the user to zoom in any part of the model, to change the perspective, to change the shape of the buildings and their placement, to see all the connections or only those of one dataset, and others. The paper details the construction process and provides examples over real datasets including the entire LOD cloud, and describes the pros and cons of each layout.
During the last years we observe an increasing trend towards
publishing data as LOD. Thousands of datasets have been
published and various visualizations that give an overview of their
number and interconnections have been proposed (e.g. see [
Visualization has been recognized as important for dataset
discovery and dataset selection [
Let S = S1, . . . Sk be the set of datasets. Each dataset Si consists of a set of triples (i.e., a set of subjectp-redicate-object statements), denoted by triples(Si ). We shall use Ui to denote the URIs, Li to denote the literals and BNi to denote the blank nodes that appear in triples(Si ). Hereafter, we consider only those URIs that appear as subjects or objects in a triple as our primary focus is on the data (not on schema). The number of common URIs between two datasets Si and Sj , is given by | Ui ∩ Uj | . We de ne the Links between two datasets as follows: Linksi, j = Ui ∩ Uj . If T is a set of triples, then we can de ne the degree of a URI e in T as: degT (e) = |{( s, p, o) ∈ T | s = e or o = e }| , while for a set of URIs E we can de ne their average degree in T as degT (E) = avge ∈E (degT (e)). Now for each dataset Si we can compute the average degree of the elements in Ui by considering triples(Si ), i.e.: Deg(Ui ) = avge ∈Ui (degtr ipl es(Si )(e)). 3.2
The main idea is that we visualize each dataset Si as a building bi . The volume of each building represents the number of triples of the respective dataset ( | triples(Si )| ). As regards the types of the buildings, we support the following options: (a) cubes, (b) c“ontext"-dependent cuboids , and (c) “feature"-based cuboids .
In (a), each dataset Si is represented by a cube with edge length equal to p3 | triples(Si )| .
In (b) we use c“ontext-dependent" cuboids . The footprint of the buildings is computed based on either the biggest dataset (bBig mode) or the smallest dataset (bSmal l mode). In the bBig mode the building of the biggest dataset is a cube, while in the 2 by Andrejs Abele, John P. McCrae, Paul Buitelaar, Anja Jentzsch and Richard Cyganiak, http://lod-cloud.net/ bSmal l mode the cube corresponds to the smallest dataset. Consequently, the buildings of the datasets that have enough triples tend to become skyscrapers.
In (c), i.e. “feature-based" cuboids , the shape depends on the features of the corresponding datasets. Since | triples(Si )| ≈ (| Ui | +| Li | +| BNi |)∗ Deg(Ui ), the height of the building is set to be analogous to | Ui | + | Li | + | BNi | , and the footprint of the building analogous to Deg(Ui ). Speci cally, assuming square footprints, we have height (bi ) = | Ui | + | Li | + | BNi | and width(bi ) = pDeg(Ui ). The volume of the building bi approximates | triples(Si )| ; if its degree is low it will become a high building with a small footprint, whereas if its degree is high then the building will be less tall but will have a big footprint.
For getting building sizes that resemble those of a real urban area, a calibration is required. For this reason we introduce an additional parameter F , through which we can obtain the desired average ratio of height/width of the buildings. Speci cally, let r be the desired ratio (e.g. 3 for three- oor buildings) provided by the user. We can add a parameter F to the de nition of height and width: height (bi ) = (| Ui | + | Li | + | BNi |)/ F and width(bi ) = pDeg(Ui ) ∗ F . Note that any positive value of F yields a pair of height (bi ) and width(bi ) that preserves the volume. What is left to do is to select the F for obtaining the desired average ratio r . This reduces to nding the F such that height (bi ) r = avg { width(bi ) | 1 ≤ i ≤ k } . The solution of this equav u t tion is: F = 3 ! 2 Íi|S=|1(| Ui | + | Li | + | BNi |)/ √Deg(Ui ) . Obviously in
r ∗ | S | stead of avg one can specify the min or max desired ratio and in that case the formula is changed accordingly, e.g., for the max desired ratio, we should rst compute for each dataset the foltuv ! 2 lowing number: Fi = 3 (| Ui | + | Li | + | BNi |)/ √Deg(Ui ) . Then, we r should sort all Fi in descending order and select the max Fi . By selecting the max Fi as the F value in all height (bi ) and width(bi ), then that guarantees that all buildings will have ratio ≤ r . 3.3
Below we describe four di erent building layout approaches, that our system supports. 1. Mountainside Layout. The k buildings are placed in an orthogonal ⌈√k⌉ × ⌈ √k⌉ grid. The biggest building is placed in one edge of the square area. The second bigger is placed next to the rst, and so on, until reaching the end of a row, where it continues the same procedure in the next one until there are no buildings to draw. The result resembles a mountainside (Figure 2 - upper left). 2. Orthogonal Spiral. The k buildings are placed in an orthogonal ⌈√k⌉ × ⌈ √k⌉ grid (see the two screenshots at the bottom part of Figure 2). The biggest building is placed in the centre of the area (summit). The process continues by adding growing enclosing squares of size N . For example, the rst contains 8 squares (3 above of the summit, one left and one right of the summit and 3 below the summit). The next enclosing square contains 16 more buildings and so on. Each building is drawn following the clockwise direction. The result resembles a mountain whose summit is at the centre of the 2D area. One shortcoming of this algorithm is that if we represent buildings with cubes then this algorithm yields very sparse peripheral areas. This was actually the motivation for the subsequent algorithm. 3. Cyclic Spiral. Based on the weaknesses of the previous layout algorithms, we identi ed the following requirements for a better layout algorithm: (a) bigger buildings should be placed at the center (b) a spirall-ike placement seems bene cial as it would resu lt to a round coverage of the space, (c) collisions should never occur, (d) no big empty spaces, especially in the outer area that hosts the majority of the buildings which are small.
For the above requirements, we devised a new 2D placement
algorithm called Concetric Spiral. The buildings, in an descending
order with respect to their size, are placed on concentric rings.
The radius of the rst (smallest) ring is the size of the biggest
building. The placement of the subsequent buildings is done as
follows. We compute the minimum chord that is required to
avoid collisions based on the sizes of the current and the
previous building. Then we compute the corresponding angle, and
we place the new building at the corresponding spot of the
circhor d
cle. The sought angle is θ = 2 arcsin( 2· r adius ). Just before we
reach 2π , we start the next bigger ring whose radius, is the
radius of the previous ring increased by the size of the last drawn
building (plus a number accounting for “roads"). In this way
the concentric rings become denser as the buildings get smaller
avoiding the unnecessary empty spaces. The algorithm is
appropriate for sets of datasets whose sizes vary a lot, even if they
exhibit a power law distribution (i.e. very few big datasets and
too many small ones, see [
Comparison. Table 1 summarizes the distinctive characteristics points of each visualization approach including the 2D LOD Cloud diagram. The value r“ich" in the line i“nteractive" re fers to interactive selection, zooming, panning, rotation, and control of visibility of labels and connections. 3.4
If there are links between two datasets Si and Sj then a line segment is created, resembling a road that connects the corresponding buildings (see the left side of Figure 4). The links can be also visualized as bridges (see the right side of Figure 4). The width of these bridges/roads, indicates the strength of the connection that 3https://github.com/davidpiegza/Graph-Visualization the correlated datasets have, and it is calculated by the division of the number of links between Si and Sj with the number of links of the most connected pair (i.e., maxLinks): width(i, j) = | Links(i, j)| . | max Links |
We downloaded manually 287 RDF datasets including their
content (i.e., triples, URIs, etc.) from the following resources: (a) the
dump of the data which were used in [
We have implemented a webb-ased visualization system, whic h
could be easily accessible by any user. We used the JavaScript
library Three.js4 which in turn uses the WebGL API5, which is
widely supported by all modern desktop and mobile browsers
without the use of plugins. Three.js o ers a less tedious
programming environment in comparison to WebGL, by
abstracting away many of the WebGL details, which is a JavaScript API
that allows the creation of GPU accelerated 3D graphics and
animations inside the environment of a web browser [
Figure 6 shows an overview of the webb-ased visualization system. The visualization is interactive, allowing the user to zoom in any part of the model. For instance, one can change the perspective, the shape of the buildings or their placement, search for a dataset through an auto-completion search , see all the connections or those of one dataset, and others. The presented model could be improved in several ways. Below we sketch two indicative enrichments: (a) for aiding the user to get a more informative and “live" overview immediately the system could be enriched with “guided tours" , i.e. with trails of camera mov ements over the space occupied by the buildings and (b) for reducing the crossings of the edges, each set of buildings that forms 4three.js is available at http://threejs.org/ 5https://www.khronos.org/webgl/ 6 There are similar JavaScript libraries like GLGE, SceneJS, PhiloGL, etc. a strongly connected component could be visualized as a small round park (or roundabout) where only one line segment connects each building to that park.
The proposed 3D interactive system: (i) illustrates accurately the relative sizes of the datasets in triples, (ii) can indicate the average degree of the datasets, (iii) allows the user to control which connections to show or hide, (iv) makes evident (through the layout algorithms) the di erences in the sizes of datasets or their commonalities. It supports various building types (cubes, contextdependent cuboids, featureb-ased cuboids), as well as seve ral layout algorithms(mountainside, orthogonal spiral, cyclicSpiral, similarityb-ased adaptations of forced-irected algorith ms), that order the buildings appropriately, depending on the user needs, and similarityb-ased adaptations of forced-irected algor ithms.
Acknowledgements. Work partially supported by a) the EU project BlueBRIDGE (Building Research environments for fostering Innovation, Decision making, Governance and Education to support Blue growth), H2020E-INFRA2-0151-, 20152-018 and b) the General Secretariat for Research and Technology (GSRT) and the Hellenic Foundation for Research and Innovation (HFRI).