Ontologies at Ericsson Why and How

1
Ontologies at EricssonWhy and How

• Lars Taxén, PhD
• Department of Science and Technology,
• Campus Norrköping, Linköping University
• lars.taxen_at_telia.com, 46 73 0977864

2
Background Lars Taxén

• M.Sc. KTH 1968
• Ericsson 1968 - 2003
• Development methods for hardware and software
• Global information system support for
  coordination
• Doctoral studies Linköping University 1998 - 2003
• A Framework for the Coordination of Complex
  Systems Development
• Now researcher and consultant

There is nothing so practical as a good theory.
(Kurt Lewin)
3
Background Lars Taxén

• M.Sc. KTH 1968
• Ericsson 1968 - 1990
• Tools, methods, processes
• Ellemtel 1990 - 1996
• Development methods for hardware and software
• Ericsson 1996 - 2002
• Global development of large telecom systems,
  information system support for coordination
• Doctoral studies Linköping University 1998 - 2003
• A Framework for the Coordination of Complex
  Systems Development
• Now researcher and consultant

There is nothing so practical as a good theory.
(Kurt Lewin)
4
Outline

• Definitions of ontology
• Telecommunication systems
• Pragmatic ontologies at Ericsson - why and how
• Formal ontologies in the literature
• Comparison
• Discussion
• Conclusions

5
Ontology in philosophy
Ontology studies being or existence as well as
the basic categories thereoftrying to find out
what entities and what types of entities exist.
Ontology has strong implications for the
conceptions of reality.
6
Definition
Ontologies are content theories about the sorts
of objects, properties of objects, and relations
between objects that are possible in a specified
domain of knowledge. Chandrasekaran et al.
(1999) What Are Ontologies, and Why Do We Need
Them? IEEE Intelligent Systems, Jan/Feb 1999
7
Two types of ontologies

• Pragmatic ontologies
• Context models at Ericsson
• Used to coordinate complex development projects
• Social action theories (Activity Theory,
  Structuration Theory, Actor Network Theory, etc.)
• Formal ontologies
• Origin in the AI community
• Currently hot topic in the Semantic Web
• First-order logic

8
Telecom background
9
The telecom network
Exchange
Exchange
Router
10
Developing a node

• Issues
• Development lead-times
• Coordination and dependencies
• Progress follow-up
• Culture - disciplines
• Geographical distribution
• Commitments and responsibilities
• Competence
• Quality

• Drivers
• Market push
• Shorter time to market
• More competitors
• Less margins
• Shorter product life cycles
• Technological complexity
• Standardization
• Change

11
Development of 3G mobile systems

• Development centers
• S-domain (Stockholm)
• A-domain (Aachen)
• L-domain (Linköping)
• C-domain (Stockholm)

12
(No Transcript)
13
Coordination

• The management of dependencies btw activities
• Malone Crowston, 1994
• Communal meaning about how to coordinate
• requirements
• engineering change orders
• products
• documents describing products
• test cases
• integrations
• baselines
• milestones
• deliveries
• ...
• Information system support

14
Pragmatic ontologies at Ericsson - a
historical Odyssey
15
From waterfall to integration centric development
16
Method development
1996
S-domain
Incremental Development Method Package
17
Context model S-domain 1996
Assignment Specification
System Issue
AD plan
Constr. plan
AD package
Project
Project
Increment
Proj MS def
MCI
Incr MS def
Incr. Task Specification
Increment Specification
Function Anatomy
Customer
New Feature
Set of reqs
Test Object
Test Case
Function
Incr dep. matrix
Interface
Characte- ristics
Design Base
Baseline
Design Item
AXE System
Specification
MCI
Document
Project Document
Product Document
Implementation
New categories
System Issue
18
Information system support
1996
1997
S-domain
Incremental Development Method Package
Information system (IS) introduced
19
Context model S-domain 1997
System Issue
Project
Project MS
Customer
Customer Feature
AD Task
AD MS
Set of Reqs
AD Package
IS
Tech. Feature Inc Spec
Feature Increment
Increment Task Spec
Inc. MS
IP
Increment Responsible
Functional Anatomy
Impact
Individual
FF
Resource
Function
Teaml
Design Item
Design Base
LDC
Sub projectl
Product
Document
Project
New categories
...
ANT
CNT
CAA
FS
FD
TS
...
20
IS support for the context model S-domain 1997
21
Prototyping real usage
1996
1997
1998
S-domain
Incremental Development Method Package
1st sharp project prototype
Information system (IS) in pilot projects
22
Context model S-domain 1998
Req Issuer
PROJ. ITEMS
Parent_Child
Input Req
Needs
Project MS
REQUIREMENT
REQUIREMENT
Detailed Req
AD MS
DESIGN ITEM
MILESTONE
Increment MS
Project
System Issue
IP
AD Task
AD Package
Increment Task
TECH INCR SPEC
Baseline
INCREMENT
Change Request
Design Base
Function
Baseline
Consists_Of
Change Request
Design Base
PRODUCT
Role
CR Comment
DOCUMENT
CCB Meeting
PROJECT DOCUMENT
CCB Decision
Requirement Coordinator
Designer
Configuration Manager
Project Manager
PRODUCT DOCUMENT
23
First project
1996
1997
1998
1999
S-domain
Incremental Development Method Package
1st sharp project up and running
1st sharp project prototype
Information system (IS) in pilot projects
24
Context model S-domain 1999
Test Case
PROJ. ITEMS
Req Issuer
TEST ITEM
Project MS
MILESTONE
Parent_Child
TestedBy
Input Req
Increment MS
REQUIREMENT
Project
AllocatedTo
Detailed Req
DESIGN ITEM
Includes
DELIVERY
IP
System Issue
AD Package
Consists_Of
TECH INCR SPEC
Function
Package
Use Case
INCREMENT
Baseline
Design Base
PRODUCT
Change Request
DOCUMENT
Role
CR Comment
PROJECT DOCUMENT
CCB Meeting
PRODUCT DOCUMENT
CCB Decision
Requirement Coordinator
Designer
Configuration Manager
Project Manager
25
Expansion
A-domain
1996
1997
1998
2000
1999
2001
S-domain
Incremental Development Method Package
1st sharp project up and running
1st sharp project prototype
L-domain
Information system (IS) in pilot projects
Two more domains created
26
Context model A-domain 2001
ARS, CRS, MRS
High-level RS
Feature Groups
DependsOn
Feature Group
DescribedIn
Features
toAnatomy
Has
(s)WPG
prio
Holds
Feature
DescribedIn
RS_IP
IP_FF
FF_WP
WP
FF
RS
IP
DependsOn
Tagged(H)RS Item
RS_SIP
IncludedIn
SIP_IP
Impacts
SIP
Detailed RS
LSV
Product
27
Expansion
A-domain
1996
1997
1998
2000
1999
2001
S-domain
Incremental Development Method Package
1st sharp project up and running
1st sharp project prototype
L-domain
Information system (IS) in pilot projects
Two more domains created Two more IS applications
28
Context model S-domain 2001
TEST_ITEM
Tested_by
Requirement Issuer
ANATOMY_ITEM
has
INTEGRATION_ITEM
Included_In
LSV
Work Package
Directed_To (fulfillment-status)
AD-package
Feature Increment
Impacts (man-hours)
DESIGN_ITEM
REQUIREMENT
PRODUCT
PROGRESS_CONTROL_ITEM
PROD_DOC
Baseline
MILESTONE
CHANGE_PROPOSAL_ITEM
CR
TR
29
Centralization
A-domain
?
2003
2004
1996
1997
1998
2000
1999
2001
2002
S-domain
X
Incremental Development Method Package
1st sharp project up and running
1st sharp project prototype
C-domain
X
L-domain
Information system (IS) in pilot projects
Two more domains created
Ericsson common domain serving the other domains
One common Ericsson domain
30
Context model C-domain 2003
31
Context model evolution
A-domain
?
1996
1997
1998
2000
1999
2003
2004
2001
2002
S-domain
X
C-domain
X
L-domain
32
Construction of context models
33
A detail in the context model
To be defined...

• Entities
• Relations
• Names, icons
• Types of requirements
• Life cycle of requirements
• Attributes on requirements
• Attributes on relations
• Cardinalities on relations
• Revision stepping rules
• Actor roles
• Access rights for roles
• ...

34
Constructing communal meaning the key issue
We also had major discussion about the attributes
for each and every object, what do they really
mean and how are they to be used. That was also
something that caused quite a lot of time.
(Project Manager 3G)
35
Construction process
Req. mgr
Proj. mgr
IS vendor
Architect
36
A comparison- between context models at Ericsson
and ontologies in the literature
37
Properties of ontologies from the literature

• There are objects in the world
• Objects have properties or attributes that can
  take values
• Objects can exist in various relations with each
  other
• Objects can have parts
• Properties and relations can change over time
• There are events that occur at different time
  instants
• There are processes in which objects participate
  and that occur over time
• The world and its objects can be in different
  states
• Events can cause other events or states as effects

38
Properties of context models at Ericsson

• There are objects in the world
• Objects have properties or attributes that can
  take values
• Objects can exist in various relations with each
  other
• Objects can have parts
• Properties and relations can change over time
• There are events that occur at different time
  instants
• There are processes in which objects participate
  and that occur over time
• The world and its objects can be in different
  states
• Events can cause other events or states as effects

39
Formal Ontologies- related to the Semantic Web
40
Semantic web - purpose
The application of Semantic Web technologies to
enable Semantic eBusiness provides the
organizations the means to design collaborative
and integrative, inter- and intra-organizational
business processes and systems founded upon the
seamless exchange of knowledge.
41
Formally defined
...The only languages to describe the entities
involved and the relationships between them that
are likely to fit the bill are mathematical, and
the prime contenders are understandable in terms
of first-order logic.
42
Conceptions of knowledge
knowledge is a collection of facts about a
domain. encoding knowledge in terms of the
concepts and relations. Ontological analysis
clarifies the structure of knowledge
43
Meaning
Ontologies will provide the necessary meaning to
web content therefore enabling software agents to
understand and retrieve information in relevant
contexts.
44
Separation of ontology and knowledge
An ontology provides a set of concepts and terms
for describing some domain, while a knowledge
base uses those terms to represent what is true
about some real or hypothetical world.
45
Stability
Ontology, ... is supposed to reflect ... the
well established knowledge of a given area... It
should be stable and throughout used.
46
Commonality
Communication between distinct groups using
different vocabularies creates the need to create
common vocabularies, which optimally suit all
involved
47
Machine processing
We have presented an automated approach to
unifying heterogeneous information models based
on machine-processable metadata specifications.
48
Discussion
49
Basic tenets formal ontologies

• Knowledge
• A collection of facts that are true
• Can be managed
• Is discovered
• Ontologies separate from knowledge
• Ontologies
• Give meaning
• Describe some part of the real world
• External to the worlds they describe
• Stable
• Formally defined
• Can be machine processed
• Validated according to compliance with facts,
  truth

50
Basic tenets pragmatic ontologies

• Knowledge
• Intrinsic to humans, knowledge is what a knower
  knows
• Constructed in action
• Not a commodity
• Ontologies are inseparable from knowledge
• Ontologies
• Instruments for constructing communal meaning
• Domain specific
• Provide a communal language in the domain
• In constant evolution
• Informally described - easy to interpret for
  humans
• Machine processing not a prerequisite
• Validated for usefulness in the domain

51
Formal versus pragmatic ontologies
Formal
Pragmatic

• Commodity
• Inherent
• Description
• Stable
• Formal
• Truth
• Uniform
• External

• Inherently human
• Constructed
• Action
• Evolution
• Significant
• Usability
• Multitude
• Internal

Knowledge
Meaning
Usage
Change
Model
Validation
Commonality
Existence
On the surface formal and pragmatic ontologies
look the same Fundamentally different conceptions
of knowledge
52
Issues

• Ontology for ontologies
• Knowledge for description or action?
• Is knowledge equal to facts?
• Can knowledge be managed?
• Are ontologies external to the world it
  describes?
• Meaning
• Do ontologies encode meaning?
• Unification
• Is it possible to define one size fits all
  ontology?
• Validation
• Usefulness or truth?
• Development
• Stable or dynamic world?

53
Activity Domain Theory

• Focus on communal meaning
• Activity Modalities
• Spatialization
• Temporalization
• Technologization
• Stabilization
• Contextualization
• Transition
• Pragmatic communication
• Ontology is one modality - spatialization
• Other modalities need to be considered in
  ontology construction

54
Further reading
Taxén L (2003) A Framework for the Coordination
of Complex Systems Development. Dissertation No.
800. Linköping University, Dep. of Computer
Information Science, 2003. Retrieved from
http//www.ep.liu.se/diss/science_technology/08/00
/index.html (Nov 2004) Taxén L (2004)
Articulating Coordination of Human Activity - the
Activity Domain Theory. In Proceedings of the 2nd
International workshop on Action in Language,
Organisations and Information Systems
(ALOIS-2004), Linköping University. Retrieved
from http//www.vits.org/konferenser/alois2004/pro
ceedings.asp (Dec 2005). Taxén L (2005)
Categorizing Objective Meaning in Activity
Systems, in Whymark G, Hasan H (Eds.), Activity
as the Focus of Information Systems Research,
Eveleigh, Australia Knowledge Creation Press,
pp. 169-192 Taxén L (2005) An Integrated
Approach for the Coordination of Distributed
Software Development Projects, Information and
Software Technology, (in press).