# Building Semantic Knowledge Graphs from (Semi-)Structured Data: A Review
## 5 Results
### Adoption
#### 5.2.2 Limitations and Lessons Learned  
There is a wide variety of limitations reported. The limitations presented are related to the process used to generate the knowledge graph and the associated tools/systems. This then is often linked to future work, which also gives an insight into the primary focus of the research. Reported limitations are listed in Table 6. We see that more data are needed to be integrated in several cases, and there is a lack of tools for exploration, showing that there is still room for improvement in this area. The limitations related to linking to the other knowledge graphs and vocabulary coverage show that there is still work to do to support these core aspects. We also extracted lessons learned from the reviewed works, and the frequent ones include:  
* Publishing the knowledge graph in an alternative data format, e.g., CSV, helped those not familiar with graph technologies consume the data more easily. * Metadata helped understandability. * Publishing the vocabulary helped linking. * Using a transformation pipeline made the process more maintainable. \begin{table}
\begin{tabular}{l c} \hline \hline
**Limitation** & **Count** \\ \hline Graph content & 10 \\ Tools for exploration & 7 \\ Links to other graphs & 5 \\ Coverage by vocabularies & 4 \\ Cross-language support & 3 \\ Semantic Web skills and knowledge & 2 \\ Automation & 2 \\ Evaluation & 2 \\ Use cases & 2 \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Reported limitations. Figure 6: Evaluation methods. Users were more familiar with JSON, which helped bridge the gap between JSON-LD and RDF. * Standard vocabulary helped understandability. * Interlinking unveiled unknown analytics. * Rest API made the knowledge graph more understandable. * GitHub helped tracking data when mapping to RDF. * Data cleaning was important. * Validation was important to make vocabulary use understandable. * Use of experts helped data quality. * Linking to other graphs helped derive structural concepts. * Keeping track of sub-graphs can be difficult. * Having many sub-graphs resulted in several vocabularies. * Errors related to the automation of RDF mapping were out-weighted by the potential for improvement. * Vocabulary lookup services helped matching vocabularies. * Vocabularies may be prone to subjectivity. Several lessons learned related to making the knowledge graphs easier to use for non-experts were reported, which seems an important focus in many of the studies. Other than this, many of the mentions relate to specifics, such as handling of sub-graphs, or that GitHub helped tracking data in the mapping process. Even though these mentions can only be related to the respective primary study, they are valuable in pointing out issues that may be occurring in the future for other knowledge graph producers and motivate the developments of new solutions and tools. Even though issues are expected when transforming data, few issues were reported, including:  
* Five studies mention issues with poor quality of the data source, in terms of, e.g., missing data, duplicate data, and erroneous data. * [PERSON] et al. [75] (#6) report an unstable SPARQL endpoint. * [PERSON] et al. [82] (#13) report that the URI strategy made some of the data ambiguous. * [PERSON] et al. [96] (#27) report erroneous language classification in the graph based on user-provided country of origin. * [PERSON] et al. [97] (#28) report that blank nodes create issues when updating the knowledge graph. * [PERSON] et al. [99] (#30) report that the automated mapping pipeline gave erroneous results. * [PERSON] et al. [104] (#35) report that linking via string matching gave errors. The reported issues are quite different, and the low count indicates that they are exclusive to their respective reports. However, some of the issues, such as trouble with URI strategy, updates, and automation are expected depending on the domain.