A tutorial on how to create mappings using ontop, how inference (OWL 2 QL and RDFS) plays a role answering SPARQL queries in ontop, and how ontop's support for on-the-fly SQL query translation enables scenarios of semantic data access and data integration.
1. +
ontop: A Tutorial
Mariano Rodriguez Muro, Ph.D.
Free University of Bozen-Bolzano
Bolzano, Italy
http://www.rodriguez-muro.com
Protégé-OWL Short Course
September 2-4, 2013
Vienna, Austria
2. +
Disclaimer
License
This work is licensed under the
Creative Commons Attribution-Share Alike 3.0 License
http://creativecommons.org/licenses/by-sa/3.0/
The material for this presentation is available at:
https://www.dropbox.com/sh/q3aowgiq5dnco7n/as0QniGPKy
3. +
Who am I?
Researcher at:
Free University of Bozen Bolzano,
Bolzano, Italy
From October at:
IBM Watson Research Center
Research topics: OBDA, Efficient reasoning in OWL, Query
rewriting, Data integration
Leader of the ontop project
4. +
Why are we here?
Data and ontologies
To get the basics of ontology based data access
To learn how to do it with ontop
To grasp some of the possible uses of the technology and
hint to the resources available
5. +
Tutorial Overview
Part 1: Introduction
Quick Introduction to Ontology Based Data Access
Part 2: The basics
Creating an SQL database, creating simple (direct) mappings with
ontopPro and querying.
Part 3: Modeling in OBDA
Creating mappings that reflect the domain
Part 4: Data Integration
Using ontop to query data from multiple sources
Part 5: Ontologies and ontop
Extending and using with domain knowledge (OWL)
6. +
Material
The tutorial is organized as a hands-on session. Try to perform
the described tasks.
Most command/mappings/queries are in files in the “materials”
folder, still, try to write them on your own
Material included (ontop-tutorial-viena13.zip)
README.txt is an index for the ZIP file
H2 Database (h2.zip)
.obda/.owl files (resulting mappings and ontologies for all examples)
.sql files (. SQL commands that create the tutorial DBs)
8. +
SQL DBs
Standard way to store LARGE volumes of data
Mature, Robust and FAST
Domain is structured as tables, data becomes rows in these
tables.
Powerful query language (SQL) to retrieve this data.
Major companies developed SQL DBs for the last 30 years
(IBM, Microsoft, Oracle) and even open source projects are
now quite robust (MySQL, PostgreSQL).
9. +
OBDA and motivation
Ontology Based Data Access (OBDA) is an research are that
focuses on accessing data through ontologies. –ontop-’s focus is
on SQL DBs (RDBMs)
Benefits:
Flexible data model (OWL/RDF)
Flexible query language (OWL or SPARQL)
Inference
Speed, volume and features (by reusing SQL DBs)
Possible applications
Semantic Query Answering
Data integration
Semantic Search
10. +
Two approaches for OBDA
Extract Transform Load (ETL)
Reasoner
Source
Application
TBox
Inputs
Data Code
Data is transformed into OWL ABox
assertions that are combined with
OWL axioms and then given to a
reasoner or query engine.
Limitations: performance and memory.
11. +
Two approaches for OBDA
On-the-fly
Reasoner
Source
Application
Ontology
Mappings
Input
Mappings are axioms that relate the data in a
RDBMs to the vocabulary of the ontology (the
classes and the properties), they “connect” the two
vocabularies in a sense.
The input are ontology and mappings,
the reasoner answers the queries by
transforming them into queries over
the source.
The reasoner is connected to the
source, data is not duplicated, is always
up-to-date.
12. +
ontop is a platform to query RDBMs through OWL/RDFS
ontologies on-the-fly, using SPARQL. It's extremely fast and is
packed with features
It‟s composed by 2 main components:
Quest. A reasoner/query engine that is able to answer SPARQL 1.0
queries, supports OWL 2 QL inference and a powerful mapping
language. Can be run in Java applications or a stand-alone
SPARQL server.
ontopPro. A plugin for Protégé 4 that provides a mapping editor,
and that allows to use Quest directly from Protégé.
Today we will focus learning to use OBDA with ontopPro
14. +
Overview
Flash recap of SQL DBs with
H2
Using ontopPro
Connecting a DB with
Protégé
Creating mappings
Querying
About mappings in ontop
About query answering in ontop
15. +
An SQL database, H2
A pure java SQL database
Easy to install
Just unzip the downloaded package, already in your USB stick h2-
simple.zip
Easy to run, just run the scripts:
Open a terminal (in mac Terminal.app, in windows run cmd.exe)
Move to the H2 folder (e.g., cd h2)
Start H2 using the h2 scripts
sh h2.sh (in mac/linux)
h2w.bat (in windows)
16. starting H2 with the
terminal
A yellow icon indicates the DB is
running (right click for a context
menu)
19. +
Creating the database
We‟ll create a table to store lung cancer information as follows:
patientid name type stage
1 Mary false 2
2 John true 7
type is:
• true for Non-Small Cell
Lung Cancer (NSCLC)
• false for Small Cell Lung
Cancer (SCLC)
stage is:
• 1-6 for stage I,II,III,IIIa,IIIb,IV
NSCLC
• 7-8 for Limited,Extensive SCLC
20. +
Creating the table
To create the table (file patient-table1.sql):
CREATE TABLE tbl_patient (
patientid INT NOT NULL
PRIMARY KEY,
name VARCHAR(40),
type BOOLEAN,
stage TINYINT
)
21. +
Inserting the data
To insert the data:
INSERT INTO tbl_patient (patientid,name,type,stage)
VALUES
(1,'Mary',false,2),
(2,'John',true,7);
23. +
Other relevant queries
To get all id‟s of patients with NSCLC
SELECT patientid FROM TBL_PATIENT WHERE TYPE = false
To get all information about patients with NSCLC and stage 3
or above
SELECT patientid FROM TBL_PATIENT
WHERE TYPE = false AND stage >= 2
24. +
First ontop mapping
Objective
That each row generates the following OWL data
An OWL individual of the form:
:db1/1
OWL assertions of the form:
ClassAssertion( :Person :db1/1 )
DataPropertyAssertion ( :id :db1/1 “1”)
DataPropertyAssertion ( :name :db1/1 “Mary”)
DataPropertyAssertion ( :type :db1/1 “false”)
DataPropertyAssertion ( :stage :db1/1 “2”)
That is, we define a vocabulary of Classes and Properties that
we want to “populate” using the data from the database.
A direct mapping
25. +
A direct mapping (cont.)
Seen graphically:
Things to note:
The OWL object is identified by
an IRI
Values have OWL data types
patientid name type stage
1 Mary false 2
26. +
Step 0: Starting Protégé+ontop
Unzip the protégé-ontop bundle from your material
This is a Protégé 4.3 package that includes the ontop plugin
Run Protégé using the run.bat or run.sh scripts. That is,
execute:
cd Protege_4.3_ontopPro/
sh run.sh
27. +
Step 1: Defining the base URI
Define the ontology base URI: http://example.org/
Save the ontology
Close and re-open Protégé
(Sorry this is due to a bug)
Enable the OBDA Model tab in
Window -> Tabs
28.
29. +
Step 2: Add the datasource
Using the OBDA model tab, we now need to define the
connection parameters to our lung cancer database
Steps:
0. Switch to the OBDA model tab
1. Add a new data source (give it a name, e.g., LungCancerDB)
2. Define the connection parameters as follows:
Connection URL: jdbc:h2:tcp://localhost/test
Username: sa
Password: (leave empty)
Driver class: org.h2.Driver (choose it from the drop down menu)
3. Test the connection using the “Test Connection” button
30. +
A “Connection is OK” means Protégé and ontop were able to
connect to our H2 server and see the “tests” DB we just created.
We are now ready to add the mappings for the DB.
31. +
Step 3: Create a mapping
Add the class:
http://example.org/Patient
Switch to the “Mapping Manager” tab in the OBDA Model tab.
1. Select the LungCancerDB source
2. Add a mapping with ID “patient-map”
target: :db1/{PATIENTID} a :Patient .
source: SELECT * FROM TBL_PATIENT
NOTE: use upper case
32. +
Adding a Mapping
Select the LungCancerDB from the drop down menu.
Click the “Create Button”
33. +
The “Assertion template” a.k.a. “triple Template” tells ontop how
to create URI‟s and Class and Property assertions using the
data from the DB (from the SQL query)
34.
35. +
The meaning of mappings
Mappings + DB data “entail
(consequence)” OWL data,
i.e., OWL ABox assertions.
These “entailed” data is
accessible during query time
(the on-the-fly approach) or
can be imported into the OWL
ontology (the ETL approach)
36. +
The meaning of mappings
ontop‟s main way to access data is on-the-fly, however, you can
also do ETL using the “import data from mappings” function
in the “ontop” menu.
Do it now and explore the result in the “individuals tab”, when
done remember to delete these individuals.
Use with care, you may run out of memory.
37. +
On-the-fly access to the DB
This is the main way to access data in ontop and its done by
querying ontop with SPARQL.
The “query engine”/”reasoner” that comes with ontop is called
“Quest”
Enable Quest in the “Reasoner” menu
38. +
On-the-fly access to the DB
Next, enable the “OBDA query” tab (ontop SPARQL) in the tabs
menu
39. +
Querying with Quest
In the OBDA Tab:
1. Write the SPARQL
query
2. Click execute
3. Inspect the results
40. TEMPLATE: :db1/{PATIENTID} a :Patient .
The result is no
longer numeric
ID‟s in the
database. The
results are URI‟s
constructed in
the way that you
wrote in the
mapping by
replacing the
“column
references” with
the actual values
obtained from the
database (the
values in each
row)
41. +
The rest of the patient mappings
Add the following Data
Properties:
:id
:name
:type
:stage
target: :db1/{PATIENTID} :id {PATIENTID} .
source: SELECT * FROM TBL_PATIENT
target: :db1/{PATIENTID} :name {NAME} .
source: SELECT * FROM TBL_PATIENT
target: :db1/{PATIENTID} :type {TYPE} .
source: SELECT * FROM TBL_PATIENT
To complete the model we can add the following
mappings one by one and “synchronize” the reasoner:
target: :db1/{PATIENTID} :stage {STAGE} .
source: SELECT * FROM TBL_PATIENT
OR…
42. +
The rest of the patient mappings
Add the following Data
Properties:
:id
:name
:type
:stage
target: :db1/{PATIENTID} a :Patient ;
:id {PATIENTID} ;
:name {NAME} ;
:type {TYPE} ;
:stage {STAGE} .
source: SELECT * FROM TBL_PATIENT
Or, you can modify the original mapping as follows so that
it generates multiple assertions at the same time:
Don‟t forget to synchronize with the reasoner…
43.
44. +
About Mappings
A mapping represents OWL assertions, one set of OWL
assertions for each result row returned by the SQL query in the
mapping. The assertions that the mapping represents are those
obtained by replacing the place holders with the values from
the DB.
Mappings are composed by:
Mapping IDs are arbitrary names for each mapping (choose
something that allows you to identify the mapping)
The “Source” of the mapping is an SQL query that retrieves some
of the data from the database.
The “Target” of the mapping is a form of “template” that indicates
how to generate OWL Assertions (class or property) in a syntax very
close to “Turtle” syntax for RDF.
45. +
Assertion Template Examples
Assertion templates are formed as a triple
“subject predicate object”
The subject is always a URI, the object maybe another URI or an OWL value.
Class Assertions use rdf:type or a as predicate, and a URI as object (the
class name) e.g.,
:db1/{id} rdf:type :Person
<http://live.dbpedia.org/page/{name}> a :Writer
Object/Data Property Assertion have any URI as predicate (the property
URI) and a URIs or OWL Value as object
:db1/{id} :name {NAME}
:db1/{id} :age {C1}^^xsd:string
:db1/{id} :knows :db1/{id2}
:db1/{id} :knows :Michael_Jackson
46. +
Practical Notes About Mappings
With ontopPro, mapping and data source definitions are
stored in .obda files
.obda files are located in the same folder as the .owl ontology
They should be named as the .owl file
.obda files are text files, they may be edited and created
manually, this can be more convenient in several cases, e.g.,
automatically generating large amounts of mappings, quick
refactoring using regular expressions, etc.
47. +
About Query Answering in Ontop
ontop‟s query engine uses “query rewriting” techniques
Given a SPARQL query, ontop translates it into an SQL query
using the mappings (and the ontology). You can get the SQL
query generate by ontop using the context menu in the OBDA
query tab.
48. +
About Query Answering in Ontop
Key features:
Volume: By relying on SQL DBs, the datasets that ontop can handle
are in the GBs and TBs
Fast: ontop generates efficient SQL queries, that when combined
with a fast SQL engine to provide answers in ms. Not all SQL
queries are fast, most of the research and development efforts in
ontop go towards generating FAST SQL queries
Possible drawbacks:
Maturity: SPARQL support in ontop is under development and
many features are still missing
Know-how: SQL expertise will be required to obtain the best
performance with large datasets
50. +
The OWL vocabulary so far is a one-to-one reflection of the
database, not very interesting or useful
We would like:
Application independent
vocabulary
Vocabulary beyond the
one explicit in the DB
Individuals and relations between them
that reflect our understanding of the
domain
For example…
Application independent mappings
51. +
Redesigning our model
Highlights:
• The vocabulary is more domain oriented
• No more values to encode types or stages. There is
a new individual :db1/neoplasm/1 that stands for the
cancer (tumor) of Mary and it is an instance of the
class :NSCLC. There are URI‟s (individuals) that
represent the stage of the cancer
This model is closer to the formal model of the domain, independent from
the DB. Later, this will allow us to easily integrate new data or domain
information (e.g., an ontology).
52. +
Constructing the new model 1
Remove the old mappings and vocabulary, then:
Create the new vocabulary
Object Properties:
:hasStage, :hasNeoplasm
Classes:
:SCLC, :NSCLC
Add mappings for the new classes and properties as follows:
54. +
Classifying the neoplasm
Now we classify the neoplasm individual using our knowledge of the
database.
We know that “false” in the table patient indicates a “Non Small Cell Lung
Cancer”, so we classify the neoplasm as a :NSCLC. Similar for :SCLC
55. +
Associating a stage
We associate the
neoplasms of each patient
to a stage. Note that the
stage is no longer an
arbitrary value, but a
constant URI with clear
meaning, independent from
the DB.
56. +
Querying the new model
In the new model now we can obtain the information of each patient and their
condition through URIs of classes or individuals that have clear semantics, not
DB dependent. We are using a “global vocabulary”.
This will allow us to easily integrate new DBs and a domain ontology…
58. +
Data integration in OBDA
Even if two databases contain data about the same domain,
integrating the data is often problematic since the data may be
represented in different ways
However, if proper modeling is used, integrating multiple data
sources using OBDA may become simple:
Insert the data in the database (either as new tables, or through
database federation)
Create the new mappings for the source such that they match the
“global vocabulary”
Query using the global vocabulary as usual
Consider for example…
59. +
A different Lung Cancer DB
Consider a new lung cancer DB as follows (create it NOW in
H2 using the commands in patient-table2.sql)
ID name ssn age
1 Mariano SSN1 33
2 Morgan SSN2 45
ID stage
1 i
ID stage
2 limited
T_NAME
T_NSCLC
T_SCLC
In this DB information is distributed in
multiple tables. Moreover, the way in
which meaning is encoded is different.
In particular,
• The type of cancer is separated by
table
• The stage of cancer is text
(i,ii,iii,iiia,iiib,iv, limited, extensive)
Moreover, the IDs of the two DBs
overlap (ID 1 is a different patient
here, not Mary) and ssn and age do
not exist in the DB1
60. +
Basic mappings 2
The URI‟s for the new individuals differentiate the data sources
(db2 vs. db1)
Being an instance of NSCLC and SCLC depends now on the
table, not a column value
You can find this mappings in lung-
cancer3-4tables.obda
62. +
The integration result
Now, using a single SPARQL query, we can query both data sources
independently of their structure; they have been aligned to a global view.
63. +
However
Multiple sources maybe have different properties
We cannot know before hand if we don‟t know the sources and
the only thing you see is the ontology
This can be a BIG issue for the user of our integrating ontology,
since many queries would be empty, e.g.:
SELECT ?x ?y ?z WHERE {
?x a :Person ; :name “Mary” ; :ssn ?y ; :age ?z .
}
This query is empty because Mary is from DB1 and
individuals from DB1 have no SSN or AGE. Similar
problems arise with SQL DBs.
But, in SPARQL we have DESCRIBE…
64. +
Flexible queries with SPARQL
“Retrieve all information about
individuals named „Mary‟ and all
information about all conditions they
have”
PREFIX : <http://example.org/>
DESCRIBE ?x WHERE {
{?x :name ”Mary" .}
UNION
{ ?y :name ”Mary";
:hasNeoplasm ?x }
}
65. +
Flexible queries with SPARQL
“Retrieve all information about
individuals named „Mary‟ and all
information about all conditions they
have”
PREFIX : <http://example.org/>
DESCRIBE ?x WHERE {
{?x :name ”Mariano" .}
UNION
{ ?y :name ”Mariano";
:hasNeoplasm ?x }
}
66. +
OBDA for Data Integration
Key features of on-the-fly OBDI (ontology-based data
integration) with ontop:
Flexible: Mapping and ontology languages are powerful enough to
accommodate most needs (consider that SQL allows even to
transform the data, make calculations, etc.)
Dynamic: Changes in the data are automatically reflected during
query answering. Through DB federation new databases can be
incorporated easily
Possible drawbacks:
Performance: With large volumes of data (hundreds of thousands
of rows) performance may suffer (depends on the DB engine,
indexes, and other SQL related issues)
67. +
Data integration resources
You may integrate any JDBC resource, here go some interesting
options:
Teiid – can integrate different DB SQL dbs and other types of
documents (XML, Excel, etc.)
http://www.jboss.org/teiid/
Oracle database links – integrates Oracle DBs
http://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_conce
pts002.htm
MySQL Federated tables – integrates MySQL dbs
http://dev.mysql.com/doc/refman/5.0/en/federated-storage-
engine.html
Excel as SQL – Integrates Excel spread sheets
http://sourceforge.net/projects/xlsql/
69. +
Domain knowledge
Up to know, we only have “explicit data”, however, combining
data with domain knowledge (ontology) we can enrich our
queries with “implicit data”.
For example, that NSCLC is a kind of malignant tumor
(neoplasm), that having a neoplasm is a kind of condition, etc.
This knowledge can be expressed using OWL axioms, which
ontop will use during query answering.
71. +
The result
After synchronization, all the
implied information is available
during query answering
PREFIX : <http://example.org/>
DESCRIBE ?x WHERE {
{?x :name "Mariano"}
UNION
{ ?y :name "Mariano" ;
:hasNeoplasm ?x }
}
72. +
Our data before (only explicit)
Our existing data looked like this picture.
With the new axioms, it now looks like this
(next slide):
73. +
Our data now (implicit and explicit)
Recall, in the on-the-fly approach
all this information is
available at query time but not
really stored anywhere
74. +
Domain Knowledge
Large amounts of data “belong” in databases, i.e., it changes
fast, application specific, large volumes, etc.). OBDA allows you
to do keep it in the DB, but…
Some data in the domain does belong on the ontology side,
i.e., static information, independent from the application. For
example:
ABox data
75. +
Domain Knowledge
This information usually given in the form of OWL individual
assertions (ABox).
A unique feature of ontop is its ability to mix these two worlds,
Allows to link virtual individuals to real individuals to achieve
things like:
ABox data
We want to do this for all
individuals in db1 and db2!
76. +
Hybrid ABoxes: How?
Add the individuals ABox assertions to your ontology (6
individuals and 6 ABox assertions)
77. +
Hybrid ABoxes: How?
Add the individuals ABox assertions to your ontology (6
individuals and 6 ABox assertions)
Add mappings that link your “virtual” individuals to the real ones
80. +
Notes about reasoning in ontop
ontop can only understand OWL 2 QL axioms, that‟s:
subClassOf, subPropertyOf, equivalence
InverseOf
Domain and Range
Plus some limited forms of qualified existential restrictions
Any axiom that is not understood by ontop is ignored while
reasoning
Reasoning is also done by means of query rewriting (no data
moves from the database). Again, most of our research goes
into generating efficient SQL.
82. +
Other features of ontop
Mapping Assistant (OBDA model tab) - A view to help you
generate custom mappings quickly
Mapping bootstrapping (OBDA menu) – automatically
generate “direct” mappings (actually the first mappings we
created can be generated automatically with this function)
Mapping materialization (OBDA menu) – generate OWL
assertions from mappings with one click (import). Try it now, all
the data will be available in the “Individuals tab” and you can
now use it with any reasoner
SPARQL end-point – Use the mappings and ontology
independently from Protégé, as a SPARQL server
83. +
Other features of ontop
OWLAPI and Sesame– Once you created the ontology and
mappings, program your application with ontop and Java using
these.
Command line tools – All previous features can be used directly
from the command line with ontop scripts
R2RML mappings – Ontop now supports also R2RML mappings
(http://www.w3.org/TR/r2rml/) the expressive power of these more
or less the same, however our syntax is more user friendly ☺, use
R2RML for mapping exchange
JDBC sources – Ontop can support any JDBC data source. This
means not only RDBMs, but anything that can be seen as a
RDBMs and queried with SQL, currently there are many wrappers
that allow to do this for Excel files, XML documents, etc.
84. +
Disclaimer
Although the code of ontop is evolving fast, there are several
(Sept/13) important issues to consider when using ontop:
Datatypes many data types not supported yet, issues with
dateTime
SPARQL Current target SPARQL 1.0 plus most features of 1.1 (no
paths). From SPARQL 1.0 we still miss several built in functions
SQL issues Some issues with SQL and some DBs, e.g., problems
getting DB metadata, issues with caps and quotes to qualify
column names
SQL Optimization Performance good , but could be better. Many
planned optimizations not yet implemented.
GUI/ontopPro Many bugs in the GUI (we focus on the DB aspect)
85. +
Additional material
Ontop‟s website
http://ontop.inf.unibz.it
Ontop‟s documentation
https://babbage.inf.unibz.it/trac/obdapublic/wiki
Ontop‟s source code
https://github.com/ontop/ontop/
Since August‟13 ontop is a open source (AGPL).
Consider contributing!
Ontop‟s google group
https://groups.google.com/d/forum/ontop4obda
http://creativecommons.org/licenses/by-sa/3.0/You are free:to Share — to copy, distribute and transmit the workto Remix — to adapt the workto make commercial use of the workUnder the following conditions:Attribution — You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).Share Alike — If you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.With the understanding that:Waiver — Any of the above conditions can be waived if you get permission from the copyright holder.Public Domain — Where the work or any of its elements is in the public domain under applicable law, that status is in no way affected by the license.Other Rights — In no way are any of the following rights affected by the license:Your fair dealing or fair use rights, or other applicable copyright exceptions and limitations;The author's moral rights;Rights other persons may have either in the work itself or in how the work is used, such as publicity or privacy rights.Notice — For any reuse or distribution, you must make clear to others the license terms of this work. The best way to do this is with a link to this web page.
Mappings are axioms that relate the data in a RDBMs to the vocabulary of the ontology (the classes and the properties), they “connect” the two vocabularies in a sense.In the ont-the-fly approach, the reasoner receives ontology and “mappings”, and answers the user queries by transforming these queries into queries over the source. The reasoner is “connnected to the source” hence, data is always fresh, and not duplicated.
The objetive of this section is to learn the very basics of using ontop. We will deal with an SQL database and connect it to Protégé using ontopPro. This will allow us to learn the mapping language, to get familiar with the ontopPro interface and with it’s querying capabilities.
Additionally, a browser window will open showing the “administration page for H2”.Note that the page is pointing to your local machine (192.168.0.100 is your own machine, also 127.0.0.1 and localhost). The page being displayed is the H2 administration console. Here you can create new databases, change security preferences of the server, change the “port” of the DB, etc.To create a new database, we simply introduce a connection string pointing to a non-existing database and click connect. In this case, the H2 server has no database, so any database name we use will create a new database which will persist even if we close the database, i.e., it will be available when we start the server again. The username and password will define the “credentials” for an administrator user. You can let them as the they are “username sa with no password” or change them as you wish.Now we use as connection string jdbc:h2:tcp://localhost/test, this will create a new database called test. Click connect.
This is the “console view” here you are in a “DB session” connected to the H2 server in localhost and database test. Currently this database has no tables, we are going to create a table where we are going to store the data for an ontology.
Cancert type-- false = non-small cell lung cancer (NSCLC), -- true = small cell lung cancer (SCLC)The database has one single table that stores lung cancer information for given patients. The type of cancer stored are NSCLC and SCLC. The stage of the cancer is also recorded. Type and stage are encoded with booleans and integers as follows:-- Stages for NSCLC-- 1 = Stage I-- 2 = Stage II-- 3 = Stage III-- 4 = Stage IIIa-- 5 = Stage IIIb-- 6 = Stage IV-- Stages for SCLC-- 7 = Limited-- 8 = Extensive -- STAGES OF NON-SMALL CELL LUNG CANCER-- -- Stage I: The cancer is located only in the lungs and has not spread to any lymph nodes.-- -- Stage II: The cancer is in the lung and nearby lymph nodes.-- -- Stage III: Cancer is found in the lung and in the lymph nodes in the middle of the chest, also described as locally advanced disease. Stage III has two subtypes:-- -- If the cancer has spread only to lymph nodes on the same side of the chest where the cancer started, it is called stage IIIA.-- If the cancer has spread to the lymph nodes on the opposite side of the chest, or above the collar bone, it is called stage IIIB.-- Stage IV: This is the most advanced stage of lung cancer, and is also described as advanced disease. This is when the cancer has spread to both lungs, to fluid in the area around the lungs, or to another part of the body, such as the liver or other organs.-- -- Small Cell Lung Cancer-- -- Small cell lung cancer accounts for the remaining 15 percent of lung cancers in the United States. Small cell lung cancer results from smoking even more so than non-small cell lung cancer, and grows more rapidly and spreads to other parts of the body earlier than non-small cell lung cancer. It is also more responsive to chemotherapy.-- -- Stages of Small Cell Lung Cancer-- -- Limited stage: In this stage, cancer is found on one side of the chest, involving just one part of the lung and nearby lymph nodes.-- -- Extensive stage: In this stage, cancer has spread to other regions of the chest or other parts of the body.
To create the database we execute the following SQL command. The results should be a new table with the structure we defined. You can get the commands from the file named patient-table1.sql to save some time.
To insert the data we run INSERT SQL commands. Now we add the two rows we had in the example:
To retrieve the data, we use SELECT queries. Note also that the H2 console also allows you to edit the data right there, add new rows and delete rows.
SQL is a very powerful query language that allows you to retrieve data in very selective ways, to do computations on the data, etc. etc. Moreover, SQL databases can do all this on top of very large datasets at very high speed. Traditional OWL reasoners can only handle limited amounts of data.
Here we are using the prefix : http://example.org/
If the connection says “OK” it means Protégé and ontop were able to connect to the H2 server that is running, and that it was able to see the “test” db that we just created.
When adding the class, note that you must add “terms/Patient” and not just “Patient” to get the correct URL. Remember that the base URI of the ontology is http://example.org/ creating the class “terms/Patient” will generate the right class URI. You can see the full URI of a class in the class tree by “hovering” over the class node.Note we are using upper case in this case
This dialog is allows you to create or edit mappings (to edit just double click an existing mapping). You should write the “target” and “source” of the mapping, as well as the ID for the mapping (any unique name to identify the mapping). You may also test your SQL query directly in the dialog.
The mapping appears in the mapping manager. Double clicking on it allows you to edit it.
Note that URI’s of the individuals are constructed as we described in the template of the mapping, just replacing the placeholders with the actual values from the DB.
The queryPREFIX : <http://example.org/>PREFIX terms: <http://example.org/terms/>SELECT * WHERE { ?p a terms:Patient .}
The result is no longer numeric ID’s in the database. The results are URI’s constructed in the way that you wrote in the mapping by replacing the “column references” with the actual values obtained from the database (the values in each row)
Remember to “synchronize” the reasoner, since changes to ontology or mappings are not automatically transferred to Quest.
Mappings :db1/{PATIENTID} a :terms/Patient ; :terms/id {PATIENTID} ; :terms/name {NAME} ; :terms/type {TYPE} ; :terms/stage {STAGE} .Remember to “synchronize” the reasoner, since changes to ontology or mappings are not automatically transferred to Quest.
With all the mappings in place, now we “refresh” the reasonerPREFIX : <http://example.org/>SELECT * WHERE { ?p a :Patient . ?p :id ?id . ?p :name ?name . ?p :stage ?stage . ?p :type ?type .}
URI templates are URI’s (short with prefix or long) with place holders with column names.
URI templates are URI’s (short with prefix or long) with place holders with column names.Note that constant values can be used anywhere, e.g., Michael_Jackson.
URI templates are URI’s (short with prefix or long) with place holders with column names.
URI templates are URI’s (short with prefix or long) with place holders with column names.Note that constant values can be used anywhere, e.g., Michael_Jackson.
URI templates are URI’s (short with prefix or long) with place holders with column names.Note that constant values can be used anywhere, e.g., Michael_Jackson.
URI templates are URI’s (short with prefix or long) with place holders with column names.
Neoplasm is the technical term for tumor, an abnormal growth of tissue. NSCLC – Non small cell lung cancer
TYPO: please remove the last slash after :db1/neoplasm/{PATIENTID}/, that is after :db1/neoplasm/{PATIENTID}
TYPO: please remove the last slash after :db1/neoplasm/{PATIENTID}/, that is after :db1/neoplasm/{PATIENTID}
TYPO: please remove the last slash after :db1/neoplasm/{PATIENTID}/, that is after :db1/neoplasm/{PATIENTID}
PREFIX : <http://example.org/>SELECT * WHERE { ?x a :Person ; :hasNeoplasm ?n . ?n ?p ?v }If we query the new model now we can obtain the information of each patient and their condition. More importantly, this information is not encoded in numeric values, dependent on the DB, but in the URIs of classes or individuals that have clear semantics.
To create the database use the commands located in the file patient-table2.sql. Do it as before, copy the commands from your text editor into the H2 console and execute them. The tables should appear in the DB
Add the new data properties :age and :ssn, then your basic mappings look like this
A solution to this which is available through ontop is
In the case of the lung cancer domain, we could express some of our knowledge as depicted in the picture. The result would be
After doing this and “synchronizing with the reasoner”, instead of having just data as now (switch to slide)