Download presentation
Presentation is loading. Please wait.
Published byLionel Singleton Modified over 9 years ago
1
© University of Manchester Simplifying OWL Learning lessons from Anaesthesia Nick Drummond BioHealth Informatics Group
2
© University of Manchester Overview ►IOTA ►Requirements ►Challenges ►Separating language from identity ►Referencing non-OWL resources ►Hiding complexity ►Optionality in OWL ►Conclusion
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
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)
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)
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
7
© University of Manchester Challenges ►Separating language from identity ►Referencing non-OWL resources ►Hiding complexity ►Optionality in OWL
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
9
© 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
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)
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
12
© 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
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)
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
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
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
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
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
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
20
© 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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.