Integrating ObjectOriented and Ontological Representations: A Case Study in Java and OWL

1
IntegratingObject-Oriented and Ontological
RepresentationsA Case Study in Java and OWL

• Colin Puleston, Bijan Parsia
• James Cunningham, Alan Rector
• University of Manchester

2
Overview

• Software Models
• i.e. Domain models accessible by software
• Summary of existing approaches
• Hybrid Models
• i.e. Software models integrating
• Object-oriented representation
• Ontological representation
• Case study Patient Chronicle Model

3
The Problem

• Building programs that are sensitive
• to large amounts of domain knowledge
• which may change
• and is generated by a variety of people
• such that
• the domain model is maintainable
• the domain model is salient
• the programs are maintainable

4
Software Models
5
Software Models

• What are they?
• Domain models
• Accessible via an OOPL API
• Standard OOPL Java, C, etc.
• (Assume Java for concreteness)
• Specify, minimally
• Concept hierarchies
• Sets of fields associated with concepts
• Constraints associated with fields
• What are they for?
• Domain-aware applications
• Common format for data storage/manipulation
• Domain-neutral applications
• Domain knowledge to drive/configure software

6
Simple Software Model
Problem
Locus
Pathology
Organ
Key
ltnamegt
Model concept
Breast
Neoplasia
Sub-concept relationship
Cancer
Stage
SubStage
Occult
S-1
S-4
S-3
S-2
SS-A
SS-C
SS-B
7
Simple Software Model
Problem
locus
Locus
Pathology
Organ
Key
ltnamegt
Model concept
Breast
Neoplasia
Sub-concept relationship
ltnamegt
Model field
Cancer
subStage
stage
Stage
SubStage
Occult
S-1
S-4
S-3
S-2
SS-A
SS-C
SS-B
8
Simple Software Model
day
Integer
Problem
timePoint
locus
month
Locus
TimePoint
Integer
year
Integer
Pathology
Organ
Key
ltnamegt
Model concept
Breast
Neoplasia
Sub-concept relationship
ltnamegt
Model field
Cancer
subStage
stage
lttypegt
Data-type
Stage
SubStage
Occult
S-1
S-4
S-3
S-2
SS-A
SS-C
SS-B
9
Model-Based Software
GUIs (Domain-Neutral)
Record Browser
Model Browser
Query Formulator
Data-Creation Tools (Domain-Aware)
Patient Chronicle Simulator
Patient Chronicle Model
Patient Record Chronicliser
Storage Manager
Query Engine
Temporal Abstraction Extension
EHR Store
RDF Store
Data-Storage/Query System (Domain-Neutral)
10
Direct Models
Cancer
locus
timePoint
stage
subStage
Breast
TimePoint
Stage2
SubStageB
Instantiates
Java API is the model...
Key
ltclass-namegt
Java object
Java API
ltfield-namegt
Field on Java object
11
Indirect Models
Java API provides indirect access to external
backing model
instanceType
ModelInstance
Configured by
via a small set of domain-neutral classes
Many possible backing-model formats e.g. OWL,
UML, core Protégé, etc.
Backing Model
12
Indirect Models
Client Action instanceType set to Cancer
Cancer
instanceType
ModelInstance
locus
timePoint
stage
subStage
Locus
TimePoint
Stage
SubStage
Key (continued)
Response Set of dynamic fields created -
derived from Cancer concept
ltconcept-namegt
Reference to backing-model concept
ltconcept-namegt
Reference to instance of backing-model concept
Dynamic field - derived from backing-model
ltfield-namegt
13
Indirect Models Programmers View
name
ModelConcept
Cancer
instanceType
ModelInstance
dynamicFields
name
name
ModelField
locus
ModelField
timePoint
constraints
constraints
Dynamic fields represented via array of
ModelField objects with appropriate
constraints (field-type, root-concept, etc.)
Backing-model concepts referenced via
ModelConcept objects
14
Direct Models
Y
21
T
Z
C
B
G
A
F
U
E
9
V
D
74
W
X
A, B, , Z Instances of domain-specific classes
15
Indirect Models Programmers View
C
21
C
C
F
F
I
F
F
F
I
F
F
I
F
I
F
I
F
F
F
F
F
I
C
F
9
I
C
F
F
F
F
74
C
C
F ModelConcept I ModelInstance F
ModelField
16
Indirect Models Conceptual View
Y
21
T
Z
C
B
G
A
F
U
E
9
V
D
74
W
X
17
Software Models

• Direct
• Java API is the Model
• Conceptual view and programmers view are
  identical
• Indirect
• Java API provides indirect access to external
  backing-model
• Conceptual view and programmers view diverge

18
Static Indirect Models
Cannot represent complex constraints, e.g.
cancer-staging
Cancer
instanceType
ModelInstance
locus
timePoint
stage
subStage
Locus
TimePoint
Stage
SubStage
Breast-Cancer Sub-Stages Stage-1 NONE Stage-2
A, B Stage-3 A , B , C etc
Cancer Stages Breast Cancer 1, 2, 3, 4 Lung
Cancer Occult, 1, 2, 3, 4 etc
19
Dynamic Indirect Models
Client Action instanceType set to Cancer
Cancer
instanceType
ModelInstance
locus
timePoint
stage
Locus
TimePoint
Stage
Response Set of dynamic fields created - derived
from Cancer concept does not include subStage
20
Dynamic Indirect Models
Client Action locus updated from default value
(Locus) to Breast
Cancer
instanceType
ModelInstance
locus
timePoint
stage
Breast
BCstage
TimePoint
Response stage constraints updated accordingly
Note BCstage BreastCancerstage
(Stage1Stage2...)
21
Dynamic Indirect Models
Client Action stage updated from default value
(Stage) to Stage2
Cancer
instanceType
ModelInstance
locus
timePoint
stage
subStage
Breast
Stage2
S2BCsubStage
TimePoint
Response subStage field created - with
appropriate constraints
Note S2BCsubStage Stage2BreastCancersubStage
(SubStageASubStageB)
22
Indirect Models

• Static
• Model is fixed regardless of state of individual
  instantiation
• Dynamic
• Model evolves as state of individual
  instantiation develops

Applies to both model-shape (i.e. composition
of field-sets) and individual field-constraints
23
Dynamic Ontology-Backed Models
instanceType
ModelInstance
Configured by
Sanctioning Module
Description Logic (DL) Reasoner
OWL Ontology
24
Dynamic Ontology-Backed Models
Sanctioning DL ontologies do not provide
fields hence, sanctioning uses heuristics or
meta-data ...to associate sets of fields (and
appropriate constraints) with DL classes
Sanctioning Module
Description Logic (DL) Reasoner
OWL Ontology
25
Dynamic Ontology-Backed Models
OWL instance created for each ModelInstancedrives
dynamic updating
Cancer
instanceType
ModelInstance
locus
timePoint
stage
Stage2
TimePoint
Locus
Backing-Model (OWL Ontology DL Reasoner
Sanctioning)
Breast Cancer
Stage2 BreastCancer
Cancer
Instance XYZ
26
Dynamic Ontology-Backed Models
Client Action locus updated from default value
to Breast
Cancer
instanceType
ModelInstance
locus
timePoint
stage
Stage2
TimePoint
Breast
Backing-Model (OWL Ontology DL Reasoner
Sanctioning)
Breast Cancer
Stage2 BreastCancer
Cancer
Instance XYZ
27
Dynamic Ontology-Backed Models
Response (Backing-Model) OWL Instance
reclassified from Cancer to Stage2BreastCancer
Cancer
instanceType
ModelInstance
locus
timePoint
stage
Stage2
TimePoint
Breast
Backing-Model (OWL Ontology DL Reasoner
Sanctioning)
Breast Cancer
Stage2 BreastCancer
Cancer
Instance XYZ
28
Dynamic Ontology-Backed Models
Response (Software-Model) subStage field
createdderived from Stage2BreastCancer concept
Cancer
instanceType
ModelInstance
locus
timePoint
stage
subStage
Stage2
TimePoint
Breast
S2BCsubStage
Backing-Model (OWL Ontology DL Reasoner
Sanctioning)
Breast Cancer
Stage2 BreastCancer
Cancer
Instance XYZ
29
Direct vs. Ontology-Backed Models
Ontology-backed
Direct
Feature
Dynamic model-shape updating
ontological
YES
NO
other
NO
NO
Dynamic field-constraint updating
ontological
YES
NO
other
NO
YES
YES
YES?
Domain-neutral API
NO
YES
Domain-specific API
Instantiation processing
NO
YES
K.E. by domain experts
YES
NO
Knowledge encapsulation
YES
NO
YES Straightforward, NO Not possible/not
practical, YES? Practical proposition - but
less straightforward
30
Dynamic Model Updating
Ontology-backed
Direct
Feature
Dynamic model-shape updating
ontological
YES
NO
other
NO
NO
Dynamic field-constraint updating
ontological
YES
NO
other
NO
YES
Benefits Enables imposition of sensible
constraints (on client code/user-input) Direct
models No model-shape updating - no ontological
reasoning (?) Ontology-backed models Only via
ontological reasoning (?)
31
Domain-Neutral API
Ontology-backed
Direct
Feature
YES
YES?
Domain-neutral API

• Benefits Necessary for driving domain-neutral
  client code
• Direct models Requires combination of
• Appropriate coding conventions
• Additional reflection based mechanism
• Ontology-backed models Natural feature of
  indirect models

32
Domain-Specific API
Ontology-backed
Direct
Feature
NO
YES
Domain-specific API
Benefits Natural way to produce domain-specific
client code Direct models Natural
feature Ontology-backed models Could
auto-generate, but would lose dynamic updating
33
Instantiation Processing
Ontology-backed
Direct
Feature
Instantiation processing
NO
YES

• Benefits Attachment of code to operate over
  concept instantiations (OO-style)
• Direct models Natural feature
• Ontology-backed models Would
• Require ad-hoc mechanisms
• Lead to unnatural coding process

34
Knowledge Engineering by Domain Experts
Ontology-backed
Direct
Feature
K.E. by domain experts
YES
NO

• Benefits Potential improvement in productivity
  and quality of model
• Direct models Would require ad-hoc KE tools
• Ontology-backed models Backing-model is
  suitable, since
• Declarative format
• Comes with suitable GUI-based KE tools

35
Knowledge Encapsulation
Ontology-backed
Direct
Feature
Knowledge encapsulation
YES
NO
Advantages Allows plug-and-play and
mix-and-match of alternative backing-model
formats Direct models Not possible Ontology-backe
d models Natural feature of indirect models
36
Hybrid Models
37
Hybrid Models

• Integrating
• Direct approach
• Dynamic ontology-backed approach
• Case Study
• Patient Chronicle Model (PCM)
• PCM-Style hybrid models
• Generic model-building framework

38
Direct Models
Cancer
locus
timePoint
stage
subStage
Breast
TimePoint
Stage2
SubStageB
Domain-specific Java classes and
fields identical to concepts and fields of
domain model
39
Indirect Models
Cancer
instanceType
ModelInstance
locus
timePoint
stage
subStage
TimePoint
Breast
Stage2
SubStageB
Domain-neutral Java classes configured by
concepts and fields of backing-model
40
PCM-Style Hybrid Models
Cancer
problemType
ProblemGlimpse
locus
timePoint
stage
subStage
Breast
TimePoint
Stage2
SubStageB
Domain-specific Java classes and
fields representing reasonably generic domain
entities configured by concepts and fields of
backing-model
41
PCM-Style Hybrid Models

• Core Structure
• Directly represented
• Typically
• Very general classes
• Relatively small numbers - 10s rather that 100s
  or 1000s
• Shallow hierarchies
• Richly interconnected

C
B
A
F
E
D

• Example Classes
• TimePoint, TimePeriod
• ProblemGlimpse, ClinicalRegime

• Example Fields
• timePoint, locus
• indication, target

42
PCM-Style Hybrid Models

• Detailed Knowledge
• Peripheral parts of model
• Indirectly represented
• Typically
• 100s or 1000s of concepts
• Deeper hierarchies
• Fewer interconnections

• Example Concepts
• ProblemType, Cancer, Pain
• Locus, Breast, Lung

• Example Fields
• stage, subStage
• tumourSize

43
PCM-Style Hybrid Models

• Interaction
• Orchestrated by main software classes (e.g.
  ProblemGlimpse)
• Based on
• Ontological inference
• Non-ontological inference/manipulation
• Handful of mapped entities
• Fields (e.g. problemType)
• Root-concepts (e.g. ProblemType)
• Inter-field constraints (e.g. locus constrained
  by problemType)
• (All mappings specified externally)

44
GLIMPSE Temporal Representation
Cancer
problemType
ProblemGlimpse
locus
timePoint
stage
subStage
Breast
TimePoint
Stage2
SubStageB
Simple one-to-one correspondence between
ProblemGlimpse object and instance associated
with backing-model
OWL Instance 0001
45
SNAP/SPAN Temporal Representation
ProblemHistory object (SPAN) representing history
of a cancer
aggregating together set of ProblemSnapshot
objects (SNAPs) - each representing the cancer at
a specific point-in-time
Cancer
Breast
problemType
locus
ProblemHistory
snapshots
Problem Snapshot
Problem Snapshot
Problem Snapshot
subStage
stage
stage
stage
SubStageA
Stage3
Stage1
Stage1
46
SNAP/SPAN Temporal Representation
ProblemHistory orchestrates more complex
interaction
involving multiple backing-model instances...
Cancer
Breast
problemType
locus
ProblemHistory
snapshots
Problem Snapshot
Problem Snapshot
Problem Snapshot
subStage
stage
stage
stage
SubStageA
Stage3
Stage1
Stage1
47
SNAP/SPAN Temporal Representation
OWL Instance 0001
Cancer
Breast
problemType
locus
ProblemHistory
snapshots
Problem Snapshot
Problem Snapshot
Problem Snapshot
subStage
stage
stage
stage
SubStageA
Stage3
Stage1
Stage1
48
SNAP/SPAN Temporal Representation
OWL Instance 0002
Cancer
Breast
problemType
locus
ProblemHistory
snapshots
Problem Snapshot
Problem Snapshot
Problem Snapshot
subStage
stage
stage
stage
SubStageA
Stage3
Stage1
Stage1
49
SNAP/SPAN Temporal Representation
OWL Instance 0003
Cancer
Breast
problemType
locus
ProblemHistory
snapshots
Problem Snapshot
Problem Snapshot
Problem Snapshot
subStage
stage
stage
stage
SubStageA
Stage3
Stage1
Stage1
50
Temporal Abstraction
Summaries-over-time of temporally variable
properties
Stage1
Stage3
Stage1
Stage3
min
max
end
start
Cancer
Breast
TemporalAbstractions
problemType
locus
stage
ProblemHistory
snapshots
Problem Snapshot
Problem Snapshot
Key (continued)
stage
stage
Dynamic field derived from Temporal Abstraction
System
ltfield-namegt
Stage1
Stage1
51
Temporal Slicing
Mechanism that operates on instantiations of
SNAP/SPAN models
4
12
4
19
15
start
end
min
max
range
X
Y
TemporalAbstractions
Z
X
Y
TemporalAbstractions
Z
p
x
y
z
SPAN
SPAN
SNAP
SNAP
SNAP
SNAP
SNAP
p
p
p
p
p
q
q
A
4
B
6
19
18
12
slices-up SNAP/SPAN complexes in order to
represent arbitrary sub-periods
52
Temporal Slicing
1) Required slice specified
4
12
4
19
15
start
end
min
max
range
X
Y
TemporalAbstractions
Z
X
Y
TemporalAbstractions
Z
p
x
y
z
SPAN
SPAN
SNAP
SNAP
SNAP
SNAP
SNAP
p
p
p
p
p
q
q
A
4
B
6
19
18
12
Time (SNAPs)
53
Temporal Slicing
2) Copy made of SPAN object plus relevant subset
of SNAP objects
X
Y
Z
X
Y
Z
x
y
z
SPAN
SPAN
SNAP
SNAP
SNAP
SNAP
SNAP
p
p
p
q
q
p
p
A
19
18
B
12
6
4
Time (SNAPs)
54
Temporal Slicing
3) New limit-point SNAP objects interpolated
X
Y
Z
X
Y
Z
x
y
z
SPAN
SPAN
SNAP
SNAP
SNAP
SNAP
SNAP
p
p
q
p
q
p
p
B
12
4
A
19
18
6
SNAP
SNAP
q
p
p
B
14
10
55
Temporal Slicing
10
14
10
19
9
start
end
min
max
range
X
Y
TemporalAbstractions
Z
X
Y
TemporalAbstractions
Z
p
x
y
z
SPAN
SPAN
SNAP
SNAP
SNAP
SNAP
p
p
q
q
p
p
A
19
18
10
A
14
4) New temporal-abstractions (abstraction-sets
values) obtained from Temporal Abstraction System
56
Temporal Slicing
Used by chronicle query mechanism
10
14
10
19
9
start
end
min
max
range
X
Y
TemporalAbstractions
Z
X
Y
TemporalAbstractions
Z
p
x
y
z
SPAN
SPAN
SNAP
SNAP
SNAP
SNAP
A
19
18
10
A
14
e.g. comparison of tumour size during first and
second weeks of chemotherapy
to derive dynamically specified abstractions
57
Model Translation
Translation between hybrid format and
fully-indirect format maintaining all dynamic
interaction (Provided by of generic framework)
Y
21
Z
C
B
A
F
E
9
D
74
Y
W
X
21
Z
C

• Based on
• Coding conventions
• Java reflection
• Specification of dynamic interaction by
  individual classes (where appropriate)

B
A
F
E
9
D
74
W
X
58
Query Formulation

• Based on
• Model-translation mechanism
• Generic query-formulation extension (using
  model-realisation plug-in facility)

?p
D
gt ?p
A
C
Z
OR
B
OR
NOT
Y

• Query-specific extensions
• Logical operators
• Data-value variables
• Data-value constraints
• Temporal-abstractions over dynamically specified
  time-periods (not shown)

E
X
F
lt (?p ?q) / 2
?q
59
Hybrid vs. Other Model Types
Ontology-Backed
Direct
Hybrid (PCM-style)
Feature
ontological
YES
NO
YES
Dynamic model-shape updating
other
NO
NO
YES
ontological
YES
NO
YES
Dynamic field-constraint updating
other
NO
YES
YES
YES
YES?
YES
Domain-neutral API
NO
YES
YES cs
Domain-specific API
Instantiation processing
NO
YES
YES cs
K.E. by domain experts
YES
NO
YES dk
Knowledge encapsulation
YES
NO
YES dk
cs core structure only dk detailed
knowledge only (In each case, feature is
supported where most required)
60
Hybrid Model Building Framework
Patient Chronicle Model
Chronicle Model-Builder
Core Model-Builder
Backing-Model Access System
OWL Access
Protégé Access
FaCT
61
Hybrid Model Building Framework
Domain Model Provides core structure of domain
representation Based on structures and
mechanisms provided by the generic model-builders
Patient Chronicle Model
Chronicle Model-Builder
Core Model-Builder
Backing-Model Access System
OWL Access
Protégé Access
FaCT
62
Hybrid Model Building Framework
Patient Chronicle Model
Chronicle Model-Builder Provides core
chronicle-style SNAP/SPAN representation intera
ction with Temporal Abstraction System and
chronicle-specific mechanisms interaction-patterns
Chronicle Model-Builder
Core Model-Builder
Backing-Model Access System
OWL Access
Protégé Access
FaCT
63
Hybrid Model Building Framework
Patient Chronicle Model
Chronicle Model-Builder
Core Model-Builder Provides generic
hybrid-modelling structures interaction with
backing-model skeleton interaction
patterns model-format translation
Core Model-Builder
Backing-Model Access System
OWL Access
Protégé Access
FaCT
64
Hybrid Model Building Framework
Patient Chronicle Model
Chronicle Model-Builder
Backing-Model Access System Mediates all
backing-model access Software-model has no
knowledge of any backing-model format and no
prior knowledge of any backing-model
contents (All necessary mappings provided via
configuration file)
Core Model-Builder
Backing-Model Access System
OWL Access
Protégé Access
FaCT
65
Conclusion

• Direct vs. Dynamic Ontology-Backed Models
• Both have pros and cons
• Neither can meet all potential requirements
• Hybrid Models
• Can offer best of both worlds
• (where appropriate - not always the case!)
• Potentially wider application, well beyond
  Patient Chronicle Model, for both
• General hybrid approach
• Generic model-building framework