Visualizing Resource Description Framework (RDF) data to support decision-making processes is an important and challenging aspect of consuming Linked Data. With the recent development of JavaScript libraries for data visualization, new opportunities for Web-based visualization of Linked Data arise. This paper presents an extensive evaluation of JavaScript-based libraries for visualizing RDF data. A set of criteria has been devised for the evaluation and 15 major JavaScript libraries have been analyzed against the criteria. The two JavaScript libraries with the highest score in the evaluation acted as the basis for developing LODWheel (Linked Open Data Wheel) - a prototype for visualizing Linked Open Data in graphs and charts - introduced in this paper. This way of visualizing RDF data leads to a great deal of challenges related to data-categorization and connecting data resources together in new ways, which are discussed in this paper.
Visualization of Resource Description Framework (RDF) data [
One of the most common ways of visualizing RDF data on the Web is simply by displaying data in tables. The disadvantages with this approach of visualizing RDF data is the fact that there are no obvious ways of getting an overview over what data resources are the subjects and objects in the RDF graph, as well as what category the different data resources falls into. Also, this visualization offers no ways of interacting with other data resources apart from the Unique Resource Identifiers (URIs). This limits the visualization-potential of RDF data to a great extent.
The aim and motivation behind the LODWheel (Linked Open Data Wheel) project was to
investigate new ways of visualizing Linked Open Data on the Web that would offer as much
value to users with little or no knowledge within the domain, as well as to experienced users
with much knowledge within the domain. RDF data visualization should be
platformindependent, thus making it available to everyone, regardless of operating systems and Web
browsers. This trait would further support the principles of Linked Open Data, making raw data
available to everyone. LODWheel is a prototype for visualizing RDF data in graphs and charts.
The prototype was developed based on an extensive evaluation of open-source
JavaScriptbased libraries for visualizing data, where the libraries with the highest score in each
visualization-category (graph-visualizations and chart-visualizations), based on numerous
evaluation criteria presented later in this paper, were used as the main front-end libraries. It was
important for the visualization tool to be a JavaScript-only library, as JavaScript is compatible
with all operative systems and Web browsers, and is expected to be a part of HTML5 [
The main contribution of this paper is an extensive evaluation of relevant JavaScript libraries for visualizing RDF data. Further, the LODWheel prototype, which is built on the JavaScript libraries with the highest overall score derived from the evaluation criteria, aims at showing the possibilities and advantages of visualizing RDF data in graphs and charts. The research conducted in this project highlights the importance of addressing new ways of categorizing data resources based on what the data actually represent, and relating data resources to each other in new ways. This will be explained more thoroughly throughout the paper.
This paper is structured around six separate Sections, excluding Section 1 – the introduction. Sections 2 and 3 give an insight into the state-of-the-art tools for visualizing RDF data, mainly focusing on the evaluation of relevant JavaScript libraries and Section 4 introduces LODWheel. Sections 5 and 6 present the results and discussions derived from this research, and Section 7 presents conclusions and future work.
There exist numerous tools for visualizing RDF data, both on the Web and as desktop
applications. Most of the desktop-based applications are built with the purpose of aiding
developers when constructing ontologies (RDFS, OWL) and RDF data, and do no not offer
much value to users with little or no technical skills. Some examples of such applications are
Protégé [
In addition to the tree- and graph-visualizations that dominate desktop-applications, the
most common way of visualizing RDF data on the Web is simply by using tables. Most existing
Linked Open Data sets currently use this way of visualizing RDF data, including DBpedia [
An uncovered territory when it comes to visualizing RDF data is how JavaScript-based data visualization libraries can support the visualization of larger quantum of data. There exist a great deal of JavaScript libraries made for visualizing data in graphs and different charts, such as bar-charts, pie-charts and timelines, to mention a few. Compared to traditional tools for visualizing RDF data, JavaScript libraries can offer more in the aspects of grouping data together, adding colors to the data, and applying arrows or pointers to the different data resources. However, not all of these JavaScript libraries are sufficient when it comes to visualizing larger data sets. The next section will provide insights into the most relevant JavaScript libraries for visualizing data, and their strengths and weaknesses when using them for visualizing RDF data.
Before the development of LODWheel started, a thorough evaluation of state-of-the-art
JavaScript data visualization libraries was performed. The libraries had to be purely based on
JavaScript, as it was an ultimate criterion that the libraries should be platform-independent.
Therefore, libraries built on both JavaScript and Flash would not be taken into consideration.
The evaluation was designed to address important aspects that such tools should include when
it comes to functionality and usability. The evaluation should be based on a thoroughly devised
set of criteria. These criteria should take into consideration both technical and usability aspects.
The libraries were separated into two different categories in the evaluation: graph-visualization
libraries and chart-visualization libraries. Based on these categories, the criteria of each
librarytype were unique. All the libraries had criteria categorized as three separate groups: usability
criteria, data criteria and quality criteria. The usability-criteria focused on the libraries’
possibilities of clicking on, hovering over and dragging the nodes in the graph, supporting
different colors on data elements, displaying text on the edges and nodes of the graph,
supporting arrows/pointers between data resources, and some form of legend-functionality. All
of the usability criteria were designed in order to get an overview over how much usability
functionality the library offered, thus addressing the visualization possibilities. Also, it was
important that the library should support the JavaScript Object Notation (JSON) data format
[
Library Ajax Mgraph amCharts Arbor d3 Dracula Graph Library Flot Google Chart Tools Highcharts JS JIT JQPlot JS Charts JSViz MooWheel PlotKit
Protovis In this evaluation, the JavaScript libraries that got the highest overall score based on the criteria in Table 1 were the MooWheel and the amCharts libraries (see Table 4). Due to the fact that none of the JavaScript libraries offered both graph-visualizations and chart-visualizations, it was decided that two libraries should act as the basis of the LODWheel – one graph visualization library and one chart-visualization library. It was decided that the JavaScript libraries that were going to be implemented had to include a free license. Based on this, due to the fact that the amCharts library has a commercial license, the runner-up chart-visualization library, JQPlot, was picked as the chart-visualization library instead. MooWheel visualizes data as a graph-wheel and provides the possibility of displaying data resources with different colors, as well as showing what data resources are the subject and object in each RDF triple. Additionally, it is based on a very simple and intuitive JSON format that is very suitable with how RDF is constructed. Moreover, the MooWheel library offers the best general usability, functionality and data operability. JQPlot visualizes data as different charts, such as bar-charts, pie-charts and line-charts. The full evaluation can be viewed in an Excel file at this URL: http://opendata.computas.com:7001/lodwheel/Evaluation_of_JavaScr ipt_libraries.xsl
LODWheel is developed as a dynamic Web project based on Java Servlet Pages (JSP) with a
back-end programmed in the Java programming language, supported by the Jena framework. It
is an open-source project under the MIT license, and the prototype can be tested at this
location: http://opendata.computas.no:7001/lodwheel/. The architecture
(see Figure 1) is based on a client/server architecture where the client sends a request through a
Web browser to the JSP servlet. The servlet then sends a request to the Java back-end that
executes an HTTP GET request based on a URI input from the user. If the URI is an RDF
resource the HTTP request will return the RDF graph of the URI. If not, the request will return
null. The back-end returns the RDF graph as an Object to the servlet, which then returns the
Object as a response to the JSP request. Based on the content of the Object, the JSP sends
several requests for logic operations to be performed by the back-end, in order to know what to
do with the Object. The front-end executes in the browser and is based on JavaScript, including
the JQuery [
Moreover, this means that the data visualization of LODWheel is based on visualizing the DBpedia data entities as best as possible, and the prototype will not visualize data from other data sets optimally, unless they use the same vocabulary for defining concepts as DBpedia deploy. This is because Linked Open Data sets use different vocabularies to describe the same concepts, meaning that a great deal of work has to be done in order to address the different vocabularies of every data set and map them to the data visualization library. This is very timeconsuming, and due to the time constraints of the LODWheel project the main focus was directed towards visualizing the DBpedia data entities in the best possible way. However, all data sets that refer to the same ontologies as DBpedia will be visualized the same way as the DBpedia data set. The decision to use DBpedia as the example data set was made on the basis that DBpedia is one of the best data sets when it comes to reusing external ontologies and developing its own robust ontology. Nevertheless, it is still worth to mention that if the DBpedia data set changes its structure by using new predicates or presenting data of different types than when LODWheel was developed, the prototype may not work optimally even on the DBpedia data set.
Figure 2 shows the LODWheel graph-visualization based on the MooWheel library. It
shows the chart-visualization of the DBpedia entity of the Italian company “Fiat”. The data
resources in each category of the legend are separated by applying distinct colors and grouping
them together. Further, it is possible to see what data resources point to each other by following
the colored edges between the data resources (if the color of the edge is the same as the color of
the data resource it means that the data resource is the subject of a triple. If not, the data
resource is the object of a triple). Figure 3 shows the LODWheel chart-visualizations based on
the JQPlot library. It shows the visualizations of the economic data of the “Fiat” company.
These data include the net-income, operating-income, assets, equity and revenue, and they can
be displayed both in a bar-chart and a pie-chart. Aside from the core front-end libraries of
MooWheel and JQPlot, the front-end is built on JavaScript, JQuery, MooTools, HTML and
CSS. It is also worth to mention that a working solution based on the JIT library was also
implemented, a library that received a high overall score in the JavaScript library evaluation.
This implementation works just as well as the JQPlot implementation, but it was decided to use
the JQPlot visualization as the standard graph visualization, based on the fact that it got the
highest score of the free chart-visualization libraries. Additionally, two other
graphvisualizations were implemented, namely the d3 library, and a library based on both Flash and
JavaScript named Cytoscape Web [
LODWheel applies data categorization in order to know what functionality to give each specific data resource. For instance, it is advantageous to group all geo-data into one category, so that the data in that category can be displayed in a geo-map. Each data category that represents data resources in a specific RDF graph is being displayed as legend above the graph visualization. This legend is fully dynamic and only shows the data categories that are actually representative in the graph. The legend properties are given unique colors in order to identify each category. It is worth to mention that this legend is manually programmed into the MooWheel library, as the original MooWheel library did not offer any legend support.
LODWheel categorizes data into fourteen separate categories:
URI (the URI of RDF graph) 2. Type (all the resources the URI is a type of) 3. Subject (the subjects (topics) describing the resource) 4. Comment (comments describing the resource) 5. Abstract (textual description of the resource) 6. Label (the labels of the URI) 7. External links (external links that points to other domains) 8. Geography (resources that are related to geo-data, such as locations) 9. Image (images related to the URI) 10. Name (the names the URI goes by) 11. Economy (resources that are related to economy) 12. Broader (resources with the predicate
“http://www.w3.org/2004/02/skos/core#broader”) 13. Sameas (resources with the predicate “http://www.w3.org/2002/07/owl#sameAs”) 14. Other (resources that do not fall into any of the categories above)
All of these categories are mapped to predicate URIs related to the specific category, except for the “URI” category, which will always refer to the URI that has been looked up, as well as the “other” category that only refer to data resources that do not fall into a specific category. The categorization of the data is implemented in Java objects that store predicate URIs and map them to a specific category. Each data resource that acts as an object in a triple is being checked for what predicate that is used to give semantics to the data resource. Depending on the predicate URI, the data resources are being pushed to a specific category. For instance, the predicate “http://www.w3.org/2003/01/geo/wgs84_pos#lat”, which refers to the latitude of a location, is mapped to the “geography” category. If a data object in a triple is referred to by this predicate, then the data object is being categorized as “geography” data.
LODWheel displays data resources of the category “geography” in geo-maps, by using the Google Map API. Data resources of the category “economy” are displayed in the histograms/bar-charts and pie-charts of the JQPlot library. Data resources that are of a literal type are displayed in a text-window, image URLs are displayed as images, and external links are opened in new windows.
One of the major questions that occurred during this project was how to visualize the different
data resources optimally, based on the data they actually represent. In order to do this, some
way of categorizing data should be implemented. The most logical way to categorize the data in
this aspect would be to implement a form of ontology-categorization. To elaborate, each
predicate URI could be placed in a unique category in the actual ontology, which would make
the logical operations in the system regarding data categorization very standardized and easy to
implement. However, when using Linked Open Data on the Web as the primary data resources
of the system, ontology-categorization is trickier to implement, as external ontologies are not
open for anyone to modify. Based on this, the best way of categorizing data will be to map as
many existing ontologies on the Web with application-specific categories. This way, different
applications can use whatever categories that are purposeful for each specific application,
without having to limit themselves to pre-defined categories in external ontologies. It is also
very hard to develop shared standards for ontology-categorization of data. Moreover, if the data
of the application are based on Linked Open Data from several sources it is most advantageous
to implement some way of mapping predicates from existing ontologies to application-specific
categories, whereas if the data of the application is based on local RDF data, or Linked Open
Data that are based on the exact same ontologies, then ontology-based categorization will be
the best way to go. However, one can argue that applying ontology-categorization to data that
are meant to be a part of the Linked Open Data cloud will put constraints on how the data
should be utilized, which may prevent the data from being used optimally by others.
Nonetheless, one can argue that ontology-categorization is the best way to go when it comes to
categorizing RDF data. There already exist useful frameworks related to
ontologycategorization, e.g. the FRESNEL vocabulary [
There are also several challenges when it comes to the actual visualization of RDF data in graphs and charts. The main challenge is not related to the technical implementation of the data visualization, but rather how the data should be visualized. For instance, it makes sense to show the difference between the net income, operating income, revenue, assets and equity of a company in a bar-chart, but when converting the same visualization to a pie-chart it does not make as much sense anymore. Pie-charts are based on the fact that all resources in the chart should altogether amount to 100% of a given variable. Displaying the economic resources of a company mentioned above in a pie-chart shows the difference between each variable, but the variables do not act as parts of a superior variable. To give an example, if there is a variable representing the total net income of a company, it would make sense to display variables showing what products constituted the total net income. Then the variable “net income” would be the 100% of the pie-chart, and the income of each specific product would amount to the 100% of the total net income. Based on this, one could argue that RDF data should be carefully constructed with the idea in mind that all data resources should relate to each other in a semantic way. Moreover, RDF data could be constructed based on how the data could be visualized in the most beneficial way, making it easy to know what to do with the actual data. On the other hand, this is an ideological approach that is hard to adopt in the real world. Therefore, future research should rather go in the direction of how visualization tools can utilize RDF data in the best possible way when it comes to applying semantic relations between data resources.
Functionality that would enhance the usability of the application would include support for interacting with the legend of the directed graph. Hovering over each legend category could make a small window pop up, displaying all the resources related to that category, and providing the possibilities of quickly interacting with them. Additionally, the pointing between the nodes in the LODWheel graph could be even more intuitive, for instance by applying some type of arrow to give a clearer indication of what data resources are pointing to each other. Also, when hovering over elements it would be beneficial not to fade out the element that is hovered. When the user hovers over elements that are not subjects in the graph, the prototype does not give good feedback to the user that the element is actually possible to hover over and click on. It would also be beneficial to somehow emphasize the main URI that the graph is visualizing. It is usually easy to spot the main URI based on several factors: the URI is identified in the graph by having a “URI: “-description before the actual URI, it has a unique color, it usually points to a great deal of resource objects, and it is located in the same place in the graph in every visualization. However, the URI could be emphasized even more by applying identifiers such as increasing the font-size and node-dot only for the URI. Finally, LODWheel is only tested in the Mozilla Firefox v5.0, Google Chrome v12.0.742.122 and Internet Explorer v9.01 Web browsers. Firefox and Chrome are compatible browsers, whereas the system does not run properly in Internet Explorer. Optimizing the system to be compatible for all common Web browsers is a challenge that should be addressed in future development.
Finally, customizing the LODWheel for being compatible with other data sets apart from the DBpedia data set is not a major task. This would include mapping predicate URIs from other data sets to the visualization library and the legend data stored as Java objects. Also, an interesting aspect for future development is the idea of using several wheels for visualizing data, instead of updating the same wheel every time a new URI should be visualized.
The main purpose behind this project was to analyze the suitability of relevant JavaScript libraries for visualizing RDF data. This was done by performing an extensive evaluation of 15 JavaScript-based data visualization libraries, based on a great deal of different evaluation criteria. This evaluation acted as the foundation for choosing two JavaScript libraries that were implemented as a prototype - one library for visualizing graphs, and one library for visualizing charts. The MooWheel and JQPlot libraries acted as the foundation of the LODWheel prototype, based on the fact that the libraries obtained the highest score in the evaluation and were published under a free license. The LODWheel aims at providing insights into how RDF data can be visualized as graphs and charts, and the underlying challenges concerning these ways of visualizing RDF data. The challenges are mainly related to categorization of data resources, and relating data resources to each other in new ways. An example of this was given in Section 6, regarding the discussion of the “net income” variable of a company, and how this variable could act as a total of several different net incomes from a variety of products the company produces.
There are also big challenges related to external data issues. Since the system retrieves external data from Linked Open Data sets on the Web, it is to a great extent dependent on these data sets being well described. This is often not the case, which leads to numerous issues that need to be addressed. The challenge in this aspect is the fact that most open data sets do not use the same data terminology, meaning that the data sets describe the same data resources, but with different vocabulary. Most of these data sets do not adopt one of the main Semantic Web principles, which is the reuse of already existing ontologies. This makes it hard to develop a standardized system that is interoperable with all RDF data sets. Additionally, there is a great deal of uncovered territory when it comes to data-categorization of RDF data. Future research should look at the advantages and disadvantages between ontologycategorization versus application-specific categorization, and how each of these methods for categorizing RDF data can support different types of applications. It is also important to address how visualization tools can utilize RDF data for visualizing the data as intuitively and semantically as possible.
Acknowledgements. The work of Magnus Stuhr is partly funded by Computas AS, and the work of David Norheim is fully funded by Computas AS. The work of Dumitru Roman is partly funded by the Norwegian national project Semicolon 2, and the EU projects ENVISION (FP7-249120) and ENVIROFI.