Docstoc

Ontology engineering

Document Sample
Ontology engineering Powered By Docstoc
					     Ontology
engineering



                Valen.na
Tamma


Based
on
slides
by
A.
Gomez
Perez,
N.
Noy,
D.
McGuinness,

            E.
Kendal,
A.
Rector
and
O.
Corcho

                   Summary

•    Background
on
ontology;

•    Ontology
and
ontological
commitment;

•    Logic
as
a
form
of
representa.on;

•    Ontology
development
phases

    Ontology
design
process

                            Requirement

                            and
domain

                              analysis



                                             Determine

           Add
Instances

                                               scope





  Define

                                                     Consider
reuse

constraints





                 Define
                      Enumerate

               proper.es
                      terms




                            Define
classes

            Requirement
analysis


Performing
Requirements,
Domain
&
Use
Case
Analysis
is
a

cri.cal
stage
as
in
any
soQware
engineering
design.
It
allows

ontology

engineers
to
ground
the
work
and
priori.se.


The
analysis
has
to
elicit
and
make
explicit:

 • 
The
nature
of
the
knowledge
and
the
ques.ons

 (competency
ques-ons)
that
the
ontology
(through
a

 reasoner)
needs
to
answer.
This
process
is
crucial

for
scoping

 and
designing
the
ontology,
and
for
driving
the
architecture;

 • 
Architectural
issues;


 • 
The
effec.veness
of
using
tradi.onal
approaches
with

 knowledge
intensive
approaches;

                                  Aim:

The
main
goal
of
this
phase
is
to
support
the
applica.on
in
dealing
with:

  
–
Changing
assump.ons

  
–
Hypothesis
genera.on
(analogy)

  
–
System
evolu.on,
or
dynamic
knowledge
evolu.on
‐
where
.me

and
situa.ons
change
necessita.ng
re‐evalua.on
of
assump.ons

  
–
Support
for
interopera.on
with
other
(poten.ally
legacy)
systems

  
−
Genera.on
of
explana.on
for
dialogue
genera.on
–
facilitate

   interface
with
users

  
−
Standardiza-on
of
terminology:
to
reflect
the
engineers
different

   backgrounds



Separa.on
of
concerns
is
crucial
when
dealing
with
knowledge

•  Declara.ve
domain
knowledge
(what?)
needs
to
be
treated
differently

   from
procedural
knowledge
(how?)

    –  Ontologies
vs
Problem
solving
methods

•  Background
(unchanging)
knowledge
from
changing
informa.on

•  Provenance
and
level
of
trust
of
knowledge

          Applica.on
requirements

Applica.on
requirements
can
be
acquired
by:

•  Iden.fying
any
controlled
vocabulary
is
used
in
the
applica.on;

•  Iden.fying
hierarchical
or
taxonomic
structures
intrinsic
in
the
domain

   that
might
be
used
for
query
expansion:

    –  Vegetarian
pizza
such
as:
margherita,
funghi,
grilled
vegetables

•  Analysing

structured
queries
and
the
knowledge
they
require

•  Expressive
power
required:
Efficient
inference
(requiring
limited

   expressive
power)
vs.
increased
expressivity
(requiring
expensive
or

   resource
bounded
computa.on)

•  Ad‐hoc
reasoning
to
deal
with
par.cular
domain
requirements:

    –  temporal
rela.ons,
geospa.al,
process‐specific,
condi.onal

       opera.ons

•  
Computa.onal
tractability

•  Need
for
Explaina.ons,
Traces,
Provenance

               Domain
requirements

•  Take
into
account
heterogeneity,
distribu.on,
and
autonomy
needs


     –  
soQware
agents
based
applica.ons;

•  Open
vs.
Closed
World
(does
lack
of
informa.on
imply
nega.ve

informa.on?)

•  Sta.c
vs
dynamic
ontology
processes:

     –  Evolu.on,
alignment

•  
Limited
or
incomplete
knowledge

•  
Knowledge
evolu.on
over
.me

•  Analysis
and
consistency
checking
of
instance
data

•  Use
Case
analysis
should
facilitate
the
understanding
of:

   
–
The
informa.on
that
is
likely
to
be
available

   
–
The
ques.ons
that
are
likely
to
be
asked

   
–
Types
and
roles
of
users

  Ontology
capture
analysis:
IDEF
5

•  The
lDEF5
Ontology
Capture
Method
aims
to
construct
ontologies
in

   a
way
that
closely
reflects
human
understanding
of
the
specific

   domain.
The
process
is
based
on
extensive
itera.ons,
discussions,

   reviews,
and
introspec.on.


•  Knowledge
extrac.on
is
a
discovery
process
requiring
considerable

   introspec.on.
Collabora.on
between
ontology
engineers
and

   domain
experts
in
a
group
effort.

•  Ontological
analysis
is
accomplished
by
examining
the
vocabulary

   that
is
used
to
discuss
the
characteris.c
objects
and
processes
that

   compose
the
domain,
developing
rigorous
defini.ons
of
the
basic

   terms
in
that
vocabulary,
and
characterizing
the
logical
connec.ons

   among
those
terms.


•  The
product
of
this
analysis,
an
ontology,
is
a
domain
vocabulary

   complete
with
a
set
of
precise
defini.ons,
or
axioms,
that
constrain

   the
meanings
of
the
terms
sufficiently
to
enable
consistent

   interpreta.on
of
the
data
that
use
that
vocabulary.

  Ontology
capture
analysis:
IDEF
5

•  The
IDEF5
ontology
development
process
consists
of
the

   following
five
(0verlapping)
ac.vi.es:

   –  Organizing
and
Scoping:
This
ac.vity
involves
establishing
the
purpose,

      viewpoint,
and
context
for
the
ontology
development
project
and

      assigning
roles
to
the
team
members.

   –  Data
Collec.on:
This
ac.vity
involves
acquiring
the
raw
data
needed
for

      ontology
development.

   –  Data
Analysis:
This
ac.vity
involves
analyzing
the
data
to
facilitate

      ontology
extrac.on.

   –  Ini.al
Ontology
Development:
This
ac.vity
involves
developing
a

      preliminary
ontology
from
the
acquired
data.

   –  Ontology
Refinement
and
Valida.on:
This
ac.vity
involves
refining
and

      valida.ng
the
ontology
to
complete
the
development
process.


   hdp://www.idef.com/IDEF5.html

             Conceptual
modelling

“A
data
model
describes
data,
or
database
schemas
–
an
ontology

   describes
the
world”

               
Adam
Farquhar,
“Ontology
101”,
Stanford
University,
1997


•  
Resources
and
their
rela.onships
are
described
from
an
objec.ve

   standpoint,
and
they
do
not
reflect
the
defini.ons
in
databases,
or

   the
views
of
programmers.

   –  Experts
from
different
backgrounds
with
significant
domain
knowledge
–

      will
classify
knowledge
differently
from
someone
interested
in

      op.miza.on
of
algorithms,
or
forcing
informa.on
into
an
exis.ng

      framework,
or
legacy
applica.ons


•  Shortcuts
at
the
top
levels
do
not
help;
automa.on
and

   mappingamong
ontologies
and
terminology
at
lower
levels
provides

   significant
benefit

              Conceptual
Modelling

•  Defini.ons
range
from
high‐level
mind

    maps…

to
detailed
collabora.on,
dialog,

    and
informa.on
modelling
to
support

    knowledge
sharing;

•  Tools
can
be
very
diverse,
from
inexpensive

    brainstorming
tools
and
shareware
to

    sophis.cated
ontology
and
soQware
model

    development
environments;

•  Common
features
include:

   
–
“drawing
a
picture”
that
includes

    concepts
and
rela.onships
between
them

   
–
producing
sharable
ar.facts,
that
vary

    depending
on
the
tool
–
oQen
including

    web
sharable
drawings

    Ontology
design
process

                            Requirement

                            and
domain

                              analysis



                                             Determine

           Add
Instances

                                               scope





  Define

                                                     Consider
reuse

constraints





                 Define
                      Enumerate

               proper.es
                      terms




                            Define
classes

      Determine
ontology
scope

Addresses
straight
forward
ques.ons
such
as:

•  What
is
the
ontology
going
to
be
used
for

•  How
is
the
ontology
ul.mately
going
to
be

   used
by
the
soQware
implementa.on?


•  What
do
we
want
the
ontology
to
be
aware
of,

   and
what
is
the
scope
of
the
knowledge
we

   want
to
have
in
the
ontology?

         Competency
Ques.ons


•  Which
inves.ga.ons
were
done
with
a
high‐fat‐
   diet
study? 


•  Which
study
employs
microarray
in
combina.on

   with
metabolomics
technologies? 


•  List
those
studies
in
which
the
fas.ng
phase
had

   as
dura.on
one
day. 


•  What
is
a
vegetarian
pizza?

•  What
type
of
wine
can
accompany
seafood?



    Ontology
design
process

                            Requirement

                            and
domain

                              analysis



                                             Determine

           Add
Instances

                                               scope





  Define

                                                     Consider
reuse

constraints





                 Define
                      Enumerate

               proper.es
                      terms




                            Define
classes

                 Consider
Reuse

•  We
rarely
have
to
start
from
scratch
when

   defining
an
ontology:


   –  There
is
almost
always
an
ontology
available
from
a

      third
party
that
provides
at
least
a
useful
star.ng

      point
for
our
own
ontology

•  Reuse
allows
to:

   –  to
save
the
effort

   –  to
interact
with
the
tools
that
use
other
ontologies

   –  to
use
ontologies
that
have
been
validated
through

      use
in
applica.ons

                  Consider
Reuse

•  Standard
vocabularies
are
available
for
most
domains,

   many
of
which
are
overlapping

•  Iden.fy
the
set
that
is
most
relevant
to
the
problem
and

   applica.on
issue

•  A
component‐based
approach
based
on
modules
facilitates


   dealing
with
overlapping
domains:

   –  Reuse
an
ontology
module
as
one
would
reuse
a
soQware

      module

   –  Standards;
complex
rela.onships
are
defined
such
that
term

      usage
and
overlap
is
unambiguous
and
machine
interpretable

•  Ini.al
brainstorming
with
domain
experts
can
be
highly

   produc.ve;
then
subsequent
refinement
and
itera.on
lead

   to
the
level
required
by
the
applica.on


Modular
ontologies

                  What
to
Reuse?

•  Ontology
libraries

   –  DAML
ontology
library
(www.daml.org/ontologies)

   –  Protégé
ontology
library
(protege.stanford.edu/plugins.html)

•  Upper
ontologies

   –  IEEE
Standard
Upper
Ontology
(suo.ieee.org)

   –  Cyc
(www.cyc.com)

•  General
ontologies

   –  DMOZ
(www.dmoz.org)

   –  WordNet
(www.cogsci.princeton.edu/~wn/)

•  Domain‐specific
ontologies

   –  UMLS
Seman.c
Net

   –  GO
(Gene
Ontology)
(www.geneontology.org)

    Ontology
design
process

                            Requirement

                            and
domain

                              analysis



                                             Determine

           Add
Instances

                                               scope





  Define

                                                     Consider
reuse

constraints





                 Define
                      Enumerate

               proper.es
                      terms




                            Define
classes

               Enumerate
terms

•  Write
down
in
an
unstructured
list
all
the
relevant

   terms
that
are
expected
to
appear
in
the
ontology

   –  Nouns
form
the
basis
for
class
names

   –  Verbs
(or
verb
phrases)
form
the
basis
for
property

      names


•  Card
sor.ng
is
oQen
the
best
way:

   –  Write
down
each
concept/idea
on
a
card

   –  Organise
them
into
piles

   –  Link
the
piles
together

   –  Do
it
again,
and
again

   –  Works
best
in
a
small
group

Example:

animals
&
plants
ontology


•    Dog
         •    Carnivore
   •    Dangerous

•    Cat
         •    Plant
       •    Pet

•    Cow
         •    Animal
      •    Domes.c
Animal

•    Person
      •    Fur
         •    Farm
animal

•    Tree
        •    Child
       •    DraQ
animal

•    Grass
       •    Parent
      •    Food
animal

•    Herbivore
   •    Mother
      •    Fish

•    Male
        •    Father
      •    Carp

•    Female
                        •    Goldfish

    Ontology
design
process

                            Requirement

                            and
domain

                              analysis



                                             Determine

           Add
Instances

                                               scope





  Define

                                                     Consider
reuse

constraints





                 Define
                      Enumerate

               proper.es
                      terms




                            Define
classes

 Define
classes
and
their
taxonomy

•  A
class
is
a
concept
in
the
domain:

   
–
Animal
(cow,
cat,
fish)

   
–
A
class
of
proper.es
(father,
mother)

•  A
class
is
a
collec.on
of
elements
with
similar

    proper.es

•  A
class
contains
necessary
condi.ons
for

    membership
(type
of
food,
dwelling)

•  Instances
of
classes

   
–
A
par.cular
farm
animal,
a
par.cular
person

   
–
Tweety
the
penguin

             Organise
the
concepts

           Example:
Animals
&
Plants

•    Dog
         •    Carnivore
   •    Healthy

•    Cat
         •    Plant
       •    Pet

•    Cow
         •    Animal
      •    Domes.c
Animal

•    Person
      •    Fur
         •    Farm
animal

•    Tree
                          •    DraQ
animal

                  •    Child

•    Grass
                         •    Food
animal

                  •    Parent

•    Herbivore
                     •    Fish

                  •    Mother

•    Male
                          •    Carp

                  •    Father

•    Female
                        •    Goldfish



                                                           49

                   Summary

•  Steps
of
ontology
design

  –  Analysis
and
requirements;

  –  Determine
scope;

  –  Consider
reuse;

  –  Enumerate
terms;

  –  Define
classes;