Upload
elaina
View
25
Download
3
Embed Size (px)
DESCRIPTION
BioHealth Informatics Group. Simplifying OWL. Learning lessons from Anaesthesia Nick Drummond. Overview. IOTA Requirements Challenges Separating language from identity Referencing non-OWL resources Hiding complexity Optionality in OWL Conclusion. Guinea Pig - IOTA. - PowerPoint PPT Presentation
Citation preview
© 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