Ontology engineering ESTC2008

Ontology Engineering

Tutorial

Dr. Elena Simperl
Dr. Christoph Tempich
24.09.2008

Presenters

Dr. Elena Simperl Dr. Christoph Tempich

I am working as a senior researcher in the areas of I am a management consultant in the CP
semantic systems and technologies at STI Information Technology. at Detecon International.
Innsbruck, University of Innsbruck.
Sectors
Sectors
 Telecommunication, Automotive.
 ICT.
Functions
Functions
 Enterprise Information Management.

ESTC2008_ONTOLOGYENGINEERINGTUTORIAL_CT_V04_080916.PPT
 R&D.
 Technology markets and innovation.
 Education and training.
Experience
Experience
 Consulting at Detecon International and
 Vice director STI Innsbruck, STI International Bearingpoint (KPMG).
service coordinator for education.
 More than 10 years Semantic Web research.
 8 years of experience in Semantic Web research
 Workshops and more than 40 publications.
and development
 Two Innovation Awards for Semantic Web
 Management of more than 10 national and EU
applications.
projects

Page 1

Management Summary
You will learn how to convince your CEO to start an ontology engineering initiative and
how to implement it successfully in your company.

 The core objective of Information Management is to enable informed decision making.
 Ontologies play an increasing role in holistically organizing enterprise information.

In the tutorial we will position Ontology Engineering in the broader context of
Enterprise Information Management.

We will introduce the five steps - setup, requirements analysis, glossary creation,
modeling, test - of our methodology for developing ontologies in an enterprise context.

 For each step we will present the roles of participating actors, the methods and software available to
guide and even partially automatize particular tasks, and metrics which can be used to assess the
quality of the intermediary outcomes.

 In addition we will discuss best practices and guidelines related to critical aspects of
Ontology Engineering:
 Modeling specific types of knowledge.
 Resolving conflicts in collaborative ontology building processes through argumentation.
 The automatic generation and learning of ontologies from existing unstructured data sources.
 Ontology engineering economics.

Page 2

Content

1. Motivation

2. Enterprise Information Management

3. Ontology Engineering Methodologies

4. Ontology Development

5. Useful Management and Support Methods

6. Conclusion

Page 3

Content

1. Motivation
Vision
Customer Challenges and Benefits
Ontology Engineering Definition
What Do You Expect from This Tutorial?
Tutorial Overview

Page 4

Motivation
Vision
Seamless data integration across different data sources on the Web is a great challenge.
It also promises huge business opportunities and cost savings.

Web-scale data integration Description

 Semantic technologies refer to
techniques to help a computer
program automatically
process and use arbitrary data
(and services) in a meaningful
way.
 After a decade of intensive

research semantic
technologies seem to be the
best candidate to offer the
underlying technology for
Web-scale data integration.
 Ontologies are a core enabler
of this vision.
 Relevant terms: Web 2.0,
Web 3.0, Semantic Web
Services, Semantic Web.

Page 5

Motivation
Customer Challenges and Benefits
Enterprise Information Management aims to handle the rapidly growing amounts of
information relevant to an enterprise business.

Challenges Benefits

 The amount of available and potentially relevant  A flexible information infrastructure which allows
information is growing exponentially. to manage the growing amount of information.
 The time for decision making is decreasing  Flexible integration with business processes to
continuously. account for changing business requirements.
 Decision making is based on multiple highly  Up-to-date information for accurate decision
heterogeneous, distributed and rapidly changing making.
information sources.

 Fulfillment of regulatory requirements.
 The explosion of information is facilitated by
 Timely and informed interaction with customers
technical developments such as RFID , email,
responding to their needs.
Web, Internet.
 Identification of information leakage, customer
 Enterprises need an intelligent information
demands and cost drivers.
infrastructure which delivers the right information
at the right place in the right time.
 Data Governance is required for clear
responsibilities.

Page 6

Motivation
“the set of activities that concern the ontology development process, the ontology
life cycle, and the methodologies, tools and languages for building ontologies”.*

Methodologies:
 Distributed
 Centralized Ontology
Languages Development
 OWL Process

 RDF(S)  Requirements

 SPARQL  Evaluation

 Documentation

Ontology Life Application
Cycle: Scenarios
 Development  Search
Tools
 Maintenance  Integration
 Ontology development
 Storage, reasoning,
alignment, Web interaction,
interfaces
*Source: Gómez-Pérez, A. et. al.: Ontological Engineering. Advanced Information and Knowledge Processing. Springer, 2003.
Page 7

Motivation
What Do You Expect from This Tutorial?
Please tell us ...

Examples

Content Personal Situation

Presenters

Format Objectives

Interaction

Page 8

Motivation
Tutorial Overview
In this tutorial we focus on the ontology development process and introduce
methodologies, applications scenarios and tools.

Methodologies:
 Distributed
 Centralized Ontology
Languages Development
 OWL Process

 RDF(S)  Requirements

 SPARQL  Evaluation

 Documentation

Ontology Life Application
Cycle Scenarios
 Development  Search
Tools
 Maintenance  Integration
 Ontology development
 Storage, reasoning,
alignment, Web interaction,
interfaces

Page 9

Content

2. Enterprise Information Management
Definition
Information Value Chain
Market Growth
Enterprise Ontologies
Application Scenarios for Ontologies

Page 10

Enterprise Information Management
Definition
Enterprise Information Management takes an holistic view on decision relevant
information available within an enterprise.

Vision

Strategy

Governance
Enterprise
Data Social
BI and Content
Management Software Master Data

Organization Performance Management
and and Management
Management and Search
Integration Collaboration
Process

Enabling
Infrastructure

Metrics

Source: Gartner 2007, EIM conference 2008, Detecon Research 2008.

Page 11

Information Value Chain
Positioning of the Enterprise Information Management in the overall software application
market.

Storage/
Generation Processing Integration Analysis Presentation
Archiving
un-struc-

Web
tured

Enterprise Information Management Content
Analytics
external

Web 2.0 Sources
structured structured

Mashups
Intelligent
Social Networks Decision Portals,
E
B2B Mgmt. reports ,
T
Integr. Fraud dashboards,
Master Data Management L
ERP, CRM, Detection scorecards
SCM Data
EAI, SOA BI / BPM
internal

Warehouse
unstruc-

Email
tured

Enterprise
Enterprise Content Management
Search

Page 12
For illustrative purposes and without changing the implications the value chain is displayed in a linear form.

Market Growth
Information Management software and services are the fastest growing segment in the
software market because they leverage information in core business applications.

Market development Assessment

Western European IM software market  Data integration is a core
enabler for all other IM
CAGR BI and initiatives.
4.53B€ performance  BI and Performance
4.10 management Management are the major
11% 3.72 Data management topics for IM.
3.35 6.2% and integration
 Competing on analytics has

3.01 MDM
2.70 Enterprise content become a key issue, as
2.42 management and innovation leaders use
16.3% search analytics as a means to profit
Social software growth.
23 %
and collaboration  More important than the
technical solutions for IM are
13.7%
vision, strategy, policy,
process and organizational
15.0%
issues.
2006 2007 2008 2009 2010 2011 2012
Source: Gartner, April 2008.

Page 13

Ontologies and Enterprise Information Management
Ontologies are at the core of Enterprise Information Management.

Master Data
Data Integration
Management

Structured Information Social Networks

Enterprise Ontology

Unstructured
Business Analytics
Information
Data Governance

Page 14

Classification of Ontologies
Ontologies can be classified according their formality. You might be familiar with some
of these categories.

Thessauri General
Formal Frames Logical
“narrower term”
Catalog/ID is-a (properties) constraints
relation

Terms/ Informal Formal Value Disjointness,
glossary is-a instance Restrs. Inverse, part-Of
...

Source:Lassila O, McGuiness D. The Role of Frame-Based Representation on the Semantic Web. Technical Report. Knowledge Systems Laboratory.
Stanford University. KSL-01-02. 2001.

Page 15

Types of Ontologies
Ontologies can be classified according to their degree of reusability.

R Application Domain Application Domain
E Ontology Task Ontology
U
S Domain Ontology Domain Task Ontology
A
Core Ontology Task Ontology
B

I
Top-Level Ontology
L
I
General/Common Ontology
T
Y
Representation Ontology

Page 16

Application Scenarios for Ontologies
Ontologies are a means to enable interoperability between machines. They also facilitate
communication between people providing a shared representation of a domain.

Neutral Authoring Ontology-based Search

 Bases for application  Ontologies provide the
development as core data structure for the navigation of
model for all applications. the results, support browsing
and classification.
 Typical use case in AI.
 Ontologies allow for term
disambiguation and query
rewriting.

Ontologies
 Global view on information.  Specification of software
systems and automation of
 Organization and
code generation.
management of information
sources and their interrelation.  MDA.
 Consistency checking.  SOA.
 Currently most relevant use
case for enterprises.
Common Access to Information Ontology-based Specification
Source: Jasper & Uschold, 1999.
Page 17

Application Scenarios for Ontologies: Common Access to Information
Building a semantic application is feasible. However it still requires deep technology
insight and best practices for system integration are still under development.

Ontology Mapping of
Feasibility Requirements development data sources Set-up storage Application

Stakeholders*
 Consultants (few  System  Technology  Technology  Technicians  System
consultants integrators (only consultants (Few consultants (Scalable stores integrators (user
available small players). consultants, (Technology available, good interfaces
understanding engineering requires deep vendor support). available,
 Weakest part in
the benefit). environment technical skills).  Integration with customization
the value chain.
available). all kinds of data required,
 Decision makers  Technology ready
bases possible. expertise not
(technicians, less  Staff (requires for structured da-
available).

C-level knowledge ta sources, not
awareness) . transfer). ready for unstruc-
tured sources.
Key Deliverables
 Feasibility study.  Detailed  Ontology.  Mapping of data  Integration of  User interface.
 Identification of description of sources to triplestores with
 Sample queries.  Process to
data stores to be application. ontology. data sources by
means of support
integrated.  Translation.
 Evaluation  Enterprise application.
mappings.
 Business case- criteria.  Logical model. ontology based
 SOA
SOA messages.  Scalable storage
 Detailed  Documentation of infrastructure.
 Rough solution.
application description of ontology.
data sources.  Maintainability.
architecture.  Maintainability of
 Application ontology.
scenario
*Who should do it (current problems)
Page 18

Content

3. Ontology Engineering Methodologies
Historical Background
Methodologies Related to Knowledge Management Systems
Methodologies Related to Software Engineering
Distributed Ontology Engineering
New Approaches

Condensed Version

Page 19

Ontology Engineering Methodologies
“a comprehensive, integrated series of techniques or methods creating a general
systems theory of how a class of thought-intensive work ought be performed”*

Typical Elements of a Methodology Description

Application scenario
 The application scenario of a
methodology describes the
general settings to which the
methodology is applicable.
Process Process

 The process describes the
activities and tasks, including
their sequence, input and
Application
output, to be performed by the
scenario
stakeholders.

Tools Roles
Roles
 Describe the responsibilities
and tasks of different
stakeholders in the process.

*Source: IEEE, 1990.
Page 20

Historical Background
The development of ontology engineering methodologies has a long history and was
strongly influenced by specific project experiences of the authors.

CommonKADS
Enterprise Ontology [Schreiber et al., 1999]
[Uschold & King, 1995]

IDEF5
[Benjamin et al. 1994]
Holsapple&Joshi
[Holsapple & Joshi, 2002]
CO4
[Euzenat, 1995]

Page 21

Methodologies Related to Knowledge Management Systems
The On-To-Knowledge methodology takes a pragmatic approach to ontology engineering
and contains many useful tips to support non-experts to build an ontology.

Go / Sufficient Meets
Roll-out? Changes?
Description
No Go? requirements requirements
? ?
Common ORSD + Target Evaluated Evolved
KADS Semi-formal ontology ontology ontology  Suited for developing
Human
Worksheets ontology
description
ontologies for knowledge
Issues
management applications.

Refine- Evalu-
Application Knowledge
Feasibility
study
Kickoff
ment ation
& Management Process

Evolution
Application  Sequential/iterative process.

Software
Identify .. 5. Capture 7. Refine semi- 10. Technology- 13. Apply
Engineering Roles
1. Problems & requirements formal ontology focussed ontology
opportunities specification in description evaluation 14. Manage
ORSD
 Ontology engineers design the
2. Focus of KM 8. Formalize into 11. User- evolution and
application 6. Create semi- target ontology focussed maintenance ontology and interact with
3. (OTK-) Tools formal ontology 9. Create evaluation domain experts to develop it.
description Prototype 12. Ontology-
4. People
focussed
evaluation

Ontology Development
Source: Sure, 2003.
Page 22

Methodologies Related to Software Engineering
METHONTOLOGY contains the most comprehensive description of ontology engineering
activities. It is targeted at ontology engineers.

Ontology Management
Scheduling, controlling, quality assurance
Description

Feasibility study
Problems, opportunities, potential solutions, economic feasibility
 Generic methodology for
ontology development in
centralized settings.
Knowledge acquisition

Domain analysis
motivating scenarios, competency questions, existing solutions
Ontology reuse
Ontology reuse
Documentation

Process
Evaluation

Conceptualization  Serial process comparable to

conceptualization of the model, integration and extension of the waterfall model in software
existing solutions
engineering.

Implementation Roles
implementation of the formal model in a representation language
 The ontology is developed by
ontology engineers.
Maintenance
adaptation of the ontology according to new requirements
 Users are not directly involved
in the engineering process.

Use
ontology based search, integration, negotiation

Source: METHONTOLOGY, Gómez-Pérez, A. ,1996.
Page 23

Distributed Ontology Engineering
DILIGENT is a methodology for distributed ontology engineering. It focuses on
consensus building aspects through argumentation.

Description
2. Local
Adaptation Application scenario
1. Central O1 3. Central  Generic methodology for
Build Analysis ontology development in
5. Local
decentralized settings.
Update
Process
OI O-User 1  Rapid prototyping process
Ontology …

with short update cycles.
User Domain Ontology
Board
Expert Engineer Roles
On  Users actively participate in
O-User n
the ontology engineering
process.
Knowledge  Modeling decisions are made
Engineer 4. Central by a board including ontology
Revision engineers.

Source: DILIGENT: Tempich, 2006.

Page 24

New Approaches
Recent methodologies concentrate on decentralization. They apply Web 2.0 paradigms in
order to facilitate the development of community-driven ontologies.

Wikis Games Tagging

 Employing Wikis in  Usage of games with  Tagging is a very
ontology engineering a purpose to motivate successful approach
enables easy humans to undertake to organize all sorts of
participation of the complex activities in content on the Web.
community and lowers the ontology life cycle.
 Tags often describe
barriers of entry for non-  During such a game, the meaning of the
experts. players describe tagged content in one
images, text or term.

 So far less suitable for
developing complex, videos. Players
 Approaches to derive
highly axiomatized receive a higher score
formal ontologies from
ontologies. if they describe the
tag clouds are
content in the same
emerging.
way.

Ontology engineering increasingly becomes an community activity.
Source: Siorpaes 2008, Braun 2007.
Page 25

Condensed Version
In our project experience we found out that a number of process steps and activities
distinguish ontology development from related engineering efforts. They are crucial for
the success of an ontology development project.

Requirements analysis
motivating scenarios, use cases, existing solutions,

effort estimation, competency questions, application requirements
Test (Evaluation)
Documentation

Glossary creation (Conceptualization)

conceptualization of the model, integration and extension of
existing solutions

Modeling (Implementation)

Page 26

Content

4. Ontology Engineering
Overview
Set-up
Requirements Analysis
Glossary Creation
Modeling

Testing

Page 27

Overview
We present an ontology engineering process consisting of 5 steps. We describe those
aspects of the engineering process which are essential for its successful
implementation.
Condensed Ontology Engineering Process Elements to Be Discussed

Requirements analysis
motivating scenarios, use cases, existing solutions,
Knowledge acquisition effort estimation, competency questions, application requirements
Test (Evaluation)
Documentation

Glossary (Conceptualization)
conceptualization of the model, integration and extension of
existing solutions

Modeling (Implementation)

Objectives
Req. Glossary
analysis
creation
Process step
Set-up Ontology
Methods,
Examples
activities
Test and tools
Modeling

Page 28

Set-up: Objectives
In the set-up phase the project manager organizes the ontology development project and
gets the buy-in of all stakeholders in order to enable a smooth project implementation.

Objectives Input

 Buy-in of all stakeholders (management, project  Management contract to design an ontology.
managers, business units, developers) to the
 Business objectives and alignment with
proposed ontology engineering process.
business strategy.
 The scope of the ontology in terms of domains is
 Business goals and business drivers.
clear.
 The application scenario for the ontology is
defined (integration, search, communication,

etc).
 The number and types of applications are Output
defined.
 Defined ontology engineering process.
 The proposed tool chain works smoothly.
 Defined high-level application scenario
 List of stakeholders.
 List of relevant domains to be modeled.
 Operational tool chain.
 Training material.

Page 29

Set-up: Methods, activities and tools
The set-up step can be completed within one month.

Activities Methods Tools

Define objectives Workshops Ontology requirements specification document (ORSD).
Contains information about the goal, domain and scope of the ontology.
Specifies design guidelines, naming conventions.
Lists knowledge sources, potential users, usage scenarios and supported
applications.

Project Effort ONTOCOM for development effort estimation, project management tools
management estimation

Select Workshops, Existing standards and ontologies.
information research
e.g., TM Forum defines NGOSS Shared Information/Data Model (SID)
sources and
(domain model for the telecommunication industry), Gist (http://gist-
reusable
ont.com/) Semantic Arts Inc. (upper ontology), OASIS (standardization
ontologies
body)
Internal definitions, thesauri, glossaries, hierarchies, domain models.

Set-up tool chain Proof of Specify requirements for tracking tool, glossary documentation tool,
concept ontology engineering environment, ontology learning tool (if applicable),
data integration tool, reasoner, SOA environment, triplestore, enterprise
applications (if applicable), representation language.
Page 30

0. Set-up: Examples
We provide some examples for the selection of the relevant setting or use case.

Be clear about why the ontology is being developed and what its intended usages are.
 Data and process interoperability.
 Systems engineering.
 Semantic search.
 Semantic annotation.
 Communication between people and organizations.

Semantic search.
 Semi-formal ontology.
 Usage of natural language labels and naming conventions.
 Well-balanced at schema and instance level.
 Rich conceptualization.
 Syntactical and semantic correctness.

The ontology should not contain all the possible information about the domain of interest.

Page 31

Set-up: Examples
Examples of existing reusable ontologies are the TMForum SID domain model and the
GIST upper ontology.

SID domain model GIST upper ontology

Page 32

Requirements Analysis: Objectives
In the requirements analysis step the project team collects the expectations from the
stakeholders towards the ontology.

Objectives Input

 Guidelines for the modeling phase.  Scope and application scenario of the ontology.
 Criteria for the evaluation of the engineering  Information sources.
effort.
 Domain of the ontology.
 Agreement on ontology use cases for the
ontology between stakeholders.

 The development of the ontology is pursued
in monthly cycles.
Output
 Although requirements can be collected at
all times, they should be prioritized.  Competency questions and use case
descriptions forming the list of requirements.
 We select an excerpt of the total list of
requirements such that they can be
implemented and tested within one month.

Page 33

Requirements Analysis: Methods, activities and tools
Collecting competency questions is a proven method to describe the requirements for
an ontology.


Collect Collaboration, brainstorming. (Semantic)wiki to
requirements store and describe
Competency questions
requirements.
 A set of queries which place demands on the underlying ontology.
 Ontology must be able to represent the questions using its terminology
and the answers based on the axioms.
 Ideally, in a staged manner, where consequent questions require the
input from the preceding ones.

 A rationale for each competency question should be given.

Discuss and Argumentation, workshops DILIGENT
select relevant argumentation
requirements framework.

Align with Workshops
business  Collect requirements from the business process owners and align
process them with the information needs in the respective process.

Page 34

Requirements Analysis: Examples
We present examples of requirements produced in this step.

Competency Questions Other Requirements Issues

 Which wine characteristics  Concepts in the ontology  An ontology reflects an
should I consider when should be bi-lingual. abstracted view of a domain of
choosing a wine? interest. You should not
 The ontology should not have
model all possible views upon
 Is Bordeaux a red or white more than 10 inheritance
a domain of interest, or to
wine? levels.
attend to capture all
 Does Cabernet Sauvignon go  The ontology should be knowledge potentially
well with seafood? extended and maintained by available about the respective

non-experts. domain.
 What is the best choice of
wine for grilled meat?  The ontology should be used  Even after the scope of the
to build an online restaurant ontology has been defined,
 Which characteristics of a
guide. the number of competency
wine affect its appropriateness
questions can grow very
for a dish?  The ontology should be usable
quickly  modularization,
on an available collection of
 Does a flavor or body of a prioritization.
restaurant descriptions written
specific wine change with
in German.  Requirements are often
vintage year?
contradictory  prioritization.

Source: Ontology Development 101.
Page 35

Glossary Creation: Objectives
The glossary is the reference for all further activities. It describes the terms of the
ontology in a comprehensive manner.

Objectives Input

 Define terms of the ontology in natural language.  List of requirements.
 Build up the body of knowledge of the terms
used in an organization.
 Facilitate communication within the organization.
 Buy-in from all stakeholders in terms of selected
objects, descriptions and relationships.

 Alignment of objects with business processes.
Output
 Important terms of the domain.
 Descriptions of the terms with examples.
 Usage scenarios of the terms in the process.
 High-level relationships between terms.
 Alignment of glossary terms an business
processes.

Page 36

Glossary Creation: Methods, activities and tools
Wiki technology is very suitable to support the creation and documentation of the
glossary, because it enables easy collaboration and access.


Collect glossary terms. Workshops, collaboration. (Semantic) wikis to collect terms.

Describe the glossary terms in (Automatic or semi- A top-down development process
their application context, list automatic) Knowledge starts with the definition of the most
synonyms, list domain acquisition techniques, e.g. general concepts in the domain and
assumptions, give examples of Information Extraction, subsequent specialization of the
instances of the glossary terms. Ontology Learning. concepts.
A bottom-up development process

Define hierarchical relationships
starts with the definition of the most
between glossary terms.
specific classes, the leaves of the
Define domain relationships hierarchy, with subsequent grouping of
among glossary terms. these classes into more general
concepts.
A middle-out approach: define the more
salient concepts first and then
Align business processes with
generalize and specialize them
glossary terms.
appropriately.

Page 37

Glossary: Examples
The glossary is the first step towards an axiomatized ontology.

Collect Glossary Terms Hierarchy Visualization

 wine, grape, winery, location,  Apple is a subclass of Fruit. Top
wine color, wine body,  Every apple is a fruit. level
 wine flavor, sugar content,  Red wines is a subclass of
white wine, red wine, Wine.
 Bordeaux wine, food, seafood,  Every red wine is a wine.
fish, meat, vegetables, Middle
 Chianti wine is a subclass of
level

 cheese… Red wine.
 Every Chianti wine is a red
wine.
and not

 sightseeing Tuscany, atoms
and molecules of alcohol,
underage drinking laws…
Bottom
level
Source: Ontology Development 101.
Page 38

Modeling: Objectives

In the modeling step the glossary terms are transferred in the target representation
language.

Objectives Input

 Development of a machine understandable  Glossary.
ontology.
 Development of a reusable ontology.
 Input for the application.

Output
 Class descriptions.
 Hierarchy.
 Attributes of each class.
 Associations and other type of relationships
among classes.
 Restrictions/constraints on classes.

Page 39

Modeling: Methods, activities and tools
The complexity of the modeling step depends on the representation language and on
the complexity of the requirements.

Define classes, their attributes and Depending on the representation e.g., Protégé, Ontoprise’
relationships. language different modeling OntoStudio, TopQuadrant’s
primitives are available: Topbraid Composer, Altova,
OntologyWorks, IBM, tools for
 Cardinality, domain and
thesaurus or taxonomy building.
range restrictions.
 Hierarchies of
relationships.

 Inverse, functional,
transitive relationships.
 Equivalence.
 Disjoint classes.

Define and apply modeling Reusing modeling patterns. Collections of patterns available
patterns. from software engineering and
modeling.

Integrate with existing application Ontology alignment and mapping. Open sources prototypes
environment. available.

Relate to upper ontology. Upper ontology. Consistency checking, ontology
Page 40
alignment tools.

Modeling: Examples
Ontology development is supported by a variety of tools. Besides OWL and RDFS, UML
is gaining increasing attention as an ontology modeling language.

Ontology in UML Guidelines
 There is no unique way to
model a domain correctly —
there are always viable
alternatives. The best solution
always depends on the
application that you have in
mind and the extensions that
you anticipate.

 Ontology development is
necessarily an iterative
process.
 Concepts in the ontology
should be close to objects
(physical or logical) and
relationships in your domain
of interest. These are most
likely to be nouns (objects) or
verbs (relationships) in
sentences that describe your
domain.

Page 41

Modeling: Examples
The entity specification pattern allows to add characteristics to an entity without
changing the model. Useful if large numbers of attributes need to be represented.

Entity Specification Characteristic/Entity Characteristic Pattern

0..n 0..1 0..n
EntitySpecification Entity
E.g Mobile Entity SpecificationDescribes
0..n 1
EntitySpecCharacterizedBy
EntitySpecDescribedBy 0..n
0..1 Entity SpeciCharacteristicDescribes
EntitySpecCharacteristic
E.g Color Entity DefineBy
1
EntitySpecCharEnumeratedBy
0..n 0..n 0..n
0..n 0..1 0..n
EntitySpecCharacteristicvalue EntityCharacteristicvalue
E.g Chocolate, red, … E.g Chocolate
Entity SpeciCharValueDescribes

Source: TMForum, SID.

Page 42

Modeling: Examples
The business interaction pattern facilitates the representation of e.g., the communication
with a client in a business context.

Business Interaction

BusinessInteractionType
1

BusinessInteractionTypeCategorize
0..n
BusinessInteractionRelationship
BusinessInteractionInvolvesLocation BusinessInteraction 0..n
Place 0..n 0..n
BusinessInteractionReferences
0..n
BusinessInteractionLocation
1

BusinessInteractionInvolves
0..n
BusinessInteractionRole

PartyRole ResourceInteractionRole CustomerAccount
InteractionRole
Source: TMForum, SID.

Page 43

Test: Objectives
The test step should ensure that the result of the modeling phase does indeed meet the
requirements set in the requirements analysis phase

Objectives Input

 Tested ontology.  Modeled ontology.
 Running proof-of concept.  Requirements.
 Satisfaction of the stakeholders.
 Demonstration to top management that the
approach works.
 Early possibility to adapt approach.

Output
 Refined and tested ontology.

Page 44

Test: Methods, activities and tools

In the test phase the stakeholders get a direct feedback if their effort has been
successful.


Test queries and consistency Unit tests. Often supported by ontology
checking. engineering environment.

Deploy ontology in proof-of- Proof-of-concept. -
concept set-up.

Run different test corresponding to Test methods known from Tools used in Software
the requirements. Software Development. Development.

Page 45

Content

5. Useful Methods
OntoCom – Effort Estimation for Ontology Engineering
Modeling Guidelines
Argumentation

Page 46

Content

Ontocom – Effort Estimation for Ontology Engineering
Modeling Guidelines
Argumentation

Page 47

Ontocom
Management Summary
Ontocom is a framework to help you estimate the effort related to the building of an
ontology. It make accurate predictions and can be improved with data from your team.

Elements Description
 Ontocom is a framework to estimate the effort
related to ontology development.
 Ontocom comes with
 A process for effort estimation.
 A formula and a tool calculating the
estimations. and

Process  A methodology to adjust the estimations
to a particular company.
 Ontocom takes the size, the domain, the
Ontocom development complexity, the expected
quality and the experience of the staff as
input factors.
Formula Methodology  Ontocom estimates ontology development costs
with a 30% accuracy in 80% of the cases.

Page 48

Ontocom
Process
Applying Ontocom is easy and follows a five step process. The project manager defines
the different parameters based on the process guidelines which are part of the framework.

Evaluation of
Evaluation of Evaluation of
Size the Evaluation of

the domain the expected Effort estimation
estimation development the personnel
complexity quality
complexity

Page 49

Ontocom
Formula
The formula uses information collected in the ontology development process and of
historical information collected from previous projects to make the effort estimation.

Parametric Effort Estimation Method

PM = A * (Size ) * ∏ CD i B

Person Normaliza- Size of the Cost
Month tion Factor Ontology Drivers

Learning
Factor
Result
Input from project manager
Input from methodology

Page 50

Ontocom
Formula: Example
The parameters associated with the different cost drivers are predefined in our
calculation tool.

Effort Estimation Formula

Person Size of the Cost
Month Ontology Drivers

Quality of personnel Development complexity

very high very high

6.9 PM = 500 Entities * high X high

X average average

low low

very low very low

Page 51

OntoCom
Methodology
For a high accuracy of the model we calculated the parameters aggregating the
experience of over 40 ontology engineering projects. And counting.

Model generation

Data collection Data analysis Model Usage

Model calibration

Specify cost Collect data Analyze data Calibrate Evaluate Release
drivers model model model

Effort estimations

12.000
11.000
10.000
9.000 +/ -30% tolerance
8.000
average
7.000 estimation
6.000
5.000
4.000
3.000
2.000
1.000
0
0 4 8 1 1 2 2 2 3 3
2 6 0 4 8 2 4

The accuracy of the model increases if it is adapted and calibrated with data from your own business.

Page 52

OntoCom
Process: Cost Drivers
Step 1: Size of the ontology

Explanation Guidelines
The size of the ontology. This includes all first class  Determining the size of a prospected ontology is
citizens of an ontology. Size is measured in kilo a challenging task in an early stage of the
entities. ontology development process.
 All class definitions.  Existing domain ontologies can help to get a
 All attribute definitions. rough capture.
 All relationship definitions. 1. Search for existing domain ontologies.
 All rule definitions.

2. Compare coverage of existing domain
ontologies with the required level of detail.
Examples
3. Calculate expected size of the new ontology.
An ontology has
 500 classes.
 700 attributes.
 300 relations.
 no rules.
This totals in 1.5 k entities.

Page 53

OntoCom
Step 2: Evaluation of the domain

The Domain Analysis Complexity accounts for DOMAIN
those features of the application setting which
 Very Low: narrow scope, common-sense
influence the complexity of the engineering
knowledge, low connectivity.
outcomes. It consist of three sub categories:
 The domain complexity.  Very High: wide scope, expert knowledge, high
connectivity.
 The requirements complexity.
REQUIREMENTS
 The available information sources.

 Very Low few, simple requirements.
Examples  Very High: very high number of req. with a high
conflicting degree, high number of usability
 An ontology for the cooking domain, having a requirements.
low number of requirements and a high number
of available information sources has a very low INFORMATION SOURCES
to low domain complexity.  Very Low high number of sources in various
 An ontology for the chemistry domain, with a forms.
high number of requirements and a low number  Very High none.
of available information sources has a high to
very high domain complexity.

Page 54

OntoCom
Step 3: Evaluation of the development complexity

 The Conceptualization Complexity accounts CONCEPTUALIZATION
for the impact of a complex conceptual model
 Very Low: concept list.
on the overall costs.
 Very High: instances, no patterns, considerable
 The Implementation Complexity takes into
number of constraints.
consideration the additional efforts arisen from
the usage of a specific implementation
language.
IMPLEMENTATION

 Low: The semantics of the conceptualization
Examples compatible to the one of the implementation
language.
 An ontology for a search application with an
thesaurus has a low development complexity.  High: Major differences between the two.

 An ontology for the chemistry domain,
modeling reaction patterns has a high
development complexity.

Page 55

OntoCom
Step 4: Evaluation of expected quality

 The Evaluation Complexity accounts for the ONTOLOGY EVALUATION
additional efforts eventually invested in
 Very Low: small number of tests, easily
generating test cases and evaluating test
generated and reviewed.
results. This includes the effort to document the
ontology.  Very High: extensive testing, difficult to
generate and review.
 Required reusability to capture the additional
effort associated with the development of a REUSEABILITY

reusable ontology,
 Very Low: Ontology is used for this application
only.
Examples
 Very High: Ontology should be used across
 An ontology which is used for one application many applications as an upper level ontology.
only without extensive testing has a low factor.
 An integration ontology which should be used
across an entire organization or for many web
users with high documentation requirements has
a high or very high factor.

Page 56

OntoCom
Step 5: Evaluation of personnel

 Ontologist/Domain Expert Capability accounts ONTOLOGIST/DOMAIN EXPERT CAPABILITY
for the perceived ability and efficiency of the
 Very Low: 15%.
single actors involved in the process (ontologist
and domain expert) as well as their teamwork  Very High: 95%.
capabilities.
ONTOLOGYIST/DOMAIN EXPERT EXPERIENCE
 Ontologist/Domain Expert Experience to mea-
 Very Low: 2 month (ontology) / 6 month
sure the level of experience of the engineering
(domain).

team w.r.t. performing ontology engineering.
 Very High: 3 years (ontology) / 7 years
Examples (domain).

 The new project member who has never worked
with ontologies nor has any experience with the
domain has a very low expert experience.
 The project manager who has been working with
ontologies for several years and is experienced
in a certain field has a very high expert
experience.

Page 57

OntoCom
Case Study: Estimated vs. Actual Figures
The actual effort was higher than expected. This is mainly due to frequent changes in the
modeling team and to technical problems aligning the process and ontology model.

Actual Effort Evaluation

Changes in the development team:
12.000
 The team consisted of in average 4 people.
11.000
10.000  The team structure changed quite often due to
9.000 management decisions.
Entities
no. of entities

8.000  This required experienced modelers to train
7.000 newcomers.

6.000 Aligning the process model with the ontology:
5.000  Tool support to define the data objects required
4.000 for activities in a process model is limited.
3.000  The original model does not account for the
2.000 integration of an ontology with a process model.
1.000 Size
0
 The estimate of the size of the ontology is
0 5 10 15 20 25 30 35 relatively good.
person month
 The project is ongoing.

Page 58

Content

Modeling Guidelines
Argumentation

Page 59

Modeling Guidelines
Definition

Ontologies are conceptual models. Modeling guidelines developed for semantic models
apply to ontologies as well. Ontologies can capture domain or use case knowledge.

Conceptual/semantic models Domain/use case models
 A conceptual/semantic model is a mental  A domain model is a conceptual model of
model which captures ideas in a domain of a system which describes the various
interest in terms of modeling primitives. entities involved in the system and the
relationships among them.
 The aim of conceptual model is to express
the meaning of terms and concepts used  The domain model is created to capture
by domain experts to discuss the problem, the key concepts and the vocabulary of
and to find the correct relationships the system.
between different concepts.
 It identifies the relationships among all

 The conceptual model attempts to clarify major entities within the system, as well
the meaning of various usually as their main methods and attributes.
ambiguous terms, and ensure that Influence
 In this way the model provides a
problems with different interpretations of
structural view of the system which is
the terms and concepts cannot occur.
normally complemented by the dynamic
 Once the domain of interest has been views in use case models.
modeled, the model becomes a stable
 The aim of a domain model is to verify and
basis for subsequent development of
validate the understanding of a domain of
applications in the domain.
interest among various stakeholders of the
 A conceptual model can be described project group. It is especially helpful as a
using various notations. communication tool and a focusing point
between technical and business teams.

Page 60

Modeling Guidelines
Principles
These are some of the most important characteristic of a semantic model.

 A model is built according
1 A model describes some domain of interest in a simplified, abstract way. to a modeling theory.
 ER modeling, OO modeling,
ontologies, semantic
networks, object-role
2 Contains structural information. modeling etc.

 A model uses modeling
primitives.
3 Application-independent vs. application-dependent models.
 Concepts, classes, entities,

objects, elements.
 Attributes, properties,
4 Shared understanding. methods.
 Relationships.
 Axioms, constraints,
5 Communication. restrictions, rules.

 A model is represented
using a particular notation.
6 Reusability.  Tables and columns, XML,
UML, OWL etc.

Page 61

Modeling Guidelines
Modeling Primitives
The most important modeling primitives of an ontology are classes, attributes,
associations, and rules.

Classes Relationships

Represent sets of instances. Also called
Also called  Relations, associations,
properties, object properties
 Concepts, entities
Can have various properties.
Can have equivalent classes,
inverse classes, anonymous

classes.

Describe the characteristics of
Ontology Define formal relationships
classes. between modeling primitives.
Further constrain the meaning of
these elements.

Attributes Constraints

Page 62

Modeling Guidelines
Classes
Classes represent sets of instances. Typical candidates for classes are nouns in the
domain of interest.

Definition How to find ...?
 A class represents a set of instances.  Interview: talk to subject matter experts.
 A class should be highly cohesive, precisely  Documentation: read what experts have written
nameable, relevant. about the subject matter, read the requirements
documentation, read proposals and invitations to
 A class should have a strong identity. tender.
 Observation and reflection.
 Classes vs. instances.

 Typical candidates for classes: NOUNS.
Example  But: actors of use cases do not necessarily
correspond to classes.
 Other terms as well
 Gerund: „My eyes glazing over…“
 Verbs: an association which starts to take on
Crime Suspect attributes and associations of its own turns into an
class: „Officer arrests suspect“.
 Verbs: events: „Illness episode“.
 Passive form: re-formulate in active form.
 No pronouns.
Page 63

Modeling Guidelines
Class Hierarchy
A subclass represents a concept that is a kind of the concept represented by the
superclass. All instances of the subclass are instances of the superclass.

 A subclass of a class represents a concept that is a “kind of” the concept that the superclass represents.
 All instances of the subclass are instances of the superclass.

 Classes represent concepts in the domain and not the words that denote these concepts.
 A single person is not a subclass of all persons.
 Synonyms for the same concept do not represent different classes.

 All the siblings in the hierarchy must be at the same level of generality.
 If a class has only one direct subclass there may be a modeling problem or the ontology is not complete.
 If there are more than a dozen subclasses for a given class then additional intermediate categories may
be necessary.
 There must be a reason to define a subclass. Subclasses of a class usually
 have additional properties that the superclass does not have, or
 restrictions different from those of the superclass, or
 participate in different relationships than the superclasses.

Page 64

Modeling Guidelines
Attributes
Attributes are measurable properties of classes. They are typically denoted by

 An attribute is a measurable property of an  Interview: talk to subject matter experts.
class.
 Scalar values: choice from a range of possibilities.  Documentation: read what experts have written
 An attribute is NOT a data structure. It is not about the subject matter, read the requirements
complicated to measure. documentation, read proposals and invitations to
 Value of attributes: integer, real numbers, tender.
enumerations, text.
 Attributes should have precise representative

names.  Nouns in „-ness“
 Velocity-ness, job-ness, arrested-ness…
Example
 „How much, how many“ test.
Witness  If you evaluate this, then it is probably an attribute.
 If you enumerate classes, it is probably an entity.
name:text
 Status attributes are problematic because of
age: integer open-ended range or fixed, but very large
eyesight: possible values, or because of complex state
enum{…} dependencies.

Page 65

Modeling Guidelines
Relationships
Relationships connected class instances. They are typically denoted by verbs and verbal
phrases.

 Relationships are associations in which class  Interview: talk to subject matter experts.
instances are aware of, and characterized by,
 Documentation: read what experts have written
other class instances.
about the subject matter, read the requirements
 Properties: reflexivity, cardinality, functional, documentation, read proposals and invitations to
inverse-functional, many-to-many, all values tender.
from, some values of, transitivity, symmetry etc.

 Verbs, verbal phrases and things that could have
Example
been verbs.
 But: „The butler murdered the duchess“

 Naming conventions: isInvestigated,
* * investigates, hasInvestigated, investigated.
Crime Officer  Roles.
investigates

Page 66

Modeling Guidelines
Constraints
Constraints capture in-depth knowledge of the domain of interest. They are associated to
classes, attributes, and relationships.
How to find ...?

Definition
 Constraints introduce additional restrictions of  Interview: talk to subject matter experts.
the meaning of modeling primitives.
 Types: cardinality, domain and range, values.  Documentation: read what experts have written
about the subject matter, read the requirements
documentation, read proposals and invitations to
tender.

 Cardinality constraints: numbers, but also
Example
articles, plural forms, typical verbal phrases.
 Domain and range constraints: typical restrictive
phrases, rationales for introducing subclasses in
the first place.
1..* 1..*
Crime Murder
commit

Page 67

Content

5. Useful Methods
Modeling Guidelines
Argumentation

Page 68

Argumentation
Motivation
Ontology engineering relies a common understanding of the stakeholders upon the
domain of interest. Argumentation supports consensus building.

Motivation Example
 Reaching agreement in the ontology engineering  Issue:
process is difficult Is the relationship “isPartOf” transitiv?
 Different interests of the stakeholders lead to  Example:
different requirements for conceptualization of a Mallorca isPartOf Spain
domain. Palma di Mallorca isPartOf Mallorca
 Unsupported the discussions to reach
agreement are unstructured and time consuming  Andalusien isPartOf Spanien

Gibraltar isPartOf Andalusien
 In distributed scenarios discussions are
documented in eMails and not traceable for  Answer:
outsiders In this case it depends whether the relationship
should represent geographic or political isPartof
 There are no guidelines for discussions
relationsships.
 The consensus building process is not traceable

Page 69

Argumentation
DILIGENT Argumentation Framework
DILIGENT guides participants through their argumentation and supports faster decision
making, while keeping track of the exchanged arguments.

DILIGENT framework Description

 Issues are requirements on
the ontology.
 Ideas reflect how issues can
be modeled in the ontology.
 Participants exchange
arguments around issues and
ideas.
 They can elaborate, disagree,
agree, and propose
alternatives to issues and
ideas.
 This leads to a commonly
agreed ontology with
traceable decisions.
 The process has been proven
and tested in other
(engineering areas).
Source: Tempich et. al., IEEE, 2008.

Argumentation
DILIGENT Argumentation Ontology
The argumentation ontology captures aspects of an ontology engineering discussion, starting from
the requirements analysis to the modeling step. It can be used to detect inconsistencies in the
argumentation process, to trace back modeling decisions, and to exchange argumentation
information.

Source: Tempich et. al., IEEE, 2008.

6.
Content

Page 72
Conclusion


Conclusions

 Ontologies are a core
Get management buy-in and define the goals of the
1 enabler for Enterprise
ontology development effort.
Information
Management.
2 Agree on an ontology engineering process and stick to it.
 They can facilitate
communication
Know your application scenario on adapt the way you across business units
3
model accordingly. and create

opportunities for new
business models.
4 Implement early and show that it works.
 This tutorial has
helped you to set-up
5 Use modeling patterns. your ontology
engineering project.

6 Monitor your effort and compare it with your estimations.

Page 73

Contact

Dr. Elena Simperl
STI Innsbruck
University of Innsbruck
ICT Technologiepark
Technikerstr. 21a
6020 Innsbruck (Austria)
Phone: +43 512 507 96884
Fax: +43 512 507 9872
Mobile: +43 664 812 5236
e-Mail: elena.simperl@sti2.at

Dr. Christoph Tempich
Detecon International GmbH
Industry/Competence Practice IT

Oberkasseler Str. 2
53227 Bonn (Germany)
Phone: +49 228 700-1942
Fax: +49 228 700 – 2361
Mobile: +49 (151) 12720065
e-Mail: Christoph.Tempich@detecon.com

Page 75

Pointers to not covered topics
If you are interested in languages and standards the following links may be of interest.

Languages and Standards
 Natalya F. Noy and Deborah L. McGuinness: Ontology Development 101: A Guide to Creating Your First
Ontology

Page 77

Ontology engineering ESTC2008

More Related Content

What's hot

Viewers also liked

Similar to Ontology engineering ESTC2008

More from Elena Simperl

Recently uploaded

Ontology engineering ESTC2008