Simplifying
OWL
Learning lessons from
Anaesthesia
Nick Drummond
O p e n G A LE N
BioHealth
Informatics
Group
© 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
vin
wine
plonk
► 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??)
© 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 min x, max y Class
hasProp 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
► Hard to maintain
► Can infer membership
/ check consistency
► 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
Transform
► Allow user to maintain intent – ie min cardi
► Provide transform to create subclasses only WHEN
REQUIRED
www
► Throw away when finished ? ?
© 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
© University of Manchester