A knowledge graph (KG) is a graph that needs to fulfill specific criteria and is key in unlocking data siloes and tacit information for innovative applications. However, organizations may find it hard to identify use cases for KGs and even assessing whether a KGs is a viable approach for a particular problem. Within Smals Research, we designed the Smals KG Checklist, which guides a group of stakeholders in determining whether KG technologies can be used to address a concrete problem. The checklist is to be used in a workshop environment where a facilitator guides the stakeholders in filling the checklist.
Smals is a non-profit organization that realizes innovative ICT projects for mostly Belgian (semi-)government departments and other affiliated members. Within Smals, the Smals Research† department investigates opportunities for using, deploying, and developing skills and know-how for emerging and innovative technologies for its members. One of these technologies, amongst many others, is knowledge graphs (KGs) [1].
It has become apparent that business analysts‡ and members (from now on called stakeholders) have difficulty understanding the concept of KGs. Stakeholders do have a good understanding of the problems they face, but do not know how these problems can be solved using KGs. Anecdotally, for instance, stakeholders have shown interest in recommender systems to propose related information, whereas it turned out to be “simply” information about the same entity from two different silos—i.e., a data integration problem. Stakeholders are familiar with graph databases as they have been adopted to solve specific problems such as graph analytics. Still, these graphs cannot Copyright ©2021 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). † https://www.smalsresearch.be/ ‡ Smals employees that are working closely with its members to comprehend their business needs, translating those into ICT projects, and follow up and manage the realization of these projects. (yet) be regarded as KGs, which adds to the confusion.
To help stakeholders understand the concept of a KG and, more importantly, to assist them in assessing whether a KG is a viable approach in tackling concrete problems, we have designed the Smals KG Checklist§. The checklist is to be used in a collaborative setting such as a workshop in which stakeholders provide input. The checklist acts as a guide for the workshop facilitator, and it is up to the facilitator to capture and refine the stakeholder’s input. 2
In [1], the authors analyzed various definitions of the term KG. While there is no consensus, [1] allows us to summarize that a KG is a graph (representing entities and their relationships) that fulfills three criteria: C1) the KG has a non-trivial schema or ontology; C2) the KG integrates information from heterogeneous sources; and C3) the KG is used to gain insights by inferring implicit information from explicit information (either via the schema, machine learning, or tooling on top of the KG).
KGs are typically stored in graph databases, but graph databases are also used in other scenarios. Graph databases are necessary for graph analytics and may solve issues stemming from a relational database’s computational limitations. An example of the latter is Neo4j’s use case on access and identity management. Neo4j reported on the migration of a relational database to a graph database to avoid expensive recursive joins.** As the data was merely migrated and not all criteria were met, we argue that this project did not yield a KG.
How can we determine whether a project needs a graph or a KG? To determine whether a particular problem can be solved with a KG, we need to determine whether a solution requires the three criteria to be met. 3
KG technology vendors often publish whitepapers and blog posts on the successful application of KG. Even organizations report on their use cases and lessons learned (e.g., [2]). While valuable, not all organizations are faced with the same problems and organizations do not necessarily have the expertise to extrapolate those examples to similar cases. There are also resources aimed at both academia and industry (e.g., [3]). While they also provide valuable information on everything involved in a KG project (activities, methodologies, techniques, etc.) and examples, they do not provide a tool such as our checklist to determine the applicability of KG technologies for a problem. The Smals KG Checklist, which we present in this paper, thus addressed this critical gap.
We designed a tool that can be used in a workshop setting, much like a business model canvas or an ethics canvas [4]. As we start from concrete problems and the questions we needed to be answered are well-scoped, we did not pattern our checklist after these canvases. § Made available with a CC BY-NC-SA 4.0 via https://www.smalsresearch.be/wp-content/uploads/2021/06/smals-kg-checklist.pdf ** https://neo4j.com/blog/enterprise-identity-access-management/, last accessed May 25th, 2021
The checklist consists of two parts (see Fig. 1 and Fig. 2). In Part I, we first identify the problem, stakeholders, and core concepts. Then we aim to answer three questions by filling in Part II (Fig. 2). These three questions are related to the criteria of a KG mentioned in the previous section. The final question on Part I is used to identify future opportunities for the KG, or its applicability in the longer term. Once filled in, and refined over time, the checklist can be used to determine whether KG technologies are needed to solve a particular problem. The questions on KG criteria are given a color, and these colors reappear in the sections of the second part: purple corresponds with C1, green with C2, and orange with C3. These sections are key in determining whether all criteria are (or have to be) met: • • •
Section I is used to list the sources that will inform our schema. Section I has two colors as the integration of an existing database could appear in both the bottomup integration of structured data (Section II in Fig. 2) and as input for the KG’s schema by lifting its database schema.
Sections II and IV are concerned with integrating structured and unstructured data, respectively. The integration of provenance information, metadata, annotations,…of data mentioned in Sections II and IV is captured in Section III, and therefore placed between Sections II and IV. We have noticed that it helps to ask this question explicitly.
Sections V and VI are respectively concerned with symbolic reasoning (e.g., OWL reasoning) and machine learning. As reasoning over the KG requires an ontology, there is an arrow from Section II to Section I. Reasoning and AI techniques are clear indications of gathering insights from the KG and are therefore orange. We can argue that retrieving information according to Linked Data principles does not necessarily help one gain insights, but visualization tools (e.g., [5, 6]) and faceted browsing (e.g., [7, 8]), amongst others, may. This is why Section VII, concerned with applications on top of the KG, has a gradient fill instead of a complete fill. We deem the criteria w.r.t. to Section VII fulfilled when the need for such tools to gather insights is mentioned.
We use one of Smals Research’s KG projects with the Belgian Social Security to illustrate the checklist by filling in the forms. This project aims to integrate the data of three databases to which inspectors have access but are unable to query as a whole. Integrating the data into a KG requires an ontology and would greatly facilitate their work by allowing them to gain insights in, for instance, one’s employment histories. 5
It is difficult for organizations to identify when KGs technologies are a viable means to an end. There are many valuable resources on KGs available, but they either focus on constructing KGs or report on KG use cases that organizations need to extrapolate. To help organizations determine whether a KG will help tackle a concrete problem, we designed the Smals KG Checklist. The tool is meant to be filled by a group of stakeholders, with a facilitator taking the lead and guiding the discussion.
Disclaimer. The views and opinions expressed in this paper are those of the authors and do not express the views or opinions of Smals. Acknowledgements. We thank Gunther Hellebaut, Karel Van Eeckhoutte, and Catherine Vanden Daelen for their feedback.