Towards an Ontology Design Methodology

1
Towards an Ontology Design Methodology

• Initial work

Lars Marius Garshol CTO, Ontopia ltlarsga_at_ontopia.n
etgt TMRA 2006 2006-10-11
2
Agenda

• Background
• why this is important
• what it includes
• The process
• some background
• roles
• steps
• The guidelines
• examples
• Conclusion
• further work

3
Background

• Why this is important
• What it includes

4
The ontology challenge

• For many customers, creating the ontology is the
  biggest hurdle
• its something new to them, and they dont know
  how to approach it
• the technology is new, and so most consultants
  are not familiar with it
• this makes the process of creating the ontology
  seem very intimidating
• it also means that the costs and challenges are
  unknown
• Successfully developing an ontology is
  non-trivial
• it can be politically challenging
• the ontology interacts with every other part of
  the project...
• ontology modelling requires analytical skill
• the ontology is constrained by economical and
  technical considerations

5
The methodology vision

• A defined process
• roles involved in the process
• a defined series of steps to follow
• A set of modelling guidelines
• essentially heuristics for the correct use of the
  constructs in Topic Maps
• A pattern library
• common solutions to common problems
• A base ontology
• PSIs for common concepts like person,
  description, ...

6
Scope

• There are two general classes of applications
• information retrieval-type applications
• portals, library systems, publishing solutions,
  KM solutions, ...
• traditional applications
• CRM systems, product configuration applications,
  business process modelling, ...
• Ontology design is different for these two
  applications
• in traditional applications
• the domain is already well-understood
• the needs of the end-users are well-understood
• none of this applies to information retrieval
  applications
• Methodology focuses on information retrieval
  applications
• process especially
• guidelines are general

7
The process

• Background
• Roles
• Steps

8
Simplified process view
Lacking source data
Lack of project consensus
Vision
Cant analyse domain
9
The process exists to handle these challenges

• Source data gap or analysis gap
• make sure you discover the gap in time
• make sure you can find ways to plug it, or work
  around it
• Project consensus
• including the right people in the right way at
  the right time builds consensus
• it also ensures people know what they need to
  know
• Manage dependencies
• keep track of what depends on the ontology

10
Roles

• Project manager
• runs the project
• Developers
• write the code
• System owners
• make the decisions regarding the project
• Data source owners
• manage systems which provide data to the new
  system
• usually not part of the project
• End-user
• user of the final system

• Ontology modeller
• person responsible for ontology
• Editors
• people responsible for data in the system
• Authors
• people who write the content in the system
• Domain expert
• someone with knowledge of the domain

11
The role of the ontology
Ontology
12
Ontology considerations
Ontology
13
Startup
Analysis
Drafting
Interaction design
Verification
Startup
End-user

• Usually a workshop
• project manager, editors, ontology modeller
• presentation QA
• Key goals
• establish requirements
• get overview of data sources

14
Analysis
Analysis
Drafting
Interaction design
Verification
Startup
End-user

• Usually interviews with data source owners
• extract documentation, schemas, exports, ...
• use torture if necessary
• Key goals
• understanding of what really is in the data
  sources

15
End-user
Analysis
Drafting
Interaction design
Verification
Startup
End-user

• Well-known IA/UX exercise
• competency questions
• personas
• end-user interviews
• card sorting
• ...
• Ontology modeller IA/UX person end-user
  examples

16
Drafting
Analysis
Drafting
Interaction design
Verification
Startup
End-user

• The ontology modeller produces a draft
• should use diagrams to communicate design
• UML, ORM, boxes-and-arrows, or (later) GTM
• Draft must be reviewed with project team
• editors, developers, project manager
• nobody reads documentation
• if they do, they dont understand it, anyway

17
Interaction design
Analysis
Drafting
Interaction design
Verification
Startup
End-user

• A well-known exercise
• experienced interaction designers are out there
• Ensure that
• ontology supports proposed design
• ontology and proposed design use a consistent
  vocabulary
• Output
• normal interaction design documentation
• updated ontology

18
Verification
Analysis
Drafting
Interaction design
Verification
Startup
End-user

• Final quality assurance on ontology
• first conversion from data sources
• review interaction design against ontology
• verify ontology against output from end-user
  phase
• verify ontology against requirements from startup
  phase
• final team review of ontology

19
Guidelines

• Some examples

20
What is in the guidelines

• Heuristics for the correct use of Topic Maps
  constructs
• topic types
• type hierarchy
• association types
• occurrence types (internal and external)
• name types
• The Ontopia ontology design course has the full
  set
• taught in Kevin Trainors tutorial yesterday
• only a small subset covered here for illustration
  purposes

21
Criteria for a good topic type

• Instances should, by their intrinsic nature, be
  instances of the type
• when shown an example instance and asked what is
  this? end-users should reply with the name of
  the topic type
• instances should be instances of this topic type
  from the moment they come into being, until they
  cease existing
• Should not be context-dependent
• not a role type (like composer, employee, or
  subject)
• The topic type should be a natural kind

22
Heuristics for association types

• Keep number of roles as low as possible
• decompose n-ary associations if possible
• Have a consistent set of role types
• all instances should have the same set of role
  types
• omissible roles is acceptable
• do not attach semantics to variation in role
  types
• Create a topic for an n-ary association if (and
  only if)
• you want to say something more about the
  association

23
Conclusion

• Further work

24
Further work

• The methodology has moved on since the draft was
  written
• need to flesh it out and bring it into line with
  this presentation
• Pattern library and base ontology need to be
  developed
• this will follow in a separate phase after the
  paper is done
• Input from practitioners wanted!
• ltlarsga_at_ontopia.netgt