http:// 2006 ontopia as1 towards an ontology design methodology initial work lars marius garshol...
Post on 19-Dec-2015
218 views
TRANSCRIPT
http://www.ontopia.net/© 2006 Ontopia AS 1
Towards an Ontology Design Methodology
Initial work
Lars Marius GarsholCTO, Ontopia
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!– <[email protected]>