OwlOntDB: A Scalable Reasoning System for OWL 2 RL Ontologies with Large ABoxes

Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion

OwlOntDB: A Scalable Reasoning System for
OWL 2 RL Ontologies

Md Rokan Uddin Faruqui and Wendy MacCaull

St. Francis Xavier University
Antigonish, NS, CA

August, 2012

FHIES’12 Paris, France

1


O UTLINE

Background

Ontology and OWL

Translation

Materialization

Query Processing

Evaluation

Conclusion

2


B ACKGROUND

Collaborative Academic/Health Authority/ Industry
project (www.logic.stfx.ca)
Building Decision Support through Workﬂow for Health
Care
Vision: “Put Science into Software”
Formal methods/domain expertise/software
engineering/web-based tools: CfMS
Working on 2 community-based health care programs
Ensure continuum of care
Compliance with guidelines
Interface with coming EHR

3


B ACKGROUND

The CfMS is comprised of:
an innovative workflow development workbench, NOVA
Workflow, which can support a broad range of
collaborations among systems built on heterogeneous
platforms, integrated with
WebPal Content Server, a mobile document management
system deployed on tablet computers.
The CfMS prototype incorporates:
a graphical language to design, verify and execute
workflow and
domain specific language for writing procedural
statements, for querying the knowledge base, for applying
access control policies, and for scheduling tasks via
worklists specific to the user.

4


B ACKGROUND

CfMS provides care team providers with complete
electronic access to all forms and reference materials,
saving time and duplication of effort.
The prototype is a HTML5 web-based system where no
data is stored on the mobile device; access to the server is
secured through a VPN.
Messages can be exchanged among caregivers and tasks
can be monitored with alerts sent for tasks that miss
deadlines
Currently running a second pilot using mobile devices in
GASHA (continuing care, rehab clinic, geriatric assessment
clinic, palliative care)

5


B ACKGROUND

Health care is data intensive
Use ontology - a kind of structured knowledge base;
advantages over database systems:
knowledge can be inferred from an ontology
structure makes it easier to correctly change the knowledge
base and provide adaptability to the workﬂow
Provide access control, monitor such aspects as referral
times and pain to provides alerts to clinicians
System must consult (query) ontology at decision points
Need fast reasoners (inference engines)

6


B ACKGROUND

This talk is based on work by MSc student Rokan Faruqui;
At the end we will discuss some related and future work in
ontology reasoning done by others at the CLI.
Papers in last years’ FHIES describe some details in the
Nova Workﬂow;
Paper tomorrow with Adrian Rutle is related work using
MDE techniques wherein models are the primary software
engineering artifacts and as such are used to generate code
Correctness
Fexibility

7


O NTOLOGY AND OWL
A model of a domain
introduces vocabulary relevant to the domain
speciﬁes semantics of terms

Figure: Anatomy
8


O NTOLOGY AND OWL

The Web Ontology Language OWL
W 3C Recommendations
formal semantics based on Description Logic (DL)
OWL 1 (2004)
OWL 2 (2009)

Formal properties well understood (complexity,
decidability)
Known reasoning algorithms
Implemented systems (highly optimized)

9


T HE W EB O NTOLOGY LANGUAGE (OWL)

From OWL 2-overview (Horrocks)
Motivated by Semantic Web activity
Add meaning to web content by annotating it with terms
deﬁned in ontologies
Developed by WebOnt working group
Based on earlier languages RDF, OIL and DAML+OIL
Became a recommendation on 10 Feb 2004
Supported by tools and infrastructure
APIs
Development environments
Reasoners & Information Systems
Based on a Description Logic (SHOIN )

10


D ESCRIPTION L OGICS (DL S )

Fragments of ﬁrst order logic designed for KR
Desirable computational properties
Decidable (essential)
Low complexity (desirable)
Succinct and quantiﬁer free syntax

∀x.[Heart(x) → M uscularOrgan(x) ∧ ∃y.[isP artOf (x, y)
∧CirculatorySystem(y)]]

Heart MuscularOrgan ∃ isPartOf .CirculatorySystem

11


O NTOLOGY AND OWL

A Description Logic-based ontology has two components:
a TBox: contains vocabulary relevant to the domain and
their semantics.
Woman Person Mother Parent Woman
Person ∃isFeeling.Pain Patient

an ABox: contains assertions about individuals in terms of
this vocabulary.
Class Assertions: Mother (Mary)
Object Property Assertions: hasFather (Mary, Bob)
Data Property Assertions: hasAge(Mary, “35 )

12


O NTOLOGY AND OWL
OWL playing key role in increasing number & range of
applications
eScience, eCommerce, geography, engineering, defence,
E.g., OWL tools used to identify and repair errors in a
medical ontology:
would have led to missed test results if not corrected

Experience of OWL in use has identiﬁed restrictions:
on expressivity
on scalability
These restrictions are problematic in some applications
Research has now shown how some restrictions can be
overcome
W3COWL WG has updated OWL accordingly
Result is called OWL 2
OWL 2 is now a Recommendation
13


OWL 2

Extends OWL with a small but useful set of features
That are needed in applications
For which semantics and reasoning techniques are well
understood
That tool builders are willing and able to support
Adds proﬁles
Language subsets with useful computational properties
Is fully backwards compatible with OWL:
Every OWL ontology is a valid OWL 2 ontology
Every OWL 2 ontology not using new features is a valid
OWL ontology
Already supported by popular OWL tools & infrastructure:
Protg, HermiT, Pellet, FaCT++, OWL API

14


W HATS N EW IN OWL 2?

Four kinds of new feature:
Increased expressive power
qualified cardinality restrictions, e.g.:
persons having two friends who are republicans
property chains, e.g.:
the brother of your parent is your uncle
local reflexivity restrictions, e.g.:
narcissists love themselves
reflexive, irreflexive, and asymmetric properties, e.g.:
nothing can be a proper part of itself (irreflexive)
disjoint properties, e.g.:
you can’t be both the parent of and child of the same person
keys, e.g.:
country + license plate constitute a unique identifier for
vehicles

15



Extended Datatypes
Much wider range of XSD Datatypes supported, e.g.:
Integer, string, boolean, real, decimal, ﬂoat, datatime,...
User-deﬁned datatypes: max weight of an airmail letter:
xsd:integer maxInclusive“20” ˆˆxsd:integer

16



Metamodelling and annotations
Syntactic sugar
Disjoint unions, e.g.: Element is the DisjointUnion of Earth
Wind Fire Water
Negative assertions, e.g.:
Mary is not a sister of Ian

17


OWL 2

OWL only useful in practice if we can deal with large
ontologies and/or large data sets
Unfortunately, OWL is worst case highly intractable
OWL 2 ontology satisfiability is 2NEXPTIME-complete
Possible solution is profiles: language subsets with useful
computational properties
OWL defined one such profile: OWL Lite
Unfortunately, it isnt tractable either! (EXPTIME-complete)

18


OWL 2

OWL 2 deﬁnes three different tractable proﬁles:
EL: polynomial time reasoning for schema and data
Useful for ontologies with large conceptual part
QL: fast (logspace) query answering using RDBMs via SQL
Useful for large datasets already stored in RDBs
RL: fast (polynomial) query answering using rule-extended
DBs
Useful for large datasets stored as RDF triples
OWL 2 RL is A (near maximal) fragment of OWL 2 such
that
Can be implemented using standard rule engines
Closely related to Description Logic Programms (DLP)
No existentials on RHS

19


OWL 2RL
OWL profile that resembles an OWL-based rule language:
Intuition: subclass axioms in OWL RL can be understood as rule-like
implications with head (superclass) and body (subclass)
Different restrictions on subclasses and superclasses:
subclasses can only be class names, nominals,
conjunctsions, disjunctions, existentials if applied only to
subclass-type expressions
superclasses can be class names, universals or nominals;
also max. cardinalities of 0 or 1 are allowed, all with
superclass-type filler expressions only
Property domains and ranges only for subclass-type expressions; property
hierarchies, disjointness, inverses, (a)symmetry, transitivity, chains,
(inverse)functionality, irreflexivity fully supported
Disjoint classes and classes in keys need subclass-type expressions, equivalence
only for expressions that are sub- and superclass-type, no restrictions on equality

[P. Hitzler, M. Krotzsch, S. Rudolph: Knowledge Representation for the Semantic
¨
Web, KI 2009 (semantic-web-book.org)]

20


OWL 2RL E XAMPLES

∃parentOf. ∃parentOf. Grandfather
rule version: parentOf(x,y) ∧ parentOf(y,z) → Grandfather(x)
Orphan ∀ hasParent.Dead
rule version: Orphan(x) ∧ hasParent(x,y) → Dead(y)
Monogamous ≤ 1 married.Alive
rule version:
Monogamous(x) ∧ married(x,y) ∧ Alive(y) ∧ married(x,z) ∧ Alive(z) → y = z
childOf o childOf grandchildOf
rule version: childOf(x,y) ∧ childOf(y,z) → grandchildOf(x,z)

[P. Hitzler, M. Krotzsch, S. Rudolph: Knowledge Representation for the Semantic
¨
Web, KI 2009 (semantic-web-book.org)]

21


R EASONING WITH L ARGE O NTOLOGIES

Reasoners determine class hierarchy and allow domain
experts to check (TBox Reasoning) if, e.g.:
classes are consistent (no obvious errors)
expected subsumptions hold (consistent with intuitions)
unexpected equivalences hold (unintended synonyms)
ABox Reasoning
consistency checking
main reasoning problem is (conjunctive) query answering
Eg:
(x , z ) ← Wine(x ) ∧ drinkWith(x , y) ∧ Dish(y) ∧ fromRegion(y, z )

22


R EASONING WITH L ARGE O NTOLOGIES
What about scalability?
Reasoning often requires us to deal with large ontologies (#
assertions/#axioms/#classes and properties)
Data/Query intensive applications e.g., Healthcare
systems, use ontologies with large ABoxes.

Figure: DL Reasoners

Existing DL reasoners perform in-memory reasoning

Cannot handle ontologies with large ABoxes.
24


S CALABLE A PPROACHES

Database Integration Approach : DL − Lite
Maximal tractable subset of OWL 1 DL that can be handled
using RDBMS
Express ontology as conceptual models such as UML class
diagrams and ER diagrams
Simple rewriting mechanism
rewriting the query into an SQL query that is then answered
by the RDBMS system
Logic Programming-based Approach: DLP
Translate ontologies into logic programs
Reuse existing efﬁcient and faster inference algorithms
We use the forward-chaining method for inferencing.

25


G OAL

Goal: A scalable reasoner that supports OWL 2 RL
proﬁle.

26


O WL O NT DB: A SCALABLE REASONING SYSTEM FOR OWL 2 RL ONTOLOGIES

27


T RANSLATION : OWL 2 RL – TO – D ATALOG

Express inference tasks for the OWL 2 RL ontology in
terms of inference tasks for datalog.

Datalog is a simple rule language stemming from Prolog.

Extend an existing DLP mapping to accommodate the
new features of OWL 2 RL.

Translate the inferred ontology to a datalog programs
using the extended DLP mapping.

28


T RANSLATION : OWL 2 RL – TO – D ATALOG

OWL 2 RL Axioms DL Syntax Datalog Rule
ClassAssertions a:C C(a)
PropertyAssertion a, b : P P (a, b)
SubClassOf C D C(x) → D(x)
ObjectPropertyChain P ◦Q R P (x, y) ∧ Q(y, z) → R(x, z)
EquivalentClasses C≡D C(x) → D(x), D(x) → C(x)
EquivalentProperties P ≡Q Q(x, y) → P (x, y)
P (x, y) → Q(x, y)
ObjectInverseOf P ≡ Q− P (x, y) → Q(y, x)
Q(y, x) → P (x, y)
TransitiveObjectProperty P+ P P (x, y) ∧ P (y, z) → P (x, z)
SymmetricObjectProperty P ≡ P− P (x, y) → P (y, x)
Object/DataUnionOf C1 C2 D C1 (x) → D(x), C2 (x) → D(x)
Object/DataIntersectionOf C D1 D2 C(x) → D1 (x),C(x) → D2 (x)
Object/DataSomeValuesFrom ∃P.C D P (x, y) ∧ C(y) → D(x)
Object/DataAllValuesFrom C ∀P.D C(x) ∧ P (x, y) → D(y)
Object/DataPropertyDomain ∀P − .C P (y, x) → C(y)
Object/DataPropertyRange ∀P.C P (x, y) → C(y)

29


AB OX C ONSISTENCY C HECKING

Restrictions Checker: checks whether the ABox is
consistent with respect to the TBox.
FunctionalProperty InverseFunctionalProperty
1P 1 P−
F unctionalObjectP roperty(P ) InverseF unctionalObjectP roperty(P )
Irreﬂexive Asymmetric
∃ P.self ⊥ P ¬P −
Irref lexiveObjectP roperty(P ) AsymmetricObjectP roperty(P )
MinimumCardinality (0/1) MaximumCardinality(0/1)
nP.C nP.C
ObjectM inCardinality(n P C) ObjectM axCardinality(n P C)

30


AB OX C ONSISTENCY C HECKING

Restrictions Checker: checks whether the ABox is
consistent with respect to the TBox.
FunctionalProperty InverseFunctionalProperty
1P 1 P−
F unctionalObjectP roperty(P ) InverseF unctionalObjectP roperty(P )
Irreﬂexive Asymmetric
∃ P.self ⊥ P ¬P −
Irref lexiveObjectP roperty(P ) AsymmetricObjectP roperty(P )
MinimumCardinality (0/1) MaximumCardinality(0/1)
nP.C nP.C
ObjectM inCardinality(n P C) ObjectM axCardinality(n P C)

Example :
a TBox axiom
IrreflexiveObjectProperty(marriedT o)
an ABox assertion: marriedT o(Bob, Bob)

30


M ATERIALIZATION

Materialization is an approach of inferring and storing
implicit knowledge from an ontology using a
database-driven kind of forward chaining rather than an
in-memory forward chaining
Each datalog fact and rule is translated to an SQL
statement
The asserted and inferred knowledge is stored in a
relational database to be used for querying
Two approaches to insert facts into relational databases
Direct Mapping: one table for each predicate
Meta Mapping:
ClassAssertion − > TypeOf,
ObjectProperty − > RelationshipObj,
DataProperty − > RelationshipData

31


D ATALOG TO SQL

A datalog rule has one of the following forms

head(h1 , . . . hn )
body(b1 , . . . , bn ) → head(h1 , . . . hn )
body1 (b1 , . . . , bn ) ∧ . . . ∧ bodyN (b1 , . . . , bn ) → head(h1 , . . . hn )

INSERT INTO <Table1> VALUES( h1 , . . . hn )
INSERT INTO <Table1> SELECT
<Projectors> FROM <Tables> WHERE <SELECTORS>
INSERT INTO <TableC> SELECT <Projectors>
FROM <Table1> JOIN ... JOIN <TableN> WHERE <SELECTORS>

32


D ATALOG TO SQL – E XAMPLE

Mother (Mary) (1)
hasFather (Mary, Bob) (2)
Woman(x ) → Person(x ) (3)
hasChild (x , y) ∧ Person(y) → Parent(x ) (4)

(1) INSERT INTO TypeOf(Class, Individual) VALUES(‘‘Mother’’,‘‘Mary’’)
(2) INSERT INTO RelationshipObj(Subject, Predicate, Object)
VALUES(‘‘Mary’’, ‘‘hasFather’’, ‘‘Bob’’)
(3) INSERT INTO TypeOf(Class, Individual) SELECT ‘‘Person’’, Ind
FROM TypeOf WHERE Class == ‘‘Woman’’
(4) INSERT INTO TypeOf(Class, Individual) SELECT ‘‘Parent’’, r.Object
FROM TypeOf t, RelationshipObj r WHERE r.Predicate == ‘‘hasChild’’
AND t.Class == ‘‘Person’’ AND t.Individual == r.Object

33


Given the fact M other(M ary), the two rules
Mother (x ) → Parent(x ) and Parent(x ) → Person(x ) are found.
The corresponding SQL statements are:

(1) INSERT INTO Type Of (Class Individual) Values (Mother, Mary)
(2) INSERT INTO TypeOf (Class, Individual)
SELECT Parent, Ind FROM TypeOf WHERE Class == Mother
(3) INSERT INTO TypeOf (Class, Individual)
SELECT Person, Ind FROM TypeOf WHERE Class == Parent

34


The TypeOf table has two columns: Class and Ind – it
stores all the individuals of every class.
Using the second SQL statement, the algorithm ﬁrst selects
all the individuals of the class ”Mother”, then it inserts
these individuals as individuals of ”Parent”.
We provided the class name ”Parent” in the projector list, so
the algorithm will insert all the selected individuals in the
TypeOf table, this time as individuals of the Parent class.
Using the third SQL statement, the algorithm selects all
individuals of the class Parent and inserts these
individuals as individuals of the class Person.
Since Mary was in the class Mother, Mary will also be in
the class Parent and Person.

35


A F RAGMENT OF THE D ATABASE S CHEMA

36


Q UERY P ROCESSING
The SPARQL-DL API
is fully aligned with OWL 2.
interacts with main-memory-based reasoners.
We modified the SPARQL-DL API to extract knowledge
from the relational database
We modified following required interfaces:
allC(O), allDP (O), allOP (O), allI(O) return all classes,
data properties, object properties, and individuals
respectively defined in O.
subC(O, C), supC(O, C), eqC(O, C) return all sub classes,
super classes, and equivalent classes respectively of class C
in O.
subOP (O, P), supOP (O, P), eqOP (O, P), subDP (O, P),
supDP (O, P), eq DP (O, P) return all sub object properties,
super object properties, equivalent object properties, sub
data properties, super data properties, and equivalent data
properties respectively of properties p in O.
en(O, q) checks whether O q for a SPARQL-DLE atom q.
37


Q UERY P ROCESSING – B ENCHMARK O NTOLOGIES
The LUBM benchmark ontology
An ontology about organizational structures of universities.
Developed at the Lehigh University for testing performance
of ontology management and reasoning systems
Provides a data generator. We use two datasets: lubm1 , and
lubm100
Contains Object and Data property, inverseOf, transitive
property and existential quantification
The wine ontology
Contains a classification of wine.
Contains functional roles, disjunctions, and existential
quantifiers.
We used two datasets :
wine1 - the original wine ontology.
wine5 - which they synthetically generated by replicating 2n
times the ABox of wine1 .
.
38


Q UERY P ROCESSING – LUBM AND W INE O NTOLOGIES
(LQ1 ) Find all the students who are employees and return
their names and designations.
PREFIX ub: <http://www.lehigh.edu/2004/univ-bench.owl#>
SELECT * WHERE { Type(?x, ub:Student),
Type(?x, ?C), SubClassOf(?C, ub:Employee) }

(LQ2 ) Find the names of all students.
PREFIX ub: <http://www.lehigh.edu/2004/univ-bench.owl#>
SELECT * WHERE { Type(?x, ub:Student) }

(WQ1 ) Determine all the instances of “AmericanWine”.
PREFIX wine: <http://www.w3.org/TR/2003/wine#>
SELECT ?i WHERE { Type(?i, wine:AmericanWine) }

(WQ2 ) Determine all the instances of “Dry” wines.
PREFIX wine: <http://www.w3.org/TR/2003/wine#>
SELECT ?i WHERE {
Type(?i,?x), SubClassOf(?x, wine:DryWine) }

39


R ESULTS AND D ISCUSSIONS

Ontology C D Functional Domain Range R S C(a) P (a, b)
wine1 126 6 6 9 9 247 246
wine5 126 6 6 9 9 2717 2706
lubm1 36 0 25 18 9 20659 82415
lubm100 36 0 25 18 9 5658 11096694

Table: Number of axioms in test ontologies

lubm1 lubm100 wine1 wine5
117.58 s 130.53 s 21.422 s 217.5 s
Table: Time required for materialization

40


R ESULT AND D ISCUSSIONS

Dataset Reasoner LQ1 LQ2
lubm1 P ellet 129.02 s 127.06 s
lubm1 OwlOntDB 3.43s 0.79 s
lubm100 P ellet 142.80 s 127.66 s
lubm100 OwlOntDB 29.07 s 1.0 s

Dataset Reasoner W Q1 W Q2
wine1 P ellet 2.95 s 2.98 s
wine1 OwlOntDB 0.047 s 0.11 s
wine5 P ellet 363.089 s 363.59 s
wine5 OwlOntDB 0.3435 s 1.171 s
Table: A comparison of query answering times.

41


C ANCER PAIN M ANAGEMENT G UIDELINES
Complete pain assessment
and care plan

Yes Currently on No On weak opioid with
Pain intensity regular opioid moderate-severe pain
go to Strong Opioid Regimen

Backgound Moderate Severe
Mild pain
Discomfort (0 − 1) Pain (4 − 6) Pain (7 − 10)
(2 − 3)

If pain is not If pain is not
stable may start stable may start
Non Opioid with weak opioid with weak opioid
Regimen

Weak Opioid
No response Regimen

Strong Opioid
No response Regimen

Pain No Yes Opioid
Intensity Response Maintenance
Appropriate
dose and
reassess at
Mild pain Moderate Severe appropriate
Pain (4 − 6) Pain (7 − 10) intervals
(2 − 3)

No
Dose titration of opioid
Yes Side
For mild pain: Consider increasing dose by 10% q4h ATC Response eﬀect
Reassess at least every 48 − 72 hours
For moderate pain: Increase dose by 10 − 25% q4h ATC
Reassess at least every 24 hours No Yes

For severe pain: Increase dose by 25 − 50% q4h ATC Yes Continue
Management
Reassess at least every 12 hours dose titration
No of side eﬀect

42


T HE C ANCER PAIN M ANAGEMENT (PM) O NTOLOGY

43


T HE C ANCER PAIN M ANAGEMENT (PM) O NTOLOGY
We use the pain management ontologythat includes the
terminology and concepts of health and medicine
used in the Guysborough Antigonish Strait Health
Authority (GASHA)
from SNOMED-CT, ICNP, and the guidelines for cancer
pain treatment
.
This ontology includes
several classes including Pain, Person, Patient,
PainIntensityType, SpecialPainProblem,
SideEffects;
some object properties including hasPainIntensity,
Domain:Pain, Range:PainIntensityType,
data properties including hasPainLevel, Domain :Pain,
Range:xsd:int,
inverse object properties such as isFeeling and
isFeltBy,
functional object properties including hasPainLevel, i.e.,
44 each pain level belongs to an instance of Pain class.


Q UERY P ROCESSING – THE PM ONTOLOGY

Determine the medication information of all the patients
who are feeling “Mucositis” pain.

PREFIX pm: <http://logic.stfx.ca/ontologies/PainOntology.owl#>
SELECT ?i ?j WHERE {
Type(?i,pm:Patient),
PropertyValue(?i, pm:isFeeling, pm:MucositiesPain),
PropertyValue(?i, pm:haMedication, ?j) }

Find names of the relatives of all the patients who serve as
informal care givers.

PREFIX pm: <http://logic.stfx.ca/ontologies/PainOntology.owl#>
SELECT ?i ?j WHERE {
Type(?i,pm:Patient), PropertyValue(?i, pm:hasCarer , ?j),
SubClassOf(?j, pm:Relative) }

45


R ESULTS AND D ISCUSSIONS

P M250 P M500 P M1000 P M2000 P M3000
No. of Axioms 20344 40396 77600 156308 231555
Time (sec.) 20.71 45.94 90.34 263.24 345.28

Table: Time required for materialization

Q1 Q2
Pellet OwlOntDB Pellet OwlOntDB
P M250 41.65 7.53 65.85 9.79
P M500 91.83 11.71 127.038 14.89
P M1000 179.50 16.89 259.678 19.01
P M2000 718.18 20.78 959.32 23.21
P M3000 - 29.21 - 34.01
Table: A comparison of query answering times (in seconds). “-”
means that the reasoner failed to return the result.
46


C ONCLUSION

OwlOntDB
supports OWL 2 RL- an expressive fragment of OWL
can handle ontologies with a large numbers of instances
suitable for

decision support systems that need faster query responses
query intensive applications
applications where updates are less frequent

47


L IMITATIONS AND F UTURE D IRECTIONS

Initial Processing time / Materialization time is very high
Parallel and distributed computing
Consequence-based classiﬁcation

Update Problem: Re-materialize the whole ontology
Incremental Materialization

Extend ontology to deal with time and develop efﬁcient
reasoners.

48


C ONTRIBUTIONS

Developed a translator to generate datalog programs from
OWL 2 RL ontologies by extending the DLP mapping.

[A. Rakib, R. U. Faruqui, and W. MacCaull, Verifying Resource Requirements for
Ontology-Driven Rule-Based Agents, Lecture Notes in Computer Science, 2012, Volume
7153, Foundations of Information and Knowledge Systems (FoIKS 2012, Kiel,
Germany), Pages 312-331.]

49


C ONTRIBUTIONS


Developed a materialized algorithm that performs a
forward chaining over a datalog program, then translates
the resulting program to a set of SQL statements.


49


C ONTRIBUTIONS


Developed a materialized algorithm that performs a
forward chaining over a datalog program, then translates
the resulting program to a set of SQL statements.

Modiﬁed an existing SPAQRL-DL API

49


Thanks

50


S YNTAX AND SEMANTICS OF SROIQ CONSTRUCTORS
Constructor Syntax Semantics
Top ∆I
Bottom ⊥ ∅
Conjunction C D C I ∩ DI ALC
Disjunction C D C I ∪ DI
Negation ¬C ∆I D I
Exist Restriction ∃ R.C {a ∈ ∆I |∃b((a, b) ∈ RI and b ∈ C I )}
Value Restriction ∀ R.C {a ∈ ∆I |∀b((a, b) ∈ RI implies b ∈ C I )}
Transitive Role R+ (a, b) ∈ RI and (b, c) ∈ RI implies (a, c) ∈ RI R+
ALC R+ = S
Role Inclusion R S RI ⊆ S I H
Composite Role R◦S {(a, c) ∈ ∆I × ∆I |∃b((a, b) ∈ RI and (b, c) ∈ S I )}
Role Chain R1 ◦ . . . ◦ Rn S R1 ◦ . . . ◦ Rn ⊆ S I
I I R
Nominal {o} {oI } O
Inverse Role R− {(a, b)|(b, a) ∈ RI } I
Number nR {a ∈ ∆I |#{b ∈ ∆I |(a, b) ∈ RI } n}
Restriction nR {a ∈ ∆I |#{b ∈ ∆I |(a, b) ∈ RI } n} N
Qualified Number n R.C {a ∈ ∆I |#{b ∈ ∆I |(a, b) ∈ RI and b ∈ C I } n}
Restriction n R.C {a ∈ ∆I |#{b ∈ ∆I |(a, b) ∈ RI and b ∈ C I } n} Q
Functional 1 R and {a ∈ ∆I |#{b ∈ ∆I |(a, b) ∈ RI } 1} and
Role <2R {a ∈ ∆I |#{b ∈ ∆I |(a, b) ∈ RI } < 2} F
Reflexive Role Ref lexive(R) a ∈ ∆I implies (a, a) ∈ RI
Irreflexive Role Irref lexive(R) a ∈ ∆I implies (a, a) ∈ RI
/
Symmetric Role Symmetric(R) (a, b) ∈ RI implies (b, a) ∈ RI
Asymmetric Role Asymmetric(R) (a, b) ∈ R I implies (b, a) ∈ RI
/
Disjoint Roles Disjoint(R1 , . . . Rn ) I I
Rj ∩ Rk is empty for each i ≤ j, k ≤ n and j = k

51

OwlOntDB: A Scalable Reasoning System for OWL 2 RL Ontologies with Large ABoxes

More Related Content

What's hot

Viewers also liked

Similar to OwlOntDB: A Scalable Reasoning System for OWL 2 RL Ontologies with Large ABoxes

Recently uploaded

OwlOntDB: A Scalable Reasoning System for OWL 2 RL Ontologies with Large ABoxes