Review of OWL for Biomedicine Alan Rector & CO-ODE/NIBHI University of Manchester [email protected] OpenGALEN BioHealth Informatics Group © University.

Review of OWL for Review of OWL for BiomedicineBiomedicineAlan Rector & CO-ODE/NIBHI

University of Manchester

[email protected]

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


Logic-based Ontologies: Logic-based Ontologies: Conceptual LegoConceptual Lego

hand

extremity

body

acute

chronic

abnormalnormal

ischaemicdeletion

RadiographMRI

Echo

Skull

Contrast

infectioninflammation

Lung

Opacity


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”


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


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


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


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


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


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


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”


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


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

►


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


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


The classifier puts things The classifier puts things under definitionsunder definitions

► Classify by clicking the classify icon.

► Note definition of Pneumococcal_pneumonia


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.


Adding unit test informationAdding unit test information

► On right mouse button select Edit unit test information


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.


Test with unit tests Test with unit tests


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


Bacterial_pneumonia is Bacterial_pneumonia is now primitivenow primitive

► Classify again and run unit tests


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


Correct the errorCorrect the error

► Convert Bacterial_pneumonia back to a defined class using the toggle


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.


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


Classify and testClassify and test


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


Probably see consistent Probably see consistent classification but failed unit classification but failed unit testtest

► Why?


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


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.)


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


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


Useful to use OwlViz as wellUseful to use OwlViz as wellAsserted(Before classification)

Inferred(After classification)


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


Pure bacterial pneumonia Pure bacterial pneumonia with closure axiomwith closure axiom

► Classify


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


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


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


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


To Basic-biomed-II.pptTo Basic-biomed-II.ppt

Review of OWL for Biomedicine Alan Rector & CO-ODE/NIBHI University of Manchester [email protected] OpenGALEN BioHealth Informatics Group © University.

Documents

corethe model

complex concepts

core of ontology

ontology engineeringdebugging

review of owl

good fordescribing

ita current standard

biomedical applications