1 / 20

Simplifying OWL Learning: Insights from Anaesthesia and IOTA Challenges

This document explores the complexities of OWL (Web Ontology Language) in relation to anaesthesia terminology and the International Organisation for Terminology in Anaesthesia (IOTA). It highlights the challenges encountered in separating language from identity, referencing non-OWL resources, and hiding internal complexities while adapting OWL for practical applications. The paper examines IOTA's tools and requirements for ontology creation, including the need for a simple browsing environment, annotations, and optionality handling. The conclusion emphasizes overcoming common challenges using environment tools like Protégé.

elaina
Télécharger la présentation

Simplifying OWL Learning: Insights from Anaesthesia and IOTA Challenges

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. BioHealthInformaticsGroup Simplifying OWL Learning lessons from Anaesthesia Nick Drummond

  2. Overview • IOTA • Requirements • Challenges • Separating language from identity • Referencing non-OWL resources • Hiding complexity • Optionality in OWL • Conclusion

  3. 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

  4. 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. 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. 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. Challenges • Separating language from identity • Referencing non-OWL resources • Hiding complexity • Optionality in OWL

  8. Separating language from identity vin wine • 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??) plonk

  9. 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. 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. 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. Disguising OWL • Protégé forms are customisable • forms design for purpose • plugin form widgets • Use min/max qualified cardinality • Display “compound” restrictions

  13. Using qualified cardinality and compound restrictions

  14. 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. 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. 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. Defined Subclass Person (some people own hats) • Ontologically correct • Can infer membership / check consistency PersonThatOwnsAHat { complete Person and owns some Hat } • Hard to maintain • Loses intent – conceptually we are saying something about members of Person

  18. 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. Transform • Allow user to maintain intent – ie min cardi • Provide transform to create subclasses only WHEN REQUIRED • Throw away when finished ? ? www

  20. 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

More Related