Review of OWL for Review of OWL for BiomedicineBiomedicineAlan Rector & CO-ODE/NIBHI
University of Manchester
Open GALEN
BioHealthInformaticsGroup
© University of Manchester
© University of Manchester 2
OWL: What is it?OWL: What is it? What is it good for? What is it good for?
► What is it► A current standard for using description logics
► Part of the Semantic Web technologies
► What’s is good for► Describing, indexing, reorganising - Conceptual coatrack
Model driven architecture
►Terminologies, fragments, models, forms,
► Combining, Factoring and Assembling - Conceptual Lego
►Forms, guidelines, messages
►Not the whole solution but a key component
► Maintaining consistency across change - Conceptual Insurance
►The “one change - one place” principle
►Smooth evolution
► Containing the combinatorial explosion - Conceptual Invervse Tardis
© University of Manchester 3
Logic-based Ontologies: Logic-based Ontologies: Conceptual LegoConceptual Lego
hand
extremity
body
acute
chronic
abnormalnormal
ischaemicdeletion
RadiographMRI
Echo
Skull
Contrast
infectioninflammation
Lung
Opacity
© University of Manchester 4
Logic-based Ontologies: Logic-based Ontologies: Conceptual LegoConceptual LegoLogic-based Ontologies: Logic-based Ontologies: Conceptual LegoConceptual Lego
“Pneumonia of Left lower lobe of Lung on basis of Opacity in Chest X-Ray in PA-Lateral position status Improving …”
“Hand which isanatomically normal”
© University of Manchester 5
Logical Constructs Logical Constructs build complex build complex concepts from concepts from modularisedmodularisedprimitivesprimitives
AnatomyConditions
Signs
Modalities
Techniques
Pneumonia of RML signified by opacity
Pneumonia of RMLsignified by opacity on CXR
Pneumoonia of RML signified by opacity on CXR in PA-Lat position
Pneumonia of RML
© University of Manchester 6
ThreeThreeResourcesResources
reusable reference information resources
Metadata
MetadataMetadata
interface
interface
interface
Concept System Model(‘Ontology’)
Information Model(EHR Model,Archetypes)
Inference Model(Guideline Model)
‘Contingent’ Domain Knowledge
General Domain Knowledge
Individual Patient Records
► Each with► Model
► Knowledge/ content
► Metadata
► Interfaces tothe others
© University of Manchester 7
Separation incorporated in the GALEN Server
A single point of access for language, classification, code conversion, and indexing - well separated internally
API
Reference Management Multilingual Dictionaries
MultilingualModule
Common Reference Model
ConceptModule
Code Store
Code ConversionModule
ClientApplication
Server
Client
Extrinsics Store
IndexingModule
© University of Manchester 8
OWL as the core of Ontology OWL as the core of Ontology Indexed Reusable Resources Indexed Reusable Resources
Data store
on Individuals
Data
Contingent
Knowledge Rule base & decision Support
Prototypical
Knowledge
ReferenceKnowledgebase
Definitionalknowledge “Ontology”
Meta Data
Annotation
Linguistic knowledge
© University of Manchester 9
DLs/OWL as the coreDLs/OWL as the core
► The model of meaning
► The index to the model of use
► A guarantor of soundness
► A compact & parsimonious representation of complex spaces
© University of Manchester 10
A specific approach to OWL A specific approach to OWL ontologiesontologies
► “Normalised” & modular► Existential graphs starting from disjoint trees
► Use of definitions and classifier to compose trees
► All changes in exactly one place
► Using our standard upper ontology► Properties more important than classes
► Testing as an integral part of ontology engineering► Debugging when tests fail
► The “Model of meaning”► Model of use to be discussed later
► An “Assembly language view”► We don’t expect most developers to know this much
►Specialised interfaces and “Intermediate Representations” for everyday use
© University of Manchester 11
OWL itself: Key pointsOWL itself: Key points
► Existential vs Universal Restrictions
► Definitions (Necessary & Sufficient) vsDescriptions (Necessary)
► Open world reasoning with negation as unsatisfiabilityvsClosed world reasoning with negation as failure
► The role of closure axioms
► Disjoints and the absence of the “Unique Name Assumption”
© University of Manchester 12
Existential vs Universal Existential vs Universal qualifiers qualifiers
► Most biomedical applications are existential graphs (with additions)
► Basic pattern:(All) Cs have_this_property_with_value SOME V(All) Pneumonia has_locus SOME Lung
► OWL abstract syntax:restriction(has_locus someValuesFrom(Lung))orclass(Pneumonia …restriction(has_locus someValuesFrom(Lung))
► Tool Syntax
© University of Manchester 13
NB Dangerous to say NB Dangerous to say “ONLY”“ONLY”
► Is it true that:► (All) Pneumonia has_locus ONLY Lung?
►What about Pleural Pneumonia? Bronchopneumonia?
► Therefore avoid universal qualifiers except: in special cases:
►Universal qualifier pattern:(All) Cs have ONLY Vs for this property(All) Pneumonia has_locus ONLY Lung
► OWL abstract Syntax:
►Restriction(has_locus allValuesFrom V)
► Tool syntax
►
© University of Manchester 14
Simple Simple descriptiondescription of of PneumoniaPneumonia
► From TutorialTop-01
► This says that “All pneumonias have a locus of some lung”
► Note that in a “description” the properties are “necessary” (but not sufficient)► AKA “partial” in OWL abstract syntax
© University of Manchester 15
Definitions: Definitions: Bacterial PneumoniaBacterial Pneumonia
► This says that: “Any pneumonia caused by some bacterium is a Bacterial_pneumonia”and “All bacterial_pneumonias are caused by some bacterium”
► Definitions: Note that in definitions, the properties are sufficient & necessary► AKA “complete” in OWL abstract syntax
© University of Manchester 16
The classifier puts things The classifier puts things under definitionsunder definitions
► Classify by clicking the classify icon.
► Note definition of Pneumococcal_pneumonia
© University of Manchester 17
Resulting hierarchy:Resulting hierarchy:
► Pneumococcal pneumonia has been inferred to be subsumed by bacterial pneumonia
► This is what we expected. It would have been useful to mark this as a test.
© University of Manchester 18
Adding unit test informationAdding unit test information
► On right mouse button select Edit unit test information
© University of Manchester 19
Enter the Enter the intended resultintended result
► With a comment to explain if necessary
► Can indicate ► Whether the class is to be
consistent or inconsistent
► The intended place in the hierarchy
►NB in this version indicates only direct supers and subs.
►To be fixed RSN.
© University of Manchester 21
What happens if “Bacterial_ What happens if “Bacterial_ pneumonia” is only pneumonia” is only describeddescribed
► Convert Bacterial_pneumonia to a primitive (described) class by clicking the primitive/ defined toggle icon
© University of Manchester 22
Bacterial_pneumonia is Bacterial_pneumonia is now primitivenow primitive
► Classify again and run unit tests
© University of Manchester 23
Common errorCommon error
►The most common reason for misclassification is that a class that should have been defined has been left primitive
►To a first approximation, nothing will be inferred to be subsumed by a primitive class.
►Definitions look downwards
►Descriptions look upwards
© University of Manchester 24
Correct the errorCorrect the error
► Convert Bacterial_pneumonia back to a defined class using the toggle
© University of Manchester 25
A definition for pneumoniaA definition for pneumonia
► Pneumonia is an inflammation of the lung► We could just create “Inflamation” and give “Pneumonia” two
parents
►But multiple hierarchies are hard to manage
►And what about inflammations of other organs?
►Or Fibrosis etc. of the lung
► Normalisation
►Start from primitive trees.
© University of Manchester 26
And we might want to have And we might want to have an added abstraction for an added abstraction for “Pulmonary disorder”“Pulmonary disorder”
► And mark Pneumonia that it should be classified both as an Inflammation and a Pulmonary_disorder in the unit test information
© University of Manchester 28
Create Fibrosis of lung and Create Fibrosis of lung and check if different from check if different from PneumoniaPneumonia
► Define Fibrosis
► Define Pulmonary_fibrosis as “Fibrosis that has locus lung”
► Create a “probe class” that is a child of both Pneumonia and Fibrosis of lung
► Mark it as expected to be inconsistent.
► Classify and test
© University of Manchester 29
Probably see consistent Probably see consistent classification but failed unit classification but failed unit testtest
► Why?
© University of Manchester 30
Disjoints & lack of Disjoints & lack of “Unique name assumption”“Unique name assumption”
► OWL classes are allowed to overlap unless declared “disjoint”
► OWL individuals may be inferred to be the same unless declared “different”
► Unless you entered a disjoint between Fibrosis and Inflammation, there is nothing to say that something can’t be both.
► Makes all primitive siblings disjoint
© University of Manchester 31
Reclassify and TestReclassify and Test
► An inconsistent red class (appearing in several places)
► But all unit tests passed► Constraints have worked
as intended.
► (Now hide the probe until next time.)
© University of Manchester 32
Ontological note:Ontological note:Our usual convention…Our usual convention…
► “Fibrosis” and “Inflammation” are disjoint concepts
► They can occur together
► Either may cause the other
► But no one thing is, conceptually, both
© University of Manchester 33
Closure Axioms:Closure Axioms:Viral, Bacterial, & Mixed Viral, Bacterial, & Mixed PneumoniasPneumonias
► Create Viral Pneumonia► Note the create clone item on the class right mouse button.
Allows easy “copy and edit”
► Note that Virus and Bacterium are disjoint
► Create a mixed pneumonia caused by both a virus and a bacterium
► Classify
© University of Manchester 34
Useful to use OwlViz as wellUseful to use OwlViz as wellAsserted(Before classification)
Inferred(After classification)
© University of Manchester 35
Ontology and languageOntology and language
► What do we mean by “Bacterial pneumonia”?
► Do we really want to include “Viral pneumonias”
► We can make the notion of a “Pure bacterial pneumonia”
► Clone Bacterial_pneumonia and add a closure axiom
© University of Manchester 36
Pure bacterial pneumonia Pure bacterial pneumonia with closure axiomwith closure axiom
► Classify
© University of Manchester 37
Which should be labelled Which should be labelled “Bacterial Pneumonia” “Bacterial Pneumonia”
► Separate labeling (terms) from concepts (entities)
► Two useful concepts► “Pneumonia caused by bacteria and possibly other things”
► “Pneumonia caused purely by bacteria”.
► Which is correctly labeled “bacterial pneumonia” depends on local choice, task, and usage
► EG: If treatment of “Mixed pneumonia” is dramatically different from either bacterial or viral pneumonia, best to keep the two ‘pure’ concepts plus a third ‘mixed’ concept
If treatment for the bacterial part of the pneumonia is on the same path regardless of viral complications, no obvious reason to distinguish ‘pure’ from ‘mixed’.
► Not a once-and-for-all decision► Map the language reliably used by clinicians to the concepts needed by
the system
© University of Manchester 38
The importance of The importance of paraphrases and text paraphrases and text definitionsdefinitions
► Terms alone are not ambiguous!► Even “decontextualised” terms as in SNOMED are
ambiguous
► We need definitions paraphrases:
►For users: to improve reliability
►Perfect logic is irrelevant if inter-rater reliability is low
►Logic only guarantees that truth follows from truth
►For developers to resolve disagreements
►To know if they are arguing about what they mean or how to represent what they mean
© University of Manchester 39
Two (iterative) steps to any Two (iterative) steps to any formal concept definitionformal concept definition
► Agree the meaning in words: ► “Definition”
► “Paraphrase”
► Represent the agreed meaning formally► Examine the consequences of the formal definition
►Test against intentions
► Iterate until stable or concept declared unusable► E.g. “Gene” in many molecular biology representations
involving eukaryotes is becoming increasingly unusable because of multiple meanings
► E..g. “Heart failure” not allowed as a cause of death
© University of Manchester 40
DO NOT CONFUSE DO NOT CONFUSE FORMAL CORRECTNESSFORMAL CORRECTNESS & & CLINICAL APPROPRIATENESSCLINICAL APPROPRIATENESS
► Clinical appropriateness requires► Good inter-rater reliability
►In local community
►In wider community if possible
► Good match to clinical intentions and import
► Formal correctness requires internal consistency► Formal correctness is a pre-requisite but not sufficient
condition for clinical appropriateness
►If software doesn’t work, it is inappropirate
►If people cannot use it as intended, it is inappropriate