A generic technique for the visualization of hierarchical structures is introduced. The actual visualization is not only de ned by the underlying data but also the application of domain-driven metrics. The paper shows two use cases for the analysis of linked enterprise data in the domain of technical service information systems. In the age of digitalization and automation of industries, many companies are consolidating their business information systems and product meta-data, such as ERP, CRM, le directories, and extranet data. In many cases, not all elements of these information resources are accessible to all relevant users. The intransparent access hinders e ective work processes and often threatens business success. Therefore, the primary goal of many ICT projects is the linkage of the existing information silos into an integrated information infrastructure. Here, semantic technologies, and especially linked data models, are a successful enabler for building such knowledge warehouses mediating the information silos. Linked Enterprise Data [1] transfers the ideas and technologies of linked data [2] into the much more restricted world of business and enterprises. Standard semantic languages, such as RDF and SPARQL, are used to represent the core entities of the enterprise. Useful de-facto standard vocabularies for the enterprise usage already exist, see for instance SKOS [14] and GoodRelations [8]. Within a semantic infrastructure, all information resources are uniformly and semantically accessible by the user and novel services. In consequence, a number of advanced applications with business added value become possible [13]: { Semantic enterprise search { Semantic B2B portal with standardized data exchange { Semantic assistants { Automated data quality and curation processes
During the migration from the existing information structure to linked
enterprise data, existing information sources need to be linked with semantic concepts.
Here, a toolbox of core technologies ranging from Natural Language
Processing/Information Extraction to Information Retrieval methods [
In Figure 1 the semanti cation process of enterprise data is depicted [
Enterprise Corpus
Operations Manual #05 Repair Manual
#4711 Spare Parts Data Base
Repair Manual #4711
DoDcuomcuemntent
Info Unit #1
Information Unit: Segment 1 The necessary components for the transmission control such as the gear selector switch, the electric ..
Token necessary Term gear selector switch I Corpus Analysis
II Information Source Analysis
III Information Unit Analysis IV Concept/Term Analysis I Corpus Analysis The existing data is collected and described. All relevant information systems are analyzed with respect to the included information sources.
II Information Source Analysis The included information sources are analyzed in more detail, for instance, with respect to the size and number of elements in the corpus.
III Information Unit Analysis Information sources are composed of information units, i.e., segments of a source that are not dividable anymore. Number and distribution of segments for information sources are relevant factors.
IV Concept/Term Analysis The use of ontological concepts in the information units is analyzed and improved by automated methods.
During the process, the exploration and visualization of the data is of core
importance [
The rest of the paper is organized as follows: First we introduce the core components of a linked data city, namely buildings and (nested) districts. Then, we describe the current implementation of the approach and demonstrate the usefulness of the visualization method by examples. In the conclusions we show promising steps for further work.
The metaphor for visualizing linked data as a city is inspired by the work of
Wettel [
building building with different levels
district nested sub-district district city
Complex artifacts with part-of or hierarchical relations can be naturally visualized as a city: As we see in Figure 2, core elements of the artifacts are usually depicted as buildings of the city, that are grouped within districts. For deeper part-of or hierarchy relations the districts can be nested in sub-districts. The size of districts correlates with the number and sizes of the included buildings, whereas the size and color of the buildings represent speci c performance indicators that are de ned by the current analysis query. The speci c con guration of buildings, districts, sizes, and colors is called data city metric. At the top of the gure we also see that buildings can have di erent levels. Di erent levels of a building are commonly used to include di erent metric attributes in the visualization.
For humans it is easy to understand the city metaphor. Like in the real world, local areas of the city are represented in districts and often the size of houses corresponds to their weight. For large cities (real and arti cial) the user is familiar in incrementally explore the particular districts and buildings. For this reason, an advanced visualization application need to allow for the interactive exploration by drill-down and roll-up operations within the city. 3
The presented visualization technique is implemented as a JavaScript library. That way, it can be easily integrated into (web-based) knowledge engineering tools but also runs as a stand-alone tool in a web browser. The de nition of the city itself is represented as a JSON document. The following example shows books of a technical documentation that are represented as districts. Sections of a book are represented as buildings contained in the district.
" L a b e l " : " L i n k e d Data City 0 815 " , " D i s t r i c t s " : [ { " L a b e l " : " T e c h n i c a l D o c u m e n t a t i o n " , " c o l o r " : " # 2 9 7 B 4 8 " " D i s t r i c t s " : [ { " L a b e l " : " R e p a i r M a n u a l # 4711 " , " c o l o r " : " # 8 4 8 4 8 4 # " " B u i l d i n g s " : [ { " L a b e l " : " S e c t i o n # 4 7 1 1 . 1 " , " c o l o r " : " # 0 F 2 A 6 5 " " d e p t h " : 2 , " h e i g h t " : 1 , " w i d t h " : 2 ...
} , { } , " L a b e l " : [ " S e c t i o n # 4 7 1 1 . 2 a " ,
" S e c t i o n # 4 7 1 1 . 2 b " ] ,
" c o l o r " : [ " # 0 F 2 A 6 5 " , " # A F 5 C 0 B " ] ,
" h e i g h t " :[
The de nition of the city is straight-forward, as we can see that districts can be nested in other districts. A leaf district contains a collection of buildings in a corresponding element \Buildings". For the district \Repair Manual #4711" two buildings are shown. The rst building \Section #4711.1" is an example for a simple building having only one level included. The second building shows two labels, colors and heights representing the two levels of the building. 4
The architecture of a city is de ned by the applied data city metric, i.e., the de nition of colors, sizes, and levels of the buildings and districts. In this section, we demonstrate the approach by two use cases.
The presented metrics were used in the context of an industrial semanti
cation project, where information sources of technical service information were
analyzed. Here, buildings of a city represent a special kind of elements of the
linked enterprise data. In enterprise systems the data refers to a domain-speci c
ontology. For instance, machinery builders typically align their data
(documentation, parts, 3D models, etc.) to an ontology of products, components and
functions, cf. [
In the following we present two basic metrics that investigate (a) the use of the product structure within the available information resources and (b) the availability of annotations in the information resources.
Use Case: Usage of Product Structure (UPS) The product structure of an enterprise de nes how products are organized in di erent levels. This organization includes multiple hierarchies for representing the relation of components and parts, but also for the functions of the product.
The primary subject of the UPS analysis is the actual use of the elements de ned in the product structure. The use of the elements corresponds to annotations done with these elements included in the data of the investigated information systems. The metric is applied to nd out how well the product structure is used in current enterprise information.
In the visualization, leaf elements of the product structure are represented by buildings and upper elements of the product structure are represented as wrapping districts. The height of the buildings correlates with the number of uses within all considered information sources. Higher buildings are thus used more often.
At the left side of Figure 3, a zoomed building representing the component \Engine block" is shown. The building itself is located in the district with the name \Engine". We see that the building consists of multiple levels specializing the location of occurrences. Here, the element was used most often in the resource \doc#1" and the resource \3d#3".
Component “Engine block” Uses in doc#1 Uses in doc#2 Uses in 3d#3
Uses in parts#4
The visualization gives a very quick overview of actual application of a product structure. Unused areas can be easily spotted as well as elements with heavy use. Applied to a representative corpus of information resources, the visualization method points to areas in the structure that need re nement; both for lazy and frequent elements.
An interactive visualization is appropriate for very deep hierarchical structures. Then, buildings do not necessarily represent leaf-elements of the hierarchy but aggregated elements. Entering a building (e.g., by clicking on it) the building will drill-down the product structure and build a city visualization for all sub-elements contained in the aggregated element.
Use Case: Corpus Annotation Frequency (CAF) Besides the actual use of the product structure the annotation frequency of the information resources is of prime interest. Usually, meta-data is attached to the information units to formally describe the contents. This meta-data mainly corresponds to elements of the product structure.
For the metric CAF, the city visualization is created as follows: The information sources in the corpus are represented as districts of the city, e.g., technical documentation, spare parts catalog, or FAQ data base. Sub-elements of these districts are further represented as nested sub-districts, e.g., a particular repair manual contained in the technical documentation or the spare parts catalog of a speci c machine. Core information units are represented as buildings, for instance, a speci c chapter of a repair manual in the technical documentation. The height of a building corresponds to its number of meta-data annotations; a buildings can can have more than one level when di erent types of meta-data are included corresponding information unit. For instance, a chapter may include annotations of a component hierarchy but also of the functional hierarchy.
This visualization gives an overview of the corpus size and the existing annotations. Less annotated areas can be easily spotted but also districts (information sources, books types, etc.) with a high annotation quality. The results can help to motivate which areas of the structures need to be used much more frequently in information resources. With this knowledge, annotation initiatives (automated or manual) can be motivated and precisely planned. 5
Recently, more and more business information systems are transformed to linked enterprise data models. Appropriate visualization and exploration techniques support the semanti cation process of enterprise data. In this paper we presented Linked Data Cities, an interactive and generic method for the visualization of hierarchical structures. The actual visualization is de ned by the application of a domain-speci c metric. We introduced a number of metrics that showed its usefulness in an industrial semanti cation project.
In the future we are planning to improve the simplicity of the visualization by drill-down techniques, where similar buildings are clustered in aggregated building or districts. Then, even very large system structures can be (interactively) explored. Furthermore, we are working on the automated linkage of the city structure to existing linked data. Currently, scripts are used to transfer the information into the city data notation (the shown JSON). In the future, the automated transformation by SPARQL queries could be a possible simpli cation of this process.