BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester1 Formal Modelling Alan Rector

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester2 When to use a classifier 1.At author time: As a compiler – Pre-coordination ►Ontologies will be delivered as “pre-coordinated” ontologies to be used without a reasoner ►To make extensions and additions quick, easy, and responsive, distri but developments, empower users to make changes ►Part of an ontology life cycle 2.At delivery time: As a service: - Post-coordination ►Many fixed ontologies are too big and too small ►Too big to find things; too small to contain what you need ►Create them on the fly ►Part of an ontology service 3.At application time: as a reasoner - Post- coordination & inference ►Decision support, query optimisation, schema integration, …, …, … ►Part of a reasoning service

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester3 When to use a classifier 1: Pre-coordinated delivery classifier as compiler ►The life cycle ►Gather requirements, sketch, experiment ►Establish patterns – design a “language” ►Criteria for success: What a subject domain expert can learn in a few days ►Bulk authoring ►Classification ►Quality assurance ►Commit classifier results to a pre-coordinated ontology & deliver ►Polyhierarchies (Protégé, DAG-Edit, OWL-Lite, RDF(S), Topic Maps, … ►Query and use with you favourite tool Development & evolution

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester4 Commit Results to a Pre- Coordinated Ontology Assert (“Commit”) changes inferred by classifier

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester5 When to use a classifier 2: Post Coordination ►When the ontology too big – “Lazy classification” on demand Big on the outside: small kernel on the inside kernel model Externally available resource API

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester6 Often combined with other services: Example - the GALEN Server Service API Multilingual Lexicons Multilingual Module Ontologies & Classifie r Ontology Module Resource References External Resources & “ Coding ” Module Client Applications Users Ontology Services Client Run time classifier

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester7 The problem But we want to ►Build ontologies cooperatively with different groups ►Extend ontologies smoothly ►Re-use pieces of ontologies ►Build new ontologies on top of old ►Quit starting from scratch Knowledge is Big, Fractal & Changeable!

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester8 Assertion: ►Let the ontology authors ►create discrete modules ►describe the links between modules ►Let the logic reasoner ►Organise the result The arrival of logic-based ontologies/OWL gives new opportunities to make ontologies more manable and modular

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester9 Logic-based Ontologies: Conceptual Lego hand extremity body acute chronic abnormal normal ischaemic deletion bacterial polymorphism cell protein gene infection inflammation Lung expression

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester10 Logic-based Ontologies: Conceptual Lego “ SNPolymorphism of CFTRGene causing Defect in MembraneTransport of Chloride Ion causing Increase in Viscosity of Mucus in CysticFibrosis …” “Hand which is anatomically normal”

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester11 Logical Constructs build complex concepts from modularised primitives Genes Species Protein Function Disease Protein coded by gene in humans Function of Protein coded by gene in humans Disease caused by abnormality in Function of Protein coded by gene in humans Gene in humans

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester12 Normalising (untangling) Ontologies Structure Function Part-whole Structure Function Part-whole

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester13 Rationale for Normalisation ►Explicit distinctions between modules ►Primitives are opaque to the reasoner ►Information implicit in primitive names cannot contribute to modularisation ►Primitives are indivisible to both human and reasoner ►Each primitive should represent a single notion ►Therefore, each primitive must belong to exactly one module ►If a primitive belongs to two modules, they are not modular. ►If a primitive belongs to two modules, it probably conflates two notions ►Therefore concentrate on the “primitive skeleton” of the domain ontology

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester14 Normalisation and Untangling Let the reasoner do multiple classification ►Tree ►Everything has just one parent ►A ‘strict hierarchy’ ►Directed Acyclic Graph (DAG) ►Things can have multiple parents ►A ‘Polyhierarchy’ ►Normalisation ►Separate primitives into disjoint trees ►Link the trees with restrictions ►Fill in the values

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester15 Tables are easier to manage than DAGs / Polyhierarchies …and get the benefit of inference: Grass and Leafy_plants are both kinds of Plant

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester16 Remember to add any closure axioms Closure Axiom Then let the reasoner do the work

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester17 Normalisation: From Trees to DAGs Before classification A tree After classification A DAG Directed Acyclic Graph

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester18 Normalisation: Criterion 1 The skeleton should consist of disjoint trees ►Every primitive concept should have exactly one primitive parent ►All multiple hierarchies the result of inference by reasoner

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester19 Normalisation Criterion 2: No hidden changes of meaning ►Each branch should be homogeneous and logical (“Aristotelian”) ►Hierarchical principle should be subsumption ►Otherwise we are “lying to the logic” ►The criteria for differentiation should follow consistent principles in each branch eg. structure XOR function XOR cause

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester20 A Non-homogeneous taxonomy “ On those remote pages it is written that animals are divided into: a. those that belong to the Emperor b. embalmed ones c. those that are trained d. suckling pigs e. mermaids f. fabulous ones g. stray dogs h. those that are included in this classification i. those that tremble as if they were mad j. innumerable ones k. those drawn with a very fine camel's hair brush l. others m. those that have just broken a flower vase n. those that resemble flies from a distance" From The Celestial Emporium of Benevolent Knowledge, Borges

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester21 Normalisation Criterion 3 Distinguish “Self-standing” and “Refining” Concepts ►Self-standing concepts ►Roughly Welty & Guarino’s “sortals” ►person, idea, plant, committee, belief,… ►Refining concepts – depend on self-standing concepts ►mild|moderate|severe, hot|cold, left|right,… ►Roughly Welty & Guarino’s non-sortals ►Closely related to Smith’s “fiat partitions” ►Usefully thought of as Value Types by engineers ►For us an engineering distinction…

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester22 Normalisation Criterion 3a Self-standing primitives should be globally disjoint & open ►Primitives are atomic ►If primitives overlap, the overlap conceals implicit information ►A list of self-standing primitives can never be guaranteed complete ►How many kinds of person? of plant? of committee? of belief? ►Can’t infer: Parent & ¬sub 1 &…& ¬sub n-1  sub n ►Heuristic: ►Diagnosis by exclusion about self-standing concepts should NOT be part of ‘standard’ ontological reasoning

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester23 Normalisation Criterion 3b Refining primitives should be locally disjoint & closed ►I ndividual values must be disjoint ►but can be hierarchical ►e.g. “very hot”, “moderately severe” ►Each list can be guaranteed to be complete ►Can infer Parent & ¬sub 1 &…& ¬sub n-1  sub n ►Value types themselves need not be disjoint ►“being hot” is not disjoint from “being severe” ►Allowing Valuetypes to overlap is a useful trick, e.g. ►restriction has_state someValuesFrom (severe and hot)

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester24 Normalisation Criterion 4 Axioms ►No axiom should denormalise the ontology No axiom should imply that a primitive is part of more than one branch of primitive skeleton ►If all primitives are disjoint, any such axioms will make that primitive unsatisfiable ►A partial test for normalisation: ►Create random conjunctions of primitives which do not subsume each other. ►If any are satisfiable, the ontology is not normalised

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester25 Consequences 1 ►All self-standing primitives are disjoint ►All multiple classification is inferred ►For any two primitive self-standing classes, either one subsumes the other or they are disjoint ►Every self standing concept is part of exactly one primitive branch of the skeleton ►Every self-standing concept has exactly one most specific primitive ancestor

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester26 Consequences 2 ►Primitives introduced by a conjunction of one class and a boolean combination of zero or more restrictions ►Tree subclass-of Plant and restriction isMadeOf someValuesFrom Wood ►Resort subclass-of Accommodation restriction isIntendedFor someValueFrom Holidays

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester27 Consequences 3 ►Use of axioms limited (outside of skeleton construction) The following are a safe but not exhaustive guide: ►The right side of subclass axioms limited to restrictions ►Both sides of disjointness axioms limited to restrictions ►No equivalence axioms with primitives on either side

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester28 A real example: Build a simple treee easy to maintain

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester29 Let the classifier organise it

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester30 If you want more abstractions, just add new definitions (re-use existing data) “Diseases linked to abnormal proteins”

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester31 And let the classifier work again

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester32 And again – even for a quite different category “Diseases linked genes described in the mouse”

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester33 And let classifier check consistency (My first try wasn’t)

BioHealth Informatics Group Feb 2005Ontology tutorial, © 2005 Univ. of Manchester34 Summary Why use a Classifier? ►To compose concepts ►Allow conceptual lego ►To manage polyhierarchies ►Adding abstractions (“axes”) as needed ►Normalisation ►Untangling ►labelling of “kinds of is-a” ►To avoid combinatorial explosions ►Keep bicycles from exploding ►To manage context ►Cross species, Cross disciplines, Cross studies ►To check consistency and help users find errors