# Building Semantic Knowledge Graphs from (Semi-)Structured Data: A Review
## 5 Results
### Technical Analysis
#### 5.1.3 Resources  
There are in total seven different data source types mentioned, as shown in Figure 3. There is a diverse set of data source types. The XML format is the most common type of source, indicating that much of the data may be taken from sources available on the Web. We also see JSON, CSV, and relational data are much utilised. The JSON format is typically seen in API sources and may be an easy target for knowledge graph transformation without needing much preprocessing.  
Regarding the tools used, an account is given in Table 4. We observe that most of the listed artefacts are mentioned once and show a discrepancy in the creation of knowledge graphs; a large portfolio of tools are available (see [PERSON] et al. [113] for knowledge graph generation tools from XML and relational databases). Useful tools such as SWI Prolog [114] and languages such as SHACL are scarcely referenced. Heavily referenced tools include the triple stores Jena TDB (and Fuseki) [115] and OpenLink Virtuoso [23], together with other tools and languages such as SILK [116] for linking data, Pubby [117] for publishing, and XLST [118] as a mapping language. In addition to the two mentioned databases, it appears that there is a wide variety of needs and preferences for different knowledge graphs.  
Considering the ontologies and vocabularies used, an account is given for the most used ontologies in Table 5. We observe there is a frequent use of metadata ontologies for describing the different datasets. This may probably be due to the fact that the creators of the knowledge graphs are actually interested in following the good practice of describing  
Figure 3: Data source types used.  
\begin{table}
\begin{tabular}{l l l l} \hline \hline
**Phases** & **Total** & **Papers** & **Tasks** \\ \hline Ontology development & 36 & all & Ontology modelling (1), ontology reuse (35), ontology linking (1), \\  & & & URI/IRI strategy (28) \\ \hline Data preprocessing & 16 & \#3-\#5, \#8-\#11, \#13, \#16, \#22, \#26-\#28, \#30, \#31, \#33 & Data cleaning (14), conversion (2), refactoring (1), enrichment (5) \\ \hline Data integration & 36 & all & Mapping (36), transformation (35), virtualisation (1), data linking (22) \\ \hline Quality and refinement & 4 & \#3, \#4, \#7-\#9, \#11, \#13-\#15, \#17, \#18, \#24, \#26, \#32-\#35 & Evaluation (17), validation (3) \\ \hline Data publication & 36 & all & Publication (36), update (2), graph versioning (4) \\ \hline \hline \end{tabular}
\end{table}
Table 3: Phases and tasks for knowledge used for graph construction.  
their data, but it may also be because it becomes more relevant when the data contained come from another source. We also see that on the other side, reusing already defined classes and properties, from, e.g., Schema.org or DBPedia, is not common.  
Regarding the specific methodologies used in creation of the knowledge graphs, there were few examples of reusing existing frameworks, both for the whole creation process and also just for the ontology development, even though there are many frameworks available. From all of the 36 chosen primary studies, only [PERSON] et al. (2018) (#13) mention using the eXtreme Design methodology in development of the ontology. Other than this, some studies, such as [PERSON] et al. (2018) (#9), mention the development of tools for the creation process as a framework but do not label it as a dedicated methodology.