SIST-TP CEN/TR 15449-1:2013

SLOVENSKI STANDARD
01-januar-2013
1DGRPHãþD
SIST-TP CEN/TR 15449:2011
*HRJUDIVNHLQIRUPDFLMH,QIUDVWUXNWXUH]DSURVWRUVNHSRGDWNHGHO5HIHUHQþQL
PRGHO
Geographic information - Spatial data infrastructures - Part 1: Reference model
Geoinformation - Geodateninfrastrukturen - Teil 1: Referenzmodell
Information géographique - Infrastructures de données spatiales - Partie 1: Modèle de
référence
Ta slovenski standard je istoveten z: CEN/TR 15449-1:2012
ICS:
07.040 Astronomija. Geodezija. Astronomy. Geodesy.
Geografija Geography
35.240.70 Uporabniške rešitve IT v IT applications in science
znanosti
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL REPORT
CEN/TR 15449-1
RAPPORT TECHNIQUE
TECHNISCHER BERICHT
October 2012
ICS 07.040; 35.240.70 Supersedes CEN/TR 15449:2011
English Version
Geographic information - Spatial data infrastructures - Part 1:
Reference model
Information géographique - Infrastructures de données Geoinformation - Geodateninfrastrukturen - Teil 1:
spatiales - Partie 1: Modèle de référence Referenzmodell

This Technical Report was approved by CEN on 27 May 2012. It has been drawn up by the Technical Committee CEN/TC 287.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United
Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2012 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TR 15449-1:2012: E
worldwide for CEN national Members.

Contents Page
Foreword .4
1 Scope .7
2 Normative references .7
3 Terms and definitions .7
4 Abbreviated terms .8
5 SDI interoperability .9
5.1 Interoperability Standards .9
5.2 Challenges . 10
5.2.1 Costs . 10
5.2.2 Quality . 10
5.2.3 Impact and checkpoints . 11
5.3 The European Interoperability Framework (EIF) . 11
5.4 The Architectural reference model . 13
5.4.1 Data . 13
5.4.2 Services . 14
5.5 Combining EIF and the Architectural service reference model . 16
5.6 SDI as a dynamic framework . 17
6 Reference Model for a SDI . 19
7 SDI Components . 21
7.1 SDI core component . 21
7.2 Application and Geo-portal components . 22
7.3 Relations among service components . 23
8 Standards to implement the Core components . 24
8.1 Framework standards . 24
8.2 Relevant standards . 24
Annex A EU policy documents relevant to standardisation and interoperability . 26
A.1 Introduction . 26
A.2 Policy documents . 26
A.3 Strategy and framework documents. 26
Annex B Directive 2007/2/EC Infrastructure for Spatial Information in the European Community . 27
B.1 General . 27
B.2 Legal acts . 27
B.3 Metadata Implementing Rules . 27
B.3.1 Legal acts . 27
B.3.2 Guidance Documents . 28
B.4 Data Specifications Implementing Rules . 28
B.4.1 Legal acts . 28
B.4.2 Guidance Documents . 28
B.4.2.1Framework documents . 28
B.5 Network Services Implementing Rules . 30
B.5.1 Legal acts . 30
B.5.2 Guidance Documents . 30
B.6 Spatial Data Services Implementing Rules . 30
B.7 Data and service sharing Implementing Rules . 30
B.7.1 Legal acts . 30
B.7.2 Guidelines and good practice documents . 30
B.8 Monitoring and reporting Implementing Rules . 31
B.8.1 Legal acts . 31
B.8.2 Guidelines, justification document and templates . 31
Annex C Description of referenced ISO standards . 32
Annex D CEN/TC 287 and ISO/TC 211 standards . 34
Annex E Open Geospatial Consortium specifications . 37

Foreword
This document (CEN/TR 15449-1:2012) has been prepared by Technical Committee CEN/TC 287
“Geographic information”, the secretariat of which is held by BSI.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights.
This document supersedes CEN/TR 15449:2011.
The present standard comprises the following parts:
 CEN/TR 15449-1, Geographic information — Spatial data infrastructures — Part 1: Reference model (the
present part);
 CEN/TR 15449-2, Geographic information — Spatial data infrastructures — Part 2: Best practices;
 CEN/TR 15449-3, Geographic information — Spatial data infrastructures — Part 3: Data centric view;
 CEN/TR 15449-4, Geographic information — Spatial Data Infrastructure (SDI) — Part 4: Service centric
view.
Introduction
Spatial data infrastructure (SDI) is a general term for the computerised environment for handling data that
relates to a position on or near the surface of the earth. It may be defined in a range of ways, in different
circumstances, from the local up to the global level.
This Technical Report focuses on the technical aspects of SDIs, thereby limiting the term SDI to mean an
implementation neutral-technological infrastructure for geospatial data and services, based upon standards
and specifications. It does not consider an SDI as a carefully designed and dedicated information system;
rather, it is viewed as a collaborative framework of disparate information systems that contain resources that
stakeholders desire to share. The common denominator of SDI resources, which can be data or services, is
their spatial nature. It is understood that the framework is in constant evolution, and that therefore the
requirements for standards and specifications supporting SDI implementations evolve continuously.
SDIs are becoming more and more linked and integrated with systems developed in the context of e-
Government. Important drivers for this evolution are the Digital Agenda for Europe, and related policies (cf.
Annex A). This Technical Report takes these developments into account. By sharing emerging requirements
at an early stage with the standardization bodies, users of SDIs can help influence the revision of existing or
the conception of new standards.
The users of an SDI are considered to be those individuals or organisations that, in the context of their
business processes, need to share and access geo-resources in a meaningful and sustainable way. Based on
platform- and vendor-neutral standards and specifications, an SDI aims at assisting organisations and
individuals in publishing, finding, delivering, and eventually, using geographic information and services over
the internet across borders of information communities in a more cost-effective manner.
Existing material about SDIs abounds. The criteria used for determining if a given standard or specification is
referred to in this report are that the publication addresses an aspect of an SDI; and the publication is non-
proprietary in nature.
Based on these considerations, the following reports have been taken into account:
• legal texts and guidelines produced in the context of INSPIRE;
• documents produced by ISO/TC 211 (and co-published by CEN);
• documents produced by the Open Geospatial Consortium (OGC), including the OpenGIS Reference
Model (ORM) (OGC, 2003);
• the European Interoperability Framework and related documents;
• deliverables from the European Union-funded projects (e.g. GIGAS, SANY).
Considering the complexity of the subject and the need to capture and formalise different conceptual and
modelling views, CEN/TR 15449 is comprised of multiple parts:
• Part 1: Reference model: this provides a general context model for the other Parts, applying general
IT architecture standards.
• Part 2: Best Practices: this provides best practices guidance for implementing SDI, through the
evaluation of the projects in the frame of the European Union funding programmes.
• Part 3: Data centric view: this addresses concerns related to the data, which includes application
schemas and metadata.
• Part 4: Service centric view (in preparation): this includes the taxonomy of services, concepts of
interoperability, service architecture, service catalogue, and the underlying IT standards.
Further parts may be created in the future.
1 Scope
This part of the Technical Report provides a reference model for a Spatial Data Infrastructure (SDI). It covers
framework standards and identifies the relevant standards, technical specifications, technical reports and
guidelines.
This part of the Technical Report provides a context model for the other parts of this Technical Report
applying general architecture standards.
The intended readership of this Technical Report are those people who are responsible for creating
frameworks for SDIs, experts contributing to INSPIRE, experts in information and communication technologies
and e-government that need to familiarise themselves with geographic information and SDI concepts, and
standards developers and writers.
2 Normative references
Not applicable.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
conceptual formalism
set of modelling concepts used to describe a conceptual model
EXAMPLE UML meta model, EXPRESS meta model.
Note 1 to entry: One conceptual formalism can be expressed in several conceptual schema languages.
[SOURCE: EN ISO 19101:2005]
3.2
conceptual model
model that defines concepts of a universe of discourse
[SOURCE: EN ISO 19101:2005]
3.3
conceptual schema
formal description of a conceptual model
[SOURCE: EN ISO 19101:2005]
3.4
conceptual schema language
formal language based on a conceptual formalism for the purpose of representing conceptual schemas
EXAMPLE UML, EXPRESS, IDEF1X.
Note 1 to entry: A conceptual schema language may be lexical or graphical. Several conceptual schema languages
can be based on the same conceptual formalism.
[SOURCE: EN ISO 19101:2005]
3.5
conformance
fulfilment of specified requirements
[SOURCE: EN ISO 19113:2005]
3.6
identifier
linguistically independent sequence of characters capable of uniquely and permanently identifying that with
which it is associated
[SOURCE: ISO/IEC 11179-3:2003]
3.7
interoperability
capability to communicate, execute programs, or transfer data among various functional units in a manner that
requires the user to have little or no knowledge of the unique characteristics of those units
[SOURCE: ISO/IEC 2382-1:1993]
3.8
reference frame
aggregation of the data needed by different components of an information system
3.9
resource
asset or means that fulfils a requirement
[SOURCE: EN ISO 19115:2005]
3.10
Spatial Data Infrastructure
SDI
metadata, spatial data sets and spatial data services; network services and technologies; agreements on
sharing, access and use; coordination and monitoring mechanisms, processes and procedures, established,
operated or made available in an interoperable manner
[SOURCE: INSPIRE]
Note 1 to entry: In the context of this report the term SDI is restricted to a platform- and implementation-neutral
technological infrastructure for geospatial data and services, based upon standards and specifications.
3.11
use case
specification of a sequence of actions, including variants, that a system (or other entity) can perform,
interacting with actors of the system
[SOURCE: ISO/IEC 19501:2005]
4 Abbreviated terms
API  application programming interface
CORBA Common Object Request Broker Architecture
EIF  European Interoperability Framework
EN  European Standard (CEN deliverable)
INSPIRE Infrastructure for Spatial Information in Europe
GI  geographic information
GML Geography Markup Language
ISO  International Organization for Standardization
ICT  information and communications technology
ODP Open Distributed Processing
OGC Open Geospatial Consortium
OLE/COM Object linking and embedding/ Component Object Model
OMG Object Management Group
OSE Open Systems Environment
RM-ODP Reference Model of Open Distributed Processing
SDI  Spatial Data Infrastructure
SLD  Styled Layer Descriptor
SOA Service Oriented Architecture
UML Unified Modelling Language
WAI  Web Accessibility Initiative
WCS Web Coverage Service interface specification
WFS Web Feature Service interface specification
WMS Web Map Service interface specification
W3C World Wide Web Consortium
XML eXtensible Markup Language
XSL  eXtensible Stylesheet Language
5 SDI interoperability
5.1 Interoperability Standards
A Spatial Data Infrastructure (SDI) relies on standards and specifications in the field of geographic information
and information technology. This chapter systematically identifies standards that are of particular relevance to
SDI development and implementation. A necessary condition for the successful establishment of a SDI is that
the software industry supports relevant standards in commercial products. At the same time, public authorities
are to request the support of standards in public procurement processes.
Many of the standards and specifications are already available. There is, however, a need to systematically
identify these standards and to determine whether or not they are sufficiently precise and unambiguous so
that their implementation provides interoperability and fulfils requirements of an SDI in Europe.
Standards should make interoperability as easy, simple and reliable as possible. The ISO 19100-series of
standards both individually and collectively are quite complex. The risk of different interpretations of the same
standard in different implementations exists and has to be minimised as much as possible. The aim must be
to establish implementations of the standards which are as unambiguous and precise as possible. Avoiding
variations of interpretation can be achieved through the use of suitable, standard based tools for data
modelling, interface description, data transfer and quality control.
Recent EU initiatives have brought ‘Interoperability’ to centre-stage of the European Union’s ICT governance
framework. A range of stakeholders (governments, industry, consumers, and other social partners) have
recognised the need for interoperability and recognise the benefits interoperability could bring. Interoperability
has supplemented earlier discussions focused exclusively on open group standards, different software
licensing models, or technical specifications under public procurement laws. Interoperability embraces the
wider policy perspective to enhance ICT-embedded industries and the information society at large, including
the geographic information communities.
Interoperability is the capability to communicate, execute programs, or transfer data among various functional
units in a manner that requires the user to have little or no knowledge of the unique characteristics of those
units. Standardization of geographic information can best be served by a set of standards that integrates a
detailed description of geographic information concepts with the concepts of information technology. A goal of
the GI standardization efforts is the facilitation of interoperability of geographic information systems, including
interoperability in distributed computing environments. Interoperability provides the freedom to mix and match
information system components without compromising overall success (OGC, 2003). It is the basis for the
successful implementation of a SDI in Europe, and will allow:
a) finding information and processing tools, when they are needed, independent of physical location;
b) understanding and use of the discovered information and tools, no matter what platform supports them;
whether local or remote;
c) easier and more cost-effective integration and combination of data originating from heterogeneous
sources;
d) support of policies in Europe;
e) control of the evolution of an SDI.
Lack of interoperability should be resolved by the support and implementation of international standards by
software providers. This will greatly increase the efficiency of the use of geographic information in the future.
5.2 Challenges
5.2.1 Costs
Costs of implementation and operation are an important consideration. Whilst it is possible to establish
individual interfaces for or between any systems or databases, the advantage of using standards should be to
provide an easier and cheaper implementation. Interoperability gets more difficult for more complex systems,
databases and interfaces. Therefore it is important to keep it as simple as possible at least at the level of
system and user interfaces.
5.2.2 Quality
Quality issues are also an important consideration. Completeness and consistency of content, e.g. structure,
and format of transfer data should be automatically checkable against reference and target data model. Once
more tools based on standards are the solution of choice.
5.2.3 Impact and checkpoints
The full impact of standards on interoperability is reached when everything in the whole process from the
description of data models to the description of exchange format and quality control can be described and
derived unambiguously with a set of standard based tools following the model driven approach. This process
should be possible without any complex manual working steps to support straightforward and conformant
maintenance of the different system components.
There are several general considerations for achieving interoperability:
• Use the Modelling Driven Approach (MDA) based on standards;
• Be precise;
• Keep things simple;
• Use standard based tools;
• Automate the processes;
• Check the quality.
5.3 The European Interoperability Framework (EIF)
The generic architecture model for geographic information and services aligns with the general requirements
1)
for European e-Government Services, as stated in the European Interoperability Framework (EIF) strategy.
This framework identifies the organisational, semantic and technical interoperability aspects.
Interoperable Delivery of European eGovernment Services to public administrations, businesses and citizens
(IDABC) uses the opportunities offered by information and communication technologies to encourage and
support the delivery of cross-border public sector services to citizens and enterprises in Europe, to improve
efficiency and collaboration between European public administrations and to contribute to making Europe an
attractive place to live, work and invest.
The European Interoperability Framework comprises five interoperability levels:
• Political Context;
• Organisational Interoperability;
• Legal interoperability;
• Semantic Interoperability;
• Technical Interoperability.
These are illustrated in Figure 1.

1) See http://ec.europa.eu/idabc/.
Figure 1  EIF version 2.0 Interoperability levels
The EIF version 2.0 extended the upper Interoperability levels with political context and legal interoperability in
addition to the EIF version 1.0 levels of organisational interoperability, semantic interoperability and technical
interoperability.
An Interoperability Framework can be defined as the set of policies, standards and guidelines that describes
the way in which organisations have agreed, or should agree, to do business with each other. Consequently,
an Interoperability Frameworks architecture model is not a static document and needs to be maintained over
time as technologies, standards and administrative requirements change.
This interoperability framework focuses on the following principles:
 accessibility – non-discriminating, open and publicly available data, including guidelines for WAI (Web
Access Initiative) from the World Wide Web Consortium;
 multilingualism – support of a range of languages that are used extensively in Europe today;
 security – identification, authentication, non-repudiation, confidential information;
 privacy - personal data protection;
 subsidiarity;
 use of open standards.
To attain interoperability in the context of pan-European e-Government services, a focus on open standards is
required. The General Public Services Conceptual Model from EIF in Figure 2 shows main service areas
identified in the context of public services.

Figure 2  Public services conceptual model

This interoperability framework implements the recommendations provided by the European Interoperability
Framework (EIF). The following service types are recognised:
a) Basic Public Functions:
1) interoperability facilitating services - transformation, brokering and mediation functionalities, etc.;
2) base registration services - publication and discovery functionalities, etc.;
3) external services - business level services, payment services, connectivity services, etc.
b) Aggregate Services, grouping a number of basic public functions to appear as a single service:
1) composition services;
2) orchestration services;
3) workflow services.
5.4 The Architectural reference model
5.4.1 Data
Exchange of and access to spatial data is the principal objective of an SDI. The data are at the heart of an
SDI. The spatial data in an SDI are a model of the real world, developed according to well defined
methodologies described in different standards. The model is made explicit through a concise description of
data specifications in data specification documents. These specifications can then be used to develop new
datasets or to transform existing datasets to the specifications by mapping the existing model to the model
described in the specifications. In this way, semantic interoperability can be achieved: i.e. different datasets
can be used together and be understood by different users in the same way. Metadata are part of the datasets
and should get proper attention during the data modelling. Metadata will play a crucial role in documenting
and understanding the content of the data model and data product specification, in achieving technical
interoperability.
On top of the data, and by making use of the metadata, services can be built to make the data accessible
through the web and to use them in any information system by viewing, downloading, or process them. This is
often referred to as a Service Oriented Architecture (SOA). A SOA enables new and existing enterprise
systems to share services, information and data across technical platforms, departments and ultimately
across organisational, regional and national boundaries. The benefit is that this leads from a stand-alone
system-centric view to an enterprise data-centric view of IT. The transition to a data-centric SOA allows an
SDI to better leverage new and existing IT investments to support such an infrastructure. The data-centric
transition builds a strategy around the organisations and their geospatial data infrastructure both to preserve
the IT investment and to provide better access to authoritative data sources.
The model-driven approach follows the concepts developed in the model-driven architecture defined by OMG.
The lifetime of a technical implementation is shorter than the lifetime of the information it handles. This makes
it necessary to describe the information in a way that allows for new techniques and implementation
environments to be applied. The starting point of information modelling is the universe of discourse. There are
several aspects to the data specification development: the conceptual schema language used to describe the
application schema; the application schema itself; the features which make up these application schemas and
the organisation of features in feature catalogues; portrayal aspects to define the way features are visualised;
and the implementation through encoding rules. Data management considerations are important for good
functioning SDIs and include quality, the use of unique identifiers and metadata. The output of the data
modelling is a data product specification that can be used by data custodians for developing new spatial data
sets or for transforming existing data towards the data specifications.
The data centric view is further developed in Part 3 of this Technical Report.
5.4.2 Services
The service centric view is further developed in Part 4 of this Technical Report.
The architectural service reference model related to different types of services is adapted from the
EN ISO 19119 service architecture standard. This standard describes an architectural based taxonomy of
services, with six main service categories:
• Interaction services (Human Interaction Services) are services for management of user interfaces,
graphics, multimedia and for presentation of compound documents.
• Composition and Orchestration (Workflow/Task Services) are services for support of composed
and orchestrated services including specific tasks or work-related activities conducted by humans.
These services support use of resources and development of products involving a sequence of
activities or steps that may be conducted by different services and/or persons.
• Processing Services are services that perform large-scale computations involving substantial
amounts of data. Examples include services for providing the time of day, spelling checkers and
services that perform coordinate transformations (e.g., that accept a set of coordinates expressed
using one reference system and converting them to a set of coordinates in a different reference
system). A processing service does not include capabilities for providing persistent storage of data or
transfer of data over networks.
• Data and Things Management services (Data/Model/Information Management Services) are
services for management of the development, manipulation and storage of metadata, conceptual
schemas and datasets. It also relates to access to sensors and actuators (and Internet of Things).
• Communication Services are services for encoding and transfer and system/service interaction
including data handling across communications networks.
• System and Security Management Services are services for the management of system
components, applications and networks. These services also include management of user accounts
and user access privileges, including security rights management.
These are illustrated in Figure 3. For each of these categories it is relevant to consider SDI specific extensions
for areas where generic IT functionality and supported is not meeting all requirements.

Figure 3  Architectural service reference model

Figure 4 shows see how these categories have been used to identify SDI and Geographic specific services
within each of the categories.
Figure 4  ICT Interoperability framework from INSPIRE
The ICT Interoperability Framework has been defined in the context of INSPIRE, and illustrates relevant
examples different possible types of services in the services taxonomy, accessed through applications and
geoportals and a digital rights management layer.
This taxonomy does not introduce a strict classification; an aggregated service can belong to more than one
type (or class), depending on the context in which it is applied.
5.5 Combining EIF and the Architectural service reference model
Figure 5 shows how the different service types identified in the ICT Interoperab target for both technical and semantic interoperability in the context of the EIF. A detailing in the areas of
semantic and technical interoperability can be made with respect to each of the identified service categories.
Figure 5  Combining EIF and the ICT Interoperability Framework
5.6 SDI as a dynamic framework
A SDI should not be considered as a static framework that will offer solutions for a fixed set of requirements.
Rather, it is a dynamic framework that satisfies current requirements while at the same time generating new
requirements and solutions. It also permits creation of new services and applications, and stimulates the
creation of new standards and specifications. Once an SDI is in place, there are four activities:
1) specification and standardisation,
2) development,
3) deployment,
4) invocation.
In each activity there are standards of interest. With this in mind, an SDI can be described in terms of a set of
high-level activities that reflect its evolutionary character. These activities are:
• establish the core SDI,
• create new specifications,
• develop new services and applications,
• deploy services and applications, and
• invoke application instances.
These activities are described in Table 1. The activity diagram in Figure 6 suggests how the SDI activities
interact, thus driving the evolution of SDIs.

Figure 6  Generic SDI activity diagram
Table 1 — SDI Activities
Activity Description Example
1 Establish the Certain basic services, fundamental for the SDI, have Data, metadata content,
"core" SDI to be developed and launched according to metadata catalogues, service
standards and specifications. catalogues.
Pre-condition: standards for metadata content
(services and data).
Post condition: human-readable catalogues
2 Develop new Service interfaces are specified and published by Standards required for
specifications interface providers. description of features and
coverage: modelling
language, spatial
representation etc. standards
for description of presentation
aspects, portrayal.
3 Develop new Based on published interface specifications, services Standards for certain servers:
services and (for example a WFS for roads) and applications (for WMS, WFS, gazetteer,
applications example an application for goods delivery) are built transformation etc.
by service providers and application providers.
Standards for encoding.
Standards for finding services.
Standards for security.
4 Deploy service The services are published by the service providers.
and
application The applications are provided to the users and
instances
installed.
Standards for describing and publishing services
5 Invoke The user uses the application that finds and calls Standards for evaluation.
application appropriate services.
instances by
users
6 Reference Model for a SDI
This section provides a reference model based around EN ISO 19101 and the Reference Model for Open
Distributed Processing (RM-ODP).
SDIs can be described by different five viewpoints: the enterprise viewpoint, the computational viewpoint, the
information viewpoint, the engineering viewpoint, and the technology viewpoint, all of them addressing
different concerns (see Table 2). This section makes primarily use of the Computational Viewpoint and the
Information Viewpoint.
Table 2 — RM-ODP viewpoints
Viewpoint Definition of RM-ODP Viewpoint (ISO/IEC 10746-1)
Enterprise A viewpoint of an ODP system and its environment that
viewpoint focuses on the purpose, scope and policies of that system.
Computational A viewpoint on an ODP system and its environment that
viewpoint enables distribution through functional decomposition of the
system into objects which interact at interfaces.
Information A viewpoint on an ODP system and its environment that
viewpoint focuses on the semantics of information and information
processing.
Engineering A viewpoint on an ODP system and its environment that
viewpoint focuses on the mechanisms and functions required to support
distributed interaction between objects in the system.
Technology A viewpoint on an ODP system and its environment that
viewpoint focuses on the choice of technology in that system.

The Reference Model brings together standards at two different levels of abstraction, and under two different
architectural viewpoints, as summarised in Table 3.
 Implementation Specifications tell software developers how to express information or requests within a
particular distributed computing environment (e.g. World Wide Web, CORBA, .NET). Implementation
Specifications generally include access protocols, object models, and naming conventions. Such
specifications are specific to, and directly usable within, their target computing environment.
 Abstract models specify what information or requests are valid in principle, irrespective of individual
computing environments. They define essential concepts, vocabulary, and structure (type hierarchy) of
geospatial services and information transfer. These models set the stage for creating implementable
specifications, and for extending existing ones to new environments.
Deciding which of these to apply depends on the design lifecycle, and on the intended computing
environment. Earlier design stages often draw on abstract models to sketch a system concept; whereas later
implementation stages follow implementation specifications in detail. When it comes to writing software, if a
suitable implementation specification already exists for the applicable computing environment, it should be the
standard of choice. Otherwise, the relevant abstract model(s) should guide the design of a new
implementation specification for that environment.
Table 3 — Viewpoints and levels of abstraction applied in the Reference Model
Computation viewpoint Information viewpoint
Viewpoints
Service invocation Information transfer
Abstract models (what) Behaviour Content
Implementation Specifications Interface Encoding
(how)
At either the abstract or the implementation level, standards of two different kinds may apply:
 service invocation: these standards define the interfaces that allow different systems to work together,
or the expected behaviour of software systems. The RM-ODP calls this the computation viewpoint; its
focus is on invoking services effectively and unambiguously;
 information transfer: these standards define the content of geospatial information or its encoding for
transfer between different processing systems. In RM-ODP parlance, this is the information viewpoint,
emphasizing efficient, lossless communication.
For distributed computing, the service and information viewpoints are crucial and intertwined. For instance,
information content is not useful without services to transmit and use it. Conversely, invoking a service
effectively requires that its underlying information be available and its meaning clear. However, the two
viewpoints are also separable: one may define how to represent information regardless of what services carry
it; or how to invoke a service regardless of how it packages its information.
In a given context, either the computation view (behaviour implemented as interfaces) or the information view
(content implemented as encodings) may take priority, depending on the diversity of the target community, the
expected complexity of data and data processing, the pre-existence of related standards, and so on.
The OGC Abstract Specification, Topic 0 (Overview, Section 2) explains the roles of abstract and
implementation models, and the interdependence of service invocation and information transfer. The EN ISO
19101, Geographic information — Reference Model provides additional background on conceptual models
and their role in specification design using UML.
7 SDI Components
7.1 SDI core component
Standards and specifications are available in support of most SDI aspects. In order to help the reader in
maintaining an overview, a so-called SDI Components Reference Model is adopted. It focuses on
mechanisms for effective cooperation between software components in a SDI setting. The components have
here been identified and described from a life cycle point of view – from the perspective of resources providers
in terms of data and service providers. Parts 3 and 4 of this Technical Report offer different approaches (data
centric and service centric) to the identification of the various Reference Model components introduced in this
section.
The primary organizing structure is determined by the following SDI core components:
• Data: the information resource.
• Register: support for the activity of describing and publishing resources.
• Discovery: making it possible to search for spatial data sets and services on the basis of the content
of the corresponding metadata and to display the content of the metadata.
• Vi
...