eaft / nordterm workshop, vasa, 2006 - lars taxén ontologies at ericsson why and how lars taxén,...
TRANSCRIPT
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
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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)
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
Outline
• Definitions of ontology
• Telecommunication systems
• “Pragmatic” ontologies at Ericsson - why and how
• “Formal” ontologies in the literature
• Comparison
• Discussion
• Conclusions
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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.”
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
Telecom background
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
The telecom network
ServiceProviders
Network AccessPoints
Wide-bandBackbone
LAN
LAN
ExchangeExchange
Router
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
“Pragmatic” ontologies at Ericsson
- a historical Odyssey
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
From waterfall to integration centric development
Analysis Design VerificationPlan Integrate“Big Bang”
PlanIntegrate
Integrate
Increment
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
Method development
1996S-domain
IncrementalDevelopmentMethod Package
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
Information system support
1996 1997S-domain
IncrementalDevelopmentMethod Package
Information system (IS) introduced
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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
Context model S-domain 1997
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
IS support for the context model S-domain 1997
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
First project
1996 1997 1998 1999S-domain
IncrementalDevelopmentMethod Package
Information system (IS) in pilot projects
1st sharp project up and running
1st sharp projectprototype
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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
Context model S-domain 1999
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
Expansion
1996 1997 1998 20001999
A-domain
S-domain
L-domain
IncrementalDevelopmentMethod Package
Information system (IS) in pilot projects
1st sharp project up and running
2001
1st sharp projectprototype
Two more domains created
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
Expansion
1996 1997 1998 20001999
A-domain
S-domain
L-domain
IncrementalDevelopmentMethod Package
Information system (IS) in pilot projects
1st sharp project up and running
2001
1st sharp projectprototype
Two more domains createdTwo more IS applications
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
Context model S-domain 2001
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
!
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
Centralization
1996 1997 1998 20001999
A-domain
IncrementalDevelopmentMethod Package
Information system (IS) in pilot projects
1st sharp project up and running
2001 2002
1st sharp projectprototype
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
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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)
Config/MSControl (CC)
Impact Analyse
Comment
Config/MSControl (CC)
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.
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
Context model evolution
1996 1997 1998 20001999 2003 2004
A-domain
S-domain
2001 2002
X
X
?
C-domain
L-domain
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
Construction of context models
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
• 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...
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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)
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
Construction process
Req. mgr
Communal meaning
Meaningful artifacts
Individual meaning
Proj. mgr IS vendor Architect
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
A comparison- between context models at Ericsson and
ontologies in the literature
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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?”
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
“Formal” Ontologies- related to the Semantic Web
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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.”
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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”
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
Meaning
“Ontologies will provide the necessary meaning to web content therefore enabling software agents to understand and retrieve information in relevant contexts.”
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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.”
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
Stability
“Ontology, ... is supposed to reflect ... the well established knowledge of a given area... It should be stable and throughout used.
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
Commonality
“Communication between distinct groups using different vocabularies creates the need to create common vocabularies, which optimally suit all involved”
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
Machine processing
“We have presented an automated approach to unifying heterogeneous information models based on machine-processable metadata specifications.”
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
Discussion
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
“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
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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?
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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
EAFT / Nordterm workshop, Vasa, 2006 - Lars Taxén
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).