Ontologies at Ericsson Why and How

EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén

Ontologies at EricssonWhy and How

Lars Taxén, PhDDepartment of Science and Technology,

Campus Norrköping, Linköping University

[email protected], +46 73 0977864


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)


Outline

• Definitions of ontology

• Telecommunication systems

• “Pragmatic” ontologies at Ericsson - why and how

• “Formal” ontologies in the literature

• Comparison

• Discussion

• Conclusions


Ontology in philosophy

“Ontology studies being or existence as well as the basic categories thereof—trying to find out what entities and what types of entities exist. Ontology has strong implications for the conceptions of reality.”


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


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


Telecom background


The telecom network

ServiceProviders

Network AccessPoints

Wide-bandBackbone

LAN

LAN

ExchangeExchange

Router


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


Development of 3G mobile systems

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

EAFT / Nordterm workshop, Vasa, 2006 - Lars TaxénC7 fun ctio ns

CAMEL Ph 3 / IN

AXE

MGW

Track

GCP TRACK

Design Base1.5

GPRS+SMS

f) GDB SMSa) CAPC

d) 1/APT

f) GDB

MAP SCCPSegmentat ion

a) CAPC

d) 1/APT

Title: AXE Anatomy for 2.0

2/0062-FCPW 101 50 PA51

Editor: EED/X/D Stefan Berg

Date: 2002-04-11

PRA-Date: 2001-11-15(RFA 28.02.)

01-10-22

01-10-08

01-10-08

2E01

2E02

Dependency

2J01

Basic Callwith AXE

01-10-15

01-10-30

APG40 / APZ 11.1

Design base onfunctional level, notnecessarily on product

level

01-11-15

new CSD

H.324fallback

d) 1/APT

2U01

2U02

01-06-18halfrateremoval

d) 1/APT

01-09-20

GT Mod. forConnectionless t raff ic

a) CAPC

01-09-102J04

Announcementchangesa) CAPC

b) CNCP01-09-10

2DA03

Advanced callcases withAXE/Cello

BICC drop 2compl. basic

call

a) CAPC

01-07-16BICC drop 3

SS

a) CAPC

2DA05

new HW

lif t SMAC into 2.0(incl. drop 2)

a) CAPC

b) CNCP

c) CSPP

d) 1/APT

f) GDB

h) SMAC part

2S06

01-10-22

GPRScharging

characterist ics

f) GDB

01-10-08

2E04

RONASSSP

a) CAPC

01-10-08

2E05

ATI

g) SCP-T

01-09-10

2E06

Cause of noCLI

a) CAPC

d) 1/APT2F16

01-07-30

U2G HOfor CSDa) CAPC

d) 1/APT

2F13

01-10-08

SS

U2G HO + SRNS Relo.

R-TDM

CSD

IN

BICC ++

- MGW validat ion- AXE-Cello

interworka) CAPC

b) CNCP

Server Recovery &MGW node

recoveryb) CNCP

a) CAPC

d) 1/APT

Multiple MGWsupport

- NRM impacts formultiple MGWs

b) CNCP

enhanced traff ic cases: depending on GCP

UMTS CSD callsvi a GCP

b) CNCP

a) CAPC

d) 1/APT

enhanced traff ic cases: depending on BICC

CSD calls viaGCP ++

a) CAPC

CH, CWb) CNCP

a) CAPC

d) 1/APT

01-08-13

01-08-13

01-

08-

13

01-10-0801-11-05

01-09-1001-11-05

01-11-05

2CA05

OMS- call path

tracing

a) CAPC

b) CNCP

01-07-16

2C01 Recept ion of bearer

release i ndicat ions(call release)

a) CAPC

b) CNCP

2C03

2O01

2O02

Inter-System,intra-MSC

Handover (viaGCP)

b) CNCP

a) CAPC

Inter-System, inter-MSC Handover

(via GCP)+ charging

a) CAPC

02-02-18

2P02

2P03

2P01

MPT Y,IN conference,

O&M moni toring, LIconference

b) CNCP

a) CAPC

01-11-0502-03-15

2R02

2R01

Recovery onterminat ion,

terminat ion groupand MGW level

a) CAPC

b) CNCP

01-10-2201-11-19

Basic Call with Cel lo

Basic Call with Cel lo:2 or more servers,using BICC, using 1 MGWUMTS-to-UMTS mobile speech call

periodic audit

a) CAPC

b) CNCP

01-10-0801-11-05

2C04

01-07-26

01-10-30

01-09-20

periodic audit& test calls

a) CAPC

b) CNCP

01-11-12

01-10-2201-11-19

Speech via GCP

load controla) CAPC

b) CNCP

d) 1/APT

01-10-0801-11-05

2C05

01-08-13

MGW selectionPRA calls

a) CAPC 2F10

01-10-2202-02-18

01-10-08

LI

2L01

LI for newarchitecture (via

GCP)d) 1/APT

b) CNCP

a) CAPC

01-10-2202-02-18

Test call s (viaGCP)

b) CNCP

a) CAPC

01-10-0801-11-05

MGW + MGC coldstart

- O&M for MGW start- Context/ term.

handling for MGWstart

a) CAPC

b) CNCP

01-07-02

2CA01

Simple Call- context/ term. handling

for cal ls- basic protocol handling

a) CAPC

b) CNCP

d) 1/APT

2CA02

01-09-20

01-07-16

01-07-10

01-10-2202-02-18

2Q01

2Q02

digit sending (viaGCP), tones

d) 1/APT

b) CNCP

a) CAPC

01-10-30

01-10-0802-02-18

MGW selectionfor IN calls

a) CAPC 2Q03

Interact ivemessageing

(design base)

a) CAPC

b) CNCP

EC proceduresb) CNCP

c) CSPP

a) CAPC

01-09-10

2F06

2CA06

2CA04

01-09-1001-11-05

2T03

2T04

G2U HO

Inter-MSCG2U HOa) CAPC

d) 1/APT

Subsequent HOcases & charging

a) CAPC

d) 1/APT

2G01

2G02

01-09-30

01-10-22

01-09-10

Int ra-MSCG2U HOa) CAPC

d) 1/APT2G03

01-07-02

2F11

Satelite page loadbalancing

d) 1/APT01-08-13

2F12

TrafficBasedPricing

RMPService

Interfaceb) CNCP

Service User

a) CAPCService User

d) 1/APT

01-09-10

01-08-27

01-09-10

2H01

2H02

2H04

01-09-20

01-07-30

Traf fic handling

a) CAPC

b) CNCP

01-10-0801-11-05

2T02

configurat ion,blocking/

deblocking

a) CAPC

b) CNCP

01-09-10

2T01

MGW Selectionat re-routing

a) CAPC01-07-30

2DA09

Jap an Specific

TTC C7

d) 1/APT

2W01

2W02

FNR file I /O

f) GDB01-08-13

01-09-15

01-09-10

CALEA + GSsupport

a) CAPC

d) 1/APT01-10-22

2F08

AXE par. &DSA

a) CAPC

d) 1/APT

2F20

01-10-22

LPT Test calls

a) CAPC2F21

01-09-10

01-xx-xx FT ready;

FORLOPPimprovem.21230/33b) CNCP

2M09

RPS FC

b) CNCP2M0601-10-22

Restartreason

b) CNCP

2M07

01-10-22

SPoE

a) CAPC

b) CNCP

01-12-17

2M02

STS

a) CAPC01-12-17

2M05

Satelite backwardcompatibility

a) CAPC

d) 1/APT

01-08-13

2F07

early Shockley

a) CAPC

b) CNCP

c) CSPP2S05

01-07-02CSPP:

01-07-16

SMS Waiting

f) GDB

01-10-08

2F27

ANSI 41 NPa) CAPC

f) GDB

01-10-22

2F22

UMTS auth.redundancy

enha.

f) GDB

01-10-08

2F24

Outgoing (+incoming)AAL2 connect ions,

I. trunk (ALI FW)Reset procedures

a) CAPC

b) CNCP

2D01

01-07-16

01-07-26

New Architecture Platform

01-07-10

New Services Platform

01-07-10MGW Selection (Simple):- only for AXE MGW

- internal OIP- only basic call

a) CAPC

d) 1/APT

2A01

01-07-02

MTP3B longmessages STC

CB interface

a) CAPC

01-05-21

2B01

BICC CS1 --- basic call

a) CAPC2B03

01-07-02

MTP3B longmessages MTP

CB interface

a) CAPC 01-07-02

2B04

MTP3B longmessages

support

a) CAPC

b) CNCP

01-08-13

2DA07

BICC drop 3special services

a) CAPC01-09-24

2DA08

01-07-30

01-09-20

Basic Call with AXE MGW:2 or more servers,using BICC, using only AXE MGWs,UMTS-to-UMTS mobile speech call,UMTS-to-GSM mobile speech call,GSM-to-UMTS mobile speech call,GSM-to-GSM mobil e speech call

C-HSSL

a) CAPC

b) CNCP

2S09

01-09-10

APG40charg.

g) SCP-T

a) CAPC

2M1001-10-08

2DA04

TLV merge

a) CAPC

d) 1/APT01-09-10

2F28

Number portabil ity

MNP functions

a) CAPC

d) 1/APT

01-08-13 01-08-20

2K01

APIO

b) CNCP

2M1201-10-22

APCommunic.

b) CNCP

01-10-22

2M11

MTAPimprovments

b) CNCP

01-10-22

2M14

SW record

b) CNCP

01-10-22

2M15

Iur

d) 1/APT

a) CAPC

01-10-22

2F30

Shared Netw.

d) 1/APT

2F32

01-10-22

Long RANAPmessages

a) CAPC

d) 1/APT

2J05

01-10-08

BICC drop 4APM & Comp.

Handling

a) CAPC01-10-08

2DA10

Security

a) CAPC

b) CNCP

01-10-22

2M13

GOH

b) CNCP

2M03

01-10-22

MAPv3 MT-SMS

f) GDB

01-10-22

2F34

AMR for GSM

d) 1/APT

01-09-10

2F02

Single Cl.Group

a) CAPC

b) CNCP

01-10-22

2M16

FTP virtualroot

a) CAPC

b) CNCP

01-10-22

2M17

SEQS

a) CAPC

2F14

01-10-22

Can. Meter Puls

a) CAPC

d) 1/APT

2F35

Satelite CIP tone+ CSD

a) CAPC

d) 1/APT01-09-10

2F31

SecurityContext

d) 1/APT

2F36

01-10-22

RAB Mod.

d) 1/APT

2F37

01-10-22

2Q04

digit receiving (viaGCP)

b) CNCP

a) CAPC

01-11-05

OP / SQN

f) GDB

01-10-22

2F23 2F

33

New OIP Pack.

d) 1/APT

a) CAPC

01-10-08

TRAMif ication ofTSS (2.0 scope)

Part I

a) CAPC

2F18

01-10-08

MONCO

a) CAPC

b) CNCP

2F29

Long RANAPmessages, CO

a) CAPC

d) 1/APT

2J06

01-11-05

UMTS&GSMterm. FTM

f) GDB

2U04

01-10-22

UMTS&GSMterm. FTMa) CAPC

d) 1/APT

2U0301-09-10

ALI-Beaomon

interw.b) CNCP

2S08

01-10-22

Announcement changes II

b) CNCP

01-10-08

2DA11

TRAMif ication ofTSS (2.0 scope)Part II : Russan,

1.5 spillovera) CAPC

d) 1/APT01-11-05

2F38

HO for CSD calls viaGCP

b) CNCP

a) CAPC

d) 1/APT

2P05

01-11-0502-03-15

G2U HO,architecture spl ittest cases (test

only!)

d) 1/APT

2P06

02-01-28

SRNCreallocat ion (via

GCP; sameMGW)

b) CNCP

01-10-2202-02-18

Localsubscript ion

d) 1/APT

2F39

01-10-22

UMTS positioni ng

a) CAPC

d) 1/APT

f) GDB

01-11-05

2F26

FTM clean upa) CAPC

d) 1/APT

f) GDB

2U05/06

01-11-05

FORLOPPimprovem.21220/25b) CNCP

2M18

HO Charging

a) CAPC

d) 1/APT

01-07-02

2F09

01-11-05

ServiceUser, IN

calls

a) CAPC

01-09-10

2H05

ServiceUser, ANSI

TSS

a) CAPC01-10-22

2H06

TRAMif ication ofTSS (2.0 scope)

Part II I: Israel& Frencha) CAPC

02-02-04CN-I

2F40

TRAMif icationof PBX

a) CAPC

01-11-05

2F41

01-xx-xx01-yy-yy

1. date: d el ivery ofall products exceptGACON; al l FT that

can be do ne withoutGACON is ready!

2. date : FT ready,in cludin g GACONtest cases. INDUScan start to use i t.

ECP101

c) CSPP02-01-22

2S10

EA cleanup

a) CAPC

d) 1/APT

01-11-05

2F42

PRAmonitoring

CN-I

a) CAPC

01-12-17

2F44

Delivered to LSV, FT d one

Delivered to LSV, FT n ot co mpl.eted

Under design or FT, not del ivered to LSV,requires major management attention

Under design or F, not d el ivered to L SV, someissues req uire attention

Under design or F, not d el ivered to L SV, noproblem.

Handoverimprove.a) CAPC

d) 1/APT

2F4501-11-05

Timerimprovements

b) CNCP

d) 1/APT

01-11-05

2Q05

Kc over MAP

d) 1/APT

2F46

01-11-05

Verificat ion ofUMTS AMR

modes

c) CSPP

01-12-03

2F17

DES mark

d) 1/APT

a) CAPC

2F47

01-11-05

01-10-22

MONT f ix

a) CAPC

d) 1/APT

2F48

01-12-17CAI & CARI

a) CAPC

2F49

01-12-17Iran CAS

a) CAPC

2F43

01-11-05

periodicaudit

cl ean-upb) CNCP

02-02-04

2C06

02-02-15CN-I

CALEA for CMS40a) CAPC

b) CNCP

d) 1/APT

02-04-30CN-I

2F50


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


“Pragmatic” ontologies at Ericsson

- a historical Odyssey


From waterfall to integration centric development

Analysis Design VerificationPlan Integrate“Big Bang”

PlanIntegrate

Integrate

Increment


Method development

1996S-domain

IncrementalDevelopmentMethod Package


Project

CustomerNew

FeatureSet ofreq’s

IncrementSpecification

SystemIssue

Baseline

IncrementIncrement

DesignItem

Document

ProjectDocument

ProductDocument

AXESystem

SystemIssue

Specification

Implementation

TestObject

MCI

TestCase

InterfaceCharacte-

ristics

Function

Incr. TaskSpecification

IncrMS def

AssignmentSpecification

ProjMS def

AD planConstr.

plan

FunctionAnatomy

Incr dep.matrix

AD package

Project

Design Base

MCI

New categories

Context model S-domain 1996


Information system support

1996 1997S-domain


Information system (IS) introduced


CustomerCustomerFeature

Set ofReq’s

SystemIssue

ADPackage

Tech. Feature Inc Spec Feature

Increment

FeatureIncrement

Impact

IncrementTask Spec

Inc. MS

Project

AD Task AD MS

IncrementResponsible

Resource

DesignItem

FunctionalAnatomy

Function

DesignBase

Product Document

Individual

Teaml

LDC

Sub projectl

Project

IS

IP

FF

... ANT CNT CAA FS FD TS ...

Project MS

New categories



IS support for the context model S-domain 1997


First project

1996 1997 1998 1999S-domain


Information system (IS) in pilot projects

1st sharp project up and running

1st sharp projectprototype


Consists_Of

Includes

Role

RequirementCoordinator

DesignerConfiguration

Manager Project

Manager

Baseline

CCB Meeting

CCB Decision

CR Comment

Change Request

Needs, Impacts

Use Case

Design Base

DESIGN ITEM

DOCUMENT

PROJECT DOCUMENT

PRODUCTDOCUMENT

PRODUCT

System Issue

AD Package

MILESTONE

Project

Project MS

Increment MS

PROJ. ITEMS

IP

Req Issuer

Input Req

Detailed Req

TECH INCR SPEC

REQUIREMENT

Parent_Child

INCREMENTINCREMENT

DELIVERY

AllocatedTo

Includes

TestedBy

Package

TEST ITEM

Test Case

FunctionConsists_Of



Expansion

1996 1997 1998 20001999

A-domain

S-domain

L-domain




2001


Two more domains created


Context model A-domain 2001

Feature

WPWPFFRS IP

(s)WPG

High-level RS

Holds

SIP

ARS, CRS, MRS

Tagged(H)RS Item

Feature Group

prioFeatures

DescribedIn*

DescribedIn

DependsOn

Has

Feature Groups

Detailed RS

toAnatomy

RS_IP

RS_SIP

IP_FF FF_WP

SIP_IP

Product

Impacts

LSV

IncludedIn

DependsOn


Expansion

1996 1997 1998 20001999

A-domain

S-domain

L-domain




2001


Two more domains createdTwo more IS applications



Depends_on

ANATOMY_ITEMANATOMY_ITEM

TEST_ITEM

DESIGN_ITEM

Impacts(man-hours)

REQUIREMENT

Tested_by

Included_In

Directed_To(fulfillment-status)

Baseline

PROGRESS_CONTROL_ITEM

MILESTONE

CR

CHANGE_PROPOSAL_ITEM

TR

INTEGRATION_ITEM

LSV

AD-package

PROD_DOC

PRODUCT

Work Package

Feature IncrementFeature Increment

Requirement Issuer

has

!


Centralization

1996 1997 1998 20001999

A-domain




2001 2002


Two more domains created Ericsson

common domain serving the other domains

2003 2004

S-domain

X

X

?

C-domain

L-domain

One common Ericsson domain


Context model C-domain 2003

Requirement-Test Req

DOCUMENTITEM

REQUIREMENTITEM

ORGANISATIONITEM

Structure/ Relation

User

USERITEM

ANATOMY ITEM(WP/FEATURE)

RequirementGroup

Requirement

ProjectLine Org.

PRODUCT ITEM(Reg Prod &

Prod Structure)

PROGRESSCONTROL ITEM

Milstone

Tollgate

Baseline

WORK ITEM

Product Doc

Test doc

Project Doc

DELIVERY ITEM

Internal build*

Shipment*

Userexecutes

Defined work/task

Requirementissuer

Requirementresponsible

SOC Req.Group

Req. Alloc.

Dev. input / steering

User has roles

User ingroup

Proj.resp.

Describes/Plans(IP/FS/FD,etc)

Change Request

Included in

Becomes

MEETING ITEM

Proj. Meeting

CCB

Project delivers

Implemented by Described by

Config/MSControl (CC)


Impact Analyse

Comment


AffectsConfig

IA estimates

C. regards

CC

TEST ITEM

Test Case

Test Script

Test Req.

Included in

CC

M. handles

Anatomy relation/structure

Projecthas

Project Task list

Project Owns

Org. Property/Portfolio

usergives

Org.Performs

Test Responsible

ORGANISATIONITEM

(MIRROR)

Structure/ Relation

Structure/Traceability

User answers

Allocated to

Verified by

User assigned to

Included in

To any CI CI

Org. Doc. Archive

Structure

Company(Customer)

*Can be defined as LSV

Test Env.

Project

Cust.Contract

Drop

Proj. controls

WP teamresp.


Context model evolution

1996 1997 1998 20001999 2003 2004

A-domain

S-domain

2001 2002

X

X

?

C-domain

L-domain


Construction of context models


• 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

• ...

A detail in the context model

To be defined...


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)


Construction process

Req. mgr

Communal meaning

Meaningful artifacts

Individual meaning

Proj. mgr IS vendor Architect


A comparison- between context models at Ericsson and

ontologies in the literature


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

Example adapted after Edgington et al. (2004) “Adopting Ontology to Facilitate Knowledge Sharing”,

Chandrasekaran et al. (1999) “What Are Ontologies, and Why Do We Need Them?”


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


“Formal” Ontologies- related to the Semantic Web


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.”


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”


Meaning

“Ontologies will provide the necessary meaning to web content therefore enabling software agents to understand and retrieve information in relevant contexts.”


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.”


Stability

“Ontology, ... is supposed to reflect ... the well established knowledge of a given area... It should be stable and throughout used.


Commonality

“Communication between distinct groups using different vocabularies creates the need to create common vocabularies, which optimally suit all involved”


Machine processing

“We have presented an automated approach to unifying heterogeneous information models based on machine-processable metadata specifications.”


Discussion


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


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


“Formal” versus “pragmatic” ontologies

• Commodity

• Inherent

• Description

• Stable

• Formal

• Truth

• Uniform

• External

• Inherently human

• Constructed

• Action

• Evolution

• Significant

• Usability

• Multitude

• Internal

“Formal” “Pragmatic”Knowledge

Usage

Change

Model

Validation

Commonality

Meaning

On the surface formal and pragmatic ontologies look the same

Fundamentally different conceptions of knowledge

Existence


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?


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


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/proceedings.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).

Documents

Ontologies at Ericsson Why and How