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 forOWL 2 RL Ontologies

Md Rokan Uddin Faruqui and Wendy MacCaull

St. Francis Xavier UniversityAntigonish, NS, CA

August, 2012

FHIES’12 Paris, France

1


OUTLINE

Background

Ontology and OWL

Translation

Materialization

Query Processing

Evaluation

Conclusion

2


BACKGROUND

I Collaborative Academic/Health Authority/ Industryproject (www.logic.stfx.ca)

I Building Decision Support through Workflow for HealthCare

I Vision: “Put Science into Software”I Formal methods/domain expertise/software

engineering/web-based tools: CfMS

I Working on 2 community-based health care programsI Ensure continuum of careI Compliance with guidelinesI Interface with coming EHR

3


BACKGROUND

I The CfMS is comprised of:I an innovative workflow development workbench, NOVA

Workflow, which can support a broad range ofcollaborations among systems built on heterogeneousplatforms, integrated with

I WebPal Content Server, a mobile document managementsystem deployed on tablet computers.

I The CfMS prototype incorporates:I a graphical language to design, verify and execute

workflow andI domain specific language for writing procedural

statements, for querying the knowledge base, for applyingaccess control policies, and for scheduling tasks viaworklists specific to the user.

4


BACKGROUND

I CfMS provides care team providers with completeelectronic access to all forms and reference materials,saving time and duplication of effort.

I The prototype is a HTML5 web-based system where nodata is stored on the mobile device; access to the server issecured through a VPN.

I Messages can be exchanged among caregivers and taskscan be monitored with alerts sent for tasks that missdeadlines

I Currently running a second pilot using mobile devices inGASHA (continuing care, rehab clinic, geriatric assessmentclinic, palliative care)

5


BACKGROUND

I Health care is data intensiveI Use ontology - a kind of structured knowledge base;

advantages over database systems:I knowledge can be inferred from an ontologyI structure makes it easier to correctly change the knowledge

base and provide adaptability to the workflowI Provide access control, monitor such aspects as referral

times and pain to provides alerts to cliniciansI System must consult (query) ontology at decision points

I Need fast reasoners (inference engines)

6


BACKGROUND

I This talk is based on work by MSc student Rokan Faruqui;I At the end we will discuss some related and future work in

ontology reasoning done by others at the CLI.I Papers in last years’ FHIES describe some details in the

Nova Workflow;I Paper tomorrow with Adrian Rutle is related work using

MDE techniques wherein models are the primary softwareengineering artifacts and as such are used to generate code

I CorrectnessI Fexibility

7


ONTOLOGY AND OWLI A model of a domain

I introduces vocabulary relevant to the domainI specifies semantics of terms

Figure: Anatomy8


ONTOLOGY AND OWL

I The Web Ontology Language OWLI W3C Recommendations

I formal semantics based on Description Logic (DL)I OWL 1 (2004)I OWL 2 (2009)

I Formal properties well understood (complexity,decidability)

I Known reasoning algorithmsI Implemented systems (highly optimized)

9


THE WEB ONTOLOGY LANGUAGE (OWL)

From OWL 2-overview (Horrocks)I Motivated by Semantic Web activity

I Add meaning to web content by annotating it with termsdefined in ontologies

I Developed by WebOnt working groupI Based on earlier languages RDF, OIL and DAML+OILI Became a recommendation on 10 Feb 2004

I Supported by tools and infrastructureI APIsI Development environmentsI Reasoners & Information Systems

I Based on a Description Logic (SHOIN )

10


DESCRIPTION LOGICS (DLS)

I Fragments of first order logic designed for KRI Desirable computational properties

I Decidable (essential)I Low complexity (desirable)

I Succinct and quantifier free syntax

∀x.[Heart(x) → MuscularOrgan(x) ∧ ∃y.[isPartOf(x, y)

∧CirculatorySystem(y)]]

Heart v MuscularOrgan u ∃ isPartOf .CirculatorySystem

11


ONTOLOGY AND OWL

I A Description Logic-based ontology has two components:I a TBox: contains vocabulary relevant to the domain and

their semantics.Woman v Person Mother v Parent uWoman

Person u ∃isFeeling .Pain v Patient

I an ABox: contains assertions about individuals in terms ofthis vocabulary.Class Assertions: Mother(Mary)

Object Property Assertions: hasFather(Mary ,Bob)

Data Property Assertions: hasAge(Mary , “35 ′′)

12


ONTOLOGY AND OWLI OWL playing key role in increasing number & range of

applicationsI eScience, eCommerce, geography, engineering, defence,I E.g., OWL tools used to identify and repair errors in a

medical ontology:

would have led to missed test results if not corrected

I Experience of OWL in use has identified restrictions:I on expressivityI on scalability

I These restrictions are problematic in some applicationsI Research has now shown how some restrictions can be

overcomeI W3COWL WG has updated OWL accordinglyI Result is called OWL 2I OWL 2 is now a Recommendation

13


OWL 2

I Extends OWL with a small but useful set of featuresI That are needed in applicationsI For which semantics and reasoning techniques are well

understoodI That tool builders are willing and able to support

I Adds profilesI Language subsets with useful computational properties

I Is fully backwards compatible with OWL:I Every OWL ontology is a valid OWL 2 ontologyI Every OWL 2 ontology not using new features is a valid

OWL ontology

I Already supported by popular OWL tools & infrastructure:I Protg, HermiT, Pellet, FaCT++, OWL API

14


WHATS NEW IN OWL 2?

Four kinds of new feature:I Increased expressive power

I qualified cardinality restrictions, e.g.:persons having two friends who are republicans

I property chains, e.g.:the brother of your parent is your uncle

I local reflexivity restrictions, e.g.:narcissists love themselves

I reflexive, irreflexive, and asymmetric properties, e.g.:nothing can be a proper part of itself (irreflexive)

I disjoint properties, e.g.:you can’t be both the parent of and child of the same person

I keys, e.g.:country + license plate constitute a unique identifier forvehicles

15


WHATS NEW IN OWL 2?

Four kinds of new feature:I Extended Datatypes

I Much wider range of XSD Datatypes supported, e.g.:Integer, string, boolean, real, decimal, float, datatime,...

I User-defined datatypes: max weight of an airmail letter:xsd:integer maxInclusive“20” ˆˆxsd:integer

16


WHATS NEW IN OWL 2?

Four kinds of new feature:I Metamodelling and annotationsI Syntactic sugar

I Disjoint unions, e.g.: Element is the DisjointUnion of EarthWind Fire Water

I Negative assertions, e.g.:Mary is not a sister of Ian

17


OWL 2

I OWL only useful in practice if we can deal with largeontologies and/or large data sets

I Unfortunately, OWL is worst case highly intractableI OWL 2 ontology satisfiability is 2NEXPTIME-complete

I Possible solution is profiles: language subsets with usefulcomputational properties

I OWL defined one such profile: OWL LiteI Unfortunately, it isnt tractable either! (EXPTIME-complete)

18


OWL 2

I OWL 2 defines three different tractable profiles:I EL: polynomial time reasoning for schema and data

I Useful for ontologies with large conceptual part

I QL: fast (logspace) query answering using RDBMs via SQLI Useful for large datasets already stored in RDBs

I RL: fast (polynomial) query answering using rule-extendedDBs

I Useful for large datasets stored as RDF triples

I OWL 2 RL is A (near maximal) fragment of OWL 2 suchthat

I Can be implemented using standard rule enginesI Closely related to Description Logic Programms (DLP)I No existentials on RHS

19


OWL 2RLOWL profile that resembles an OWL-based rule language:I Intuition: subclass axioms in OWL RL can be understood as rule-like

implications with head (superclass) and body (subclass)

I Different restrictions on subclasses and superclasses:

I subclasses can only be class names, nominals,conjunctsions, disjunctions, existentials if applied only tosubclass-type expressions

I superclasses can be class names, universals or nominals;also max. cardinalities of 0 or 1 are allowed, all withsuperclass-type filler expressions only

I Property domains and ranges only for subclass-type expressions; propertyhierarchies, disjointness, inverses, (a)symmetry, transitivity, chains,(inverse)functionality, irreflexivity fully supported

I Disjoint classes and classes in keys need subclass-type expressions, equivalenceonly 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 EXAMPLES

I ∃parentOf. ∃parentOf.> v Grandfatherrule version: parentOf(x,y) ∧ parentOf(y,z)→ Grandfather(x)

I Orphan v ∀ hasParent.Deadrule version: Orphan(x) ∧ hasParent(x,y)→ Dead(y)

I Monogamous v ≤ 1 married.Aliverule version:Monogamous(x) ∧married(x,y) ∧ Alive(y) ∧married(x,z) ∧ Alive(z)→ y = z

I childOf o childOf v grandchildOfrule 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


REASONING WITH LARGE ONTOLOGIES

I Reasoners determine class hierarchy and allow domainexperts to check (TBox Reasoning) if, e.g.:

I classes are consistent (no obvious errors)I expected subsumptions hold (consistent with intuitions)I unexpected equivalences hold (unintended synonyms)

I ABox ReasoningI consistency checkingI main reasoning problem is (conjunctive) query answering

Eg:

(x , z )←Wine(x ) ∧ drinkWith(x , y) ∧Dish(y) ∧ fromRegion(y , z )

22


REASONING WITH LARGE ONTOLOGIES

I What about scalability?I Reasoning often requires us to deal with large ontologies (#

assertions/#axioms/#classes and properties)I Data/Query intensive applications e.g., Healthcare

systems, use ontologies with large ABoxes.

Figure: DL Reasoners

I Existing DL reasoners perform in-memory reasoning

I Cannot handle ontologies with large ABoxes.

24


SCALABLE APPROACHES

I Database Integration Approach : DL− LiteI Maximal tractable subset of OWL 1 DL that can be handled

using RDBMSI Express ontology as conceptual models such as UML class

diagrams and ER diagramsI Simple rewriting mechanism

I rewriting the query into an SQL query that is then answeredby the RDBMS system

I Logic Programming-based Approach: DLPI Translate ontologies into logic programsI Reuse existing efficient and faster inference algorithmsI We use the forward-chaining method for inferencing.

25


GOAL

I Goal: A scalable reasoner that supports OWL 2 RLprofile.

26


OWLONTDB: A SCALABLE REASONING SYSTEM FOR OWL 2 RL ONTOLOGIES

27


TRANSLATION: OWL 2 RL – TO – DATALOG

I Express inference tasks for the OWL 2 RL ontology interms of inference tasks for datalog.

I Datalog is a simple rule language stemming from Prolog.

I Extend an existing DLP mapping to accommodate thenew features of OWL 2 RL.

I Translate the inferred ontology to a datalog programsusing the extended DLP mapping.

28


TRANSLATION: OWL 2 RL – TO – DATALOG

OWL 2 RL Axioms DL Syntax Datalog RuleClassAssertions a : C C(a)PropertyAssertion 〈a, b〉 : P P (a, b)SubClassOf C v D C(x)→ D(x)ObjectPropertyChain P ◦Q v 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+ v P P (x, y) ∧ P (y, z)→ P (x, z)SymmetricObjectProperty P ≡ P− P (x, y)→ P (y, x)Object/DataUnionOf C1 t C2 v D C1(x)→ D(x), C2(x)→ D(x)Object/DataIntersectionOf C v D1 uD2 C(x)→ D1(x),C(x)→ D2(x)Object/DataSomeValuesFrom ∃P.C v D P (x, y) ∧ C(y)→ D(x)Object/DataAllValuesFrom C v ∀P.D C(x) ∧ P (x, y)→ D(y)Object/DataPropertyDomain > v ∀P−.C P (y, x)→ C(y)Object/DataPropertyRange > v ∀P.C P (x, y)→ C(y)

29


ABOX CONSISTENCY CHECKING

I Restrictions Checker: checks whether the ABox isconsistent with respect to the TBox.

FunctionalProperty InverseFunctionalProperty> v6 1 P > v6 1 P−

FunctionalObjectProperty(P ) InverseFunctionalObjectProperty(P )Irreflexive Asymmetric∃ P.self v ⊥ P v ¬P−IrreflexiveObjectProperty(P ) AsymmetricObjectProperty(P )MinimumCardinality (0/1) MaximumCardinality(0/1)> nP.C 6 nP.CObjectMinCardinality(n P C) ObjectMaxCardinality(n P C)

I Example :I a TBox axiomIrreflexiveObjectProperty(marriedTo)

I an ABox assertion: marriedTo(Bob,Bob)

30


MATERIALIZATION

I Materialization is an approach of inferring and storingimplicit knowledge from an ontology using adatabase-driven kind of forward chaining rather than anin-memory forward chaining

I Each datalog fact and rule is translated to an SQLstatement

I The asserted and inferred knowledge is stored in arelational database to be used for querying

I Two approaches to insert facts into relational databasesI Direct Mapping: one table for each predicateI Meta Mapping:

I ClassAssertion − > TypeOf,I ObjectProperty − > RelationshipObj,I DataProperty − > RelationshipData

31


DATALOG 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


DATALOG TO SQL – EXAMPLE

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’’, IndFROM TypeOf WHERE Class == ‘‘Woman’’

(4) INSERT INTO TypeOf(Class, Individual) SELECT ‘‘Parent’’, r.ObjectFROM TypeOf t, RelationshipObj r WHERE r.Predicate == ‘‘hasChild’’

AND t.Class == ‘‘Person’’ AND t.Individual == r.Object

33


Given the fact Mother(Mary), the two rulesMother(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


I The TypeOf table has two columns: Class and Ind – itstores all the individuals of every class.

I Using the second SQL statement, the algorithm first selectsall the individuals of the class ”Mother”, then it insertsthese individuals as individuals of ”Parent”.

I We provided the class name ”Parent” in the projector list, sothe algorithm will insert all the selected individuals in theTypeOf table, this time as individuals of the Parent class.

I Using the third SQL statement, the algorithm selects allindividuals of the class Parent and inserts theseindividuals as individuals of the class Person.

I Since Mary was in the class Mother, Mary will also be inthe class Parent and Person.

35


A FRAGMENT OF THE DATABASE SCHEMA

36


QUERY PROCESSINGI The SPARQL-DL API

I is fully aligned with OWL 2.I interacts with main-memory-based reasoners.

I We modified the SPARQL-DL API to extract knowledgefrom the relational database

I We modified following required interfaces:I allC(O), allDP (O), allOP (O), allI(O) return all classes,

data properties, object properties, and individualsrespectively defined in O.

I subC(O, C), supC(O, C), eqC(O, C) return all sub classes,super classes, and equivalent classes respectively of class Cin O.

I 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, subdata properties, super data properties, and equivalent dataproperties respectively of properties p in O.

I en(O, q) checks whether O � q for a SPARQL-DLE atom q.37


QUERY PROCESSING – BENCHMARK ONTOLOGIES

I The LUBM benchmark ontologyI An ontology about organizational structures of universities.I Developed at the Lehigh University for testing performance

of ontology management and reasoning systemsI Provides a data generator. We use two datasets: lubm1, and

lubm100

I Contains Object and Data property, inverseOf, transitiveproperty and existential quantification

I The wine ontologyI Contains a classification of wine.

I Contains functional roles, disjunctions, and existentialquantifiers.

I We used two datasets :I wine1 - the original wine ontology.I wine5 - which they synthetically generated by replicating 2n

times the ABox of wine1..

38


QUERY PROCESSING – LUBM AND WINE ONTOLOGIES

I (LQ1) Find all the students who are employees and returntheir 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) }

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

I (WQ1) Determine all the instances of “AmericanWine”.

PREFIX wine: <http://www.w3.org/TR/2003/wine#>SELECT ?i WHERE { Type(?i, wine:AmericanWine) }

I (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


RESULTS AND DISCUSSIONS

Ontology C v D Functional Domain Range R v S C(a) P (a, b)

wine1 126 6 6 9 9 247 246wine5 126 6 6 9 9 2717 2706lubm1 36 0 25 18 9 20659 82415lubm100 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


RESULT AND DISCUSSIONS

Dataset Reasoner LQ1 LQ2

lubm1 Pellet 129.02 s 127.06 slubm1 OwlOntDB 3.43s 0.79 slubm100 Pellet 142.80 s 127.66 slubm100 OwlOntDB 29.07 s 1.0 s

Dataset Reasoner WQ1 WQ2

wine1 Pellet 2.95 s 2.98 swine1 OwlOntDB 0.047 s 0.11 swine5 Pellet 363.089 s 363.59 swine5 OwlOntDB 0.3435 s 1.171 s

Table: A comparison of query answering times.

41


CANCER PAIN MANAGEMENT GUIDELINESComplete pain assessment

and care plan

Currently on

regular opioidPain intensityOn weak opioid with

go to Strong Opioid Regimen

moderate-severe pain

Backgound

Discomfort (0− 1)Mild pain

(2− 3)

Moderate

Pain (4− 6)

Severe

Pain (7− 10)

Non Opioid

Regimen

If pain is notstable may startwith weak opioid

If pain is notstable may startwith weak opioid

Weak Opioid

RegimenNo response

Strong Opioid

RegimenNo response

Opioid

MaintenanceResponseYesPain

Intensity

No

Mild pain

(2− 3)

Moderate

Pain (4− 6)

Severe

Pain (7− 10)

Dose titration of opioid

For mild pain: Consider increasing dose by 10% q4h ATCReassess at least every 48− 72 hours

For moderate pain: Increase dose by 10− 25% q4h ATCReassess at least every 24 hours

For severe pain: Increase dose by 25− 50% q4h ATCReassess at least every 12 hours

reassess at

appropriate

intervals

Appropriate

dose and

ResponseSide

effect

Continuedose titration

No

Yes

No

Yes

No

Yes

Management

of side effect

Yes No

42


THE CANCER PAIN MANAGEMENT (PM) ONTOLOGY

43


THE CANCER PAIN MANAGEMENT (PM) ONTOLOGYI We use the pain management ontologythat includes the

terminology and concepts of health and medicineI used in the Guysborough Antigonish Strait Health

Authority (GASHA)I from SNOMED-CT, ICNP, and the guidelines for cancer

pain treatment.

I This ontology includesI several classes including Pain, Person, Patient,PainIntensityType, SpecialPainProblem,SideEffects;

I some object properties including hasPainIntensity,Domain:Pain, Range:PainIntensityType,

I data properties including hasPainLevel, Domain :Pain,Range:xsd:int,

I inverse object properties such as isFeeling andisFeltBy,

I functional object properties including hasPainLevel, i.e.,each pain level belongs to an instance of Pain class.

I We also use propositional connectives to create complexclass expressions (e.g., persons who feel pain are patients,in DL Person u ∃isFeeling .Pain v Patient).

44


QUERY PROCESSING – THE PM ONTOLOGY

I Determine the medication information of all the patientswho 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) }

I Find names of the relatives of all the patients who serve asinformal 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


RESULTS AND DISCUSSIONS

PM250 PM500 PM1000 PM2000 PM3000

No. of Axioms 20344 40396 77600 156308 231555Time (sec.) 20.71 45.94 90.34 263.24 345.28

Table: Time required for materialization

Q1 Q2

Pellet OwlOntDB Pellet OwlOntDBPM250 41.65 7.53 65.85 9.79PM500 91.83 11.71 127.038 14.89PM1000 179.50 16.89 259.678 19.01PM2000 718.18 20.78 959.32 23.21PM3000 - 29.21 - 34.01

Table: A comparison of query answering times (in seconds). “-”means that the reasoner failed to return the result.

46


CONCLUSION

I OwlOntDBI supports OWL 2 RL- an expressive fragment of OWL

I can handle ontologies with a large numbers of instances

I suitable for

I decision support systems that need faster query responsesI query intensive applicationsI applications where updates are less frequent

47


LIMITATIONS AND FUTURE DIRECTIONS

I Initial Processing time / Materialization time is very highI Parallel and distributed computing

I Consequence-based classification

I Update Problem: Re-materialize the whole ontologyI Incremental Materialization

I Extend ontology to deal with time and develop efficientreasoners.

48


CONTRIBUTIONS

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

I Developed a materialized algorithm that performs aforward chaining over a datalog program, then translatesthe resulting program to a set of SQL statements.

I Modified an existing SPAQRL-DL API

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

49


Thanks

50


SYNTAX AND SEMANTICS OF SROIQ CONSTRUCTORS

Constructor Syntax Semantics

Top > ∆I

Bottom ⊥ ∅Conjunction C uD CI ∩DI ALCDisjunction C tD CI ∪DI

Negation ¬C ∆I \DIExist Restriction ∃ R.C {a ∈ ∆I |∃b((a, b) ∈ RI and b ∈ CI)}Value Restriction ∀ R.C {a ∈ ∆I |∀b((a, b) ∈ RI implies b ∈ CI)}Transitive Role R+ (a, b) ∈ RI and (b, c) ∈ RI implies (a, c) ∈ RI R+

ALCR+= S

Role Inclusion R v S RI ⊆ SI HComposite Role R ◦ S {(a, c) ∈ ∆I ×∆I |∃b((a, b) ∈ RI and (b, c) ∈ SI)}Role Chain R1 ◦ . . . ◦Rn v S RI1 ◦ . . . ◦RIn ⊆ SI RNominal {o} {oI} OInverse Role R− {(a, b)|(b, a) ∈ RI} INumber > n R {a ∈ ∆I |#{b ∈ ∆I |(a, b) ∈ RI} > n}Restriction 6 n R {a ∈ ∆I |#{b ∈ ∆I |(a, b) ∈ RI} 6 n} NQualified Number > n R.C {a ∈ ∆I |#{b ∈ ∆I |(a, b) ∈ RI and b ∈ CI} > n}Restriction 6 n R.C {a ∈ ∆I |#{b ∈ ∆I |(a, b) ∈ RI and b ∈ CI} 6 n} QFunctional > 1 R and {a ∈ ∆I |#{b ∈ ∆I |(a, b) ∈ RI} > 1} andRole < 2 R {a ∈ ∆I |#{b ∈ ∆I |(a, b) ∈ RI} < 2} FReflexive Role Reflexive(R) a ∈ ∆I implies (a, a) ∈ RI

Irreflexive Role Irreflexive(R) a ∈ ∆I implies (a, a) /∈ RI

Symmetric Role Symmetric(R) (a, b) ∈ RI implies (b, a) ∈ RI

Asymmetric Role Asymmetric(R) (a, b) ∈ RI implies (b, a) /∈ RI

Disjoint Roles Disjoint(R1, . . . Rn) RIj ∩RIk is empty for each i ≤ j, k ≤ n and j 6= k

51

owlontdb: a scalable reasoning system for owl 2 rl ontologies with large aboxes

Education