Semantic Models for Constructing Knowledge Graphs | by Giuseppe Futia | Towards Data Science

If you are completely new to Knowledge Graphs and related concepts, such as the mapping from data sources to ontologies, I invite you to read the following introductory articles.
towardsdatascience.com
towardsdatascience.com.
Knowledge Graphs (KG) are effective tools for capturing and structuring a large amount of multi-relational data, which can be explored through query mechanisms. Considering their capabilities, KGs are becoming the backbone of different systems, including semantic search engines, recommendation systems, and conversational bots.
Integrating and publishing data into KGs is a complex process. Indeed, it requires extracting and merging information from heterogeneous sources. In the case of structured sources, such as tables (CSV, HTML tables, relational databases, etc.) and tree-based structures (XMLs, JSONs, etc.), the integration strategy is to map their local schemas to the global schema represented by the target ontologies.
In a previous article, I discussed the widest-adopted approaches for the mapping step based on the so-called custom mappings. These approaches exploit customizable documents written with declarative languages to perform the mapping generation step. Declarative languages adopt the Semantic Web formalisms (RDF, SPARQL, etc.) to describe the relationships between the local schemas of data sources and the global schemas of ontologies. I proposed an example in the public procurement domain using the JARQL declarative language:
@prefix dcterms: <http://purl.org/dc/terms/> .@prefix pc: <http://purl.org/procurement/public-contracts#> .@prefix gr: <http://purl.org/goodrelations/v1#> .@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .CONSTRUCT {    ?BusinessEntity0 dcterms:identifier ?proposing_struct__business_id ;        rdf:type gr:BusinessEntity.    ?BusinessEntity1 dcterms:identifier ?participants__business_id ;        rdf:type gr:BusinessEntity .    ?Tender0 pc:bidder ?BusinessEntity1 .    ?Contract0 dcterms:identifier ?contract_id ;        rdf:type pc:Contract ;        pc:contractingAuthority ?BusinessEntity0 ;        pc:tender ?Tender0 .}WHERE {    ?root a jarql:Root.    OPTIONAL { ?root jarql:contract_id ?contract_id . }    OPTIONAL { ?root jarql:proposing_struct ?proposing_struct . }    OPTIONAL { ?proposing_struct jarql:proposing_struct__business_id    ?proposing_struct__business_id . }    OPTIONAL { ?root jarql:participants ?participants . }    OPTIONAL { ?participants jarql:participants__business_id    ?participants__business_id . }    BIND (URI(CONCAT('http://purl.org/procurement/public-contracts/contract/',    ?contract_id)) as ?Contract0)    BIND (URI(CONCAT('http://purl.org/goodrelations/v1/businessentity/',    ?proposing_struct__business_id)) as ?BusinessEntity0)    BIND (URI(CONCAT('http://purl.org/goodrelations/v1/businessentity/',    ?participants__business_id)) as ?BusinessEntity1)    BIND (URI(CONCAT('http://purl.org/procurement/public-contracts/tender/'    ?contract_id + + '_' participants__business_id)) as ?Tender0)}
In this article, I want to focus the attention of the reader on the CONSTRUCT section, which describes the graph patterns that encode two different results of the mapping process: the semantic types (or semantic labels), such as:
?BusinessEntity0 dcterms:identifier ?proposing_struct__business_id .
and the semantic relations, such as:
?Contract0 pc:contractingAuthority ?BusinessEntity0
Considering the CONSTRUCT section, the mapping problem can be seen as a graph-based problem. In particular, based on the original work provided by the Center on Knowledge Graphs of the Information Sciences Institute (USC — University of Southern California), the result of the mapping can be seen as a graph, known as a semantic model, which can express the links between the local schema, represented by the attributes of the target data source, and the global schema, represented by the reference ontologies.
A semantic model is a powerful tool for representing the mapping for two main reasons. In the first place, it frames the relations between ontology classes as paths in the graph. Secondly, it enables the computation of graph algorithms to detect the correct mapping.
The implementation of the semantic model approach requires that ontology axioms are represented in a graph structure. The ontology can be seen as a directed, typed, labeled, and multi-relational graph depicted in the following figure:
The graph nodes represent the classes defined by the ontology. The edges represent the different types of property in terms of object properties, depicted with black arrows, data properties, depicted with the grey-dashed arrows, and subclass relations, depicted with grey arrows. Based on the ontology graph, the mapping can be framed into the semantic model, a directed and labeled graph, whose leaf nodes represent the data source's attributes. The other parent nodes and edges derive from the classes and the properties defined in the ontology. In the running example, the correct semantic model is depicted in the following figure. You can observe that this graph corresponds to the CONSTRUCT section of the JARQL file introduced before.
The automatic generation of a semantic model is based on two main steps. The first step is represented by the semantic type detection, where each attribute of the data source is annotated with a pair of an ontology class and a datatype property. From a graph-based perspective related to the running example, the attribute node contract_id is connected to the class node Contract through the identifier data property. Details related to the semantic types are depicted in the following figure:
The second step is the semantic relation inference, whose goal is to identify the connections between the annotated attributes. In the simplest case, this relation is represented by an object property, and the length of the relation (or path) is equal to 1. In the running example, the classes Contract and BusinessEntity that annotate the attributes contract_id and proponent_struct**business_id are connected with the property contractingAuthority.
In more complex situations, the path includes different ontology classes and properties, and its length is longer than 1. In the public procurement domain, this type of semantic relation includes the class nodes Contract, Tender, and BusinessEntity. Contract and Tender are connected by the tender object property, while Tender and BusinessEntity are connected by the bidder object property.
This example demonstrates that inferencing the correct semantic relation is a complex task. In fact, many semantic relations of different lengths can be plausibly correct for building the target source's semantic model. The following figure shows an example of an inaccurate semantic model for the target source.
However, representing the explicit semantics of data sources using graphs enables new opportunities for automatic computation. For instance, we could assign cost edges that can convey the semantics of the data. Then, we could apply graph algorithms: for instance, we can try to detect a minimum weight spanning tree (Steiner Tree), which connects all the data nodes, or in other words, the attributes of the target data source. The following figures show two different integration graphs describing all plausible semantic relations between the annotated attributes. You can notice how Steiner Tree's detection changes according to the integration graph's edge costs.
In this example, you can see that the shortest path connecting a Contract and a Business Entity on the right side of the figure is the edge labeled using the contractingAuthority property.
Instead, this example shows that the shortest path connecting a Contract and a Business Entity on the right side of the figure includes the Tender class. This Steiner Tree correctly represents the semantic model of the data source because it can interpret its semantics.
The article shows how the well-known mapping for constructing KGs from data sources can be shaped as a graph structure known as a semantic model. This structure enables new opportunities for automation. In fact, as shown in the previous examples, the inference of the semantics of a data source can be performed by applying graph algorithms to the integration graph. This graph describes all plausible semantic models of the data source, and its edges need to be weighted to drive the selection of the correct semantic model. Based on this principle, in the next article, I will present a novel approach based on Graph Neural Networks to assign the edge costs to make explicit the semantics of the data sources.
If you like my articles, you can support me using this link https://medium.com/@giuseppefutia/membership and becoming a Medium member.