© university of manchester simplifying owl learning lessons from anaesthesia nick drummond...

Download © University of Manchester Simplifying OWL Learning lessons from Anaesthesia Nick Drummond BioHealth Informatics Group

If you can't read please download the document

Upload: lionel-singleton

Post on 13-Dec-2015

215 views

Category:

Documents


1 download

TRANSCRIPT

  • Slide 1

University of Manchester Simplifying OWL Learning lessons from Anaesthesia Nick Drummond BioHealth Informatics Group Slide 2 University of Manchester Overview IOTA Requirements Challenges Separating language from identity Referencing non-OWL resources Hiding complexity Optionality in OWL Conclusion Slide 3 University of Manchester Guinea Pig - IOTA I nternational O rganisation for T erminology in A naesthesia Part of the Anaesthesia Patient Safety Foundation 2 parallel efforts: official feed of anaesthesia terms to SNOMED-CT Ontology required for AIMS systems Slide 4 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) Slide 5 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) Slide 6 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 Slide 7 University of Manchester Challenges Separating language from identity Referencing non-OWL resources Hiding complexity Optionality in OWL Slide 8 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 Slide 9 University of Manchester Separating ID from language in Protege Meaningless IDs generated automatically conceptName is human readable Protg supports idea of Browser Slot ie the property that is displayed to the user Extra search support needed Slide 10 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) Slide 11 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 Slide 12 University of Manchester Disguising OWL Protg forms are customisable forms design for purpose plugin form widgets Use min/max qualified cardinality Display compound restrictions Slide 13 University of Manchester Using qualified cardinality and compound restrictions hasProp some ClasshasProp min 1 Class Not hasProp some ClasshasProp max 0 Class hasProp min x Class hasProp max y Class hasProp min x, max y Class hasProp cardi x ClasshasProp min x, max x Class hasProp only ClassTo implement closure column to hide this away hasProp hasValue individualTo implement hasProp min 1, max 1 individual Optionally hasProp some Class hasProp min 0 Class (see next) Slide 14 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 Slide 15 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 Slide 16 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 Slide 17 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 Slide 18 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 Slide 19 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 Slide 20 University of Manchester Conclusion IOTA have some common problems Many can be overcome even in OWL Open environments like Protg can help create simpler interfaces General requirements found for Protg-OWL