Proposed UNSDI Tech Gov Framework

United Nations Spatial Data Infrastructure
(UNSDI)
Proposed Technical Governance Framework
Preliminar !eport
"ersion #$#
%&'%(')%%*
!o+ ,tkinson
Paul -o.
UNSDI Technical Governance Framework Proposal 1
Preliminary Report v1.1
Table of Contents
EXECUTIVE SUMMARY............................................................................................5
PART 1 - INTRODUCTION AND BACKGROUND...............................................6
1. Introduction............................................................................................................6
1.1 Purpose and scope..........................................................................................6
1.2 Distribution....................................................................................................6
1.3 Organisation...................................................................................................6
2. Consultancy terms of reference..............................................................................7
2.1 ac!ground....................................................................................................7
2.2 Ob"ecti#es.......................................................................................................7
2.3 Consultancy deli#erables...............................................................................$
2.% Consultancy approac&....................................................................................$
2.%.1 O#er#ie'................................................................................................$
2.%.2 (ta!e&older engagement........................................................................$
2.5 )*(DI +uiding Principles............................................................................,
PART 2 - CONTEXT AND REQUIREMENTS........................................................,
3. Institutional and go#ernance conte-t...................................................................1.
3.1 (cope and definitions...................................................................................1.
3.1.1 +o#ernance..........................................................................................1.
3.1.2 (O/ go#ernance...................................................................................1.
3.1.3 Operational0tec&nical go#ernance and institutional go#ernance..........11
3.2 (eparation of go#ernance concerns..............................................................11
3.3 Inter and intra (DI go#ernance....................................................................12
3.% 1#ol#ing nature of go#ernance approac&.....................................................12
3.5 /ddressing intangible (DI success factors..................................................12
3.6 +o#ernance dimensions of an )*(DI.........................................................13
3.6.1 O#er#ie'..............................................................................................13
3.6.2 2ulti3domain.......................................................................................13
3.6.3 2ulti4"urisdictional..............................................................................13
3.6.% Di#erse participation capabilities.........................................................1%
3.6.5 2ultiple interoperability le#el support.................................................1%
3.6.6 Differing conte-t and re5uirements for )* (DIs................................1%
3.6.7 6emporal c&ange..................................................................................1%
3.7 )* reform....................................................................................................15
%. Data conte-t.........................................................................................................16
%.1 Interoperability.............................................................................................16
%.2 Data generation7 distribution and use...........................................................1$
%.3 Data concentrations and silos.......................................................................1$
%.% Custodians&ip and sources...........................................................................1$
5. 6ec&nology conte-t..............................................................................................1,
5.1 1merging 6ec&nical 8actors.........................................................................1,
5.1.1 (ignificant patterns...............................................................................1,
5.1.2 (er#ice Oriented /rc&itectures............................................................1,
5.1.3 9eb ser#ices and conformance profiles...............................................2.
5.1.% Open (ource and :eference Implementations.....................................22
5.1.5 :egistries..............................................................................................23
5.1.6 Ontologies............................................................................................26
5.2 ;egacy systems and migration.....................................................................27
5.2.1 Currently &eterogeneous systems.........................................................27
5.2.2 2igration to ser#ices............................................................................27
5.2.3 +o#ernance implications......................................................................2$
5.3 Constraints....................................................................................................2$
5.3.1 :esourcing............................................................................................2$
5.3.2 +o#ernance realities.............................................................................2$
6. :e5uirements........................................................................................................2$
6.1 Current situation and need for c&ange.........................................................2,
6.2 +eneral re5uirements...................................................................................31
6.2.1 Inter4(DI go#ernance re5uirements.....................................................31
6.2.2 Intra4(DI go#ernance re5uirements.....................................................32
6.3 +o#ernance of data model and &armoni<ation processes............................32
6.% /rc&itectural go#ernance.............................................................................33
PART 3 - PROPOSED SOLUTION........................................................................35
7. +o#ernance frame'or! 4 conceptual o#er#ie'...................................................35
7.1 Introduction..................................................................................................35
7.2 inter4(DI go#ernance...................................................................................36
7.3 Intra4(DI go#ernance...................................................................................36
$. 6&e )*(DI proposed solution.............................................................................36
$.1 1nterprise #ie'point....................................................................................37
$.1.1 )se cases..............................................................................................3$
$.1.2 )se case scenarios................................................................................3$
$.2 Information #ie'point..................................................................................%3
$.3 Computational #ie'point.............................................................................%3
$.% 1ngineering #ie'point.................................................................................%%
$.5 6ec&nology #ie'point..................................................................................%%
,. +o#ernance actors7 responsibilities and institutional mappings..........................%%
,.1 /ctors and 6erms of :eference....................................................................%%
,.2 2apping roles to organi<ations....................................................................%5
1.. Pro"ect 'or!4plan.............................................................................................%5
1..1 O#er#ie'......................................................................................................%5
1..2 Principles......................................................................................................%6
1..3 (cope of t&e 'or!4plan................................................................................%6
1..3.1 )*(DI arc&itecture pro"ect..................................................................%6
1..3.2 Creation of )* (DI instances..............................................................%6
1..3.3 (DI 2.. 3 a reference implementation..................................................%7
1..3.% 2odeling and &armoni<ation of priority )* data sets.........................%$
1..3.5 :egistry creation..................................................................................%$
1..% 9or!4plan implementation issues................................................................%$
/ppendi- 1 4 :eferences..............................................................................................5.
/ppendi- 2 4 /cronyms and abbre#iations..................................................................52
List of Figures
8igure 1 :ole of Organi<ation in register management =I(O 1,135>..........................25
8igure 3 Current arrangements for s&aring resources..................................................2,
8igure 5 2ultiple bilateral agreements........................................................................2,
8igure 6 6&e publis& and re4use pattern.......................................................................3.
8igure $ Publis& and re4use pattern bet'een (DIs......................................................3.
List of Boxes
o- 1 *eed for data models 4 )*1P 1ast /frican consultation..................................16
o- 2 )*?;C 6ransport data modelling.....................................................................16
o- 3 6&e need for data models 3 98P (DI proposal................................................17
o- % +eoscience data &armoni<ation case study 4 +eo(ci2; and I*(PI:1............17
o- 5 (ingle0multiple aut&oritati#e sources and supply points for data sets...............1,
o- 6 (DI (er#ice Profiling re5uirements 3 an emerging pattern...............................21
o- 7 / clear need for standards..................................................................................31
o- , I*(PI:1 met&odology for t&e de#elopment of data specifications..................33
o- 11 6&e /ustralian Ocean Portal (DI 4 *eed for a s&ared arc&itectural #ie'......3%
Name Version Date Description
P . % October Draft doc structure and bullet points
:/ ..1 7 October 8les&ed out points
P ..2 2 *o#ember Part 1 initial draft
:/ ..3 6 *o#
P ..% 7 *o#ember :estructure7 draft 'or!4plan and go#ernance frame'or!
:/ ..6 7 *o# (olution elements
P ..11 $ *o# 8urt&er 1dits
P ..1% 1, *o# 8inal draft for consultation
:/ ..15 1, *o# Interim consultation distribution
P ..16 23 Dec :e#ie' and edits
:/ 1.. 31 Dec 8inalisation of #ersion
P 1.1 .%4.34.$ 8inal edits identified by )* OC@/
UNSDI Technical Governance Framework Proposal %
EXECUTIVE SUMMARY
6&e )*(DI 'ill be a Asystem of systemsB t&at e#ol#es o#er time to create a gro'ing
capacity to meet t&e c&allenges of efficiency7 responsi#eness7 global o#er#ie' and
capability building t&at is re5uired. 1ssentially7 t&e )*(DI is an enabling frame'or!.
It 'ill pro#ide go#ernance structures and !ey resources to de#elop blueprints for t&e
establis&ment of interoperating operational (DIs 'it&in )* clusters7 agencies7
programmes and national capacity building efforts.
/ccordingly7 t&e governance framework for t&e )*(DI needs to be a robust
structure t&at creates co&erence bet'een t&e many different go#ernance acti#ities
&appening at many le#els t&roug& t&e system of systems t&at 'ill reali<e t&e )*(DI
#ision. 6&e robustness of t&is structure is dependent on understanding all t&e aspects
t&at need to be addressed =scoping t&e problem>7 t&e o#erall s&ape of t&e structure =t&e
arc&itecture> and a mec&anism to fill t&e structure in 'it& details =a go#ernance
met&odology>.
6&e go#ernance frame'or! proposed7 e-ploits best practices 'it&in t&e )*
information management space7 )*4auspiced domains7 e-isting (DI initiati#es7
international standards bodies and general information systems design.
6&is document is presented in t&ree partsC
Part 1 describes t&e document7 t&e scope and approac& of t&e consultancy.
Part describes t&e conte-ts 'it&in '&ic& t&e )*(DI and its go#ernance frame'or!
'ill be de#eloped. 6&is part of t&e document also details t&e !ey re5uirements for t&e
go#ernance frame'or!. 6&ese descriptions are not e-&austi#e7 but are intended to
identify t&e factors t&at 'ill distinguis& an effecti#e )*(DI from t&e current limited
capability.
Part ! of t&e document describes t&e proposed set of measures re5uired to meet t&e
re5uirements from eac& of t&e perspecti#es t&at affect suc& a system. 6&is &olistic
arc&itectural approac& ensures t&at all concerns identified can be addressed
systematically. / 'or!4plan is presented t&at comprises discrete pro"ects t&at build
!ey elements of t&e )*(DI capability. 6&is 'or! plan s&ould be combined 'it& t&e
business priorities and resourcing model to establis& an initial capability for t&e
)*(DI t&at pro#ides sufficient go#ernance to meet t&e tec&nical re5uirements and
mec&anisms to manage t&e ongoing e#olution of t&e )*(DI.
6&e document is an initial draft7 a Astra' manB based partly on t&e 'or! of
)*+I9+7 e-tended to include feedbac! and e-perience from t&e implementing
community and ot&er identified best practices. It is &oped t&at t&e Aseparation of
concernsB 'it&in t&e sections of t&is document ma!e it possible for sta!e&olders to
focus on t&e areas of concern and e-pertise t&ey can bring7 and to t&en pro#ide
feedbac! to identify any critical gaps in t&e !no'ledge7 scope or analysis. 6&e
solution can t&en be refined to be t&e most practical possible approac& t&at addresses
all t&e critical issues t&at &a#e been identified by t&e sta!e&olders.
6&e solution is based on t&e realities of reusability of resourcesC t&ese resources &a#e
to be building bloc!s 'it& !no'n si<e and be&a#ior7 and t&ere is an optimum si<e for
any suc& building bloc!s to pro#ide con#enience7 fle-ibility and manageability. It is
simpler to build a &ouse out of bric!s t&an randomly si<ed stones and gra#el7 and it is
easier to build a sc&ool program using a modular curriculum t&an by employing
sub"ect e-perts. 1ssentially t&e )*(DI needs to support a common understanding
from bot& t&e user and t&e producer as to '&at7 '&ere and &o' suc& building bloc!s
can be created.
PART 1 - INTRODUCTION AND BACKGROUND
#$ Introduction
#$# Purpose and scope
6&is document presents an analysis of t&e conte-t and re5uirements of a )*(DI
go#ernance frame'or! toget&er 'it& a proposed solution comprising a practical
go#ernance frame'or! for a notional )*(DI arc&itecture and a 'or!4plan to build
!ey elements of t&e )*(DI.

6&is initial draft of t&e document is intended to be used as a !ey sta!e&older
engagement tool to support t&e process of sta!e&older assessment of and input to t&e
analysis of t&e conte-t and re5uirements of t&e )*(DI as 'ell as t&e proposed
solution.
#$) Distri+ution
6&is document is intended for distribution to )*(DI sta!e&olders for internal
discussion.
#$( /r0anisation
Part 1 pro#ides an introduction7 comprising a description of t&e document7 an outline
of t&e scope7 deli#erables and approac& of t&e consultancy toget&er 'it& guiding
principle for t&e analysis and proposed design.
Part of t&e document describes !ey aspects of t&e =go#ernance7 tec&nology and
information> conte-ts 'it&in '&ic& t&e )*(DI and its go#ernance frame'or! 'ill be
de#eloped and e#ol#ed =sections 37 %7 and 5>. (ection 6 details t&e !ey re5uirements
for t&e go#ernance frame'or!.
Part ! of t&e document pro#ides a description of t&e proposed solution. 8ollo'ing a
conceptual o#er#ie' of t&e go#ernance frame'or! presented in section7 77 !ey
elements of t&e proposed solution described using fi#e viewpi!"# $%e
p%e#e!"e& i! #e'"i! () E$'* + "*e viewpi!"# $&&%e##e# &i,e%e!"
$#pe'"# + "*e #-#"e. $!& e!$/0e# "*e 1#ep$%$"i! + '!'e%!#2 "*$"
#3pp%"# /"* $ '.p0e"e4 '!#i#"e!"4 #03"i! $!& #i.p0i5'$"i! +
"*$" i!" #pe'i5' #e"# + &e"$i0#) T*e 5!$0 #e'"i! 6#e'"i! 178
p%vi&e# a 'or!4plan t&at comprises discreet pro"ects t&at build !ey elements of t&e
)*(DI capability and address critical c&allenges t&at relate to eac& of t&e 5
#ie'points or aspects of t&e )*(DI.
6&e document is intended to be a li#ing document t&at reflects t&e articulated
re5uirements7 feedbac! and ultimately design decisions t&at are ta!en by t&e
sta!e&older community.
)$ 1onsultanc terms of reference
6&is section pro#ides a brief description of t&e bac!ground to t&e )*(DI initiati#e
and outlines t&e scope of t&e consultancy and t&e approac& used to tac!le t&e problem
of go#ernance frame'or! design. 6&e section also articulates some important guiding
principles '&ic& inform t&e design of t&e )*(DI.
)$# -ack0round
/ny comple- problem needs to be resol#ed by brea!ing it do'n into smaller
problems t&at can be tac!led using a#ailable resources. Infrastructures by definition7
pro#ide benefits to multiple sta!e&olders7 so t&e problem is furt&er complicated by
ma!ing sure t&at t&ere is a mandate and business dri#er for eac& part of t&e solution.
In t&e case of a (patial Data Infrastructure7 t&e scope of t&e problem is 'ell
documented7 but t&e brea!do'n of t&e problem into smaller units is still an emerging
process. It is necessary for t&e )* to determine t&e fundamental factors influencing
t&e ability to Adi#ide and con5uerB t&e problem of impro#ing information
management and access. One ac!no'ledged constraint is t&at t&e )*(DI 'ill be a
synt&esis of acti#ities underta!en by )* agencies and sta!e&olders7 and not a single
massi#e system replacing many e-isting systems.
6&e !ey enabler for implementing t&e )*(DI is t&us a governance framework7 so
t&at t&e roles and responsibilities of eac& participant can be clearly defined.
Identification of !ey roles pro#ides a frame'or! for targeted implementation planning
of t&e critical s&ared components. It is important to &a#e a tec&nical blueprint for a
)*(DI to identify specific re5uirements7 but to minimi<e t&e e-tent to '&ic& t&is
depends on current tec&nologies.
)$) /+2ectives
6&e primary ob"ecti#e of t&e consultancy is to de#elop a conceptual frame'or! for
t&e resolution of go#ernance issues t&roug& t&e creation of appropriate go#ernance
mec&anisms. (pecifically t&e frame'or! mustC
articulate t&e scope of tec&nical0operational go#ernance and its relations&ip to
enclosing institutional go#ernance processes and realities7 and 'it& reference to
t&e )*(DI Compendium =@enric!sen7 2..7> and t&e (trategy for De#eloping and
Implementing )*(DI
1
documentD
detail !ey aspects of t&e operational0tec&nical go#ernance as it relates to t&e
)*(DI as an enabling and integration tool for operational infrastructures 'it&in
)* agencies7 national "urisdictions and regional or international collaborationsD
1
Ibi
&ig&lig&t and ma!e recommendations regarding critical priority tec&nical
go#ernance issues t&at need to be addressed by t&e )*(DI in reference to !ey )se
Cases and associated roles for ma"or actors.
6&e go#ernance frame'or! presented in t&is document 'as presented at t&e 1ig&t
)*+I9+ Plenary &eld from 2$43. *o#ember 2..77 in ang!o!7 6&ailand.
)$( 1onsultanc delivera+les
6&e principle deli#erables from t&e consultancy areC
a. / document describing t&e )*(DI 6ec&nical +o#ernance 8rame'or!7
including an e-ecuti#e summary.= t&is document>
b. Draft terms of reference =6O:>7 for #arious roles adopted by )*+I9+
'it&in t&e tec&nical go#ernance structure
c. / guidance note '&ic& 'ill &elp t&e C&air of t&e tec&nical go#ernance
session=s> to conduct a structured discussion and decision ma!ing process
on priority issues and t&e 'ay to address t&em.
d. / draft pro"ect 'or! plan for t&e de#elopment of t&e )*(DI tec&nical
arc&itecture. 6&e outline of a pro"ect plan 'ill be prepared for t&e ang!o!
meeting for discussion. 6&is document 'ill be more fully fles&ed out
based on t&e deliberations of t&e ang!o! meeting.
)$& 1onsultanc approach
)$&$# /verview
6&e approac& of t&e consultancy 'as to e-amine7 'it& t&e aid of specific e-amples of
needs7 t&e interoperability re5uirements implied by t&e scope of t&e )*(DI. 6a!ing a
broad #ie'7 'it& practicalities in mind7 an o#erall go#ernance frame'or! 'ill be
deri#ed7 t&roug& '&ic& t&e de#elopment of specific go#ernance and tec&nical
interoperability arrangements can be facilitated. /lt&oug& t&e details of suc&
arrangements are beyond t&e scope of t&e frame'or!7 specific e-amples are included
to e-plain t&e simplifying abstractions of t&e conceptual frame'or!. It s&ould be
noted t&e detail of t&ese e-amples is purely illustrati#e7 and not proscripti#e7 since
t&ere is no intention to preclude meaningful sta!e&older participation or tec&nical
#alidation processes.

rea!ing t&e scope of t&e problem into more manageable pieces is a !ey aspect of t&e
approac&. 6&is can be furt&er refined using a formal system modelling approac&7 'it&
emp&asis on identifying t&e actors and )se Cases in#ol#ed in t&e go#ernance
processes implied by t&e establis&ment of a )*(DI. est practice in (DI arc&itecture
pro#ides a basic separation of concerns7 '&ereby t&e problem can be bro!en do'n
into a set of issues 'it& minimal interdependence. / preliminary analysis of t&e
go#ernance re5uirements for establis&ment of eac& arc&itectural component 'as
underta!en.
)$&$) Stakeholder en0a0ement
(ta!e&older input to t&e go#ernance frame'or! 'as ac&ie#ed primarily t&roug& t&e
)*+I9+4$ meeting in ang!o!. Dra'ing on best practice and prioritised action areas
UNSDI Technical Governance Framework Proposal $
allo's t&e consultation to focus on critical issues and identifying gaps in t&e needs
analysis.
9&ile de#eloping t&e go#ernance frame'or!7 targeted sta!e&older engagement 'as
used to capture representati#e sta!e&older re5uirements. 6&is 'as ac&ie#ed byC
:e#ie' of e-isting materials from rele#ant (DI initiati#es to capture
go#ernance re5uirements
Discussions 'it& selected sta!e&olders '&om &ad identified c&allenges in t&e
go#ernance realm typically t&roug& on4going initiati#es in t&e )*(DI space.
)$3 UNSDI Guidin0 Principles
/doption of a +eospatial 1nterprise approac& as ad#ocated in t&e )*(DI
Compendium
6&e )*(DI pro"ect 'ill implement t&e minimum necessary to reali<e
effecti#e access and reuse of e-isting and future )* information resourcesD
6&e )*(DI 'ill be implemented t&roug& support for impro#ed
interoperability bet'een components of )* operational systems and e-ternal
resourcesD
6&e )*(DI 'ill pro#ide a common mec&anism for =bi4directional> s&aring
)* information resources bet'een t&e )* and e-ternal sta!e&olders7 t&ereby
enabling '&ole4of4)* access to e-ternal resources '&ere appropriate.
6&e )*(DI 'ill be an implementation of emerging best practice7 and 'ill
adopt and adapt solutions before in#ention of ne' approac&esD
6&e needs of )* internal information management 'ill be used to scope a
go#ernance frame'or!7 &o'e#er eac& aspect 'ill be e-amined to identify its role
in a 'ider integration bet'een t&e )*(DI and ot&er domainsD
(ome components may e-ist to enable integration and management of t&e
)*(DI7 and t&ese may &a#e specific go#ernance re5uirementsD
1ac& component needs to &a#e a specific role7 go#ernance arrangements and
functionality t&at is useful to sta!e&olders 3 i.e. can be relied on for a particular
purposeD
1ac& component must be implementable today7 and be re4implemented 'it&
impro#ed tec&nologies at any time in t&e futureD
*eed to support broad impro#ements instead of mandating strict ad&erence to
ideals7 '&ilst still de#eloping EaspirationalF targets for t&ose people de#eloping
ne' systemsD
(implicity of indi#idual components is !ey7 rat&er t&an t&e system as a '&oleD
(implicity of use s&ould pre#ail o#er simplicity of implementation7 and
li!e'ise simplicity of deployment s&ould ta!e precedence o#er implementation of
tec&nologyD
)* specific scenarios 'ill be used to e-plain t&e general principles identified7
&o'e#er t&ey are intended to be illustrati#e7 not proscripti#e7 as to &o' to ac&ie#e
)*(DI goals.
UNSDI Technical Governance Framework Proposal ,
PART 2 - CONTEXT AND REQUIREMENTS
6&is section of t&e document describes pertinent interrelated aspects of t&e reality in
'&ic& t&e )*(DI e-ists and '&ic& must be factored into )*(DI design. 6&e section
co#ers institutional and go#ernance conte-t7 data and information conte-t and t&e
tec&nology conte-t of t&e )*(DI.

($ Institutional and 0overnance conte.t
($# Scope and definitions
($#$# Governance
!Governance makes ecisions that e"ine e#pectations$ %rant power$ or veri"y
per"ormance. It consists either o" a separate process or o" a speci"ic part o"
mana%ement or leaership processes.&
'
+o#ernance aims to de#elop and manage consistent7 co&esi#e policies7 processes and
decision4rig&ts for a gi#en area of responsibility.
($#$) S/, 0overnance
/ narro'er scope of definition applied to net'or! ser#ices 'it&in a (er#ice Oriented
/rc&itecture =(O/> approac&7 suc& as t&ose en#isaged as a !ey enabler of t&e )*(DI
data access strategy isC
!S() %overnance is abo*t mana%in% the +*ality$ consistency$ preictability$ chan%e
an interepenencies o" services.& =(tane!7 2..6>
9i!ipedia also pro#ides a useful set of typical issues t&at are li!ely to emerge in
(O/C
,ompliance to stanars or laws- IT systems re+*ire a*itin% to prove their
compliance to re%*lations like .Sarbanes/(#ley0. In a S()$ service behavior
is o"ten *nknown
,han%e mana%ement- chan%in% a service o"ten has *n"oreseen conse+*ences
as the service cons*mers are *nknown to the service proviers. This makes an
impact analysis "or chan%in% a service more i""ic*lt than *s*al.
1ns*rin% +*ality o" services- The "le#ibility o" S() to a new services
re+*ires e#tra attention "or the +*ality o" these services. This concerns both
the +*ality o" esi%n as the +*ality o" service. )s services o"ten call *pon other
services$ one mal"*nctionin% service can ca*se ama%e in many applications.
Some key activities that are o"ten mentione as bein% part o" S() %overnance are-
2ana%in% the port"olio o" services- plannin% evelopment o" new services an
*patin% c*rrent services
2ana%in% the service li"ecycle- meant to ens*re that *pates o" services o
not ist*rb c*rrent service cons*mers
2
&ttpC00en.'i!ipedia.org0'i!i0+o#ernance
UNSDI Technical Governance Framework Proposal 1.
Usin% policies to restrict behavio*r- r*les can be create that all services
nee to apply to$ to ens*re consistency o" services
2onitorin% per"ormance o" services- beca*se o" service composition$ the
conse+*ences o" service owntime or *nerper"ormance can be severe. 3y
monitorin% service per"ormance an availability$ action can be taken instantly
when a problem occ*rs.&
($#$( /perational4technical 0overnance and institutional 0overnance
It is of critical importance is ensure t&at t&ere is no gap bet'een t&e institutional
mec&anisms and t&e tec&nical implementation re5uirements. 6&is &as pro#ed to be t&e
biggest single barrier to effecti#e interoperability in t&e past7 and is typified by lac! of
a publication and c&ange control process for common elements.
8or e-ample7 a typical scenario is '&ere t'o or more organi<ations agree to s&are a
common #ocabulary7 and create copies of t&at #ocabulary 'it&in database systems
'it&out formally publis&ing t&e #ocabulary and agreeing c&ange control processes.
O#er time eac& organi<ation adapts and e-tends t&e #ocabulary7 and interoperability is
compromised '&en t&e data is t&en accessed #ia a common mec&anism. 6&is situation
is so common as to almost c&aracteri<e t&e current situation.
8or t&e purposes of t&is e-ercise7 'e distinguis& bet'een t&ree critical areas of
go#ernanceC
Institutional go#ernance7 relating to t&e roles and responsibilities )* agencies
&a#e in t&e ongoing use and contribution to t&e )*(DI and its enabled outcomesD
8rame'or! go#ernance7 relating to t&e de#elopment of an initial capability
and ongoing institutional support for t&e critical enabling componentsD
6ec&nical go#ernance7 relating to t&e specific go#ernance re5uirements of
components of a functional )*(DI.
In general7 an issue can be regarded as a tec&nical go#ernance issue if t&ere is an
artifact to be go#erned. (uc& an artifact is somet&ing t&at eit&erC
o specifies an agreement about &o' some aspect of a component 'ill
be&a#e
o deploys a component t&at implements t&ese agreement
($) Separation of 0overnance concerns
In order to understand t&e re5uirements for and t&us design7 a large comple-
distributed system it is necessary to partition t&e problem space into logical7 discrete
parts. 6&is separation of concerns enables bot& t&e parts and t&e relations&ip bet'een
t&em to be analy<ed and understood. 6&is approac& enables t&e analysis7 design and
implementation of a system to be tac!led in step'ise7 logical se5uence of acti#ities.
(eparation of concerns 'ill ensure t&at roles and responsibility for lifecycle of e#ery
element of t&e )*(DI are clearly articulated. 8rom t&e go#ernance perspecti#e7 t&is is
essential. 6&e identification of t&e Eo'nerF and go#ernance of a specific component of
t&e )*(DI be it a policy7 a standard7 a ser#ice7 a ser#er7 or a data set ensures t&at
go#ernance realities and dependencies are understood. 6&is informs t&e tec&nical
design of t&e solution as 'ell as enabling critical dependencies and t&us ris!s for
o#erall )*(DI go#ernance to be flagged and addressed.
6o ensure t&at )*(DI capabilities are identified and addressed in order of priority 7
t&e business dri#ers for usage of s&ared resources 'ill need to be understood. 6&e
mapping of business needs to de#elopment of !ey capabilities 'ill ensure t&at t&e
essential business4dri#en capabilities are prioriti<ed. 8rom a pragmatic perspecti#e it
is useful to identify business cases '&ere t&e data pro#ider is ready for
implementation toget&er 'it& 'ell understood use case for t&e use of t&e geospatial
data.
($( Inter and intra SDI 0overnance
Conceptually7 t&e )*(DI is concei#ed as being built from (DI building bloc!s. 8rom
t&is conceptual position7 t&e go#ernance problem space &as been di#ided into inter4
(DI and intra4(DI go#ernance realms.
8or indi#idual (DIs to interoperate and t&us s&are resources7 agreements defining
interoperability e-pectations bet'een t&e (DIs need to be in place. 6&ese agreements
need to be go#erned so t&at t&ey can be adopted7 adapted7 disco#ered7 used and
retired. 6&is critical set of go#ernance capabilities is termed inter"#D$ governance.
9it&in indi#idual (DIs t&ere is a need to publis& interoperable ser#ices t&at deli#er
seamless data for users. 6&is is ac&ie#ed t&roug& agreements t&at determine policy4
le#el =e.g. (DI participation>7 tec&nology4le#el =e.g. protocols7 ser#ices7 soft'are> and
information4le#el =e.g. data models7 metadata7 common #ocabularies> interoperability.
:at&er t&an duplicating effort to re4create agreements bet'een sta!e&olders 'it&in an
(DI it is proposed t&at agreements are in&erited from e-isting (DIs ='it& '&ic& t&e
(DI 'is&es to align itself> and adapted as re5uired.
6&e go#ernance of agreements toget&er 'it& t&e assets produced using t&em i.e. t&e
tec&nical7 information and ot&er resources of t&e infrastructure7 is termed intra"#D$
governance%

($& 5volvin0 nature of 0overnance approach
+o#ernance arrangements ta!e longer to de#elop t&an anyt&ing else 'it&in t&e (DI.
6&erefore as t&e (DI gro's7 fle-ible responsi#e go#ernance 'ill be re5uired. 6&e
go#ernance frame'or! must also support effecti#e transition from interim to longer
term goals of t&e (DI as it matures from start4up configuration to a mature
infrastructure.

($3 ,ddressin0 intan0i+le SDI success factors
A# #"$"e& i! "*e UNSDI '.pe!&i3. 9i!:3e!'e + i!"$!;i/0e +$'"%#
#3'* $# "*e pep0e4 p%'e&3%e# $!& "*e w%< '30"3%e# i!v0ve& wie0&
(7= + "*e %e#p!#i/i0i"- +% "*e #3''e## % "*e%wi#e + "*e SDI)>
A0"*3;* $""e.p"i!; " "$'<0e "*e#e i!"$!;i/0e #3''e## +$'"%# i#
/e-!& "*e #'pe + "*e "e'*!i'$0 ;ve%!$!'e +%$.ew%<4 $!$0-#i#
$!& %e#30"$!" p%p#$0# $%e ';!i?$!" + "*e !ee& " .i"i;$"e "*e#e
%i#< +$'"%#)
T*e #03"i! &e#i;! $""e.p"# " 5!& $pp%$'*e# " $&&%e## +$'"%#
#3'* $# pe%$"i!; e!vi%!.e!" $!& '30"3%e4 v$%-i!; 0eve0# +
'..i".e!" $!& "*e '.p0e@4 +"e! p0i"i'i#e& !$"3%e +
%e0$"i!#*ip# /e"wee! $'"%# wi"*i! "*e UN)
Gey issues to be addressed in t&is conte-t areC
1ngagement 'it& and roles of I6 fol!s in )*(DI and (O/ go#ernance
1ngagement 'it& management to 'in support for )*(DI and t&e paradigm
s&ifts t&at s&ared resources and (O/ imply
(timulating7 supporting c&anging 'or!ing practices 3 mo#e from sto#epipes
to ser#ices

($6 Governance dimensions of an UNSDI
($6$# /verview
6&e )*(DI go#ernance frame'or! needs to ta!e into account t&e multiple
sta!e&olders '&o 'ill be directly and indirectly affected by t&e establis&ment of
impro#ed information access and management.
6&ese sta!e&olders are many and #aried7 and are best understood by e-ploring t&e
different AdimensionsB of t&e )*(DI. 1ac& of t&e aspects described belo' represent a
#alid 'ay of di#iding t&e scope of t&e )*(DI c&allenge7 and in total pro#ide a basis
to identify t&e simplest common approac&es t&at can be used to define component
be&a#ior7 and &ence an implementation strategy.
Ob#iously7 t&ere may be natural correspondences bet'een sta!e&olders as identified
in different dimensions7 for e-ample national "urisdictions are natural data pro#iders
to global users7 and global programs =in particular 1art& Obser#ation> are data
pro#iders to national users.
($6$) 7ulti8domain
6&e )nited *ations acti#ities co#er a broad range of domains and t&e operations of
single agencies typically re5uire data spanning multiple domains. 6&e )*(DI must
enable t&e de#elopment of common applications t&at are able to utilise data from
different sources. 8or effecti#e data integration across "urisdictions7 common
semantics and data models are re5uired 'it&in eac& domain. @armonisation across
domains is also re5uired to ensure t&e consistent treatment of ob"ects t&at are included
in a number of different domains. It is a desirable end goal to pro#ide seamless data
integration7 '&ere t&e end user does no need to be a'are of differences in data
management7 &o'e#er t&e more pragmatic goal is to enable a continual e#olution of
impro#ements in data integration.
6&e need for t&e &armoni<ation of data models 'it&in and across domains impliesC
go#ernance of common modelling aims and institutional processes across
domains
use of standards and common approac&es to data modelling
modular models components t&at are interoperable and t&at can be reused
($6$( 7ulti'2urisdictional
)* operations co#er multiple "urisdictions. 6&e "urisdictions t&at fall 'it&in t&e
mandate of )* entities =programmes7 funds and agencies> also #aries from agency to
agency.
6o effecti#ely use information for decision ma!ing7 t&e )* needs to collate7 generate
and use data co#ering a number of "urisdictions. 6o be able to integrate data products
seamlessly across "urisdictions7 a mec&anism for supporting de#elopment and use of
common standards is re5uired.
/lt&oug& national standards for data sets7 data products and ser#ices t&at enable
integration of data 'it&in a national (DI may e-ist7 t&ere is a need to &armoni<e and
standardi<e standards across (DIs and "urisdictions.
6&e standardi<ation bet'een t'o "urisdictions implies t&e e-istence of a &ig&er
go#erning aut&ority. 9&en attempting to standardi<e across t'o global or regional
(DI t&at comprise multiple domains and multiple "urisdictions7 t&e )* is best
mandated to tac!le t&is c&allenge.
($6$& Diverse participation capa+ilities
It is clear t&at t&ere is a large #ariation in geospatial tec&nology upta!e 'it&in t&e )*
as 'ell as t&e degree of understanding of and participation in t&e )*(DI. 6ec&nical
go#ernance must t&erefore support a broad spectrum of participation so t&at
sta!e&olders 'it& #arying le#els of tec&nical s!ills7 geospatial re5uirements and
commitment le#els can effecti#ely participate in t&e (DI effort.
($6$3 7ultiple interopera+ilit level support
6&ere are li!ely to be different interoperability re5uirements and e-pectations
bet'een sta!e&olders 'it&in and bet'een (DIs. 6&e )*(DI 'ill need pro#ide
mec&anisms to support interoperability at t&e follo'ing le#els of interoperabilityC
Organi<ational interoperability 3 consistent policies la's7 business cases
o /m I aut&ori<ed to access it
o is it of use
6ec&nical interoperability
o protocols and synta- 3determines ability to s&are data7 processing and
tools
Information interoperability
o Common structure 4 ability to integrate and transform data if t&e
information is structured consistently
o /greed semantic 4 agreed descriptions and definitions to ensure t&at
information can be understand and use
($6$6 Differin0 conte.t and re9uirements for UN SDIs
/ )*(DI component may &a#e significantly different go#ernance re5uirements for
different uses7 e#en if t&e tec&nical details are identical. 6&e most ob#ious split is
bet'een operational systems7 systems acti#ated in response to a crisis7 systems used
UNSDI Technical Governance Framework Proposal 1%
to optimi<e planning processes and researc&. (ome systems7 suc& as monitoring
systems7 may be used in multiple roles.
($6$: Temporal chan0e
1stablis&ing t&e initial capability and organi<ational go#ernance arc&itecture of t&e
)*(DI 'ill re5uire a pro"ect administered by a single )* agency. It is anticipated
t&at t&e )*(DI pro"ect7 &a#ing ac&ie#ed stated ob"ecti#es7 'ill become a programme
and t&us attain a more permanent status in t&e )* system. 6&is is a !no'n
organi<ational c&ange. In addition7 current )* reform may lead to as yet un!no'n
c&anges in &o' business is conducted by t&e )*.
6&e tec&nical go#ernance frame'or! must t&erefore be separated from t&e
institutional frame'or! t&at go#erns t&e )*(DI. In addition t&e frame'or! must be
able to adapt to anticipated system4'ide re4organi<ation t&at are li!ely to lead to
s&ifting business practices7 rules and institutional roles and relations&ips of !ey
sta!e&olders in#ol#ed in t&e )*(DI effort.
6&e go#ernance frame'or! must also transcend any current (DI implementation
tec&nology paradigm. 6&e go#ernance structure must t&erefore be clearly separated
from t&e system tec&nology as t&e go#ernance frame'or! 'ill in fact enable t&e
transitions bet'een tec&nology paradigms.
($: UN reform
In 2... t&e t&en )* (ecretary +eneral7 Gofi /nnan produced a report t&at pro#ided
recommendations for Arene'ing t&e )*& to meet t&e c&allenges facing t&e 'orld in
t&e ne' millennium =/nnan7 2...>. In addition to t&e need to become more effecti#e
and efficient7 t&e report &ig&lig&ted t&e need for t&e )* to EH.increasin%ly serve as a
catalyst "or collective action$ both amon% its 2ember States an between them an
the vibrant constellation o" new non/state actors&. 6&e report also &ig&lig&ted t&at t&e
)nited *ations s&ould !harness the power o" technolo%y to improve the "ort*nes o"
evelopin% ,o*ntries&.
ot& statements &ig&lig&t !ey potential roles of t&e )*(DI in mediating bet'een
domains and "urisdictions to enable (DI interoperability and of assisting de#eloping
countries to de#elop (DI capabilities.
2ore recently7 t&e )* (ecretary4+eneralFs @ig&4;e#el Panel made a series of
recommendations to Aovercome the "ra%mentation o" the Unite Nations so that the
system can eliver as one& =)nited *ations7 2..6>. 6&e report recommended
focusing on impro#ing )* efficiency and effecti#eness7 system4'ide co&erence and
management reform.
8rom t&e foregoing and as noted in t&e )*(DI compendium =@enric!sen7 2..7>7 it
can be concluded t&at t&e )* system recognises a need to Emove with the timesF in
order to deli#er on its mandate.
6&e )*(DI is t&erefore li!ely to be implemented during a period of ma"or reform
'it&in t&e )*. 6&is represents a t&reat as 'ell as an opportunity. 6&e t&reat is t&at t&e
institutional conte-t of t&e )*(DI 'ill be e#ol#ing and structures7 staffing roles and
relations&ips bet'een )* sta!e&older organi<ations are li!ely to c&ange.
6&e )* reform process can also be #ie'ed as an opportunity. In an ideal 'orld t&e
analysis of critical )* business processes using structured7 transparent business
process analysis tools could add significantly not only to t&e design of tec&nical
system but to t&e broader institutional systems of t&e )*.
6&e go#ernance frame'or! must be fle-ible enoug& to adapt to t&ese c&anging
institutional reality.
&$ Data conte.t
&$# Interopera+ilit
Currently7 geospatial data are &eld in a range of &eterogeneous7 proprietary data
standards and formats. /lt&oug& tec&nical interoperability &as been ac&ie#ed t&roug&
t&e use of 'eb ser#ices and t&e ability of geospatial applications to read ot&er non4
nati#e data formats7 increasing emp&asis is being placed on t&e need to standardi<e
data structure and semantics7 t&roug& t&e use of data models.
Communities t&at are acti#ely building (DI using (O/ approac&es &a#e reali<ed t&at
in order to mo#e beyond simple #isual integration of data from geospatial 'eb
ser#ices7 t&ere is a need to de#elop and use standardi<ed data models =or application
sc&ema> for domains and to &armoni<e data models across domains and "urisdictions.
6&is need becomes increasingly critical as t&ematic and "urisdictional (DIs attempt to
interoperate to build national7 regional and global (DIs.
2any data modeling acti#ities are already under'ay 'it&in sub"ect domains7 often
under t&e auspices of )* sanctioned bodies 1-amples include geosciences7 marine7
meteorology7 land co#er7 and land administration. 1fforts to &armoni<e data models
&a#e commenced and e-periences to date &a#e unco#ered some #ery important
c&allenges in t&e go#ernance sp&ere.
6&e )*(DI go#ernance effort 'ill need to incorporate go#ernance mec&anisms to
support &armoni<ation and integration of cross4domain data modeling initiati#es if
true data interoperability is to be ac&ie#ed.

Box 1 Nee& for &ata mo&els " 'N(P (ast )frican consultation
/t t&e )*1P :egional =1ast /frican> Consultation on t&e +o#ernance of t&e )*(DI7
participants identified t&e follo'ing as demands of (DI customers related to data standards
and models =9ilson7 2..7>C
aligned7 reconciled7 &armonised data items
standardised #ocabularies for data items7 ser#ices and attributes =t&esaurus for domain
specialisation>
3rd party li!e )* to assist in data &armonisation and data standards
Box 'N*LC Transport &ata mo&elling
!

)*?;C recently completed t&e de#elopment of t&e first #ersion of a transport data model. 6&e
)*(DI46ransport focus 'as on semantics 3 i.e. to ensure t&at '&ate#er database structure a
gi#en agency c&ose to implement7 it 'ould &a#e a common core set of attributes and #alue
domains on '&ic& to base data import0e-ports.
6&e starting point for scoping semantic definitions 'as a compilation of t&e most common
practices in logistics data collection and data storage. Consultation 'it& logisticians 'ere used
to furt&er refine and clarify re5uirements. 6&e result of t&e consultation 'as a list of ob"ects
definition 'it& attributes and #alue domains. 6&e ob"ect model 'as using 1(:IIs +eodatabase
model
%
.

/lt&oug& t&e model 'as de#eloped by )*?;C based on re5uirements of logistics users7 t&e
process 'as cognisant of t&e need to be compatible 'it& t&e e#ol#ing )*(DI as 'ell as ot&er
related modelling efforts. 6&e )*(DI46 team are no' e-ploring integration0&armoni<ation of
t&e semantics of t&e )*(DI46 'it& ot&er transport data modelling efforts suc& as t&e
COD/6/ open source 1C2..7... map pro"ect.
6&e follo'ing general =)*(DI related> and specific data modelling go#ernance c&allenges
'ere identified by t&e team during t&e modelling processC
+eneral 'N#D$ governance
9&o &as o'ners&ip of t&e #arious components of t&e )*(DIJ
/lt&oug& t&ere is a Enatural mandateF for certain agencies o#er specific parts of t&e
)*(DI7 s&ould t&is mandate0aut&ority be formalised7 if so &o'J
Data mo&elling
9&at is t&e mec&anism for updating sc&ema and &o' is consensus builtJ
Is t&ere to be a set timetable for updates and &o' can participation be effecti#ely
ac&ie#ed =i.e. &a#ing too many unstructured contributors becomes unmanageable>
:e5uirements =for data model> can come from t&e consumers in an ad &oc manner 4
&o' can t&is input be impro#ed
*eed to ad#ocate for a culture of disaggregated indicators0attributes t&at can be
recombined as needed as t&e basis for a )*(DI.
*eed to determine structured and documented mec&anism for translation from e-ternal
data models to )*(DI and #ice #ersa =e.g.C '&en integrating a national road data model
into )*(DI7 t&ere 'ill be some #alue mapping to be done. On '&at basis are
e5ui#alencies determinedJ>.
Box ! T,e nee& for &ata mo&els - .FP #D$ proposal
98P conducted an (DI needs assessment to de#elop a proposal for a 98P (DI as part of t&e
)*(DI effort =98P K I6@/C/7 2..7>. 6&e assessment focused on t&e needs of 98P +I(
user departments =OD/P7 OD/L and )*?;C>. One of t&e principle needs identified 'as to
define implement maintain and distribute common data sets for use across all geospatial data
departments. 6&e de#elopment of a data model 'as identified as being t&e critical first step to
ac&ie#ing t&e data reliability7 integrity7 standardi<ation and metadata integration.
Box / +eoscience &ata ,armoni0ation case stu&1 " +eo#ci2L an& $N#P$3(
4
3
ased on con#ersations0correspondence 'it& Oli#ier Cottray )*?;C October 2..7
%
(ee )*(DI46 'ebpage '''.un"lc.org0mapcenter0unsdi
5
ased on discussions bet'een I*(PI:1 and +eo(ci2; communities
I*(PI:1 data specifications are being de#eloped for !ey data sets. 6&ese data specifications
'ill be t&e result of a &armonisation process based on e-isting =national> data specifications
and7 '&ere a#ailable7 user re5uirements and use cases pro#ided by I*(PI:1 sta!e&olders.
6&ere are ongoing discussions regarding approac&es to &armonisation of data modelling
efforts for geoscience data in a global domain =+eo(ci2;> and a "urisdictional conte-t
=I*(PI:1>.

6&e +eo(ci2; International effort ta!es t&e position t&at it cannot become dependent on a
local or regional frame'or!7 especially one 'it& immature go#ernance and tec&nical
processes. It cannot t&erefore become based on an I*(PI:1 generic conceptual model.
6&e mec&anisms a#ailable for resol#ing t&is include t&e de#elopment of a profiling
met&odology 'it&in t&e I*(PI:1 conceptual model7 to allo' adoption of t&e +eo(ci2;
model. 6o ac&ie#e t&is7 bot& frame'or!s may need to agree on common profiling
mec&anisms7 so t&at on t&e one &and +eo(ci2; can identify t&e target ob"ects for suc&
profiling in a 'ay t&at ma!es it easy7 and I*(PI:1 'ould need to apply t&e profiling
mec&anism.
/n alternati#e option 'ould be for t&e I*(PI:1 +eneric Conceptual 2odel to be replaced by
an internationally recognised e5ui#alent7 suc& as a )* endorsed7 and e#entually I(O
standardised tool!it. It is li!ely t&at t&e profiling mec&anism 'ould still &o'e#er be re5uired
to ac&ie#e implementation.
In any e#ent7 t&e fact t&at bot& modelling e-ercises dra' from a common I(O basis ma!es it
feasible to consider addressing t&e go#ernance issues and ac&ie#ing a common data model
bet'een I*(PI:1 and t&e international community of practice.
+eoscience data &armoni<ation case study 4 +eo(ci2; and I*(PI:1

&$) Data 0eneration; distri+ution and use
)*(DI sta!e&olders 'ill &a#e mar!edly different re5uirements and responsibilities
according to '&et&er t&ey are deli#ering data or ac5uiring it. 2any sta!e&olders 'ill
participate in bot& roles7 and generally any data pro#ider 'ill re5uire access to
ancillary data as part of t&e data generation process.
&$( Data concentrations and silos
6&e concentration and nature of data a#ailable for a particular p&enomenon
significantly determines t&e resources re5uired to manage and distribute t&at data.
+lobal satellite based monitoring re5uires arc&i#al capabilities t&at need an ongoing
'ell resourced mandate. Indi#idual pro"ects may create information '&ose re4use and
potential #alue is un!no'n7 but re5uires little o#er&ead to manage and ma!e
a#ailable.
Data t&at could potentially be re4used are often &eld in isolated EsilosF t&at are7 to
#arying degrees accessible 'it&in t&e pro"ect7 unit7 department7 or organi<ation t&at is
data custodian as 'ell as outside of t&e organi<ation. 6&e data are stored in different
storage formats 'it& different data structures and semantics 'it& and 'it&out
metadata.
UNSDI Technical Governance Framework Proposal 1$
&$& 1ustodianship and sources
/ priority tas! in t&e creation of any (DI is t&e determination of core common
geospatial data and t&e identification of custodian responsible for creation and
maintenance of t&e data set. ;ac! of clarity about aut&oritati#e sources of data leads
toC
Duplication of effort to produce and maintain data sets
/dministrati#e o#er&ead to sync&roni<e data sets
Confusion for users about point of trut&
In addition t&ere is a need to determine point of trut& for data sets i.e. '&ere data can
be obtained from7 and to determine &o' to sync&roni<e multiple copies of t&e same
data set a#ailable from multiple locations.
Box 4 #ingle5multiple aut,oritative sources an& suppl1 points for &ata sets
Participants at t&e :egional =1ast /frican> Consultation on t&e +o#ernance of t&e )*(DI
discussed issues related to desirability of &a#ing single or multiple aut&oritati#e data sources
and t&e supply options =9ilson7 2..7> . Issues raised includeC
Desirability of &a#ing a single aut&oritati#e source for data and does t&is mean a single
point of supply
Desirability of &a#ing multiple aut&oritati#e sources for data '&ere t&ere could be direct
competition7 confusion in t&e minds of users =customers>7 different sources based on scale
=duplication 'it&out generalisation>7 competition from pri#ate suppliers7 different
access0pricing arrangements
Desirability of &a#ing multiple points of supply. :aises issues of contemporaneity and
sync&roni<ing of data &oldings
Due to band'idt& limitations7 t&ere is s need to store local copies of data. 6&is again
raises issues of contemporaneity and sync&roni<ing of data &oldings
3$ Technolo0 conte.t
3$# 5mer0in0 Technical Factors
3$#$# Si0nificant patterns
6&is section deals 'it& t&e significant emerging factors in t&e tec&nical aspects of
(DI7 and in particular t&ose t&at specifically rely on or implement tec&nical
go#ernance. 6&is section in particular attempts to identify emerging best practices
t&at are not already addressed in t&e )*(DI Implementation (trategy.
3$#$) Service /riented ,rchitectures
(er#ice Oriented /rc&itectures =(O/> are7 li!e most suc& concepts and terminology7
sub"ect to a fair amount of self4ser#ing narro'ness of definition around particular
tec&nologies. 6&e core description from 9i!ipedia
6
pro#ides a useful o#er#ie'.
Issues &ig&lig&ted in bol& are of critical importance to t&e )*(DI strategy.
!Relative to earlier attempts to promote software reuse via mo*larity o" "*nctions$
or by *se o" pree"ine %ro*ps o" "*nctions known as classes$ S()4s atomic level
ob5ects are 166 to 1$666 times lar%er$ an are associate by an application esi%ner
or en%ineer *sin% orchestration. In the process o" orchestration$ relatively lar%e
ch*nks o" so"tware "*nctionality 7services8 are associate in a non/hierarchical
6
&ttpC00en.'i!ipedia.org0'i!i0(er#ice4orientedMarc&itecture
UNSDI Technical Governance Framework Proposal 1,
arran%ement 7in contrast to a class4s hierarchies8 by a so"tware en%ineer$ or process
en%ineer$ *sin% a special so"tware tool which contains an e#ha*stive list o" all o" the
services$ their characteristics$ an a means to recor the esi%ner4s choices which the
esi%ner can mana%e an the so"tware system can cons*me an *se at r*n/time.
Underlying and enabling all of this is metadata which is s*""icient to escribe not
only the characteristics o" these services$ b*t also the ata that rives them. 92: has
been *se e#tensively in S() to create ata which is wrappe in a nearly e#ha*stive
escription container. )nalo%o*sly$ the services themselves are typically escribe by
;SD:$ an comm*nications protocols by S()P. Whether these description
languages are the best possible for the job, and whether they will remain the
favourites going forward, is at present an open question. ;hat is certain is that SO
is utterly dependent on data an services that are escribe *sin% some
implementation o" metaata which meets two criteria. !he metadata must be in a
form which software systems can consume to dynamically configure to maintain
coherence and integrity, and in a form which system designers can understand and
use to manage that metadata.
The %oal o" S() is to allow "airly lar%e ch*nks o" "*nctionality to be str*n% to%ether
to form ad"hoc applications which are built almost entirely from e#isting software
services. The lar%er the ch*nks$ the "ewer the inter"ace points re+*ire to implement
any %iven set o" "*nctionality< however$ very lar%e ch*nks o" "*nctionality may not be
%ran*lar eno*%h to be easily re*se. 1ach inter"ace brin%s with it some amo*nt o"
processin% overhea$ so there is a per"ormance consieration in choosin% the
%ran*larity o" services. The %reat promise o" S() is that the mar%inal cost o" creatin%
the n/th application is =ero$ as all o" the so"tware re+*ire alreay e#ists to satis"y the
re+*irements o" other applications. Only orchestration is required to produce a new
application.&
In t&e conte-t of t&e )*(DI7 t&e actual form of t&e ser#ices are not t&e critical issue7
so muc& as t&e ability to encapsulate6 &escribe and re"use% (er#ices may be
net'or!4accessible or e#en CD4distribution7 but t&e implications for go#ernance
relate to t&e ability of ser#ice be&a#iors and metadata to be bro!en do'n into
standardi<ed c&un!s t&at can be used to Aorc&estrateB t&e pro#ider0consumer
interaction.
3$#$( <e+ services and conformance profiles
Impro#ed access to data is t&e rationale for (DI establis&ment. 6&is is ac&ie#ed
t&roug& establis&ment and publis&ing of ser#ices t&at enable access to data. One
family of standards t&at are a#ailable to implement t&is function is t&e Open
+eospatial Consortiums 9eb (er#ices specifications. 6&ese define t&e semantics of
spatial operations and pro#ide bindings to common net'or! protocols.
(uc& 'eb ser#ice specifications are necessarily broad since t&ey pro#ide common
semantics across a #ariety of possible implementations. In general7 t&ese
specifications &a#e many optional elements t&at may be seen as necessary 'it&in a
s&ared resources frame'or!7 suc& as detail of metadata about a#ailable data. 6&e
specifications7 for t&e most part7 ma!e no restriction on t&e type7 meaning or
identification of t&e data itself. Differing implementation c&oices for aspects of
ser#ices can significantly reduce information interoperability. 8or e-ample if one data
publis&er users a particular concept of time =e.g. a season indicated by t&e first day of
t&e season> for a ser#ice and second publis&er users a different time format as 'ell as
different semantics for start and end date for t&e temporal e-tent of a data set7 it is not
possible to searc& for and use data in a consistent manner across t'o ser#ices.
9it&in t&e broader I6 sector7 it &as been found t&at general standards7 suc& as t&e
93C 9eb (er#ices protocols7 are not sufficient to ac&ie#e interoperability by t&em
sel#es. / community 'ill generally need to agree on a common profile to ensure t&at
a compatible set of options are c&osen.
Box 7 Conformance Profiles
/fter many years of failure to ac&ie#e interoperability bet'een different #endor
systems implementing 93C 9eb (er#ices standards7 a ne' go#ernance body 'as formed
to publis& a set of common profilesC t&e 9eb (er#ices Interoperability Organi<ation
=&ttpC000'''.'s4i.org>
Includes all ma"or #endors7 including t&ose instrumental in t&e 93C specifications
Creates Aconformance profilesB t&at can be used to actually test conformance as 'ell
as specify.
1stablis&es an ongoing process for adding profiles as re5uired.
9(4I &as establis&ed 3 'or!ing groups t&at address different aspects of t&e problemC
#ample )pplications .orking +roup 4 Illustrate best practices for implementations on
multiple #endor platforms
Testing Tools .orking +roup " De#elops self4administered tests to #ery conformance
'it& 9(4I profiles
3e8uirements +at,ering .orking +roup " Captures business re5uirements to dri#e future
profile selection
6o ensure interoperability 'it&in a data access and distribution conte-t7 ser#ice
profiles t&at conte-tuali<e t&e generic ser#ices are needed e.g.
use a community agreed #ocabulary to describe ser#ices ob"ects 4 =ser#ice
metadata>
use a community agreed #ocabulary to describe geograp&ic ob"ects =content
metadata>
use a community agreed #ocabulary in specific attributes =information
modeling>
Currently7 t&ere is no standard 'ay to describe profiles. @o'e#er7 some !ey
re5uirements for profile &andling includeC
*eed for profiles to be mac&ine readable to enable e-ploitation of ser#ices
*eed to manage c&anging profiles
/bility to determine conflict '&en t&ere are multiple dependencies and
separately go#erned parts of a profile
*eed for profiles to be disco#erable =by t&e ser#ice de#elopers> to support
ser#ice instantiation
Box 9 #D$ #ervice Profiling re8uirements - an emerging pattern
(e#eral /ustralian "urisdictional and domain based (DI pro"ects =see belo'> &a#e reac&ed
similar conclusions about t&e importance of ser#ice profiles.
9ater :esources Obser#ation *et'or!
2arine Portal
Nueensland +o#ernment 1nterprise arc&itecture pro"ect
+eo(ci2; 6estbed
/ !ey common re5uirement is t&at different parts of profiles be deri#ed0in&erent from
multiple7 e-ternally4go#erned communities.
Initial implementations &a#e been tested as an open source soft'are pro"ect includingC
Place&older (DI profilesD
(oft'are to aggregate &ierarc&ies of profiles into a single specification in&eriting
re5uirements from parentsD
(oft'are to create &uman readable documentation pac!ages
Conformance testing tools
8urt&er discussion on t&e t&eory and lin!s to t&e soft'are can be found at
&ttpsC00'''.seegrid.csiro.au0t'i!i0bin0#ie'0/pp(c&emas0(er#iceProfiles
6&is tool!it is still at a proof of concept stage7 but &as already demonstrated t&at t&e 9(4I
approac&7 coupled 'it& t&e AI(O1,1.6 3ProfilesB model allo's significant impro#ement in
t&e 'ay interoperability re5uirements can be specified7 &armonised and publis&ed.
6o enable real interoperability of data deli#ered t&roug& ser#ices7 common data
product specifications including consistent data models =for t&e data output or
e-posed by ser#ices> is re5uired. 8or t&e same type of data =e.g. roads> is deli#ered #ia
t'o ser#ices =e.g. from neig&boring *(DIs>7 unless t&e data sets s&are a common data
model7 data from t&e different ser#ices cannot be accessed and used consistently. 6&is
is a !ey enabler for t&e creation of common applications t&at use data from7 multiple
ser#ices.
3$#$& /pen Source and !eference Implementations
6&e success of t&e 9orld 9ide 9eb 'as based on t'o main factorsC
1. pro#ision of a strongly go#erned infrastructure =D*(>
2. pro#ision of a free reference implementation of bot& ser#er and client
=bro'ser> components.
!a reference implementation> is a so"tware e#ample o" a standar "or *se in helpin%
others implement their own versions o" the stanar. ) stanar is m*ch easier to
*nerstan with a workin% e#ample in han.&
?
2any aspects of t&e )*(DI 'ill be unfamiliar to sta!e&olders7 and some 'ill re5uire
attention to detail to ac&ie#e t&e efficient scalability re5uired for t&e )*(DI. (ome
components 'ill be critical for success7 and re5uire careful testing and sponsors&ip of
rele#ant standards. 1ac& component critical for t&e )*(DI to operate7 as defined by
t&e e-pectations of t&e &ig&4le#el use cases7 s&ould &a#e a pro#en and accessible
reference implementation.
7
9i!ipedia =&ttpC00en.'i!ipedia.org0'i!i0:eferenceMimplementation>
6&e )*(DI Compendium recogni<es t&e important potential role of t&e 8ree and
Open (ource (oft'are =8O((> mo#ement in enabling t&e )*(DI. It is t&erefore
important t&at reference implementations using 8O(( are de#eloped to pro#ide
concrete e-amples of &o' tec&nology components can be stitc&ed toget&er to build an
(DI .
6&e recently appro#ed )*OC@/ Policy on +eograp&ic Information (ystems and
+eospatial Data 2anagement =)*OC@/7 2..7> sets out t&e OC@/ approac& to t&e
use of open source soft'are =O((>. It states t&at OC@/ 'ill attempt to @miti%ate
so"tware costs thro*%h increase *sa%e o" appropriate open so*rce %eo/spatial
so"twareA t&at complies 'it& Open+I( specifications. It furt&er states t&at OC@/ 'ill
in t&e longer term mo#e to'ards O(( soft'are pro#ide t&at it is inter alia E"*lly
s*pporte %lobally an aopte as a stanar within the UN SecretariatA
In order to ma-imi<e t&e potential role of 8O(( =in particular7 O(+1O>7 in t&e
)*(DI and facilitate t&e important potential role of t&e 8O(( community t&e )*
needs to determine an effecti#e engagement strategy.
Open (ource is free to use7 but not cost4free to build and maintain. 6&erefore a !ey
element of t&e engagement strategy s&ould be an in#estigation of &o' )*(DI can
support rele#ant 8O(( efforts.
*eed for )*(DI to set interoperability targets for commercial soft'are
de#elopers to meet
8or commercial soft'are7 particularly 1(:I =as currently represents a ma"or
proportion of t&e geospatial tec&nology used by t&e )*> need to de#elop a test
bed so t&at commercial #endors can test interoperability of t&eir products against
targets establis&ed by t&e )*(DI
3$#$3 !e0istries
5.1.5.1 Overview
If a resource cannot be found it cannot be used. ?ust as importantly7 if t&e pro#enance
of a resource cannot be identified7 it is difficult to use in any real fas&ion. :egistries
are t&us a critical element of distributed data infrastructures. :egistries are t&e
mec&anisms by '&ic& artifacts related to agreements =e.g. a ser#ice specification> and
t&eir implementation =e.g. a ser#ice instance> can be publis&ed7 disco#ered7 and any
data resources can be made a#ailable for re4use. 6&e sets of resources a#ailable are
called registers =I(O 1,135>.
8rom a tec&nical perspecti#e an industry4standard Ameta4modelB for registries
$
&as
been de#eloped7 '&ic& underpins suc& tec&nologies as )DDI7 and ebO2;
:egistry0:epository. 6&us7 t&e be&a#ior of registries and registers can be identified at
an abstract le#el7 e#en if t&e implementations are #aried.
6&e go#ernance of registries is usefully described in I(O 1,135 AProcedures for
registration of +eograp&ic ItemsB =I(O7 1,$$>. 6&is standard pro#ides a clear7
$

=I(O0I1C 1117,7 1,,,>
concise and practical articulation of t&e #arious actors and roles. /pplication of t&is
meta4model &as been found to be a &ig&ly effecti#e 'ay of identifying t&e pragmatic
realities t&at face any real 'orld implementation.
5.1.5.2 Role of registries in an SDI
!;hen combine with a portal$ a re%istry acts as the h*b o" a istrib*te ata
in"rastr*ct*re as it presents *sers with an a%%re%ate view o" in"rastr*ct*re content
compile "rom n*mero*s hetero%eneo*s so*rces.& =6andy K 6&omas7 2..6>.

8or content to be aggregated into a single #ie' t&ey must ad&ere to standards and t&e
publication of t&ese standards =into registers> enables t&eir disco#ery7 re4use and
application7 t&us leading to practical interoperability.
6o date t&e ma"ority of registry implementations 'it&in (DI implementations can be
c&aracteri<ed as containing =6andy K 6&omas7 2..6>C
2etadata about resources t&at can be do'nloaded
;in!s to locations '&ere t&ose resources can be accessed
6&e c&allenge is to understand '&at metadata is actually re5uired. 6&e )*(DI &as
not emerged automatically out of metadata describing data sets7 and t&is pattern is
consistent globally. 6&e arc&itectural perspecti#e of an (DI ma!es it clear t&at t&ere
are in fact many aspects to operational interoperability7 and t&e set of agreements
t,at &efine aspects of service be,avior are t&e re5uired metadata artifacts.
6&e role of registers is 5uite simpleC any time an artifact is re5uired to reali<e an
agreement bet'een a data pro#ider and a user 4 suc& as a ser#ice location7 data model7
#ocabulary7 ser#ice profile7 organi<ation identifier7 ser#ice le#el agreement7 sc&ema7
5uery template etc 3 a register must be establis&ed at a registr1 t&at bot, parties
know about%
Determining '&at registers are re5uired and '&ic& actors play '&at roles in t&e
ongoing process of creation and maintenance of registers7 is t&e !ey to understanding
and building effecti#e (DI go#ernance.
6&e ob#ious conclusion &ere is t&at an (DI must maintain a register of registers at t&e
#ery least7 so t&at all parties can find '&ere suc& metadata is located.
5.1.5.3 ISO 19135 registry conceptual model
/ccording to I(O 1,135 a register is a !set o" "iles containin% ienti"iers assi%ne to
items with escription o" the associate items& and a registr1 is an !in"ormation
system on which a re%ister is maintaine&
6&e conceptual model s&o'n in 8igure 1 presents t&e relations&ip bet'een t&e #arious
organi<ations t&at play roles in management of a registry and registers =I(O7 1,$$>.
! e 0 i s t e r / w n e r S u + m i t t i n 0 / r 0 a n i = a t i o n
1 o n t r o l - o d ! e 0 i s t e r 7 a n a 0 e r
! e 0 i s t e r ! e 0 i s t r
! e 0 i s t e r U s e r
1
1 . . ! u a l i f i e r
! u a l i f i e d " y
1
1 . .
a p p o i n t e r
a p p o i n t e d " y 1 . .
1
d e l e g a t e d " y
d e l e g a t o r
1
1 . .
o w n e r
r e g i s t e r
1
1 . .
r e c e i v e r
s u # m i t t e r
1 . .
1
m a n a g e d
m a n a g e r
1 . . 1 c o n t e n t s t o r e d O n
1
1 . .
o p e r a t o r
s y s t e m
1
1
c o n t e n t $ o n t r o l l e r
c o n t r o l l e d
1 . .
1 . .
u s e d " y
u s e r
1 . .
1 . .
a c c e s s o r
a c c e s s e d " y
% a n a g e m e n t
& e v e l
' s e r & e v e l
( ) e c u t i v e
& e v e l
D e p l o y m e n t
& e v e l
! e 0 i s t r 7 a n a 0 e r
1 . .
1 . .
c o n t e n t % a n a g e r
s y s t e m % a n a g e r
1 . .
1 d e c i s i o n * u t + o r i t y
d e c i s i o n R e ! u e s t e r
Figure 1 3ole of :rgani0ation in register management ;$#: 1<1!4=
:egistration management roles and t&e !ey responsibilities of eac& role are as
follo'sC
3egister owner
1stablis&es one of more registers
:esponsible for t&e management dissemination and intellectual content of t&e
register
Can act as register manager or can appoint anot&er organi<ation to act as
register manager
(pecifies criteria '&ic& determines '&ic& organi<ations can act as submitting
organi<ations =to ma!e c&anges to t&e register>
2ay ser#e as t&e control body or may &elegate role to sub4group 'it&in t&e
organi<ation
3egister manager
role delegated by :egister o'ner
may manage multiple registers. /
register manager may o'n and operate t&e registry t&at &olds a register or it
may delegate operation of t&e registry to a registry manager
accepts and manages proposals from submitting organi<ations
passes proposals to t&e control body for decisions
reports to t&e register o'ner at inter#als
#ubmitting organi0ation
register manager determines '&et&er an organi<ation is 5ualified to submit
re5uests to c&ange registers in accordance 'it& t&e criteria establis&ed by t&e
register o'ner.
manages t&e submission of proposals to t&e register manager and appeals to
t&e register o'ner initiated from t&eir sta!e&olders.
Control bo&1
group of tec&nical e-perts appointed by a register o'ner to decide on t&e
acceptability of proposals for c&anges to t&e content of a register
ma!es decision on proposals pro#ided by t&e register manager
3egistr1 manager
responsible for t&e day4to4day management of a registry.
may engage a t&ird4part ser#ice pro#ider to perform t&is ser#ice.
ensures integrity of registers &eld in t&e registry
pro#ide means for electronic access to t&e registry for register managers7
control bodies7 and register users.
3egister user
Different categories of register users are
o De#elopers of standards and specifications 'ant to re4use items
specified in a register
o Data producers 'ant to use in t&eir products items specified in a
register
o Data users 'ant to understand t&e meaning of register items used by a
data producer
o (ystem de#elopers 'ant to pro#ide a capability to use register items in
data production7 interc&ange7 or consumption
register o'ner may set terms and conditions for different le#els of access to
t&e register for different categories of users
5.1.5., Role of registries in t+e '-SDI
/s 'e &a#e seen7 t&e )*(DI 'ill be primarily concerned 'it& t&e registration and
reuse of interoperability4enabling agreements and resources. /t t&e core of t&e
)*(DI is t&e means to adopt and adapt appropriate approac&es and ma!e t&em
a#ailable.
6&is in turn 'ill create a net'or! of resources t&at t&e )*(DI can inde- and ma!e
a#ailable to t&e community.
3$#$6 /ntolo0ies
Ontologies are formalised agreements about t&e identity and description of concepts.
/t t&e simplest le#el t&ese are simple 'ord4lists7 but in general t&e )*(DI 'ill need
to manage relations&ips bet'een sets of simple #ocabularies7 cross4'al!s etc.
6&e conceptual #ie' of ontologies can greatly inform t&e creation of go#ernance
mec&anisms to deal 'it& data modeling7 #ocabulary de#elopment and re4use.
6&e ontology community classifies ontologies into t&ree main typesC
)pper le#el 3 used for broad disco#ery e-amples include #ocabularies 'it&in
t&e +lobal C&ange 2aster Directory =+C2D>
Core le#el 3 relating to common be&a#ior and business process
Domain le#el 3 focusing on t&e data content and &o' its described
6&is stratification of conceptual space into distinct le#els of abstraction pro#ides a
natural frame'or! for t&e go#ernance of semantic aspects of interoperability.
6&e )*(DI 'ill not be dri#en by t&e de#elopment of an ontological frame'or!.
@o'e#er an ontological view can be automatically e-tracted from a co&erent set of
reusable patterns7 supported by reusable resources. 6&is ontological #ie' 'ill en&ance
t&e disco#ery function7 and probably t&e ability to orc&estrate t&e use of multiple
ser#ices to access and process data.

It is beyond t&e scope of t&is document to discuss t&e roles7 t&eories and toolsets of
ontologies.
3$) >e0ac sstems and mi0ration
3$)$# 1urrentl hetero0eneous sstems
6&e )* system landscape is &eterogeneous and is a be&a#ioral artifact3 a function of
)* culture and organi<ation '&ic& reflects t&e broad range of domains and needs t&at
t&e system spans.
/lt&oug& efforts to de#elop geospatial enterprise solutions are 'ell under'ay 'it&in
t&e )*7 t&e ma"ority of geospatial solutions continue to be locally de#eloped for
limited =agency7 domain and geograp&ic> use. 6&ey are typically designed to meet
specific local pro"ect or agency goals and necessitate system users to negotiate access
bilateral agreements to access data7 create ad &oc data models and generate data7
obtain and clean data7 customi<e application and 'or!flo's and produce bespo!e
information products.
3$)$) 7i0ration to services
In order to rationali<e legacy systems t&ere is a need to mo#e from =s&ort4term>
tec&nology dri#en system lifecycles to'ards a stable7 yet e#ol#ing Asystem of
systemsB. /c&ie#ing t&e creation of a s&ared and interoperable system landscape
re5uires migration of e-isting systems and practices to a ser#ices model using a
ser#ice oriented arc&itecture =(O/> approac&.
@o'e#er7 ser#ices are more costly to implement t&an locally appropriate solutions
and benefits =to users t&at are beyond t&e immediate scope of a pro"ect> are &ard to
"ustify in t&e conte-t of t&e pro"ect t&at is paying for t&em.
2anagerial support and funding 'ill be re5uired to ac&ie#e t&is ma"or conceptual
s&ift. /'areness raising7 education7 return on in#estment =:OI> studies 'ill all be
re5uired to communicate t&e business case for mo#ing to a ser#ice model and to
generate sufficient political 'ill and organi<ational c&ange to ma!e it &appen.
3$)$( Governance implications
(er#ice Oriented /rc&itecture =(O/> approac&es using 'eb ser#ices7 &as been
identified as t&e tec&nology paradigm for )*(DI implementation. 6&e tec&nical
go#ernance c&allenges related to building and sustaining an (O/ are addressed by t&e
tec&nical go#ernance frame'or! as outlined in section 7.
@o'e#er7 t&ere are also significant organi<ational c&allenges particularly 'it& regard
to s&ift in organi<ational culture and funding models necessary to build and gro' an
(O/ and t&e migration of legacy systems and t&eir entrenc&ed 'or!flo's to a
systems model.
/lt&oug& operational0tec&nical go#ernance frame'or! design is cogni<ant of t&e need
to address t&ese institutional c&allenges7 t&is and ot&er intangible (DI success factors
'ill need to be addressed 'it&in t&e institutional go#ernance frame'or!.
3$( 1onstraints
3$($# !esourcin0
Current )* agency and pro"ect based4funding models ma!e s&aring large I6 pro"ect
costs across agencies c&allenging. It may be difficult to "ustify large up4front costs for
information infrastructure pro"ects '&en returns for t&e organi<ation occur muc&
furt&er do'nstream. 2a!ing t&e business case for t&is in#estment is made e#en more
difficult as t&ere are significant benefits to ot&er sta!e&olders t&at do not directly
benefit t&e funding organi<ation. It is t&erefore li!ely t&at )*(DI 'ill be built
t&roug& pro"ect based funding. /s only portion of pro"ect costs 'ill be a#ailable to
fund go#ernance acti#ities t&e design of go#ernance solutions 'ill need to be
financially realistic.
3$($) Governance realities
It is anticipated t&at t&e go#ernance starting configuration 'ill be dictated by
institutional constraints of t&e )* system and t&at as t&e )*(DI matures and gro's
go#ernance 'ill need to e#ol#e and gro' 'it& t&e infrastructure pro"ect by pro"ect.
It is also anticipated t&at t&e )*(DI may e#ol#e from a pro"ect to programme o#er
time. 6o ensure t&e gro't& and sustainability of t&e )*(DI7 t&e go#ernance solution
must be inclusi#e and distributed rat&er t&an being centrali<ed and must be able to
operate 'it&in and adapt to c&anging circumstances.
6$ !e9uirements
6&is section of t&e document identifies t&e capabilities and c&aracteristic of t&e
)*(DI. 6&ese re5uirements are one of t&e main inputs to t&e system design process.
6&ese re5uirements s&ould accurately reflect sta!e&older consensus regarding t&e
critical business needs t&at t&e system must address
6$# 1urrent situation and need for chan0e
Currently in order to s&are resources pro#iders and users of resources negotiate
bilateral arrangements. 6&ese are ad &oc7 costly =especially in time7 effort and s!ills
capacity> to negotiate7 and cannot be found and re4used by ot&ers. 8igure 27 belo'
illustrates t&is situation

Figure Current arrangements for s,aring resources
If t&is situation is #ie'ed across multiple agencies t&e situation rapidly becomes
un'or!able.
Figure ! 2ultiple bilateral agreements
<
,
source :ob (tarling7 Open+I( Consortium =/ustralasia> ;td7 2..%
1ount
Governments
1ivilian
,0encies
State
Govt
s
Tri+al Govt
s
1it
Govt
s
Defence
,0encies
1ommercial
Sector
>ocal Users
Do
D
User
s
Tri+al Users
State
Users
?omeland
Securit
1ommercial
User
s
1ivilian
Users
International Users
Federal
Users
Other standards -
based portals
1urrent situation simplified
Documented .
validated
information
6&e creation of a s&ared infrastructure is t&erefore necessary to rationalise and
impro#e access to resources. 6&is is ac&ie#ed by a pro#ider publis&ing resources
using t&e capabilities pro#ided by an infrastructure. 6&ese capabilities include
reusable resources and precedents from many similar acti#ities7 suc& as soft'are
tools7 data models7 access policies7 data 5uality procedures7 metadata descriptions7
conformance testing tools7 disco#ery aids etc>. 6&e infrastructure t&en supports
multiple users disco#ering and re4using t&ese resources. 6&is pattern is illustrated in
8igure %7 belo'.
Figure / T,e publis, an& re"use pattern
6&e same publis& and re4use pattern can also be applied to sol#ing problems of
interoperability bet'een infrastructures i.e. t&e ability for users from one (DI to find
and re4use resources t&at &a#e been publis&ed 'it&in t&e operational conte-t of a
different (DI. 6&is is illustrated in 8igure 57 '&ic& s&o's t&e relations&ip bet'een t&e
)*(DI and an (DI t&at is a EmemberF of t&e )*(DI.
Figure 4 Publis, an& re"use pattern between #D$s
:esources in t&e conte-t of t&is discussion include agreements about &o' t&e
infrastructure be&a#es as 'ell as t&e data access ser#ices t&at e-pose data products
t&at are t&e raison Aetre of t&e infrastructure.
(ome e-amples of t&e type of agreements about infrastructure be&a#iour includeC
service specifications an& profiles 4 agreements adopted by t&e community
about ser#ice specifications and conformance profiles to be used '&en building
and publis&ing ser#ices
&ata mo&els 4 de#eloped and adopted by t&e community and used 'it&in data
products7
portra1al rules 4 for map products.
registers of governance actors t1pes 4 lists of t&e actors in#ol#ed in
go#ernance of t&e infrastructure and t&e roles t&ey play so t&at sta!e&older can
find out '&o to contact regard a specific data model or a 5uery &o' to subscribe to
and publis& resources to t&e infrastructure.
6&is need to de#elop and promote a #ariety of standards t&at enable s&aring of
resources &as been clearly articulated by )*(DI sta!e&olders =see Box 7>. 6&is
re5uirement necessitates go#ernance mec&anisms and resources.
Box 7 ) clear nee& for stan&ar&s
6&e 2y(DI
1.
initiati#e aimed at capturing geospatial information access and dissemination
e-pectations. 9it& regard to e-pectations of t&e )*(DI regarding standards t&e follo'ing
comments 'ere madeD
Promote use standards and common protocols and guidelines and recommended standards
for data s&aring =)*@C:>
1ncourage proprietary systems to ad&ere to interoperability standards =)*OC@/7 8I(>
/d#ocating of standards by ob"ecti#e e-ternal body and promotion of simple standardised
data access policy templates =)*1P>
Promotion of metadata standards and ensure support for future data and ser#ices
=)*O(/6>
6$) General re9uirements
6&e goal of t&e go#ernance frame'or! is to reduce organi<ational c&allenges to
creating7 gro'ing and ac&ie#ing interoperability bet'een (DIs. 6&e !ey to ac&ie#ing
t&is =at least in terms of tec&nical0operational go#ernance> is t&e go#ernance of
artifacts t&at describe7 or are an implementation of interoperability agreements =and
e-pectations> bet'een sta!e&olders 'it&in an (DI and bet'een (DIs.
6&e entire go#ernance frame'or! must be scalable7 based on resource a#ailability and
commensurate 'it& t&e #olume of resources =data7 ser#ices and agreements> t&at are
being go#erned.

It is anticipated t&at t&e s&ort and longer4term go#ernance configurations 'ill be
different as t&e c&allenges and resourcing le#els 'ill c&ange as t&e infrastructure
gro's. 6&e go#ernance approac& t&erefore must offer a means of creating common
t&reads bet'een s&ort and long term re5uirements.
6&e go#ernance frame'or! needs to be fle-ible and adapti#e and ensure t&at it is able
to easily go#ern and adapt itself =structure7 organi<ation7 strategy and policies> to meet
c&anging organi<ational7 tec&nology and business realities.
6$)$# Inter'SDI 0overnance re9uirements
8or (DIs to interoperate7 and t&us s&are resources7 agreements defining
interoperability e-pectations bet'een t&e (DIs need to be in place. 1-istence and
1.
(ee &ttpC00'''.ungi'g.org0my(DI.&tm
disco#erability of agreements implies a go#ernance frame'or! t&at deals 'it& all
aspects of t&e agreement lifecycleC
Identification
Creation
/doption
@armoni<ation ='it&in and bet'een domains>
2odification and retirement
In addition7 management of t&e artifacts t&at describe t&e agreements 'ill also be
re5uired so t&at t&ey can be disco#ered and used.
6$)$) Intra'SDI 0overnance re9uirements
In addition to t&e go#ernance of agreements bet'een (DIs t&e )*(DI go#ernance
frame'or! 'ill also need to address t&e internal operational go#ernance c&allenges of
indi#idual (DIs comprising t&e )*(DI.
:at&er t&an duplicating effort to re4create agreements bet'een sta!e&olders 'it&in an
(DI it is proposed t&at agreements are in&erited from e-isting (DIs and adapted as
re5uired.
It is anticipated t&at many of t&e agreements re5uired to establis& a =)*>(DI instance
'ill be adopted from e-isting (DIs 'it& '&ic& t&e (DI 'is&es to align itself. 6&e
standards may need to be adapted to t&e conte-t of t&e (DI and t&e adapted
agreements 'ill need to be managed =publis&ed7 accessed and used> 'it&in t&e (DI to
ensure conformance.
6$( Governance of data model and harmoni=ation processes
Data model &armoni<ation pro#ides an opportunity to lin! data from different
operational domains to address a specific problem. @armoni<ation does not imply a
single common data model =t&oug& t&is &as been attempted>7 but rat&er t&e ability to
effecti#ely de#elop independent data models but still s&are enoug& common elements
to enable pragmatic lin!ages of data '&ere appropriate.
8or e-ample7 if flood 'arning7 land use and forestry management data systems s&are
t&e same concepts and identifiers of ri#ers and catc&ments7 suc& data can be lin!ed to
impro#e !no'ledge about t&e systems. Or if transport logistics data and &umanitarian
needs s&are common ga<etteer of place4names t&is 'ill aid effecti#e relief planning
and inter#ention.
6&e c&allenge is7 of course7 t&at related domains de#eloping t&eir o'n internal
go#ernance arrangements need to be able to tap into a common go#ernance
arrangement to actually s&are common concepts. It is unrealistic to assume t&at any
indi#idual domain 'ill be able to fill t&is role7 and &ence t&e criticality of t&e )*(DI
to pro#ide suc& a mec&anism.
I*(PI:1 recently de#eloped a draft A2et&odology for t&e De#elopment of Data
(pecificationsB '&ic& articulates a process for addressing data model &armoni<ation
=see o- $>.
o- $ I*(PI:1 met&odology for t&e de#elopment of data specifications
6&e recently publis&ed I*(PI:1 draft met&odology for t&e de#elopment of data
specifications outlines a process for data &armoni<ation t&roug& t&e de#elopment of data
specifications =I*(PI:1 Drafting 6eam PData (pecificationsP7 2..7>. 6&e steps of t&is
process areC
Capture user re8uirements described as use cases and application scenarios.
)nal1sis of current situation carried out in parallel to user re5uirements to assist in
identifying t&e rele#ant data &armonisation aspects.
+ap anal1sis to identify user re5uirements t&at cannot be met by t&e current data
offerings
8or eac& gap7 a data ,armonisation approac, is de#eloped and agreed.
)pplication sc,ema de#eloped to document t&e approac& to filling gaps .
o (c&ema describes re5uired spatial ob"ect types ='it& constraints7 properties>
o Described in a conceptual sc&ema language 3 )2;.
Development of &ata specification comprisingC
o /t leastC specification scope7 data product identification7 data content and
structure7 reference systems7 data 5uality7 data product deli#ery7 and
metadata.
o Optionally information onD maintenance7 data capture7 portrayal
o /pplication sc&ema =abstract4le#el in )2;>
o 8eature catalogue
o +2; application sc&ema =implementation4le#el in O2;>
Testing 3 data specifications tested 'it&in a pilot under real 'orld conditions.
2onitoring 4 trac!ing costs0benefits of &armonisation efforts
6$& ,rchitectural 0overnance
6&e arc&itecture of t&e )*(DI is t&e mec&anism to ensure t&at t&at eac& component
re5uired is identified and t&at eac& component is properly designed to fulfill a certain
role. It also pro#ides for practical engineering and tec&nology c&oices to be made and
related bac! to t&at basic need. 6&e reality is t&at tec&nology c&anges7 data #olumes
gro'7 users c&ange o#er time7 and better ideas 'ill emerge.
6&e )*(DI 'ill e#ol#e o#er time. Qet7 t&ere 'ill be an ongoing need to assess t&e
best 'ay to accommodate ne' c&allenges and opportunities7 as 'ell as communicate
to sta!e&olders t&e current recommended practices.
In particular7 a successful )*(DI 'ill engender creation and integration of many
related (DI implementations7 '&ic& 'ill continually test and refine t&e o#erall
arc&itecture. 8or e-ample7 an initial arc&itecture for t&e )*(DI and !ey cluster
acti#ities 'ill need to e#ol#e into one t&at supports and integrates national (DIs.
/dditional sub"ect domains 'ill bring different types of data and processing.
6&e arc&itecture becomes a contract bet'een t&e implementers of systems and t&e
)*(DI t&at t&e systems can be built in a 'ay '&ic& 'ill 'or! 'it&in t&e broader
system. /nalysis of t&is 'it&in a single domain7 'it&in a single "urisdiction7 &as
clearly identified t&e general nature of t&is problem.
6&e )*(DI tec&nical go#ernance frame'or! s&ould t&erefore ensure t&at an agreed
notional arc&itecture can be de#eloped and maintained t&roug& effecti#e go#ernance
mec&anisms to ensure a s&ared arc&itectural #ie' of t&e )*(DI.
Box < T,e )ustralian :cean Portal #D$ " Nee& for a s,are& arc,itectural view
:eflections on t&e e-periences of de#eloping an /ustralian Oceans Portal =8inney7 2..7>
&ig&lig&ted t&e need to maintain a s&ared arc&itectural #ie' of t&e infrastructure. 6&is s&ared
#ie' is re5uired to mitigate t&e ris! of loss of arc&itectural and tec&nical co&erence due toD
c&anging system re5uirements as t&e system and its users mature7 and t&e de#elopment and
di#ergence of sub4infrastructures based on competing standards.
It is crucial t&erefore t&at t&e arc&itecture itself includes maintenance functions for t&e
arc&itecture7 and t&at t&e functions are properly resourced 'it& bot& go#ernance
mec&anisms and a permanent capability t&at can be called upon to address needs as
t&ey arise.
6&ese needs 'ill occur across all t&e acti#ities in de#eloping t&e )*(DI7 but in
particularC
De#elopment of data models
Design of core ser#ice types
/ddressing engineering aspects of scalability
1#aluating role of ne' tec&nologies
Dri#ing impro#ements to tec&nologies
Design and go#ernance of content =#ocabularies>
Design of purpose4specific (DIs
Design of capability toolset for national (DIs
8or e-ample7 t&e integration of numerical models or decision support tools into t&e
)*(DI to meet a particular domain need 'ill propagate into an e-tension of t&e
arc&itecture so t&at t&ese capabilities can be broadly e-ploited. 6&is e-tension 'ill
t&en be a#ailable to en&ance national (DIs7 or more li!ely7 specific systems 'it&in t&e
national "urisdiction. (uc& a problem re5uires a co&erent approac& for describing t&e
ser#ices7 data models7 etc as 'ell as ability to communicate t&e en&anced capability of
t&e )*(DI.
6&e criticality of t&is tas!7 and t&e broad range of tec&nical s!ills re5uired7 means t&at
a permanent capability needs to be establis&ed as a )*+I9+ standing tas! group for
e-ample7 'it& specific responsibilities and resources allocated to be bot& proacti#e
and responsi#e to sta!e&older needs.

PART 3 - PROPOSED SOLUTION
6&e solution section of t&e document contains four sections. 6&e first section pro#ides
a conceptual o#er#ie' of t&e go#ernance frame'or!.
6&e second section presents a proposed solution from a number of different
perspecti#es. 6&e section focuses on t&e identification and description of t&e critical
go#ernance functions t&at enable t&e creation of t&e )*(DI and an identification of
t&e !ey actors '&o e-ercise t&ese functions as 'ell as t&eir roles.
6&e t&ird section describes a process of mapping registry management roles to
institutional entities. 6&is 'ill enable t&e tec&nical go#ernance tas!s to be assigned to
organi<ational entities so t&at t&e tec&nical go#ernance can be implemented t&roug&
institutional go#ernance structures.
6&e final section relates more broadly to t&e '&ole )*(DI and presents a 'or!4plan
comprising a number of pro"ects t&at build specific priority elements of t&e )*(DI.
6&ese components represent t&e critical mass of )*(DI t&at must be built for
elements of t&e go#ernance frame'or! to be de#eloped. 1ac& of t&e pro"ects
addresses a critical aspect of t&e )*(DI &ig&lig&ted in t&e #ie'points.
Presentation of t&e solution using a number of #ie'points =or perspecti#e> '&ic&
describe different aspects of t&e system suc& as business7 information and enables
readers to assess t&e solution from eac& of t&e different dimensions.
(ta!e&older re#ie' of t&e proposed solution and t&e re5uirements pro#ides an
important opportunity to assess '&et&er t&e proposed solution addresses t&e
articulated re5uirements.
:$ Governance framework ' conceptual overview
:$# Introduction
6&is section &ig&lig&ts t&e !ey aspects of t&e go#ernance frame'or!7 elaborated in
more detail in t&e subse5uent sections.

Conceptually7 t&e design of t&e go#ernance frame'or! is based upon t&e I(O 1,135
conceptual model of registry management. 6&e frame'or! is presented as a series of
use cases based upon a conceptual (DI model =notional arc&itecture> t&at reflects t&e
underlying re5uirements of t&e )*(DI7 informed by past (DI implementation
e-perience. It is proposed t&at t&is notional arc&itecture be de#eloped as a reference
implementation in its o'n rig&t7 fully elaborated and refined t&roug& (DI
implementation pro"ects as a priority 'or! plan item7 and publis&ed as a reusable
template.
@a#ing identified t&e go#ernance use cases actors =t&e E'&oF> and roles t&at t&ey
perform =t&e E'&atF>7 t&e details of &o' go#ernance is implemented can be elaborated.
Conceptually7 t&e )*(DI go#ernance frame'or! comprises t'o separate but
integrated tiers of go#ernanceC
4 inter"#D$ governance 3 enabling interoperability bet'een (DIs t&roug& t&e
creation and management of registers of )*(DI resources
4 intra"#D$ governance 3 dealing 'it& t&e tec&nical go#ernance of (DI
instances created 'it& t&e )*(DI
6&e go#ernance frame'or! assumes t&atC
4 6&e )*(DI go#ernance institution 'ill rely &ea#ily on t&e delegation of
responsibility for creation and maintenance of (DI resources
4 Operational go#ernance of components s&ared across =)*> (DI instances 'ill
be delegated by t&e )*(DI
4 6&e #ariety of roles necessary to operate registries and registers are li!ely to
need to be delegated
4 /n arc&itecture toget&er 'it& use cases =t&at also address go#ernance> can be
re4used as a template by agencies or community t&at 'is& to create (DIs
'it&in t&e )*(DI
:$) inter'SDI 0overnance
6&is set of go#ernance capabilities aims to ensure interoperability bet'een (DI
instances and includesC
Policies7 rules procedures7 processes and tools for t&e management of entire
lifecycle of artifacts t&at describe interoperability bet'een (DIs
/ go#erned common reference arc&itecture
:$( Intra'SDI 0overnance
6&e )*(DI is concei#ed as being a #irtual system comprising a constellation of
indi#idual (DIs. 6&ese (DIs 'ill be created indi#idually or collecti#ely by )*
agencies or business units to meet s&ared geospatial business needs. It is anticipated
t&at t&e )*(DI 'ill act as an enabler for *ational (DIs =*(DI> creation7 particularly
in de#eloping nations7 t&at 'ill also become part of t&e )*(DI constellation.
6&e focus t&erefore of internal =intra4(DI> go#ernance is on t&e creation and operation
of s&ared resources =agreements7 ser#ices7 data> 'it&in an (DI. 6&e (DI notional
arc&itecture =illustrated by reference implementation=s>>7 is intended to act as a
template for (DI creation and 'ill include a modular re4usable template for internal
go#ernance of t&e (DI instance.
6&e use of a common arc&itecture 'ill ensure t&at =)*>(DI instances t&at are created
interoperate 'it& eac& ot&er. In addition7 interoperability 'it& e-ternal (DI =beyond
t&e )*(DI boundaries> 'ill be ensured by t&e inter4(DI interoperability go#ernance
acti#ities.
*$ The UNSDI proposed solution
Gey components of t&e )*(DI =t&at address critical business needs of t&e sta!e&older
community> are presented in t&is section. /s noted earlier7 it is not possible to design
a go#ernance frame'or! in isolation7 as ob#iously t&ere 'ould be not&ing to go#ernR
6&erefore t&e solution proposes t&e de#elopment of t&e minimum re5uired
capabilities namely7 a &ig&4le#el notional arc&itecture for t&e )*(DI toget&er 'it&
some of its !ey components.
6&e proposed solution is described using elements of t&e Open Distributed Processing
3 :eference 2odel =:24ODP>
11
. T*e RM-ODP i# $! i!"e%!$"i!$0 #"$!&$%&
+% $%'*i"e'"i!; pe!4 &i#"%i/3"e& p%'e##i!; #-#"e.# $!& p%vi&e# $
'!'ep"3$0 +%$.ew%< +% /3i0&i!; &i#"%i/3"e& #-#"e.# i! $!
i!'%e.e!"$0 .$!!e%)
T*e 3#e + "*e RM-ODP p%vi&e# $ w$- + "*i!<i!; $/3"
$%'*i"e'"3%$0 i##3e# i! "e%.# + +3!&$.e!"$0 p$""e%!# % %;$!i?i!;
p%i!'ip0e# $!& p%vi&e# $ #e" + ;3i&i!; '!'ep"# $!& "e%.i!0;-)
RM-ODP &e5!e# "*e +00wi!; 5ve viewpi!"# + $ #-#"e. e$'* +
w*i'* $&&%e##e# &i,e%e!" $#pe'"# + "*e #-#"e. $!& e!$/0e# "*e
1#ep$%$"i! + '!'e%!#2 &3%i!; "*e $!$0-#i# $!& #03"i! &e#i;!A
(nterprise Viewpoint 3 describes 'it& t&e purpose7 scope and business
conte-t of t&e )*(DI.
$nformation Viewpoint 3 focuses on t&e information dimension of )*(DI.
Including t&e identification of information elements7 and information flo's.
Computational Viewpoint 3 focuses on partitioning t&e )*(DI into
functional components independent of any specific en#ironment.
(ngineering Viewpoint 3 focuses on t&e practical realities of building t&e
)*(DI from deployed components 'it&in a net'or! infrastructure.
Tec,nolog1 Viewpoint> Identifies possible tec&nical artefacts for engineering
mec&anisms7 computational structures7 information structures and enterprise
structures '&ilst being as independent of t&e ot&er four #ie'points as possible.
8urt&er refinement of t&e 6ec&nical +o#ernance 8rame'or! is re5uired7 based on
elaborating t&e enterprise #ie'point t&roug& t&e de#elopment of A)se CasesB t&at
describe re5uired go#ernance functions of t&e )*(DI.
@o'e#er7 to de#elop t&e use cases7 a notional arc&itecture =based on t&e arc&itecture
e-pressed in t&e )*(DI Compendium> &as been posited. Gey elements of t&e
notional arc&itecture are described in t&e enterprise7 information7 tec&nology and
computation #ie'points.
6&e 'or!4plan t&at is presented in section 1.7 describes a number of pro"ects t&at
build different dimensions of t&e )*(DI. 1ac& of t&e pro"ects addresses issues or
c&allenges described in t&e :24ODP #ie'points
*$# 5nterprise viewpoint
6&e )*(DI go#ernance structures 'ill be establis&ed around a set of P6erms of
:eferenceP for t&e /ctors identified in a set of publis&ed )se Cases.
11
I(O0I1C 1.7%
6&is approac& allo's for management of t&ese roles and responsibilities t&at 'ill
ensure critical aspects are properly documented and effecti#ely assigned to
appropriate )* bodies.
6&e set of actors and )se Cases 'ill be fully documented as a priority acti#ity in
follo'4on acti#ities. @o'e#er7 it is clear from analysis of best practice t&at t&e general
nature of t&e arc&itecture and roles are common.
Identifying and placing under appropriate go#ernance t&e commonality of t&e
arc&itectures is one of t&e !ey acti#ities t&at establis&ment of a )*(DI 'ill underta!e
to enable more effecti#e (DI integration in future.
*$#$# Use cases
6&e articulation of t&e !ey uses cases and actors is a critical step in t&e process of
elaboration of t&e go#ernance frame'or!. @a#ing identified t&e critical functions
necessary to enable tec&nical go#ernance7 and t&e actors t&at e-ercise t&ese functions
it is possible toC
Identify t&e agreements =and t&e artifacts t&at describe t&em> t&at need to be
go#erned
2ap t&e actors and t&eir roles to institutional entities and0or specific agencies
and persons 'it&in t&e )*(DI pro"ect.
6&e articulation of suc& )se Cases 'ill be a !ey component of t&e )*(DI
arc&itecture7 to be formali<ed as a priority acti#ity 'it&in t&e )*(DI initiation pro"ect
proposed.
6&ese )se Cases s&ould be arranged in modular pac!ages7 so t&at specific acti#ities
can import "ust t&e rele#ant pac!ages7 and t&en document t&e specific implementation
of t&ese cases.
8or e-ample7 an e-isting mec&anism for recording disputed national boundaries mig&t
be modeled as a speciali<ation of a generali<ed process of recording alternati#e
representations of an ob"ect7 but t&e e-isting named processes can be #isually mapped
to t&e common model. 6&is allo's t&e domain to continue using t&e familiar terms7
but ot&er sta!e&olders to immediately see &o' t&e specific practice relates to common
practices.
*$#$) Use case scenarios
In order to illustrate critical dimensions of t&e )*(DI go#ernance frame'or!7 use
cases scenarios &a#e been de#eloped. 6&e scenarios pro#ide a narrati#e #ie' of &o'
!ey actors interact 'it& t&e )*(DI to ac&ie#e specific goals. /ctor names suc& as
standard coordinator and )*(DI manager &a#e been used to aid clarity. 6&e actors
and t&eir roles and responsibilities need to be determined in a follo'4on acti#ity7 t&at
establis&ed t&e arc&itecture itself under formal go#ernance arrangements.
It s&ould be noted t&at t&e scenarios are illustrative onl1 and &a#e been de#eloped
based upon articulated re5uirements of business needs. 6&e scenarios do not represent
complete re5uirements but instead illustrate !ey representati#e aspects of t&e
go#ernance frame'or!. /dditional scenarios can be de#eloped at a later date to
#alidate t&e use cases and by inference t&e notional arc&itecture.

6&e use cases focus on t&e go#ernance functions of t&e system as t&e end4user use
cases for (DI are pretty 'ell establis&ed. 6&e use cases co#er
Inter4(DI pac!ageC
Creation of @umanitarian (DI7 a )* (DI instance
Intra4(DI pac!ageC
Creation of a data product specification for transport data
(er#ice profile disco#ery and implementation
)se cases scenarios illustrate aspects of t&e )*(DI capability t&at t&e 'or!4plan
proposes to build. 6&e scenarios assume t&at certain capabilities of t&e )*(DI
=primarily o#erarc&ing go#ernance )*(DI go#ernance frame'or!> are in place.
6&ese o#erarc&ing mec&anisms are referred to in t&e scenarios in order to pro#ide
conte-t.
)se cases scenarios 'ill need to be more fully elaborated once t&e principles for
adopting t&is approac& &a#e been appro#ed by t&e )*(DI and t&e use case models
&a#e been more elaborated in more detail.
*$#$)$# Scenario # ' 5sta+lishment of a humanitarian SDI
i% Backgroun& an& Context
OC@/ &as been tas!ed 'it& Cluster information management responsibilities at t&e
country le#el. / significant dimension of t&is responsibility relates to geospatial data
management and pro#ision functions t&at need to be pro#ided.
In order to meet its geospatial data Cluster Information 2anagement obligations
OC@/ as 'ell as to pro#ide a s&ared platform for creation and management and
s&aring of geospatial data for emergencies OC@/ proposes to de#elop a &umanitarian
(DI =@)24)*(DI> under t&e umbrella of t&e )*(DI.
ii% $nitiation of t,e ?'2"'N#D$
8ollo'ing consultation 'it& !ey &umanitarian actors7 a proposal for t&e creation of a
@)24)*(DI is submitted to )*(DI oard by )*OC@/ on be&alf of t&e
sta!e&olders in t&e @)24)*(DI
6&e )*(DI oard appro#es t&e creation of a @)24)*(DI. 6&e )*(DI 2anager
ad#ises t&e )*(DI registry administrator ='&o managers t&e !ey )*(DI registers
and registry> of t&e c&ange and a ne' (DI record is added to t&e register of (DIs
OC@/ de#elops a pro"ect proposal for t&e creation of t&e @)24)*(DI based upon
#ersion 2.5 of t&e )*(DI /rc&itecture t&at 'as do'nloaded from t&e rele#ant
register.
In accordance 'it& t&e go#ernance template contained in t&e arc&itecture7 a decision
is ta!en by t&e community to appoint a @)24)*(DI manager. OC@/ is duly
appointed to lead t&e @)24)*(DI initiati#e. In accordance 'it& t&e 6O: for t&is
role OC@/ establis&ed t&e follo'ing @)24)*(DI registers all of '&ic& 'ere
Eo'nedF by #irtue of its role as (DI coordinator
iii% ?um"'N#D$ 3egisters
:egister of @)24)*(DI participants and t&eir roles =i.e. t&ose agencies t&at
'ere signatories to t&e standard )*(DI 2O) and to t&e @)24)*(DI 2O).
and t&e roles t&at t&ey performed
:egister of data models 3 being de#eloped
:egister of data modellers and initiati#es
:egister of community #ocabularies
:egister of ser#ice conformance profiles
:egister of ser#ices instances
iv% 3egister an& registr1 management
8ollo'ing community discussion and based on establis&ed )(DI go#ernance policies
it is decided t&atC
6&e management of E(DI participant registerF is delegated to t&e )*(DI
registry manager '&o manages t&e register of participants in ot&er (DI instances
as 'ell as participants in t&e )*(DI. 6&e register is t&erefore stored in t&e
primary )*(DI registry.
6&e register of @)24)*(DI ser#ices =management of '&ic& &as been
delegated t&e )*(DI registry manager> is managed using t&e +eonet'or!
ser#ices registry. 6&is registry is used to manage t&e ser#ice registers of t&e ot&er
(DI instances establis&ed under t&e )* umbrella
a single registry 'ould be created to store t&e ot&er registers re5uired by t&e
@)24)*(DI and t&at management of t&e registry 'ould be delegated to /gency
O.
v% Control Boar&s an& #ubmitting organi0ations
Control oards and submitting organisations for t&e ne' registers are determined in
accordance 'it& t&e guidelines and go#ernance policy rules contained in t&e (DI
arc&itecture template.
8ollo'ing community discussion7 t&e follo'ing !ey (DI go#ernance roles 'ere
assigned to specific agencies based on t&e template pro#ided in t&e )*(DI
arc&itecture L2.5C
(tandards Coordinator Data =(CD> 3 /gency /
(tandards coordinator (er#ices =(C(> 4 /gency
vi% ?'2"'N#D$ scoping
@a#ing establis&ed t&e go#ernance roles and associated mec&anism =registers and
registries> t&e @)24)*(DI pro"ect focuses on scoping t&e @)24)*(DI in terms of
data and functionality.
vii% Functional re8uirements
UNSDI Technical Governance Framework Proposal %.
)sing t&e )*(DI arc&itecture L2.57 t&e community identified !ey functional
re5uirements and necessary components of t&e @)24)*(DI7 namelyC
/ portal to pro#ideC
o access to registries 4 of ser#ice instance =for general users> and ot&er
registries =for specialised community users>
9eb4mapping functionality to #ie' sources of disco#ered data
o to configure automatic updates for end users from capable data access
ser#ices
/ number of registers =outlined pre#iously>
/ number of 'eb ser#icesC
o asic map portrayal ser#ices
o 6ransactional data access ser#ices to enable bi4directional
sync&ronisation of field and centralised copies of geospatial data =e.g.
ga<etteer and administrati#e boundaries>
o Orc&estration ser#ices t&at integrate and process data from se#eral
sources to generate automatically updated situation reports
:eference implementations 'ere re#ie'ed to identify appropriate commercial and
O(( components to meet t&ese functional re5uirements. 6&e reference
implementations also &ig&lig&ted t&e need for t&e de#elopment of specialised ser#ice
orc&estration functionality.
viii% Data re8uirements
In order to determine data re5uirements for t&e @)24)*(DI a &umanitarian user
group 'as formed. 6&is group confirmed t&e recommendations of t&e OC@/ +I( and
+eospatial Data 2anagement Policy regarding t&e !ey data sets re5uired for
&umanitarian response
T?3()D# :F T?( #T:3@ C:NT$N'(D
6&e follo'ing scenario t&reads trace specific aspects of data and ser#ice design and
de#elopment process necessary to build t&e content and deli#ery elements of t&e
@)24)*(DI. 6&e scenario t&reads are intended to illustrate !ey dimensions of intra4
(DI go#ernance.
*$#$)$) Scenario ) ' Data Product Specification ' Transport data modelin0
6&e (tandards Coordinator for data =(CD> creates a number of t&ematic data teams
including one for transportation and appoints a team leader.
6&e transportation data team leader first identifies rele#ant modeling initiati#es7
models and modelers t&at e-ist 'it&in and outside of t&e )*(DI. (&e searc&es t&e
data model7 )*(DI participants register =to identify data modelers>7 #ocabulary7
reference implementation registers using t&e searc& term EtransportationF
6&e searc& re#ealsC
a transport data model =)*(DI46> de#eloped by 98P to support t&e
standardi<ed implementation of transport data storage models in +I(
UNSDI Technical Governance Framework Proposal %1
e-ternal transport modeling initiati#es including an I*(PI:1 transport data
specification de#elopment initiati#e
an draft I*(PI:1 transport data product specification
se#eral )* agencies 'or!ing on data modeling of ri#ers =part of t&e
conceptual transport data model>
(&e in#ites a number of data modelers to "oin t&e transport data modeling team.
6&e )*(DI data modeling guidelines set by t&e (tandards coordinator are used to
de#elop t&e data model. 6&e guidelines 'ere based on t&e I*(PI:1 data product
specification met&odologyC

/n early draft of t&e I*(PI:1 transport data product specification toget&er 'it& t&e
)*(DI46 model are re#ie'ed as candidate standards.
/ re#ie' of t&e @)24)*(DI re#eals t&at it could not be adopted for t&e follo'ing
=indicati#e> reasonsC
(cope is too broad as it includes features t&at are included in ot&er )*(DI
data model pac!ages
(cope is too narro' in ot&er dimensions in t&at it does not address transport
realities in conte-ts outside of 1urope e.g. sub4(a&aran /frica
Data model structure and #ocabularies are too detailed for practical application
in emergency settings
6&e team t&erefore decides to adapt t&e data model using t&e proscribed
met&odology>7 comprising t&e follo'ing steps
/rticulation of user re5uirements t&roug& use cases and application scenarios
obtained from a broad range of domain e-perts7 and end user of bot& &e
information products and applications t&at produce t&em
+ap analysis to determine unmet re5uirements and to meet t&em
2odification of t&e data product specificationC
o 2odification of t&e conceptual data model using =in )2;> using a
standard profiling tec&ni5ue informed by t&e )*(DI46 data model
o 2odification of t&e transport feature catalogue
o 2odification of t&e application sc&ema =e-pressed in +2;>
o Creation of reference implementation in t&e form of +eodatabases for
users 'is&ing to adopt t&e data model as a storage model
6est and refinement of t&e models
6&e 6ransport data product specifications and its !ey facets7 =t&e conceptual model7
application sc&ema7 features catalogue and reference implementations> are publis&ed
to t&e rele#ant registers.
*$#$)$( Scenario & ' Service desi0n throu0h profilin0
6&is scenario is intended to illustrate t&e process of de#eloping a ser#ice profile based
on specific user defined data needs. Gey steps in t&e scenario areD
ased upon data product specifications pro#ided by (tandards Coordinator 3
Data =(CD>7 t&e (tandards Coordinator (er#ices =(C(> commences t&e
process of de#eloping a ser#ice specification to deli#er t&e data
(C( disco#ers e-isting ser#ice specifications used else'&ere in t&e )*(DI
using t&e register of registers and t&e ser#ice profile register
(C( assesses profiles and determines t&at specific constraints need to be
placed on t&e ser#ice metadata to ensure t&at a re5uired application
=orc&estration ser#ice> is able to 5uery and filter data coming from a specific
ser#ice type
6&e (C( de#elops a profile and publis&es a draft in t&e register
/ ser#ices publis&er de#elops a test ser#ice based upon t&e profiles and
conformance tested using mac&ine readable profile obtained from t&e register
6&e profile is refined to address semantic and tec&nical issues and tested again
8ollo'ing successful testing of t&e test ser#ice a production profile is
publis&ed to t&e register
*$#$)$& Scenario 3 ' Service instantiation ' profile discover and implementation
6&is scenario is intended to illustrate t&e process of disco#ery of ser#ice profiles by a
ser#ice pro#ider and t&e de#elopment and publication of an instantiation of t&e
ser#ice.
/ geospatial data manager in a )* agency 'is&es to publis& security incident
information to t&e recently establis&ed &umanitarian (DI.
6&e geospatial manager7 using t&e register of registers7 registers of ser#ices profiles
and data models finds t&at t&ere is a ser#ice profile t&at meets &is need =a generic
92( profile for time4enabled7 point4based &umanitarian information>. 6&e manager
does not find a data model t&at could be used for security incident information. @e
t&erefore decides to utili<e &is internal storage data model.
6&e manager also disco#ers a reference implementation for t&e generic 92( using
O((. 6&em manager obtains t&e O(( tools to implement t&e ser#ice7 builds a ser#ice
and tests t&e ser#ice using t&e mac&ine readable ser#ice profile register and t&en
publis&es &is ser#ice to t&e &umanitarian (DI using +eo*et'or!
*$) Information viewpoint
/rticulation of an information model for tec&nical go#ernance is beyond t&e scope of
t&is frame'or!. 6&e information #ie'point including information models7 'ill need
to be elaborated based upon clearly articulated use cases. @o'e#er some critical
c&allenges t&at 'ill need to be addressed from t&e perspecti#e of t&e information
#ie'point areC
De#elopment and adoption of a data model &armoni<ation process and
e-ercise t&is 'it& t&e identified priority baseline data sets.
Identify t&e set of registers t&at muc& be maintained to store !ey information
ob"ects
Delegate responsibility for maintaining all baseline information resources
*$( 1omputational viewpoint
6&e mec&anics of &o' components can be combined t&roug& interfaces is beyond t&e
scope of t&is frame'or!. In principle7 &o'e#er7 t&e frame'or! can7 and must7 be
capable of supporting an e#ol#ing suite of o#erlapping tec&nical solutions7 sinceC
8unctional capabilities e-ist using disparate tec&nologiesD
Con#ergence on a smaller set of options 'ill ta!e timeD
Only in certain cases 'ill tec&nical solution be mandatedD
(ome tec&nology platforms are better suited for certain applications.
/ gi#en7 considering t&at multiple sta!e&olders 'ill be in#ol#ed7 is t&at net'or! based
data access is necessary7 and t&us a (er#ice Oriented /rc&itecture is re5uired. It is not
considered feasible or desirable to create a common operating platform across
multiple agencies7 'it& common infrastructure. 6&e cost of planning suc& a concept
'ould d'arf t&e implementation costs of a loosely coupled standards4based solution.
6&e go#ernance of a multi4agency (O/ solution is &o'e#er an immature field of
endea#or.
It is e-pected t&at t&e O+C 9eb (er#ices specifications 'ill form a significant #endor
neutral platform for many ser#ices. 6&is is appropriate because t&e O+C pro#ides a
formal go#ernance process for t&ese standards. 6&e O+C standards t&emsel#es7 to an
increasing degree7 form a layer on top of baseline I168 and 93C standards.
*$& 5n0ineerin0 viewpoint
6&ere 'ill be practical considerations regarding t&e distribution and deployment
arc&itecture of t&e )*(DI. Data 'are&ouse and distributed point4of4trut& &a#e
distinct ad#antages and disad#antages7 and it is e-pected t&at a &ybrid solution 'ill be
re5uired. (ignificant furt&er effort is re5uired to analy<e t&ese issues7 &o'e#er t&e
)*(DI can 'it& reasonable confidence proceed7 based on t&e principle of a
distributed solution allo'ing fle-ibility as to e-actly '&ere and &o' to implement
components.
*$3 Technolo0 viewpoint
6&e )*(DI concept proposed is fundamentally tec&nology4neutral7 and t&is s&ould
be formali<ed in policies. *ot'it&standing t&is desire7 it is occasionally ad#antageous
to select a 'idely a#ailable tec&nology for an implementation p&ase. Care s&ould be
ta!en to ma!e sure t&at #endor4neutrality is build into pro"ect plans7 eit&er as a built4in
re#ie' process or subse5uent p&ase.
Open source reference implementations s&ould be soug&t for eac& component7 to
ensure e5uity of access7 and t&e ability to e-periment and de#elop local capacity using
t&e same tools as t&e )*(DI.
@$ Governance actors; responsi+ilities and institutional
mappin0s
@$# ,ctors and Terms of !eference
@a#ing identified go#ernance )se Cases and actors7 6erms of :eference =6O:> for
!ey actors 'ill need to be defined. One of t&e ma"or tas!s of go#ernance actors is t&e
UNSDI Technical Governance Framework Proposal %%
management of registers. 6&e follo'ing section describes t&e process of mapping
roles in registry management to organi<ations.
+o#ernance of t&e go#ernance establis&ment process =e.g. determining aut&ority
delegation decision rig&ts> 'ill need to be determined as part of t&e go#ernance
frame'or! initiation.
@$) 7appin0 roles to or0ani=ations
:egisters are t&e !ey enabler to interoperability in a distributed en#ironment as t&ey
enable resources to be publis&ed7 disco#ered and used. / !ey responsibility of t&e
go#ernance actors 'ill be to manage t&e registers t&at list t&e artifacts =agreements
and t&eir implementations> t&at underpin information interoperability.
/s outlined in t&e I(O 1,135 conceptual model for registration of items of geograp&ic
information7 t&ere are a number of roles in managing registers. It is clear t&at in most
cases t&e Eo'nerF of a register 'ill be t&e actor fulfilling t&e go#ernance role being
enabled by t&e register. @o'e#er7 ot&er roles suc& as register and registry manger
=delegated by t&e register o'ner>7 submitting organi<ation =organi<ations t&at pro#ide
re5uests to c&anger register content> and control bodies =to ad"udicate on c&ange
re5uests> need to be assigned to indi#iduals and organi<ations so t&at go#ernance can
be implemented. 6&ese =I(O proscribed> register management roles areC
3egister owner 3 t&e agency t&at establis&es t&e register and &as primary
responsibility for t&e management7 dissemination7 and intellectual content of t&e
register
3egister manager 3 agency or person to '&om responsibility is delegated. It
is anticipated t&at register management 'ill often be delegated to speciali<ed
actors
3egistr1 manager 3 agency responsible for managing t&e information system
in '&ic& t&e register is &eld. It is li!ely t&at many registers 'ill be managed 'it&in
a single registry. It is also anticipated t&at t&e )*(DI 'ill comprise multiple
distributed registers e.g. multiple registers containing ser#ice metadata7 multiple
registers containing data models
#ubmitting organi0ation 3 submitting re5uests to c&ange registers =add edit
delete items>
Control bo&1 3 an appointed panel of ad#isors '&o ad"udicate on
submissions for register c&anges from submitting organi<ations
6&e assignment of roles 'ill need to be carried out follo'ing t&e elaboration of an
arc&itecture7 toget&er 'it& t&e go#ernance use cases and actors t&at are identified.
+o#ernance process policies 'ill need to be establis&ed to go#ern t&e process of role
assignment7 delegation etc.
#%$ Pro2ect work'plan
#%$# /verview
/ 'or!4plan is proposed t&at comprises a series of discrete but related pro"ects t&at
meet '&at are understood to be t&e priority needs of t&e )*(DI sta!e&older
community. 6&e pro"ects build different dimension of t&e )*(DI capability. 6&ese
discrete pro"ects also enable t&e step'ise creation and e#olution of t&e go#ernance
capabilities t&at 'ill be de#eloped in parallel. 6&is approac& reflects t&e resource
constraints7 and tests t&e concept of adapti#e go#ernance as t&e infrastructure gro's
Critical dependencies bet'een pro"ects 'ill need to be analy<ed in more detail to
identify critical pat& tas!s and to ensure pro"ects and tas!s are implemented in correct
se5uence.
#%$) Principles
6&e principles of t&e 'or!4plan are as follo'sC
1stablis&ment of )*(DI by means of a series of sub4pro"ects 'it&in t&e
)*(DI pro"ect7 t&atC
o Lalidate principles of t&e )*(DI
o /ct as test case for fle-ible e-tensible go#ernance frame'or!
1stablis& core initial capability
1stablis&7 adaption and e#olution mec&anism for t&e )*(DI t&at transcends
t&e implementation conte-t e.g. as t&e )*(DI implementation conte-t mo#es
from pro"ect to programme
(tep'ise approac& to de#elopment of )*(DI capabilities and components
toget&er 'it& t&e necessary adapti#e go#ernance capabilities
#%$( Scope of the work'plan
6&e 'or!4plan focuses on fi#e areasC
)rc,itecture "6&e creation and maintenance of a )*(DI arc&itecture to
support (DI creation
#D$ &evelopment " 6&e creation of (DI instances t&at are nodes0systems
'it&in t&e )*(DI and t&e publis&ing of standardi<ed data and ser#ices
Tools " (DI 2..7 an (DI toolset 'it& 8O(( reference implementation
Data mo&els " de#elopment and &armoni<ation and deployment of data
models for priority geospatial data sets and t&e
3egistr1 of #D$ resources 4 Implementation of registry for t&e management
of (DI resources
#%$($# UNSDI architecture pro2ect
Create7 publis& and create capacity to manage7 a co&erent )*(DI arc&itecture to test
and support t&e process of e-tending and enabling operational (DIs to align t&eir
acti#ities. 6&e arc&itecture 'ill be de#eloped based upon common elements of t&e
re5uirements for t&e (DI instances t&at are created =sub4pro"ect 1..3.2>.
/s t&ere are important interdependencies bet'een t&e elaboration of t&e arc&itecture
and t&e creation of (DI instances7 implementation of t&ese t'o pro"ects 'ill be need
to be 'ell coordinated.
#%$($) 1reation of UN SDI instances
6&e aim of t&is pro"ect is to establis&ment of a number of representati#e =)*>(DI
instances to meet clearly articulated business needs of specific communities and
t&roug& t&eir implementation7 demonstrate interoperability bet'een t&e (DIs. In
addition to components of t&e o#erarc&ing )*(DI =e.g. aggregation ser#ices> t&at
may be re5uired7 (DI instance test cases s&ould reflect t&e 'idely di#ergent needs of
different communities 'it&in t&e )*. (uggested test cases s&ould includeC
;ocal emergency response (DI 3 e.g. to &umanitarian (DI
+lobal monitoring (DI e.g. en#ironmental )*1P
Capacity building e.g. e.g. t&e proposed Pa!istan Pro#incial 2apping of )*
/cti#ities pro"ect 3 a potential country capacity building and *(DI de#elopment
pro"ect
9it& regard to populating (DI 'it& ser#ice and data t&e follo'ing pro#ides an
indicati#e processC
Define core )* data access ser#ices 3 re5uired across =)*>(DI instances
based upon clearly articulated end4user demand e.g. International and (econd
;e#el /dministrati#e oundaries database and global7 3.m D12
Define additional data sets re5uired 'it&in eac& (DI instance e.g.
&umanitarian response base datasets co#erage at 1C25.7... scale for countries
#ulnerable to disasters
1stablis& data product specification de#elopment teams in accordance 'it&
agreed policies and 'or!ing to agreed standards
8or t&e preceding t&ree steps it is re recommended t&at an approac& suc& as
t&e I*(PI:1 A2et&odology for t&e De#elopment of Data (pecificationsB be used
to capture end user data usage re5uirements t&roug& use cases and applications
scenarios
12
Conformance profiles ser#ices de#eloped for specific usage conte-ts
2apping of data models to ser#ice profiles e.g.
(er#ices instantiated7 tested and deployed
:egisters of artifacts =toget&er 'it& one of more registries to operate t&em> 'ill be
re5uired to support t&is process =see section 1..3.5>.
/s noted in t&e preceding section t&ere are critical dependencies bet'een t&is pro"ect
and t&e arc&itecture pro"ect as t&e abstracted common re5uirements of t&e test case
(DIs toget&er 'it& t&e re5uirements for t&e broader )*(DI 'ill be used to define t&e
arc&itecture. In turn.7 t&e arc&itecture 'ill be used as a template for (DI creation. It is
t&erefore clear t&at t&e t'o pro"ects need to be 'ell sync&roni<ed.
#%$($( SDI )$% 8 a reference implementation
In parallel 'it& t&e (DI de#elopment7 t&e (DI 2.. pro"ect is proposed. 6&e aim of t&is
pro"ect 'ill be to de#elop a co&erent collection of (DI tools7 supported by a 8ree and
Open (ource (oft'are =8O((> reference implementation. 6&e proposed (DI 1.. is a
collation of independent best practice '&ereas (DI2.. is designed to de#elop a toolset
t&at support (DI implementation and operation. Critical elements of t&e pro"ect 'ould
includeC
12
=I*(PI:1 Drafting 6eam PData (pecificationsP7 2..7>.
De#elopment and implementation of a 8O(( engagement strategy and in
particular a formali<ation of relations&ips 'it& !ey 8O(( (DI partners suc& as
O(+1O
o :eference implementations supported by 8O(( and t&e 1(:I
en#ironment
o Create a test bed to support 1(:I and ot&er geospatial tec&nologies
reac& compliance 'it& common le#el of interoperability. =)* designs
goals and pays for test bed and maintains control of interoperability
agenda>
#%$($& 7odelin0 and harmoni=ation of priorit UN data sets
1. Create data model across !ey priority data set identified by OC@/ geospatial
policy document =)*OC@/7 2..7> =clause 1,>. / !ey dimension of t&is pro"ect
'ould be ac&ie#ing &armoni<ation 'it& I*(PI:1 t&roug& t&e in#ol#ement of t&e )*
in t&e I*(PI:1 data modeling process. 6&is sub4pro"ect 'ould &a#e t&e follo'ing
!ey outcomesC
@armoni<ed data models for !ey data sets
Identification and #alidation of critical cross domain data model
&armoni<ation met&odologies leading to )* sponsors&ip as international
standards t&roug& partners&ip 'it& rele#ant bodies
6&e establis&ment of #ocabularies =including go#ernance of #ocabularies> and
determine relations&ip bet'een t&em and data models in '&ic& t&ey are used. 9&ere
e-isting #ocabularies are not go#erned7 go#ernance 'ill need to be de#eloped

#%$($3 !e0istr creation
1stablis& registries capable of managing di#erse range of artifacts and t&e
relations&ip bet'een t&em
o (ponsor a common set of register profiles re5uired for an (DI e.g. /
register of eac& set of actors re5uired to manage (DI including for
e-ampleC
:egister of agencies
:egister of policies =data s&aring policies7 go#ernance policies7
(DI participation policies7 tec&nology policies>
:egister of agreements =ser#ice le#el agreement7 2O) for (DI
participation7 data licenses>
:egister of data product specifications =including data models
and feature catalogues>
:egister of ser#ice specifications and profiles
:egister of ser#ice instances
o Creation and registration of resources and actors.
#%$& <ork'plan implementation issues
6&e 'or! plan proposes a number of related pro"ects t&at are understood to reflect t&e
priority needs of )*(DI sta!e&olders. /ssociated 'it& t&is step'ise7 pro"ect4based
approac& are se#eral critical implementation issues t&at are described belo'.
UNSDI Technical Governance Framework Proposal %$
6&e 'or!4plan approac& necessitates parallel de#elopments. 6o ensure t&at t&is suite
of pro"ects are ade5uately managed and correctly se5uenced7 an in4dept& analysis of
pro"ect dependencies and critical pat& 'ill be re5uired. 8urt&ermore7 t&ere 'ill be a
need to synt&esi<e approac&es at a later date to minimi<e dependencies and ris!s.
/lt&oug& t&e longer term goal of t&e )*(DI is to align its go#ernance 'it& ot&er
go#ernance processes and t&us le#erage and potentially reuse go#ernance resources7
initially7 t&e )*(DI cannot build too many dependencies on ot&er (DI initiati#es and
t&eir go#ernance arrangements. 1-ternal (DIs and t&eir go#ernance 'ill &a#e
different priorities t&at may c&ange and 'ill operate and e#ol#e o#er different time
periods. 6&us7 dependencies bet'een )*(DI and ot&er (DI initiati#es introduce
ma"or ris! from a pro"ect management perspecti#e.
+i#en t&e adapti#e go#ernance approac& it is li!ely t&at different institutional
configuration and resourcing 'ill be re5uired for !ic! start and for long term
go#ernance as t&e infrastructure and resources gro'. :e#ie' and adaption of
go#ernance during t&e initial de#elopment p&ases of t&e )*(DI must remain a !ey
cross4cutting t&eme of t&e 'or! plan.
UNSDI Technical Governance Framework Proposal %,
,ppendi. # ' !eferences
/nnan7 G. =2...>. I'e t&e peoplesI t&e role of t&e united nations in t&e 21st century .
)*7 *e' Qor!. :etrie#ed from
&ttpC00'''.un.org0millennium0sg0report0full.&tm.
8inney7 G. =2..7>. / Pbottom upP go#ernance frame'or! for de#eloping australiaIs
marine spatial data infrastructure =sdi>7 Data Science Bo*rnal7 67 6%4,..
@enric!sen7 . =2..77 8ebruary>. )nited nations spatial data infrastructure
compendium a unsdi #ision7 implementation strategy and reference
arc&itecture.
I*(PI:1 Drafting 6eam PData (pecificationsP. =2..77 /ugust 23>. Drafting team
Pdata specificationsP 3 deli#erable d2.6C met&odology for t&e de#elopment of
data specifications. I*(PI:1 Drafting 6eam PData (pecificationsP. :etrie#ed
October %7 2..77 from &ttpC00'''.ec4gis.org0inspire0'&atsne'.cfm.
I(O. =1,$$7 December 15>. International standard iso0iec
1.7%641 information tec&nology S open distributed processing S reference
modelC o#er#ie'. I(O. :etrie#ed ?anuary $7 2..$7 from
&ttpC00standards.iso.org0ittf0Publicly/#ailable(tandards0inde-.&tml.
I(O0I1C 1117,. =1,,,>. International standard iso0iec
1117, information tec&nology S specification
and standardi<ation of data elements . :etrie#ed *o#ember $7 2..77 from
&ttpC00'''.iso.org0iso0isoMcatalogue0catalogueMtc0catalogueMdetail.&tmJ
csnumberT353%3.
(tane!7 :. =2..67 2ay 17>. +o#ernance7 t&e !ey to soa success7 :oosely co*ples.
:etrie#ed from &ttpC00'''.looselycoupled.com0opinion02..60stane!4
go#.517.&tml.
6andy7 ?.7 K 6&omas7 D. =2..6>. :egistry tec&nology and case study implementation
In . (eoul7 :epublic of Gorea7 *o#ember 64$ 2..6C 92O. :etrie#ed
(eptember 217 2..77 from &ttpC0072.1%.253.1.%0searc&J
5Tcac&eC"nm);UI?<&o?C'''.'mo.int0pages0prog0'''061CO4
9I(0Programme.docV61CO4
9I(V6andyK&lTenKctTcln!KcdT1KglTauKclientTfirefo-4a.
)nited *ations. =2..6>. )nited nations7 2..6. Edeli#ering as oneC report of t&e &ig&4
le#el panel on united nations system4'ide co&erence in t&e areas of
de#elopment7 &umanitarian assistance and t&e en#ironmentF. in report of t&e
un general assembly a6105$3 . )*7 *e' Qor!.
)*OC@/. =2..7>. Policy instruction 4 geograp&ic information systems and
geospatial data management. )*OC@/.
9eb (er#ices Interoperability Organi<ation. =2..7>. 3asic Services Pro"ile. &ttpC00'''.'s4
i.org0
98P7 K I6@/C/. =2..77 2ay 1$>. 9fp spatial data infrastructure =sdi> in support to
unsdi preliminary proposal #ersion 1...
9ilson7 2. =2..7>. Re%ional cons*ltation o" the %overnance o" the *n spatial ata
in"rastr*ct*re- better ata sooner ra"t meetin% notes "or comment
7version ra"tC1 (ctober 'Dth '66?8. *airobi7 GenyaC )*1P.
,ppendi. ) ' ,cronms and a++reviations
D*( 3 Domain *ame (ystem
DPKO - UN Dep$%".e!" + Pe$'e<eepi!; Ope%$"i!#
ebO2; 4 1lectronic usiness using eOtensible 2ar!up ;anguage
1(:I 4 1n#ironmental (ystems :esearc& Institute
BAO - B& $!& A;%i'30"3%e O%;$!i?$"i! + "*e UN
8O(( 4 8ree and Open4(ource (oft'are
+C2D 3 +lobal C&ange 2aster Directory see &ttpC00gcmd.nasa.go#0
CIC - C3.$!i"$%i$! I!+%.$"i! Ce!"%e
I111 4 Institute of 1lectrical and 1lectronics 1ngineers7 Inc.
I*(PI:1 3 Infrastructure for (patial Information In 1urope
I(O " International (tandards Organi<ation
O+C - Open +eospatial Organisation7 Inc.
O(+1O 4 Open (ource +eospatial 8oundation
O(( 4 Open4(ource (oft'are
:24ODP 4 :eference 2odel Open Distributed Processing
(DI 4 (patial Data infrastructure
(O/ 3 (er#ice Oriented /rc&itecture
(O/P 4 (imple Ob"ect /ccess Protocol
)DDI 4 )ni#ersal Description7 Disco#ery and Integration
UN - U!i"e& N$"i!#
UNEP - U!i"e& N$"i!# E!vi%!.e!" P%;%$..e
UNGIDG - U!i"e& N$"i!# Ge;%$p*i' I!+%.$"i! D%<i!; G%3p
UNCCR - OE'e + "*e U!i"e& N$"i!# Ci;* C..i##i!e% +%
Re+3;ee#
UNFLC - U!i"e& N$"i!# Fi!" L;i#"i'# Ce!"%e
UNOCCA - U!i"e& N$"i!# OE'e +% C%&i!$"i! + C3.$!i"$%i$!
A,$i%#
UNSDI - U!i"e& N$"i!# Sp$"i$0 D$"$ I!+%$#"%3'"3%e
98P 4 9orld 8ood Programme
9(4I 4 9eb (er#ices Interoperability Organi<ation
9(D; 4 9eb (er#ices Description ;anguage
O2; 4 1-tensible 2ar!4up ;anguage

Proposed UNSDI Tech Gov Framework

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Proposed UNSDI Tech Gov Framework

Transféré par

Droits d'auteur :

Formats disponibles

United Nations Spatial Data Infrastructure

Vous aimerez peut-être aussi