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

2 OWL: What is it? 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: Conceptual Lego hand extremity body acute chronic abnormal normal ischaemic deletion Radiograph MRI Echo Skull Contrast infection inflammation Lung Opacity

© University of Manchester 4 Logic-based Ontologies: Conceptual Lego “ Pneumonia of Left lower lobe of Lung on basis of Opacity in Chest X-Ray in PA-Lateral position status Improving …” “Hand which is anatomically normal”

© University of Manchester 5 Logical Constructs build complex concepts from modularised primitives Anatomy Conditions Signs Modalities Techniques Pneumonia of RML signified by opacity Pneumonia of RML signified by opacity on CXR Pneumoonia of RML signified by opacity on CXR in PA-Lat position Pneumonia of RML

© University of Manchester 6 Three Resources reusable reference information resources Metadata 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 to the 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 APIAPI Reference Management Multilingual Dictionaries Multilingual Module Common Reference Model Concept Module Code Store Code Conversion Module Client Application Server Client Extrinsics Store Indexing Module

© University of Manchester 8 OWL as the core of Ontology Indexed Reusable Resources Data store on Individuals Data Contingent Knowledge Rule base & decision Support Prototypical Knowledge Reference Knowledge base Definitional knowledge “Ontology” Meta Data Annotation Linguistic knowledge

© University of Manchester 9 DLs/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 ontologies ►“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 points ►Existential vs Universal Restrictions ►Definitions (Necessary & Sufficient) vs Descriptions (Necessary) ►Open world reasoning with negation as unsatisfiability vs Closed 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 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)) or class(Pneumonia …restriction(has_locus someValuesFrom(Lung)) ►Tool Syntax

© University of Manchester 13 NB Dangerous to say “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 description of Pneumonia ►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: Bacterial 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 under definitions ►Classify by clicking the classify icon. ►Note definition of Pneumococcal_pneumonia

© University of Manchester 17 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 information ►On right mouse button select Edit unit test information

© University of Manchester 19 Enter the intended 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 20 Test with unit tests

© University of Manchester 21 What happens if “Bacterial_ pneumonia” is only described ►Convert Bacterial_pne umonia to a primitive (described) class by clicking the primitive/ defined toggle icon

© University of Manchester 22 Bacterial_pneumonia is now primitive ►Classify again and run unit tests

© University of Manchester 23 Common 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 error ►Convert Bacterial_pneumonia back to a defined class using the toggle

© University of Manchester 25 A 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 an added abstraction for “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 27 Classify and test

© University of Manchester 28 Create Fibrosis of lung and check if different from Pneumonia ►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 classification but failed unit test ►Why?

© University of Manchester 30 Disjoints & lack of “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 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: 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: Viral, Bacterial, & Mixed Pneumonias ►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 well Asserted (Before classification) Inferred (After classification)

© University of Manchester 35 Ontology 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 with closure axiom ►Classify

© University of Manchester 37 Which should be labelled “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 paraphrases and text definitions ►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 formal 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 FORMAL CORRECTNESS & CLINICAL 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

© University of Manchester 41 To Basic-biomed-II.ppt