Data visualisation over semantic datasets and Knowledge Graphs becomes a challenging task as the data volume increases. The amount of nodes and edges linking them produce overwhelming diagrams in which understanding the information displayed is cumbersome. In this work we introduce Graphless, a visualisation interface that exploits the statistical information of the usage of instances and relations to produce graphical summaries of entities. The system supports several heuristics, providingfferdenit visualisations, according to configurable parameters2.
Graphless is an online 3 toothlat provides a user interface for graphically exploring RDF-based datasets. The main goal of this tool is to provide a way for summarizing entity graphs,supporting a better understanding of how individuals and their relations are stated. In a way, our aim is to reduce big portions of data to a more easy to digest representation, trying to preserve the most relevant elements while doing so.
For doing so, we have to consider the data features that semantic datasets have. In the most basic and common scenario, semantic data is represented as a graph of individuals and properties linking them. Even when an schema, defined as an ontology, could be expected, having it is not always the case. Many available SPARQL endpoints hosting datasets do not contain the ontology (or ontologies) used to generate them. In this work we aim to provide a generic approach for producing visualization summaries. We rely only on the statistical features that are common to RDF data graphs. We consider the following two main features:
Connectivity degree: the number of ingoing and outgoing links from/to a given node is an indicator of the relevance of the node in the dataset. Central nodes (e.Cg ountries as birthplacesY,ears for dates) tend to have many incoming links, as they are referenced by many other instances. Also, nodes of prominent entities usually assert many outgoing properties, either to other entities or to literal valueAsut(heo.gr.s to the books they wrote, Places to their names ffinerednit languages).
Property usage: the distribution of properties along the instances on a dataset is, as expected, not strictly homogeneous. Properties nasumceh as or birthplace are more likely to be instantiated on instancesPerosfontype than others such caaspital of orfoundation yea.r Thus, classes allow us to estimate which are the most used properties for their instances.
We use these two factors to analyze the structure of the data graph, and based on the results obtained, the system decides which element to depict on the final diagram. From the two explanations above, we derive the following tentative assumptions for summarizing data visualizations, which are the base of our system. 1. Users are more interested in exploring nodes that have
they are more relevant. 2. Users are more interested in visualizing the most frequently used properties for the nodes depicted, as they provide more insights. more connections, as The two assumptions that we introduce may seem quite straightforward, but as we discuss in this work, they allow to build informative data visualizations, by using them for analyzing the data graph. Whereas other features could be also included (e.g. ontology taxonomy, discriminative properties), these two ones are appropriate as they often apply to any given dataset. The final goal of the system presented in this work is to generate summarized graph diagrams, to provide a better visual exploration experience. An illustrative example of tfihneal product is shown in Figure 1, which depicts the Graphless GUI with a summary of an entity from a semantic dataset. This paper will introduce how to calculate these summaries and display them, explaining as well how the system is being currently used for the Jamendo dataset[1], which contains a large collection of data about records, music artists, songs, lyrics and genres. The reminder of this paper is organized as follows. Section 2 introduces how the analysis process of the tools works. Secti on 3 introduces the twffoerednit algorithms for exploiting the data generated in the previous step, and Section 4 describes how the system has been implemented. In Section 5 the results of applying our approach to the aforementioned Jamendo dataset. Section 6 compares our approach to existing ones. Finally, Section 7 discusses about the advantages and drawbacks of this contribution and outlines some lines of future work. 2
In order for the interface to be fialbteler taond display the data properly, the target graph has to be analyzed according to the metrics described previously. This process starts by retrieving the list resources and their corresponding types from the dataset. Using this information the system counts how many times each property is instantiated, keeping track of the type of the subject of the triple as well as of the object (only for object properties). Only resources with types are thus considered in the system.
In this process, the system records the statistical usage of properties, both as ingoing and outgoing links of instances of each tyfipnee. Wae prdoeperty as outgoing for a given type when an instance of such type is used as the subject of a triple. Similarly, ingoing properties are those with a resource of a given type as the object.
With this information, the system is able to generfialtee faor preoach type in the dataset, assigning weights to each type-property combination. In order to have a relative measure, raw counts are normalized for each type, generating a weight value from 0 to 1 (that is, dividing all weights by the maximun one found for the given type). Values closer to 1 would imply highly used properties, and thus highly relevant, following the discussion introduced previous section. Those properties with weights close to 0 imply that these properties are low in relevance as they are rarely used.
The result of this process is efixeedmpliin Table 1 which displays the statistic analysis of the Jamendo dataset, which we will describe in Section 5. The table depicts the property counts for thmeo:cMlausssicArtist4 in the dataset, including outgoing properties.
Property foaf:made foaf:based_near foaf:name foaf:homepage foaf:img mo:biography owl:sameAs foaf:maker
Prop.Type Outgoing Outgoing Outgoing Outgoing Outgoing Outgoing Outgoing Ingoing
Count 5786 3244 3505 3006 2982 485 119 5786
Normalized weight 1.0
Besides the property usage for each type, the system also analyzes how many properties link to each resource in the dataset, obtaining the ingoing and outgoing degree for each node (i.e. individual) in the graph. These measurements indicate the connectivity degree of the node, and serve as indicators of the relevance of the node in the graph. Intuitively, the more connected a node is, the more relevant it is.
Table 2 shows the information generated during this process for a set of resources belonging to ffedrient classes. As explained for the previous process, the system normalizes the raw counts, so as to have a consistent measurement of the importance of the node in the graph. This is achieved by dividing each ingoing and outgoing count by the corresponding maximum value found on the graph.
Once these two analysis (i.e. properties usage and connectivity degree) have been conducted, their results are combined, assigning to each node on the graph the corresponding information. That is, each node in the graph will be annotated with the connectivity degrees and the usage weights for each property instantiated for it, discussed in Section 4 the relationship features of Ne5o.4j
both property for ingoing and outgoing weights annotations are properties. As done using the
As depicted in Figure 2, each property of the resource http://dbtune.org/jamendo/artist/1442 is annotated with their corresponding weights, along with the ingoing and outgoing degrees of the resource. These parameters can be used filttoer and reduce the elements to be displayed on the final diagram, as we introduce in the following section. 3
The results obtained by the statistical analysis are the base for a set of algorithms that explore the graph to generate a summarized visualization. The current version of the system includes fftweroentdi algorithms that can be used to explore a dataset. The following sections introduce them. In both cases, the algorithm requires a root node to be selected, as the starting point to traverse the graph. Depending on the algorifftehrmen, t dpiarameters can be dfiened. As well, when selecting the properties to be displayed, the system considers both ingoing and outgoing ones, using fftehrent diweights associated to them. 3.1
Top-K
heuristic This algorithm implements an straightforward heuristic for traversing the graph, selecting only the top relevant properties on each step. Starting on the root node, the algorithm selects the K top properties of the node, which link to new nodes. The process recursively executes the same steps obtaining new nodes. In order to restrict the amount of nodes being explored, the algorithim limits the number of steps in the process to a maximumfinidnegpth,owde deep the graph can be explored from the starting node. Figure 3 shows an example of the Top K algorithm, starting from the node http://dbtune.org/jamendo/artist/7373, selecting the two top properties, with a max depth fiovfe, as shown on the right-hand side of the picture. That is, for each node the system picks only the two most relevant properties, and keeps on traversing the graph until it reaches nodes sepafirvaetedstebpys from the root resource. In this case, to calculate which properties are the most relevant, the system multiplies the weight of the property by the weight of the node that it links to, providing a combined measure of the importance of the property and the target node in the graph. This algorithm selects all the properties that have a weight higher than a given threshold value, and retrieves all their associated nodefis.rstIn sttehpe, the given threshold parameter is usefidltert.o After that, for all the retrieved nodes the process is repeated, increasing the threshold valuefiedas bsypeci the decay parameter. This way, the threshold is higher on each step, until it reaches the maximum value for a property weight (i.e. 1.0), which will stop the process. Figure 4 shows the diagram resulting of using this algorithm for the same resource from the previous example (i.e. http://dbtune.org/jamendo/artist/7373) decay of 0.1. Thus, for firtshte iteration than 0.8 will be selected, then only 1.0 is reached, the system stops, property.
with a only those as this base threshold of 0.8, properties with a value higher than 0.9, and is the maximum and a higher once the weight for value any When comparing Figure 3 and Figure 4, we can observe how the system provides dffierent visualizations based on the same dataset, by applying different heuristics. Whereas these two heuristics are rather simple and straightforward they showcase the potential of our approach. The Top-K heuristic provides a more consistent view along the graph, depicting always the same amount of nodes each step. The Threshold heuristic is intented to generate more restrictive visualizations, in which only strictly relevant nodes are depicted.
In the coming sections we will discuss about how this system is implemented and how the usage of a graph-oriented database allows to store the required annotations and perform queries using ffitchienmtly.e 4
4.1
management The information extracted from the process described in Section 2 has to be stored in a way that can be acfficecsiseendtly.e This requires a data system able to support the annotation of properties and nodes. Both things could be done using just RDF over the original dataset, using custom properties for annotating nodes and firceaition statements for the properties. However we decided to use a more graph-oriented solution, providing better performance and ease of use when querying the data. The use of extra properties, and specially the use of ficaretion, would increase the complexity of SPARQL queries, dffiiculting the process of exploring the graph.
For these reasons, we selected 5Neoa4sj our data backend solution, for storing the dataset and the related annotations. This graph dffaetrasbase o the required features for storing the nodes and the properties (known as relationships according to Neo4j's naming conventions), with annotations for both of them. These annotations can be used directly 6in quCeyripehs,er the query language used in Neo4j. Listing 1, shows the two types queries used for the Top-K and Threshold algorithms respectively. As we can see, we can exploit the annotations over the properties ("r" in both examples) to either sort by weight and select the top two properties (top-k heurfiislttiecr) or to based on the weight being higher than a given value (threshold heuristic). MATCH (n:JARLABS)-[r:JARLABS]->(x:JARLABS) WHERE n.nodeid = '...' RETURN ... ORD ER BY r.weight DESC LIMIT 2 MATCH (n:JARLABS)-[r:JARLABS]->(x:JARLABS) WHERE n.nodeid = '...' AND r.weight > 0.8 RETURN ...
Listing 1.Cypher queries (shortened usin…g")" 4.2
The frontend of the system is developed as a web interface, which aims to provide a clean and clear visualization experience fintaol tuhseer. The graphs visualization is supported vbiys.js7, a popular Javascript library for drawing statical reports, graphs and relation diagrams on the web. The interface itself is composed by two parts, the main area, in which graphs are displayed, and the right menu, which is hidden by default in order to maximize the visualisation space.
As depicted in the GfigUuIres in this paper, the graphs are displayed in the main area, following a shade color scheme. The root node, the one the user queried, is displayed with the strongest red hue. As the distance from this root node increases, the color code of the node gets lighter and lighter. This is intended for the user to have a more clear view of which are the most relevant nodes, assuming that those closer to the main one are more informative for it. Circles and nodes are used ffteorendtiiate between object nodes and literal ones respectively. In both cases, the local name or the literal value are used as the node label. Properties are also labeled with their name and weight.
All nodes are clickable objects. On double click, the right menu is opened and the information about the selected node is displayed, as seen in Figure 5. The code, implemented in Java, is divided inffertewnot pdriojects, for the analysis process and interface, which are available8,9o.nline 5
In this section we introduce the result of applying our approach to the Jamendo dataset, currently available in Graphless. This dataset contains information about records, musical artists, torrents, lyrics, signals, tags, documents and tracks. It combinfievse dffierent ontologies and contains 412,564 object nodes, 251,698 literals, and a total of 1,267,012 instantiated relations.
The data ingestion process, undertaken during the analysis process, starts by querying the public Jamendo end1p0,oinftrom which the system retrieves all the subjects, objects, and their related properties and types. This is done by means of SPARQL queries, which are executed with a time delay between them to avoid overloading the system.
Jamendo individuals and properties can be visualized on the currently available version of Graphless, using the two exploratory algorithms described above. Thefinal dataset is also available as a Neo4j 1d1atabase 6
This work is inspired by the SDType [2] system, which uses statistical analysis of datasets to infer missing entity types. In our flcipase,thiwse approach, using the types of the entities as indicator of the importance of the properties asserted for their individuals. This way, we can select those that are commonly used for each type.
As discussed before, tfihneal goal of our system is to provide visualization summaries of entities. In this direction, several approaches have been proposed for entity summarisation. LinkSUM [3] and [4] pursue a goal similar to the one exposed in this work, aiming to reduce the number of properties displayed for an entity. In this case, authors propose to use the well-known PageRank algorithm for calculating the relevance of properties. This score is then used for selecting the top properties of an entity, without traversing the graph, as we do in this work. A similar approach, obtaining lower results than LinkSUM is introduced in FACES [5]
Other systems have been proposed for graph summarisation in the context
of Linked Data [
One interesting contribution on how semantic data can be organized from a
conceptual point of view is introduced in [
In this paper we introduce Graphless, a data visualization tool for semantic datasets, which combines statistical analysis and graph traverse heuristics to produce graph summaries. Combining these two approaches the system is able to provide smaller diagrams, which are easier to read and interpret.
This work represents firast version of the tool, in which only the Jamendo dataset has been included. We plan to extend the collection of datasets, including more representative ones, such as DBpedia. Our intuition is that a tool such as this would be of help specially in heterogeneous datasets, containing information from ffedrient sources and with a wide range of varied types and properties.
From the technical point of view, we plan to include new features, currently under development, such as the generation of RDF snippets from the visualizations. We also plan to support new algorithms implementing novel heuristics. Ourfinal goal is to provide a programmable interface in which developers can integrate their algorithms based on the available data properties.
Finally, we are currently conducting a usability evaluation with several users, which will provide feedback for improving the tool. This will allow us to measure how suitable the two assumptions introduced in Section 1 are, as well as to explore new ones.
project, from FEDER Funds.
was
the partially
Spanish funded
State by the esTextAnalytics (RTC-2016-4952-7) Investigation Agency of the MINECO and
Footnotes 1 http://dbtune.org/jamendo/ 2 The online version of this paper can be found in http://w3id.org/people/idafensp/p apers/graphless/ 3 http://graphless.linkeddata.es/ 4 The following pfirxees are used throughout the texmt:o (http://purl.org/ontology/mo/), foaf (http://xmlns.com/foaf/0.1/), tag (http://www.holygoat.co.uk/owl/redwood/0.1/tags/), owl (http://www.w3.org/2002/07/owl#) 5 https://neo4j.com/ 6 https://neo4j.com/developer/cypher-query-language/ 7 http://visjs.org/ 8 https://github.com/idafensp/graphless-lds 9 https://github.com/idafensp/graphless-ldv 10 http://dbtune.org/jamendo/sparql 11 https://doi.org/10.5281/zenodo.1284979