Simplifying OWL

© University of Manchester

Simplifying OWL

Learning lessons from Anaesthesia

Nick Drummond

BioHealthInformaticsGroup

O p en G A L E N

© University of Manchester

Overview

►IOTA

►Requirements

►Challenges►Separating language from identity

►Referencing non-OWL resources

►Hiding complexity

►Optionality in OWL

►Conclusion

© University of Manchester

Guinea Pig - IOTA

►International Organisation for Terminology in Anaesthesia

►Part of the Anaesthesia Patient Safety Foundation

►2 parallel efforts:►official feed of anaesthesia terms to SNOMED-CT

►Ontology required for AIMS systems

© University of Manchester

IOTA Tools

►Had DATAMS browser/editor►Simple interface

►Completely designed for single task

►But►Non standard solution – no semantics defined

►Limited functionality

►Restricted support

►Not extensible

►Only 2 relationships (isa, hasa)

© University of Manchester

Requirements

►Simple browsing/editing environment

►Standards for reuse

►Heavily concerned with language and references to external resources (for SNOMED)

►Simple structure but above and beyond sub/superclass (more properties wanted)

© University of Manchester

OWL Subset

►Subsumption

►Primitive classes only (so far)

►Existential / Complement / Cardi restrictions (identified through competency questions)

►No complex fillers – only Named Classes

►No disjoints (yet) – likely to be added automatically

►Lots of annotations

© University of Manchester

Challenges

►Separating language from identity

►Referencing non-OWL resources

►Hiding complexity

►Optionality in OWL

© University of Manchester

Separating language from identity

► Resources are referred to by their URI

► rdfs:label or other properties can be used to hold the human-readable name

► IDs remain constant when renaming

► Can have multiple names (in different languages)

► Label string values less restricted (can use spaces etc)

► Can use the same label for multiple resources (disadvantage??)

vin wine

plonk

© University of Manchester

Separating ID from language in Protege

► Meaningless IDs generated automatically

► conceptName is human readable

► Protégé supports idea of “Browser Slot”► ie the property that is displayed to the user

► Extra search support needed

© University of Manchester

Referencing non-OWL resources

► owl:seeAlso

► Have no URI to point to in SNOMED

► Create an individual in which to store any SNOMED info (such as name etc)

► Can be refactored later to point to the actual concept (if SNOMED ever published in OWL)

© University of Manchester

Hiding Complexity

► Backward Es and upside-down As best left to the logicians

► Not all expressivity of OWL required► eg “simple” fillers – just named classes

► Currently no defined classes

© University of Manchester

Disguising OWL

►Protégé forms are customisable►forms design for purpose

►plugin form widgets

►Use min/max qualified cardinality

►Display “compound” restrictions

© University of Manchester

Using qualified cardinality and compound restrictions

hasProp some Class hasProp min 1 Class

Not hasProp some Class hasProp max 0 Class

hasProp min x Class

hasProp max y Class

hasProp min x, max y Class

hasProp cardi x Class hasProp min x, max x Class

hasProp only Class To implement

closure column to hide this away

hasProp hasValue individual To implement

hasProp min 1, max 1 individual

Optionally hasProp some Class

hasProp min 0 Class

(see next)

© University of Manchester

Optionality

► Common requirement

► 2 use cases:

►Reasoning – using ontological knowledge – an object may or may not have this feature

►Driving Forms – using epistemic knowledge – an object has this feature. The value may or not need to be specified

© University of Manchester

Representing optionality in OWL

► No inbuilt notion in OWL

► Because of the open world assumption, possible to say anything about anything unless it has been explicitly discounted

► Several “patterns”, “workarounds” or “botches” – could be subject in themselves

► We are considering a mixture to help make INTENT obvious and simple to manage but allow for CORRECT modelling in OWL

© University of Manchester

Options (overview)

► State nothing (Open World)

► Using domain of property

► Use of “possibly…” superproperty

► Universal/Existential restrs on inverse

► Reification

► Tool specific annotations

► Qualified Min Cardinality 0

► Define a subclass that has the property

© University of Manchester

Defined Subclass

Person (some people own hats)

PersonThatOwnsAHat { complete

Person and owns some Hat

}

► Ontologically correct

► Can infer membership / check consistency

► Hard to maintain

► Loses intent – conceptually we are saying something about members of Person

© University of Manchester

Min Cardi 0 (Qualified)

► QCRs standard in OWL1.1

► Means nothing to reasoners, but…

► Captures intent

► matches our conceptual model and close to other representations – relational models

► Simple to add/manage in OWL

► Easy to use as hints for GUI generation

© University of Manchester

►Allow user to maintain intent – ie min cardi

►Provide transform to create subclasses only WHEN REQUIRED

►Throw away when finished ? ?

Transform

www

© University of Manchester

Conclusion

► IOTA have some common problems

► Many can be overcome – even in OWL

► Open environments like Protégé can help create simpler interfaces

► General requirements found for Protégé-OWL