#  1 Introduction

##  1.1 Purpose and scope of the document

Heterogeneous data sources are integrated into the iASiS knowledge graph in
order to offer an integrated view of data presented in different formats, e.g.
clinical notes, images, publications, web data. Diverse techniques are
implemented for transforming these heterogeneous data into a unified schema,
and curate and integrate this data. Furthermore, techniques for traversing and
exploring the iASiS knowledge graph are demanded in order to exploit the
benefits of the knowledge graph. This document describes the data management
techniques implemented in iASiS to transform data in diverse formats into the
unified schema of the knowledge graph; these techniques are the result of task
T5.4 of WP5. Moreover, this document presents the query processing techniques
implemented by Ontario, which is a federated SPARQL query engine able to
explore the iASiS knowledge graph and their knowledge graphs. This document is
structured as follows: Section 2 presents RML, a mapping language for
transforming raw data into RDF triples, as well as the SPARQL query language;
main characteristics of existing federated query approaches are also
described. Section 3 presents the semantic enrichment process implemented in
iASiS, as well as the main characteristics of the current version of the iASiS
knowledge graph. Section 4 outlines the main features of Ontario and
illustrates how it is integrated into the iASiS framework. Finally, the
conclusions and outcomes reached during the execution of tasks T5.4 and T5.5
are outlined, as well as the next steps to be followed in WP5.

##  1.2 Relationship with other documents

This document is related to the following deliverables of WP5: i) D5.1 where
the iASiS data sources are defined; ii) D5.5 where the privacy-aware
techniques are reported presented; iii) D5.6 where the final version of the
privacy aware strategies will be described; and iv) D5.7, D5.8, and D5.9 where
the iASiS data management and analytics services will be reported.

#  2 Background

##  2.1 RML, a Mapping Language for RDF

Big Data is usually presented in different formats, e.g. images, unstructured
text, or tabular, being required the definition of mapping rules in order to
transform data in these diverse formats into a unified schema. RML  1  is one
of the existing mapping languages; it expresses mappings to transform sources
represented in tabular format, e.g. CSV or relational, into RDF. Each mapping
rule in RML is represented as a **Triple Map** which consists of the following
parts; Figure 1 presents an overview of the main concepts of the RML mapping
language.

  * A **Logical Source** (rr:logicalSource) that refers to a data source from where data is collected; it is composed of the following components: 

    1. **Source** (rml:source) - is an input source, can be JSON, XML, or CSV; 

  
  

  

○ **Iterator** (rml:iterator) - is not required when it comes to tabular input
sources, like relational databases. It is needed in case of hierarchical or
structured data sources. The iterator (rml:iterator) determines the iteration
pattern by the input source and specifies the extraction of the data displayed
during each iteration;

○ **Reference Formulation** (rr:referenceFormulation) - as RML deals with
different data serializations with various ways to refer to their elements,
RML defines the reference. Such reference is specified based on the source of
the input data file, e.g. in case of a JSON file, a Reference Formulation
would be "JSONPath", in case of an XML file, a Reference Formulation would be
"XPath".

  * A **Subject Map** (rr:subjectMap) - defines the subject of the generated RDF triples. 

  

  * Several **Predicate-Object Maps** (rr:predicateObjectMap), combining: 

    1. **Predicate** Maps (rr:predicate) expressing the predicate of the RDF triple; 

  
  

  

○ **Object** Maps (rr:objectMap) expressing the object of the RDF triple; ○ A
**Referencing Object Map** , that indicates the reference to another **Triples
Maps** (rr:parentTriplesMap).

**Figure 1: An Overview of the RML mapping schema. Based on Dimou et al** 2
**.**

##  2.2 RDF and SPARQL Query Language

Resource Description Framework (RDF) – is a model developed by the W3C
consortium for describing the metadata of resources. The main goal is to
present statements in the form, that is equally well perceived by both, the
person and the machine. RDF provides interoperability between applications
that exchange computer-understood information via the Web. It also pays
attention to the means that automatically process Web resources. RDF
distinguishes three different type of values:

  * **IRI** (Internationalized Resource Identifier) – denotes entities, act as an identifier, representing the same resource; 

  

  * **Literals** – denote entities; 

  

  * **Blank nodes** – represent a resource, but without a specific identifier. Finally, an RDF triple is composed and relates three elements: 

  

  * **Subject** \- a described resource, represented by a URI reference or a blank node; ● **Predicate** \- the property of a resource, represented by a URI reference; 

  

  * **Object** \- property value, represented by a URI reference, blank node or a literal. 

  

Thus, the subject can be represented by an IRI or a blank node, the object can
be an IRI, a blank node or a literal. Links between nodes are always specific,
that is why a predicate can be only represented by an IRI. The basic building
block in RDF is represented by a triplet "Subject-Predicate-Object".

SPARQL  3  is a W3C standard query language used to define and manipulate data
in the RDF format. SPARQL queries comprise triple patterns including
conjunction and disjunction operations. The main query clauses supported by
SPARQL are SELECT, CONSTRUCT, ASK, and DESCRIBE. An evaluation of a SPARQL
query **Q** over an RDF graph **G** , corresponds to the set instantiations of
the variables in the SELECT clause of **Q** against RDF triples in **G.** A
SPARQL query can include different operators, e.g. JOIN, UNION, and OPTIONAL.
Moreover, FILTER can be used in order to filter from the output the
instantiations of the variables of the SELECT clause of **Q** that meet a
certain condition. The basic building block in the WHERE clause of a SPARQL
query is the triple pattern, or a triple with variables. A Basic Graph pattern
is the conjunction of several triple patterns, where a conjunction corresponds
to the JOIN operator. Finally, Basic Graph patterns can be connected with the
JOIN, UNION, or OPTIONAL operators. The following SPARQL query expresses the “
_Mutations of the type Confirmed somatic variant located in transcripts which
are translated as proteins that interact with the drug Docetaxel_ “.

PREFIX rdf: < http://www.w3.org/1999/02/22-rdf-syntax-ns#>

PREFIX iasis: <http://project-iasis.eu/vocab/>

SELECT DISTINCT ?mutation

WHERE {

?mutation **rdf:type** **iasis:Mutation** .

?mutation **iasis:mutation_chromosome** ?chromosome .

?mutation **iasis:mutation_start** ?start.

?mutation **iasis:mutation_NucleotideSeq** ?nucleotideSeq.

?mutation **iasis:mutation_isClassifiedAs_mutationType** ?type.

?mutation **iasis:mutation_somatic_status 'Confirmed somatic variant'** .

?mutation **iasis:mutation_cds** ?cds.

?mutation **iasis:mutation_aa** ?aa.

?mutation **iasis:mutation_isLocatedIn_transcript** ?transcript .

?transcript **iasis:translates_as** ?protein .

?drug **iasis:drug_interactsWith_protein** ?protein .

?drug **iasis:label** **'docetaxel'** }

This query is composed of 12 triple patterns; each triple, e.g. “?mutation
**rdf:type** **iasis:Mutation** ” corresponds to a triple pattern, where
“?mutation” corresponds to a variable, “ **rdf:type** ” to a predicate, and “
**iasis:Mutation** ” a mutation. Triple patterns are connected using the “.”
operator which corresponds to a JOIN. The 12 triple patterns in the WHERE
clause of the query comprise a Basic Graph Pattern.

###  2.3 Federated Query Engines and Existing Approaches

A federation of SPARQL endpoints is a set of RDF datasets that can be accessed
via SPARQL endpoints. A SPARQL endpoint is a Web service that provides a Web
interface to query RDF data following the SPARQL protocol  4  . RDF datasets
comprise sets of RDF triples; predicates of these triples can be from more
than one Linked Open Vocabulary  5  , e.g. FOAF  6  or DBpedia ontology.
Additionally, proprietary vocabularies can be used to describe the RDF
resources of these triples, and controlled vocabularies like VoID  7  , can be
used to describe the properties of the RDF data accessible through a given
SPARQL endpoint. Queries against federations of SPARQL endpoints are posed
through federated SPARQL query engines. A generic architecture of a federated
SPARQL query engine is based on the mediator and wrapper architecture  8  .
Wrappers translate SPARQL subqueries into calls to the SPARQL endpoints as
well as convert endpoint answers into the query engine internal structures.
The mediator rewrites original queries into subqueries that can be executed by
the data sources of the federation. Moreover, the mediator collects the
answers of evaluating the subqueries over the selected queries, merges the
results and produces the answer of a federated query; mainly, it is composed
of three components:

  * **Source Selection and Query Decomposition** \- decomposes queries into subqueries, and selects the endpoints that are capable of executing each subquery. Simple subqueries comprise a list of triple patterns that can be evaluated against at least one endpoint. 

  

  * **Query Optimizer** \- identifies execution plans that combine subqueries and physical operators implemented by the query engine. Statistics about the distribution of values may allow for the identification of combination of subqueries and plans that reduce execution time. 

  

  * **Query Engine** \- implements different physical operators to combine tuples from different endpoints. Physical operators implement logical SPARQL like JOIN, UNION, or OPTIONAL. 

  

FedX  9  , ANAPSID  10  , and MULDER  11  are exemplars federated SPARQL query
engines able to execute queries over a federation of SPARQL endpoints. FedX
implements source selection techniques able to contact the SPARQL endpoints on
the fly to decide the subqueries of the original query that can be executed
over the endpoints of the federation. Thus, FedX relies on zero knowledge
about the content of the SPARQL endpoints to perform the tasks of Source
Selection and Decomposition. ANAPSID exploits information about the predicates
of the RDF datasets accessible via the SPARQL endpoints of the federation to
select relevant sources, decompose the original queries, and find efficient
execution plans. Moreover, ANAPSID implements physical operators able to
adjust schedulers of query executions to the current conditions of SPARQL
endpoints, i.e. if one of the SPARQL endpoint is delayed or blocked, ANAPSID
is able to adjust the query plans in order to keep producing results in an
incremental fashion. Finally, MULDER is a federation SPARQL engine that relies
on the description of the properties and links of the classes in the RDF
graphs accessible from SPARQL endpoints, to decompose the original queries
into the minimal number of subqueries required to evaluate the original query
into the relevant SPARQL endpoints. MULDER utilises the RDF Molecule Templates
(RDF-MTs) to describe the classes in an RDF graph and its links; it also
exploits the physical operators implemented in ANAPSID to provide efficient
query executions of SPARQL queries, i.e. MULDER provides Source Selection and
Query Decomposition and Query Optimizer components which effectively exploit
the ANAPSID query engine.

Ontario is the query engine implemented in the iASiS framework for accessing
data from the iASiS knowledge graph. Similar to MULDER, Ontario relies on RDF
Molecule Templates (RDF-MTs) for describing the RDF classes included in the
iASiS knowledge graph. Additionally, Ontario maintains in the RDF-MTs metadata
describing the data privacy and access control regulations imposed by the
provider of the data used to populate the RDF classes of the knowledge graph.
Moreover, Ontario relies on adaptive physical operators to be able to adjust
query execution plans to the condition of the SPARQL endpoints that make
accessible the iASiS knowledge graph. More importantly, contrary to existing
federated SPARQL query engines, Ontario is able to execute SPARQL queries over
data sources that are not integrated in the knowledge graph and are stored in
raw formats, e.g. CSV or JSON. This feature of Ontario allows for executing
queries over both RDF graphs and against data collections that are not
physically integrated into the knowledge graph, providing thus a virtual
integration of data sources.

#  3 The Semantic Enrichment for Creating the iASiS Knowledge Graph

In this section, the semantic enrichment component is described; it is able to
transform and integrate heterogeneous data sources into the iASiS knowledge
graph. First, the iASiS data-driven pipeline is explained. Then, the pipeline
implemented by the semantic enrichment component is defined, as well as RML
mappings utilised to transform raw data into RDF. Finally, the main
characteristics of the version

1.0 of the iASiS knowledge graph are reported.

##  3.1 The iASiS data-driven pipeline

The iASiS data-driven pipeline transforms Big clinical and biomedical data
into actionable insights for the support of precision medicine and decision
making; the main steps of the pipeline are presented in Figure 2\. The
pipeline receives Big data sets as input, e.g. electronic clinical nodes,
genomic data, medical images, and open data, and produces as output the iASiS
knowledge graph. Moreover, tasks of knowledge discovery are performed in order
to detect potential novel patterns and associations between entities in the
iASiS knowledge graph, e.g. signatures of long survival patients of lung
cancer.

First, the aim of the **knowledge extraction methods** is to create ontology
annotated data sets from data represented in different formats, e.g. clinical
notes, medical images, hospital-derived genomic data; biomedical ontologies
are used for annotation. Clinical data is collected from the clinical partners
and anonymisation techniques are performed in order to remove confidential
attributes, e.g. national identifier, name, address, and profession. **EHR
text analysis** and **Image analysis** components are executed in order to
extract relevant information from the clinical notes and medical images, e.g.
treatments, diagnostics, and results of clinical tests. Biomedical
vocabularies, e.g. UMLS or SNOMED are used to represent the knowledge
extracted from the clinical notes. Additional knowledge extraction tasks, i.e.
genomic and open data analysis are performed over open data collections; these
techniques also annotate data using terms from Biomedical ontologies, e.g.
UMLS and the Human Phenotype Ontology (HPO).

**Figure 2: The iASiS Pipeline for Knowledge Management and Discovery**

Once the annotated datasets are produced, tasks of knowledge graph creation
are performed in order to semantically describe and integrate annotated data
into the **iASiS** **knowledge graph** ; the iASiS unified schema is utilised
for describing the data. Annotations for biomedical ontologies, e.g. UMLS,
SNOMED, and HPO, are exploited to curate and integrate the entities in the
annotated datasets; also, **entity linking techniques** are used to connect
these entities to equivalent entities in other knowledge graphs, e.g. DBpedia
and Bio2RDF; DBpedia Spotlight  11  solves the tasks of entity extraction,
disambiguation, and linking. Moreover, RML mapping rules are used by the
Semantic Enrichment component in order to create the RDF triples that populate
the iASiS knowledge graph.

Once the iASiS knowledge graph is created, it can be explored and consulted by
using Ontario; moreover, Ontario allows for performing federated queries
between the iASiS knowledge graph, as well as the knowledge graphs linked to
it, e.g. DBpedia and Bio2RDF. Results of executing a federated query can be
used as input of the tasks of Data Analytics or Knowledge Discovery, enabling
thus the discovery of patterns among entities in the iASiS knowledge graph.
Data privacy and access control policies are verified and enforced by all the
components in the pipeline.

##  3.2 The Knowledge Graph Creation Process

Creating a knowledge graph from heterogeneous data sources requires the
description of the entities in the data sources using RDF vocabularies, as
well as the performance of curation and integration tasks in order to reduce
data quality issues, e.g. missing values or duplicates. Figure 3 depicts the
pipeline followed during knowledge graph creation; it is composed of three
main components:

  * **Semantic Enrichment** \- transforms annotated data into RDF; it relies on rules in a mapping language, e.g. RML, to generate the RDF triples that correspond to the semantic description of the input data. The iASiS unified schema and properties from existing RDF vocabularies like RDFS and OWL, are utilised as predicates and classes. Annotations in the input data are also represented as RDF triples. The RDF representation of these annotations are linked to the corresponding entities in the knowledge graph, e.g. the resource of the UMLS annotation C00031149 is associated with the resource of the PubMed publication 28381756. Moreover, equivalences and semantic relations between annotations are represented in the knowledge graph. These relationships allow for detecting entities annotated with equivalent annotations and that may correspond to the same real-world entities, i.e. they are duplicates; thus, equivalent annotations represent the input to the tasks of knowledge integration. 

  

  * **Knowledge Creation & Integration ** \- receives an initial version of the iASiS knowledge graph that may include duplicates and it outputs a new version of the knowledge graph from where duplicates are removed. In order to detect if two entities correspond to the same real-world entity, i.e. they are duplicates, similarity measures are utilised, e.g. GADES  12  or Jaccard  13  ; all the entities in an RDF class of the knowledge graph are compared pairwise. Then, a 1-1 perfect weighted matching algorithm is performed in order to identify duplicates in the class; thus, if two entities are matched, they are considered as equivalent entities and merged in the knowledge graph. Fusion policies  14  are followed to decide how equivalent entities are merged in a knowledge graph; the fusion policies include: 

  

○ **Union** \- creates a new entity with the union of the properties of the
matched entities.

○ **Semantics based Union** \- creates a new entity with the union of the
properties of the matched entities. Only _most general properties_ are kept in
case of properties related by the _subproperty_ relationship; furthermore, if
two properties are equivalent, only one of them is kept in the resulting
entity.

○ **Authoritative Merge** \- creates a new entity with the properties of the
entity with the data provided from an authoritative source.

  * **Interlinking** \- receives the iASiS knowledge graph and a list of existing knowledge graphs, e.g. DBpedia or Bio2RDF, and outputs a new version of the iASiS knowledge graph where entities are linked to equivalent entities in the input knowledge graphs. Entity Linking tools like DBpedia Spotlight are used for linking; additionally, link traversal techniques are performed to further identify links with other knowledge graphs, e.g. Bio2RDF or DrugBank. 

  

##  3.3 RML Mapping Rules to Create the iASiS Knowledge Graph

In order to transform data from heterogeneous data sources into the version
1.0 of the iASiS knowledge graph, 66 RML mapping rules have been defined.
These mapping rules are defined based on the classes of the iASiS unified
schema available as an instance of the ontology development tool VoCol  15  ;
the mappings are available in the GitHub repository  16  of the LUH team. The
RML mappings are executed by the Semantic Enrichment component defined above.
Given the number of rules and the size of the data sources, optimisation
techniques have been implemented with the aim of scaling up. Empirically,
scalability has been evaluated, and the Semantic Enrichment component is able
to generate knowledge graphs in the order of Terabytes. Furthermore, the
Semantic Enrichment component is able to detect data quality issues in the
input data collections; it has been empowered with data curation capabilities

that

allow

for

detecting

missing

values,

and

malformed

names

and

identifiers.

**Figure 3: The Pipeline for Knowledge Graph Creation**

The following is one exemplar RML mapping rule for defining the properties of
a Drug. This rule is used to transform data in CSV format into RDF data. This
RML mapping rule describes the data source from which the data is extracted
and the format of this data, i.e. CSV. Additionally, it specifies the URL of
the class subject; finally, two properties of the class Drug are defined. The
Semantic Enrichment component receives the mapping and iterates over each row
of the file to transform the values of the columns of the raw file according
to the mappings in the rules annotated with

Class Subject and Class Properties labels. Once the end of file is reached, an
RDF file is produced as output; this RDF file corresponds to the input of the
knowledge integration component.

###  3.4 Example of Knowledge Graph Creation

In this section, the pipeline for creating the iASiS knowledge graph is
illustrated with an example. Suppose input data describing a drug, is received
in a tabular format, e.g. as a CSV file, then, an RDF graph describing the
drugs in the file is created. These RDF graphs are called **simple RDF
molecules** or group of RDF triples that share the same subject. RML mapping
rules are defined and executed to transform raw data into the RDF triples that
comprise the resulting RDF molecules. Furthermore, these mapping rules
indicate the format of the URIs of the resources that appear as subjects or
objects of the RDF molecules created during their execution. In this case,
three URIs are created, i.e. for the drug, publication, and variation.

The same process is

repeated for all the RML

mappings that define the

RDF classes in the iASiS

knowledge graph in terms

of

the

available

data

sources. In case several

simple RDF molecules are

defined for the same real-

world entity, e.g. the drug

Docetaxel, the process of

_knowledge integration_

is

executed.

This

process

determines RDF molecules that represent equivalent entities of a class,
according to the available fusion policies. These simple RDF molecules are
then merged or integrated into a complex RDF molecule that represent all the
properties of the real-world entity, that are represented in the different
simple RDF molecules.

Finally, entity linking techniques allow for discovering links between
entities in the iASiS knowledge

graph

and

equivalent

entities

in

existing

knowledge

graphs,

e.g.

DBpedia. In this case, the

resource representing the

drug Docetaxel in the

iASiS knowledge graph is

linked to the resource

that represents the same

drug

in

DBpedia;

the

owl:sameAs property

is

utilised to represent these

type of links. Linking the

iASiS

knowledge

graph

with other knowledge graphs not only allows for exploring properties that are
not represented in the original knowledge graph (e.g. dbo:atcPrefix), but also
enables the identification of data quality issues like missing values or
duplicates.

#  4 Ontario: A Federated Query Engine

In this section, the characteristics of Ontario are presented. It is a
federated SPARQL query engine being able to evaluate SPARQL queries over the
iASiS knowledge graph and the knowledge graphs that are linked to it, e.g.
DBpedia and Bio2RDF. Further, examples of federated queries are utilised to
illustrate the main features implemented in Ontario in order to scale up to
federation of large knowledge graphs. Finally, the RDF Molecule Templates
(RDF-MTs), i.e. the source description formalism of Ontario, is utilised as
the basis to provide an analysis of the main properties of the iASiS knowledge
graph.

##  4.1 SPARQL Query Processing in Ontario

Ontario is a federated query engine able to execute queries against a
federation of data sources accessible via a Web Access Interface, e.g. SPARQL
endpoints; Figure 4 depicts the main components of the Ontario architecture.
First, Ontario maintains the description of the data sources in the federation
in terms of RDF molecule templates (RDF-MTs). Thus, a data source is described
in terms of the RDF classes of the data in the data sources, and the
properties of these classes; additionally, data privacy and access policies
imposed by data providers are represented in RDF-MTs. An RDF Molecule Template
(RDF-MT)  17  is characterised by the following properties:

  * **rdfMT:hasClass** represents a class **C** of the entities described by the RDF-MT, e.g. iasis:Patient. 

  

  * **rdfMT:hasProperty** represents the properties of the class of the entities described by the RDFMT, e.g. **iasis:hasBiopsy** and **iasis:hasTumorStage** . 

  

  * **rdfMT:hasPolicy** allows for representing the operations that can be performed over a property whose data is provided by a given data source. The object of the rdfMT:policies is related to an entity which is an instance of the class **rdfMT:AuthorizationEntity;** which relates a property with access rights authorized by a data provider **s** to an access consumer **c** during a given time period. 

  

  * **rdfMT:hasCardinality** represents the cardinality of the entities in the class **C** . 

  

  * **rdfMT:endpoint** corresponds to the Web access interface to access entities of the class **C** . 

  

  * **rdfMT:linkedTo** represents the links between the class **C** and other classes in the knowledge graph or in other knowledge graphs. 

  

**Figure 4: The Ontario Architecture**

Given a SPARQL query Q, the **Source Selection and Query Decomposer**
identifies a **query decomposition** of Q; it is composed of subqueries (SQi)
of Q, and the data sources where these subqueries can be executed, e.g. in
Figure 4 subquery SQ2 is executed over @KG1, @KG2, and @KG3. Metadata
represented in the RDF-MTs are exploited during source selection and query
decomposition, in order to identify the minimal number of data sources that
have to be contacted to produce a complete answer of the query, i.e. a
solution to the problem of finding the relevant sources for a federated query.
Next, the **Query Optimizer** receives the query decomposition and finds an
**efficient query plan** , i.e. a plan of Q over the relevant data sources
that produces all the answers but in the minimal time. Different **physical
operators** 18  are implemented by the Query Engine to collect the answers of
the subqueries against the relevant data sources, e.g. SMJOIN or gJOIN, as
well as to produce the query answer. In Figure 4, a multiway-join operator
connects the subqueries over @KG1, @KG2, and @KG3. This operator is able to
adjust query execution schedulers to the conditions of the sources, e.g. data
transfer delays and unexpected source workload; moreover, it allows for
producing query answers incrementally, thus, users do not have to wait until
all the subqueries are completely executed to receive the first answer and can
collect answer continuously. Techniques implemented in Ontario have been
empirically evaluated and compared with state-of-the-art approaches. Observed
experimental results suggest that Ontario is not only able to scale up to
large data sources, but also is outperforming the state of the art in queries
over a large number of RDF data sources.

The main features of Ontario are illustrated in Section 4.2 with an example.
Furthermore, Section 4.3 presents an analysis of the characteristics of the
iASiS knowledge graph based on the metadata encoded in the RDF-MTs and links.
The results suggest that the current version of the iASiS knowledge graph
represents a relatively good number of connections between biomedical
concepts, e.g. drugs, publications, variants, tumors, and annotations.
Nevertheless, these connections need to be extended, being part of future work
of WP5, through the analysis and discovery of new links between the concepts
represented in the iASiS knowledge graph.

###  4.2 Example of Federated Query Processing

Consider the following SPARQL query **Q** that produces “ _Mutations of the
type Confirmed somatic variant located in transcripts which are translated as
proteins that are transporters of the drug Docetaxel_ “.

**Q:**

PREFIX rdf: < http://www.w3.org/1999/02/22-rdf-syntax-ns#>

PREFIX iasis: <http://project-iasis.eu/vocab/>

PREFIX drugbank: <http://bio2rdf.org/drugbank_vocabulary:>

PREFIX owl: <http://www.w3.org/2002/07/owl#>

SELECT DISTINCT ?mutation

WHERE {

?mutation **rdf:type** **iasis:Mutation** .

?mutation **iasis:mutation_somatic_status 'Confirmed somatic variant'** .

?mutation **iasis:mutation_isLocatedIn_transcript** ?transcript .

?transcript **iasis:translates_as** ?protein .

?drug **iasis:drug_interactsWith_protein** ?protein .

?protein **iasis:label** ?proteinName .

?drug **iasis:label** **'docetaxel'** .

?drug **owl:sameAs** ?drug1 .

?drug1 **drugbank:transporter** ?transporter .

?transporter **drugbank:gene-name** ?proteinName . }

To execute this query, both the iASiS and the Bio2RDF knowledge graphs need to
be consulted. Ontario maintains metadata about these two knowledge graphs,
represented in RDF molecule templates, and it is able to select them as
relevant sources for the query. Then, once the RDF molecule templates are
selected, Ontario decomposes query **Q** into subqueries **SQ1** and **SQ2,**
and executes them over the iASiS and Bio2RDF knowledge graphs, respectively.

**SQ1:**

PREFIX rdf: < http://www.w3.org/1999/02/22-rdf-syntax-ns#>

PREFIX iasis: < _http://project-iasis.eu/vocab/_ >

PREFIX owl: <http://www.w3.org/2002/07/owl#>

SELECT DISTINCT ?mutation ?proteinName ?drug1

WHERE {

?mutation **rdf:type** **iasis:Mutation** .

?mutation **iasis:mutation_somatic_status 'Confirmed somatic variant'** .

?mutation **iasis:mutation_isLocatedIn_transcript** ?transcript .

?transcript **iasis:translates_as** ?protein .

?drug **iasis:drug_interactsWith_protein** ?protein .

?protein **iasis:label** ?proteinName .

?drug **iasis:label** **'docetaxel'** .

?drug **owl:sameAs** ?drug1 .

}

**SQ2:**

PREFIX drugbank: <http://bio2rdf.org/drugbank_vocabulary:>

SELECT DISTINCT ?proteinName ?drug1

WHERE {

?drug1 **drugbank:transporter** ?transporter .

?transporter **drugbank:gene-name** ?proteinName .

}

As a result, **24 mutations** of the protein **ABCB1** and **11 mutations** of
the protein **ABCG2** are identified. It is important to highlight that
without the integration of COSMIC data into the iASiS knowledge graph and the
linking of the corresponding entities with Bio2RDF, this federated query could
not be executed. Thus, these results illustrate not only the features of
Ontario as a federated query engine, but also the benefits of semantically
describing and integrating heterogeneous data sources into a knowledge graph.

###  4.3 Main Characteristics of the iASiS Knowledge Graph

The current version of the iASiS knowledge graph has 236,512,819 RDF triples,
26 RDF classes, and in average, 6.98 properties per entity. Figure 5 shows the
distribution of number of entities per RDF-MT in the iASIS knowledge graph and
in the RDF-MTs from DBpedia (with prefix _dbo:_ ) and Bio2RDF (with prefix
_bio2rdf:_ ) that are connected to its RDF-MTs. As observed, some RDF-MTs are
populated with a relatively large number of entities, e.g. the annotations of
the publications, and the mutations; in average there are 86,934.00 entities
per class.

Figure 5: Number of Entities per RDF-MT in the iASiS Knowledge Graph, and
related RDF-MTs in DBpedia and Bio2RDF

RDF-MTs of the iASiS knowledge graph and connected knowledge graphs are used
to describe the main characteristics of the integrated data and their
connections. To conduct this analysis, an undirected graph with the RDF-MTs of
the iASiS, DBpedia, and Bio2RDF knowledge graphs was built. Figure 6 shows
this graph; RDF-MTs correspond to 35 nodes in the graph, while 58 edges
represent links among RDF-MT. It can be observed that all the RDF-MTs are
connected to at least one RDF-MT, i.e. there are no isolated classes.

**Figure 6: RDF-MTs in the iASiS, DBPedia, and Bio2RDF**

**Knowledge Graphs**

Using network analysis, several graph measures were computed; Table 1 reports
on the results of these measures. Clustering coefficient measures the tendency
of nodes who share the same connections in a graph to become connected. If the
neighbourhood is fully connected, the clustering coefficient is 1.0 while a
value close to 0.0 means that there is no connection in the neighbourhood.
Transitivity measures if RDF-MTs are transitively connected; values close to
1.0 indicate that almost all the RDF-MTs are related, while low values
indicate that many RDF-MTs are not related. Clustering coefficient and
transitivity are both relatively low, i.e. 0.224 and 0.23, respectively. This
suggests that many more connections between RDF classes can be included in
future versions of the iASiS knowledge graph.

**Table 1: Graph Analysis of the RDF-MTs of the iASiS Knowledge Graph**  
  
<table>  
<tr>  
<th>

RDF-MT graph property

</th>  
<th>

Value

</th> </tr>  
<tr>  
<td>

Number of RDF-MTs (nodes)

</td>  
<td>

35

</td> </tr>  
<tr>  
<td>

Number of connections (edges)

</td>  
<td>

58

</td> </tr>  
<tr>  
<td>

Clustering coefficient

</td>  
<td>

0.224

</td> </tr>  
<tr>  
<td>

Transitivity

</td>  
<td>

0.23

</td> </tr>  
<tr>  
<td>

Avg. number of neighbours

</td>  
<td>

2.629

</td> </tr> </table>

#  5 Conclusions and Future Work

The outcomes of performing the tasks T5.4 and T5.5 of WP5 have been presented
in this document. The reported results have allowed for the understanding of
the main data management techniques implemented in the iASiS framework. These
techniques enable the transformation and curation of heterogeneous data
sources into RDF, as well as their integration into the iASiS knowledge graph.
Moreover, the Ontario federated query engine is described in terms of its
components. The depicted examples illustrate the functionalities of the
developed techniques, and the reported statistics of the iASiS knowledge graph
facilitate the understanding of the amount of knowledge represented in the
version 1.0 of the iASiS knowledge graph, as well as the opportunities that it
offers for knowledge exploration and discovery. As the number of sources to be
integrated in the iASiS knowledge graph will increase, techniques for
physically distributing the iASiS knowledge graph will be demanded.
Furthermore, caching techniques for keeping the results of the most frequent
federated queries will facilitate the execution of queries at large scale. All
these tasks are part of future work in WP5.