Building Knowledge Graphs from Structured Sources | by Giuseppe Futia | Towards Data Science

Knowledge Graphs (KGs) are labeled and directed multigraphs that encode information in the form of entities and relations relevant to a specific domain or organization. KGs are effective tools for capturing and organizing a large amount of structured and multi-relational data that can be explored employing query mechanisms. Considering these features, KGs are becoming the backbone of Web and legacy information systems in different research fields and industrial applications. Further details on KG features, including RDF, ontologies, and SPARQL, are available in the following article:
towardsdatascience.com
Publishing data into KGs is a complex process because it requires extracting and integrating information from heterogeneous sources. The goal of integrating these sources is harmonizing their data and leading to a coherent perspective on the overall information. Heterogeneous sources range from unstructured data, such as plain text, to structured data, including table formats such as CSVs and relational databases, and tree-structured formats, such as JSONs and XMLs. The contribution of this article is specifically related to the publishing of data into KGs from structured data sources through a mapping-based approach.
Structured data sources play a fundamental role in the data ecosystem because much of the valuable (and reusable) information within organizations and the Web is available as structured data.
Unlike other sources, such as plain texts, structured information can be mapped to KGs through a semantic integration process. The common strategy adopted by the Semantic Web (SW) community to apply this process is adopting reference ontologies as global schemas. Then, mappings are constructed to describe the relationships between the global schema and the local schema of the target data source. From a data integration perspective, this approach is classified as Global-As-View (GAV).
According to this perspective, data integration performance is based on the consistency and the expressiveness of the ontology adopted as a global schema. In order to clarify the mapping process in a real scenario, the following section introduces a running example in the public procurement domain.
Public procurement refers to the process by which public authorities and administrations purchase goods or services from companies. In this process, the public authority announces a call for tenders, companies participate in this call with a specific tender, and the public authority shall award one of these tenders.
Suppose we have a target data source ds, including a set of attributes ds{a1, a2, a3, ...}. In public procurement, the target data source is a JSON file representing a specific public contract. The JSON (JavaScript Object Notation) is a language-independent data interchange format. It employs human-readable text to store and transfer data objects characterized by attribute-value pairs and any serializable datatype, including arrays.
{   "contract_id":"Z4ADEA9DE4",   "contract_object":"MANUTENZIONE ORDINARIA MEZZI DI TRASPORTO",   "proposing_struct":{      "business_id":"80004990927",      "business_name":"Ministero dell'Interno"   },   "participants":[      {         "business_id":"08106710158",         "business_name":"CAR WASH CARALIS"      }   ]}
This JSON describes the following data:
contract_id includes the identifier of the required service (“Z4ADEA9DE4”).
contract_object includes the description of the service (“MANUTENZIONE ORDINARIA MEZZI DI TRASPORTO”).
business_id and business_name, nested in the proposing_struct field, include the identifier (“80004990927”) and the name (“Ministero dell’Interno”) of the public body, which proposes the tender.
business_id and business_name, nested in the participants field, include the identifier (“Z4ADEA9DE4”) and the name (“CAR WASH CARALIS”).
The mapping process requires a reference ontology O as a global schema. The Czech OpenData.cz initiative releases one of the most common ontologies adopted in public procurement, and it is available on GitHub: https://github.com/opendatacz/public-contracts-ontology.
The ontology axioms involved in the mapping process related to our running example can be represented in Turtle format as follows:
@prefix dcterms: <http://purl.org/dc/terms/> .@prefix gr: <http://purl.org/goodrelations/v1#> .@prefix owl: <http://www.w3.org/2002/07/owl#> .@prefix pc: <http://purl.org/procurement/public-contracts#> .@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .####### ####### Classes#######pc:Contract a owl:Class .gr:Offering a owl:Class .pc:Tender a owl:Class ;    rdfs:subClassOf gr:Offering .####### ####### Relations (or Object Properties)#######pc:contractingAuthority a owl:FunctionalProperty, owl:ObjectProperty ;    rdfs:domain pc:Contract ;    rdfs:range gr:BusinessEntity .pc:tender a owl:ObjectProperty ;    rdfs:domain pc:Contract ;    rdfs:range pc:Tender .pc:awardedTender a owl:FunctionalProperty, owl:ObjectProperty ;    rdfs:subPropertyOf pc:tender .pc:bidder a owl:ObjectProperty ;    rdfs:domain pc:Tender ;    rdfs:range gr:BusinessEntity .####### ####### Datatype properties#######dcterms:identifier a owl:DatatypeProperty ;    rdfs:domain pc:Contract ;    rdfs:domain gr:BusinessEntity ;    rdfs:range rdfs:Literal .rdfs:label a owl:DatatypeProperty ;    rdfs:domain pc:Contract ;    rdfs:domain gr:BusinessEntity ;    rdfs:range rdfs:Literal .rdfs:description a owl:DatatypeProperty ;    rdfs:domain pc:Contract ;    rdfs:range rdfs:Literal .
The whole mapping process includes two main steps. The first step is creating a map between the local schema of the target data source and the reference ontology. The second step is materializing the source’s data as KG statements or virtualizing the access to the source, defining a graph-based view over the legacy information. Materialized statements can be directly published into KGs, while a graph-based and virtualized access allows us to retrieve and explore data of the target data source like it is a KG.
The widest-adopted approaches for the mapping step are based on the so-called custom mappings. These approaches exploit customizable documents written with declarative languages to perform the map generation step. Declarative languages exploit the SW formalism to describe the relationships between the local and the global schemas.
The most prominent language adopted by the research community is R2RML, which expresses customized mappings written in RDF between relational databases to KGs. An extension of this language, known as RML, is a more generic mapping language, whose applicability is extended to other types of tables, such as CSV files and tree-structured schemes. Other types of languages, such as TARQL and JARQL, adopt the SPARQL syntax to create mappings for specific formats, such as CSV and JSON files, respectively. An example of JARQL describing the mapping between the ds and O is available below:
@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)}
This JARQL file includes 3 main parts. The first one is included in the CONSTRUCT section, while the others are included in the WHERE section.
The CONSTRUCT section describes the graph patterns that encode the semantic types, such as
?BusinessEntity0 dcterms:identifier ?proposing_struct__business_id .
and the semantic relations, such as
?Contract0 pc:contractingAuthority ?BusinessEntity0 .
The first segment of the WHERE section, which includes the OPTIONAL operators, describes how to parse the JSON file for extracting the data required to create the KG statements. For instance: the pattern
?proposing_struct jarql:proposing_struct__business_id ?proposing_struct__business_id .
indicates that the variable ?proposing_struct__business_id has to be replaced with the proposing_struct__business_id attribute of the JSON.
The second segment of the WHERE section, which includes different BIND operators, declares how to generate the entity URIs for the data extracted from the JSON. The line
BIND (URI(CONCAT(‘http://purl.org/procurement/public-contracts/contract/', ?contract\_id)) as ?Contract0) .
indicates that the URIs of contracts are built combining the http://purl.org/procurement/public-contracts/contract/ URI and the value extracted from the values bound to the ?contract_id variable.
Language-driven engines aim to materialize or virtualize KG statements, following the instructions of the mapping documents written using declarative languages. These engines perform two different tasks: the first task is to link the target data source fields to a class or a property defined by the reference ontology. Once this link has been created, these engines materialize or virtualize the URIs and the KG statements, retrieving the legacy information included in the data source. The JARQL file describing the link between the set of attributes ds{a1, a2, a3, ...} and the global schema represented by O allows to materialize the following statements:
@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#> .@prefix contract: <http://purl.org/procurement/public-contracts/contract/> .@prefix be: <http://purl.org/goodrelations/v1/businessentity/> .@prefix tender: <http://purl.org/procurement/public-contracts/tender/> .# ?BusinessEntity0 dcterms:identifier ?proposing_struct__business_id ;#      rdf:type gr:BusinessEntity .be:08106710158 dcterms:identifier 08106710158 ;    rdf:type gr:BusinessEntity .# ?BusinessEntity1 dcterms:identifier ?participants__business_id ;#        rdf:type gr:BusinessEntity .be:08106710158 dcterms:identifier 08106710158 ;    rdf:type gr:BusinessEntity .# ?Tender0 pc:bidder ?BusinessEntity1 .tender:Z4ADEA9DE4-80004990927 pc:bidder be:08106710158 .# ?Contract0 dcterms:identifier ?contract_id ;#     rdf:type pc:Contract ;#     pc:contractingAuthority ?BusinessEntity0 ;#     pc:tender ?Tender0 .contract:Z4ADEA9DE4 dcterms:identifier Z4ADEA9DE4 ;    rdf:type pc:Contract ;    pc:contractingAuthority 80004990927 ;    pc:tender tender:Z4ADEA9DE4-80004990927 .
To clarify the transformation process enabled by the JARQL file, this example reports as comments the graph patterns included in its CONSTRUCT section. One of the main reasons for using JARQL as declarative language is its capacity to create URIs, combining data located at different levels of the JSON tree structure. In the running example, the Tender’s URI is built combining the id of the contract (“Z4ADEA9DE4”), located at the JSON’s root level, and the id of the business entity (“80004990927”), located in a nested structure of the JSON.
In the following article, I will show you a particular approach based on semantic models for capturing the semantics of data sources with graph-based structures.
towardsdatascience.com
If you like my articles, you can support me using this link https://medium.com/@giuseppefutia/membership and becoming a Medium member.
Some rights reserved