http://www.ontopia.net/© 2006 Ontopia AS 1

Towards an Ontology Design Methodology

Initial work

Lars Marius GarsholCTO, Ontopia

<larsga@ontopia.net>

TMRA 2006

2006-10-11

http://www.ontopia.net/© 2006 Ontopia AS 2

Agenda

• Background– why this is important– what it includes

• The process– some background– roles– steps

• The guidelines– examples

• Conclusion– further work

http://www.ontopia.net/© 2006 Ontopia AS 3

Background

Why this is important

What it includes

http://www.ontopia.net/© 2006 Ontopia AS 4

The ontology challenge

• For many customers, creating the ontology is the biggest hurdle– it’s something new to them, and they don’t 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

http://www.ontopia.net/© 2006 Ontopia AS 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”, ...

In the paper

http://www.ontopia.net/© 2006 Ontopia AS 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

http://www.ontopia.net/© 2006 Ontopia AS 7

The process

Background

Roles

Steps

http://www.ontopia.net/© 2006 Ontopia AS 8

Simplified process view

VisionLacking

source data

Can’t analyse

domain

Lack of

project consensus

http://www.ontopia.net/© 2006 Ontopia AS 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

http://www.ontopia.net/© 2006 Ontopia AS 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

http://www.ontopia.net/© 2006 Ontopia AS 11

The role of the ontology

Ontology

DevelopersProject manager

End-usersEditors

Authors

Data integration

Presentation logic

Editorial system

http://www.ontopia.net/© 2006 Ontopia AS 12

Ontology considerations

Requirements

End-user needs

Interface issues

Ontology

Existing data

http://www.ontopia.net/© 2006 Ontopia AS 13

Startup

• Usually a workshop– project manager, editors, ontology modeller– presentation + Q&A

• Key goals– establish requirements– get overview of data sources

Startup

Analysis

End-user

DraftingInteraction

designVerification

http://www.ontopia.net/© 2006 Ontopia AS 14

Analysis

• 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

Startup

Analysis

End-user

DraftingInteraction

designVerification

http://www.ontopia.net/© 2006 Ontopia AS 15

End-user

• Well-known IA/UX exercise– competency questions– personas– end-user interviews– card sorting– ...

• Ontology modeller + IA/UX person + end-user examples

Startup

Analysis

End-user

DraftingInteraction

designVerification

http://www.ontopia.net/© 2006 Ontopia AS 16

Drafting

• 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 don’t understand it, anyway

Startup

Analysis

End-user

DraftingInteraction

designVerification

http://www.ontopia.net/© 2006 Ontopia AS 17

Interaction design

• 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

Startup

Analysis

End-user

DraftingInteraction

designVerification

http://www.ontopia.net/© 2006 Ontopia AS 18

Verification

• 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

Startup

Analysis

End-user

DraftingInteraction

designVerification

http://www.ontopia.net/© 2006 Ontopia AS 19

Guidelines

Some examples

http://www.ontopia.net/© 2006 Ontopia AS 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 Trainor’s tutorial yesterday– only a small subset covered here for illustration purposes

http://www.ontopia.net/© 2006 Ontopia AS 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”

http://www.ontopia.net/© 2006 Ontopia AS 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

http://www.ontopia.net/© 2006 Ontopia AS 23

Conclusion

Further work

http://www.ontopia.net/© 2006 Ontopia AS 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!– <larsga@ontopia.net>