ONTOLOGY - PowerPoint PPT Presentation

1 / 24
About This Presentation
Title:

ONTOLOGY

Description:

Testing of ontology within final application. Case study - evaluation ... Objects: (gun, house, painting, statue, arm) Synonyms. Links to associated' terms ... – PowerPoint PPT presentation

Number of Views:54
Avg rating:3.0/5.0
Slides: 25
Provided by: usersEncs
Category:
Tags: ontology

less

Transcript and Presenter's Notes

Title: ONTOLOGY


1
ONTOLOGY (Tutorial III)
Arash Shaban-Nejad Comp 691B Foundation Of
Semantic Web Winter 2004
2
Ontology Evaluation
  • We do not have a uniform pattern for judging all
    ontologies
  • Testing of ontology within final application.
  • Case study - evaluation
  • Problem integrating existing vocabularies.
  • Meaning cannot be taken on face value
  • No human to intervene
  • Must also explicitly take into account context
    is which term is used

3
Some Problems with Ontologies
  • The Authors
  • The Users
  • The Domain
  • The Reader

4
Author Problems
  • Construction is difficult and obtuse
    - Labour intensive
  • Quality Assurance - How to check result ?
    - Too big to do exhaustively by hand
  • - Existing manual ontologies as a reference
    ?
  • Maintenance
  • - Versioning
  • - Update penalty
  • Merging and interoperation (difficult even for
    static ontologies Because they usually share
    peripheral concepts)

5
Author Problems
  • Expertise
  • -Ontologies are large
  • Can not be built by one person - needs lots of
    people
  • Unlikely to be the same people, start to finish
  • Varying levels of expertise at same time
  • -Cast of thousands increases risk of error
  • Formal Error
  • Knowledge Error

6
The Coding of Chocolate(An Example of Formal
Error)
Ontology for an international conversion guide
SNOMED-CT
  • C-F0811
  • C-F0816
  • C-F0817
  • C-F0819
  • C-F081A
  • C-F081B
  • C-F081C
  • C-F0058

"Milky Way" in the US is sold as the 'Mars Bar'
in the UK, where thename 'Milky Way' is used for
what in the States is called the "3 Musketeers".
...
7
User Problems
  • User requirements expectations
  • Expertise and User Interface issues
  • - UI issues Long lists and Difficult
    navigation
  • Types of user error
  • -Missed coding Not coding at all
  • -Over coding Coding at a higher level of
    granularity than is justified
  • -Under coding Coding at a lower level of
    granularity than is justified
  • -Mis-coding Coding something with the wrong
    code
  • (e.g. using the term arms, as the body
    part, But in another Ontology its corresponds
    to the concept of an armrest as a component of a
    piece of furniture)

8
User Problems (Cont.)
ART ARCHITECTURE THESAURUS (AAT) Domain art,
architecture, decorative arts, material
culture Content 125,000 terms Structure 7
facets, 33 polyhierarchies Associated concepts
(beauty, freedom, socialism) Physical attributes
(red, round, waterlogged) Style/Period (French,
impressionist, surrealist) Agents (printmaker,
architect, jockey) Activities (analysing,
running, painting) Materials (iron, clay,
emulsifier) Objects (gun, house, painting,
statue, arm) Synonyms Links to associated
terms Access lexical string match
hierarchical view
  • Confused Users

9
User Problems (Cont.)
  • Causes of error
  • - Coder limitations
  • time pressure, no training, language, culture
  • Limitations of structure of domain
  • - Different interpretation of same term (e.g. Arm)
  • Cost

- Entering metadata takes time
10
Domain Problems
  • Semantic Problems
  • -The nature of knowledge ( fractal and
    Domain is not static)

- Ambiguity, imprecision
How you can work with a data item when the
meaning of the data itself isnt precisely
known or isnt constant ?
- Different Perspectives
11
Different Perspectives
  • Given
  • Glass_of_water
  • HAS_FEATURE ltempty, fullgt
  • TASTES ltgood, badgt
  • CONTAINS ltsugar, saltgt
  • Empty, Full
  • HAS_LEVEL ltpercentagegt

Glass_of_waterCONTAINS sugarHAS_FEATURE empty
HAS_LEVEL 50 Glass_of_waterCONTAINS
saltTASTES good Glass_of_waterCONTAINS
sugarHAS_FEATURE full HAS_LEVEL 50
12
The Reader Problems
Who, ultimately, is reading your data ? Who is
interpreting your ontology ?

13
Who is interpreting your ontology ?
- Looking For Common Language for problems and
Errors
  • Engineers errors
  • it works in my application, thus it is good
  • who needs formality anyway?
  • it did not work when I looked at it 10 years ago
  • AI peoples errors
  • it is good if it is formal
  • it is good if someone with a logic background may
    easily use it
  • it is good if the language allows everything

14
Ontology Quality precision and Coverage
15
Evaluation with Logic
  • What does the logic give you?
  • Logical consistency checked automatically
  • Semantic consistency can be assisted by the DL
    reasoner
  • By classification miss-classification
  • Additional tools
  • By query and visualisation missed classification

16
DL based Ontologies
  • More complete than humans can achieve
  • Faster than human
  • Reproducible results
  • Scalable in theory
  • Explainable
  • Support complex, precise and detailed modelling.

17
Challenges with DL based ontologies
  • Concepts are complex
  • Multiple ways of classifying the same concept
  • - Humans are not good at high levels of
    complexity, precision or detail
  • Concepts cover a wide range of granularity
  • -Need to be organised in a classification
  • Scale
  • -Vocabulary will be large e.g. 1000s of terms
  • - Machine can cope with scale but Hard to
    maintain consistently by hand

18
The UK Drug OntologyAn Example for Complexity
  • 20,000 branded preparations (unstable list)
  • VECF34087E Ventolin CFC free inhaler 100mcg per
    puff
  • SACF26553E generic salbutamol 100mcg cfc-free
  • SAAC28242E Salbutamol 200mcg Accuhaler
  • SADI19641E Salbutamol diskhaler 400mcg
  • ..need indexing by c. 1500 drug classes (more
    stable)
  • 9084561 salbutamol inhaler
  • Except
  • We dont know what the classes will be up front
  • drugs for treatment of angina that cause skin
    rashes
  • So need dynamic classification

19
The UK Drug Ontology
Drug preparation
contains
ingredient
has drug feature
has form
form
biochemical action
biochemical process
which is
has feature
physiological process
physiological action
which is
has feature
interaction
drug preparation
with
clinical condition
causes
side effect
clinical condition
which is
Clinical Condition Ontology ??
has feature
contraindication
clinical condition
which is
has feature
clinical condition
treatment act
indication
for
acts on
has feature
20
Ontologies in Action
Patient ID 4578 Medication DITA906
DISR10514B Problem List 183... (Oedema) 1B17..
(Depressed) G5732. (Paroxysmal Atrial
fibrillation) G73z0. (Intermittent claudication)
H3.... (Chronic obstructive pulm.dis.) 137S.. (Ex
smoker) 246... (O/E - blood pressure reading)
442... (Thyroid hormone tests) 44P... (Serum
cholesterol) 7L172. (Blood withdrawal for testing)
G57.. Cardiac dysrhythmias G573. Atrial
fibrillation and flutter G5730 Atrial
fibrillation G5731 Atrial flutter G5732
Paroxysmal atrial fibrillation G573z Atrial
fibrillation and flutter NOS
IDENT 9099269 MAIN digoxin PROPERTIES HAS_DRUG_
FEATURE physiological action WHICH_IS
process ACTS_ON heart HAS_DRUG_FEATURE
indication FOR treating ACTS_ON
supraventricular arrhythmia HAS_DRUG_FEATURE
indication FOR treating ACTS_ON atrial
fibrillation HAS_DRUG_FEATURE information
source IS_PART_OF interaction appendix
21
Reasoning support
  • Consistency check if knowledge is meaningful
  • Subsumption structure knowledge, compute
    taxonomy
  • Equivalence check if two classes denote same
    set of instances
  • Instantiation check if individual i instance of
    class C
  • Retrieval retrieve set of individuals that
    instantiate C
  • Problems all reducible to consistency
    (satisfiability)

22
Why Reasoning Services?
  • Ontology design
  • Check class consistency and (unexpected) implied
    relationships
  • Particularly important with large
    ontologies/multiple authors
  • Ontology integration
  • Assert inter-ontology relationships
  • Reasoner computes integrated class
    hierarchy/consistency
  • Ontology deployment
  • Determine if set of facts are consistent w. r. t.
    ontology
  • Determine if individuals are instances of
    ontology classes
  • Query Inclusion
  • Service description matchmaking
  • Classification-based querying.

23
Conclusion
  • Evaluation of Ontologies are more complicated
    than they look
  • - Many of the problems lie in human factors
  • - Easy to underestimate needs of the machine
  • - Humans are clever, but inconsistent
  • - Computers are consistent, but stupid
  • Interoperation still difficult
  • - Many different resources must share one
    ontology
  • - But differing perspectives or ambiguity in the
    domain is a problem

24
Acknowledgements
Many of these slides are based on slides prepared
by Jeremy Rogers MRCGP Medical Informatics Group
and Ian Horrock , University of Manchester and
Enrico Franconi , Faculty of Computer Science,
Free University of Bozen-Bolzano
Write a Comment
User Comments (0)
About PowerShow.com