Post on 13-Mar-2018
transcript
National Environmental Information Infrastructure:
Reference Architecture
Contributing to the Australian Government National Plan for Environmental Information initiative
National Environmental Information Infrastructure: Reference Architecture v1.2
Environmental Information Programme Publication Series, document no. 4 ISBN 978-0-642-70650-8 (paperback)
Other documents in the Environmental Information Programme Publication series: no. 1 The environmental accounts landscape no. 2 Biodiversity profiling: components of a continental biodiversity information capability no. 3 Guide to environmental accounting in Australia
Environmental Information Programme
Bureau of Meteorology
Email: environment@bom.gov.au
www.bom.gov.au/environment
Citing this publication
Bureau of Meteorology 2014, National Environmental Information Infrastructure: Reference Architecture,
Environmental Information Programme Publication Series, document no. 4, Bureau of Meteorology, Canberra,
Australia.
With the exception of logos or where otherwise noted, this report is licensed under the Creative Commons
Australia Attribution 3.0 Licence. The terms and conditions of the licence are at:
www.creativecommons.org/licenses/by/3.0/au
Copyright in graphics and data provided by external agencies and libraries remains the copyright of the individual
contributors.
i
National Environmental Information
NEII Reference Architecture
Contents
1 Purpose of the document ................................................................................................................... 1 2 Introduction ........................................................................................................................................ 2
2.1 Background ........................................................................................................................ 2 2.2 Why is a national environmental information infrastructure necessary? ........................... 2 2.3 Australian Government information context ...................................................................... 3 2.4 Technical overview ............................................................................................................ 3 2.5 Scope ................................................................................................................................. 5 2.6 Requirements .................................................................................................................... 5 2.7 Assumptions ...................................................................................................................... 5 2.8 Constraints ......................................................................................................................... 5 2.9 Principles ........................................................................................................................... 6
3 Architectural overview ........................................................................................................................ 8 3.1 Use of Reference Model for Open Distributed Processing ................................................ 8
4 Enterprise viewpoint ........................................................................................................................... 9 4.1 Purpose.............................................................................................................................. 9 4.2 Architecture scope ............................................................................................................. 9 4.3 Policies.............................................................................................................................10 4.4 Roles and functions .........................................................................................................10
5 Information viewpoint .......................................................................................................................11 5.1 ISO 19156 Observations and Measurements model ......................................................11 5.2 Information types .............................................................................................................13 5.3 Information dynamics .......................................................................................................25
6 Computational viewpoint ..................................................................................................................27 6.1 Catalogue Service for the Web ........................................................................................27 6.2 Web Feature Service .......................................................................................................28 6.3 Sensor Observation Service ............................................................................................29 6.4 Web Map Service ............................................................................................................29 6.5 SISSVoc (Vocabulary Service) ........................................................................................30
7 Engineering viewpoint ......................................................................................................................31 7.1 National Environmental Information Catalogue (NEICat) ................................................32 7.2 National Environmental Monitoring Sites Register (NEMSR)..........................................33 7.3 National Environmental Information Service (NEIServ) ..................................................35 7.4 National Environmental Vocabulary Service (NEVS) ......................................................36 7.5 National Environmental Observing Methods Register (NEOMR) ....................................38 7.6 National Environmental Information Explorer (NEIExp) ..................................................39
8 Technology viewpoint ......................................................................................................................42 8.1 Geospatial standards .......................................................................................................42 8.2 Spatial Information Services Stack ..................................................................................43
9 Viewpoint correspondences .............................................................................................................44 9.1 Information—computational consistency .........................................................................44 9.2 Engineering—computational consistency ........................................................................44 9.3 Technology—engineering consistency ............................................................................48
10 Acknowledgements ..........................................................................................................................49 11 Glossary: Abbreviations and terms ..................................................................................................50 12 References .......................................................................................................................................58
ii
National Environmental Information
NEII Reference Architecture
List of tables
Table 1: High level National Environmental Information Infrastructure roles ............................................. 10
Table 2: Observations and Measurements and National Environmental Information Infrastructure ......... 11
Table 3: Relevant standards for National Environmental Information Infrastructure information classes . 13
Table 4: National Environmental Information Infrastructure computational interfaces............................... 27
Table 5: National Environmental Information Infrastructure components .................................................. 31
Table 6: National Environmental Information Infrastructure geospatial standards .................................... 42
Table 7: Spatial Information Services Stack technology components ....................................................... 43
Table 8: National Environmental Information Infrastructure computational interfaces and information ..... 44
Table 9: Technologies realising National Environmental Information Infrastructure component ............... 48
iii
National Environmental Information
NEII Reference Architecture
List of figures
Figure 1: The standard spatial data infrastructure architectural pattern .................................................... 4
Figure 2: National Environmental Information Infrastructure value chain .................................................. 9
Figure 3: National Environmental Information Infrastructure basic high-level use cases .......................... 10
Figure 4: Observation core model .............................................................................................................. 12
Figure 5: NEII information types related to O&M ....................................................................................... 14
Figure 6: Example of a metadata record .................................................................................................... 15
Figure 7: Examples of environmental observations from different domains .............................................. 16
Figure 8: Information model example in UML ............................................................................................ 18
Figure 9: Examples of observable environmental parameters for.............................................................. 19
Figure 10: Examples of monitoring sites .................................................................................................... 20
Figure 11: Gridded data examples ............................................................................................................. 21
Figure 12: Examples of environmental geographies .................................................................................. 22
Figure 13: Example of hierarchical observing methods ............................................................................. 23
Figure 14: Example of hierarchical species taxonomy for Acacia species ................................................ 24
Figure 15: Discovery of individual datasets or services using metadata search ........................................ 25
Figure 16: Metadata containing keywords for geography, site, and parameters ....................................... 26
Figure 17: Communication flows between National Environmental Information Catalogue components . 32
Figure 18: Mechanisms for populating the National Environmental Monitoring Sites Register ................. 34
Figure 19: National Environmental Monitoring Sites Register high-level conceptual model ...................... 34
Figure 20: Accessing observation and geographic data through the National Environment Information .. 35
Figure 21: Use of the National Environmental Vocabulary Service by the National Environmental Information Service and within the National Environmental Information Explorer ................... 37
Figure 22: NEIExp 'integration index' for advanced functionality and performance ................................... 40
Figure 23: NEIExp interaction with 'integration index' ................................................................................ 41
Figure 24: National Environmental Information Infrastructure components and computational interface . 47
Page 1
NEII Reference Architecture
This document defines the reference
architecture for the National Environmental
Information Infrastructure (NEII). It provides a
high level technical description of a system for
enhancing the discovery, access, and use of
national environmental information. It factors the
NEII architectural description into multiple
complementary viewpoints. While it describes
information types, interfaces, and architecture
components required to realise a working
system, it does not describe a specific
deployment.
Moreover, the reference architecture
documented here is a flexible solution: it
supports a phased implementation towards
increasing degrees of conformance and
maturity. It enables value to be realised even at
the early stages of implementation.
Enhanced scalability and reduced maintenance
overheads are the main benefits of increasing
architectural completeness.
This document will be reviewed and the content
updated periodically to ensure the information
remains current.
1 Purpose of the document
Page 2
NEII Reference Architecture
2.1 Background
The National Plan for Environmental
Information (NPEI) initiative is an Australian
Government programme intended to improve
the quality and accessibility of environmental
information for decision-making. It is being
jointly implemented by the Bureau of
Meteorology (the Bureau) and the Department
of the Environment. The Bureau’s role focuses
on operational elements including
implementation of technical components of a
functional environmental information system.
This environmental information system is being
realised through the development of the
National Environmental Information
Infrastructure (NEII).
The NEII is a federated platform that facilitates
the discovery, access, and use of
environmental information. It includes the
standards and specifications that define its
core supporting IT components. Further, it
demonstrates the development of a national
information fabric that supports decision-
making through the delivery of environmental
data.
Key outcomes expected to emerge from the
infrastructure include:
• an ability to discover, access, and use
national environmental information data
through harmonised online services and
web portals;
• a standards-based federated
environmental information architecture that
can support multiple application use cases;
and
• an approach to collaboration and
governance that coordinates the adoption
of environmental information standards by
partners.
The NEII will initially be designed and led by
the Bureau with technical partners including
CSIRO, the Department of the Environment,
and Geoscience Australia. Its ongoing impact,
however, will only be realised through strategic
collaborations with the environmental
information community, and in particular those
agencies that produce and manage
environmental information or use
environmental information to support their
business needs.
Because the initial development of NEII is
proceeding in parallel with the other NPEI
activities, it will inevitably be subject to future
requirements arising from related strategic
priorities. Moreover, the detailed deployment
architecture is evolving based on identification,
capacity for engagement, and priority of
relevant information providers. Therefore, a
reference architecture approach has been
adopted for the initial phase of NEII. The
Reference Model for Open Distributed
Processing (RM-ODP, ISO 10746-{1,2,3,4})
provides an appropriate architecture
framework for this purpose, based on:
• the federated nature of NEII; and
• the use of RM-ODP in related standards
(the ISO TC211 series) and infrastructures
(e.g., spatial data infrastructures).
2.2 Why is a national environmental information infrastructure necessary?
The Australian Government invests significant
resources into environmental information
acquisition and management through the
activities of a number of agencies. The
information is required to support their
business activities. This includes the breadth of
weather, climate, and water information
developed by the Bureau; the earth science
and national mapping and remote sensing
capability of Geoscience Australia; and the
various activities of other Australian
Government agencies including the
2 Introduction
Page 3
NEII Reference Architecture
Department of Agriculture and the Department
of the Environment.
Investment also occurs indirectly through the
Australian Government’s administration of
national programmes, such as devolved
natural resource management programmes;
research and research infrastructure
investment supported by the National
Collaborative Research Infrastructure Strategy
and the National Environmental Research
Program; and the activities of the research
sector including in particular CSIRO and
universities.
The breadth of national and international
requirements for environmental information
across many sectors of Australian Government
has recently been detailed in the Statement of
Australian Government requirements for
environmental information (Australian
Government Environmental Information
Advisory Group, 2012).
Although environmental information is
abundant, potential users are typically
hampered by an inability to discover, access,
and use the information. Information often
exists only within individual agencies to
support internal business requirements, or
within individual environmental domains. As a
result, enabling discovery, access, and use
across domains (e.g., air, land, oceans and
water) remains challenging.
Where data can be found, gaining access can
introduce new challenges because not all
agencies are equipped to provide data and
outreach services; data may utilise proprietary
file formats; or increasing data volumes makes
delivering data difficult. And, finally, the
absence of standards introduces a major
challenge when users attempt to use
information and lack the domain specific
understanding to make informed decisions
around data quality and its fitness-for-purpose.
2.3 Australian Government information context
In addition to the importance of the NEII to the
environmental information community, its
development comes at a time of increasing
recognition of the importance of transparency
of all government data and information. This
transparency agenda includes the Declaration
of Open Government and the data.gov.au
initiative. A related government open
information agenda is also being actively
championed in the context of spatial
information, through the Office of Spatial
Policy.
In both the United States and the United
Kingdom, development of an open public
information policy is being influenced strongly
by semantic web and ‘linked data’
technologies. The Australian Government
information transparency agenda will play a
defining role in organisational, political and
technical implementation aspects of the NEII.
The NEII could thus become a key enabler for
realising a whole of government open
information policy agenda.
2.4 Technical overview
Internationally, there is a growing body of work
on environmental information systems
associated with the emerging discipline of
environmental informatics. A related area is the
development of spatial data infrastructures
(SDIs) at regional, national, and international
scales. The most advanced of these
internationally is being developed under the
European INSPIRE Directive (2007/2/EC;
European Parliament, 2007).
The SDI pattern (Figure 1) allows a network of
datasets to be federated and interoperable by
conforming to common data models, exchange
formats, and standard network protocols, and
Page 4
NEII Reference Architecture
by providing centralised catalogues of uniform
metadata descriptions.
NEII adopts key elements of this best-practice
and adds particular extensions to support the
unique requirements of environmental
information. Example extensions embedded in
the NEII architecture include explicit
information about environmental monitoring
sites and methods used to observe the
environment (e.g., instrument type, protocol,
and parameter).
The SDI architecture represents state-of-the-
art in large-scale environmental information
systems and represents a low-risk path to
realising an initial NEII capability, albeit
requiring supplementation for environment-
specific value-added functionality.
Figure 1: The standard spatial data infrastructure architectural pattern (1—metadata discovery;
2—common services; 3—standard exchange formats)
Page 5
NEII Reference Architecture
2.5 Scope
The scope of this document is to:
• describe basic high-level use cases;
• classify important information types;
• describe key architectural components and
interfaces; and
• identify implementation technology
options.
Jointly, these comprise the NEII reference
architecture. Describing the detailed solution
architecture for individual NEII components is
beyond the scope of this document.
2.6 Requirements
The essential requirement for NEII is to:
• enhance the discovery, access, and use of
environmental information.
2.7 Assumptions
The following assumptions apply to the NEII in
its first phase:
• NEII will be federated in nature as it is
beyond the capacity of any single agency,
including the Bureau, to warehouse all
environmental information in one location.
• The SDI architecture pattern is extensible
to environmental information.
• The reference architecture, including any
technical reference implementations must
not be based on proprietary solutions and
should conform to relevant international
standards and best practice.
• Initial development of the programme will
involve planning and deploying the
foundation components; documenting the
NEII architecture and testing it in a small
number of applied settings; and
establishing collaborations to develop and
deliver the NEII’s long-term objectives.
2.8 Constraints
A number of constraints influence the design of
the reference architecture. First, there is
explicit recognition that implementation will
proceed in stages. By analogy, the European
INSPIRE SDI implementation roadmap
extends over more than a decade. Similarly,
the Canadian SDI (GeoConnections) has taken
10 years to reach a stage of maturity sufficient
for promoting its operational use. Over an
extended implementation timetable, best
practice evolves; this reference architecture
will need to evolve in parallel, while still
delivering value at an early stage. A related
constraint is that the architecture must be
resilient—it should support integration of
providers, for instance, at varying degrees of
maturity and conformance.
Second, a number of activities internationally
(e.g., NSF’s EarthCube and the European
Shared Environmental Information System) are
attempting to develop federated environmental
information systems. The NEII reference
architecture must demonstrate value with
respect to peer initiatives to justify its continued
adoption into the future.
Third, there is significant momentum
internationally (especially by the UK and US
governments) behind semantic web and
linked-data technologies as an emerging
platform for publishing public sector
information in a domain-neutral manner (i.e.
across various sectors such as environment,
health, statistics, and finance). While this
approach shows significant promise, NEII
cannot wait until these technologies are
proven. Therefore, a two-pronged strategy will
be followed: the reference architecture will
adopt the current best-practice SDI pattern as
a lower-risk initial solution; in parallel, the
Page 6
NEII Reference Architecture
Bureau will take a leadership role in trialling
linked-data approaches.
2.9 Principles
A number of foundation principles inform the
long-term vision for NEII. Where conflicts arise,
the reference architecture prioritises practical
considerations over aspirational principles to
deliver near-term value. The reference
architecture will evolve over time to reflect
feasibility, technological developments, and
emerging user requirements.
2.9.1 Feasible and sustainable
The NEII reference architecture will be
federated where possible, but centralised
where necessary. It must be feasible to build
NEII and cost-effective to sustain it. NEII will
succeed by starting simply and growing in
complexity. NEII proposes maintaining data at
source wherever possible, to reduce the cost
of duplicating and warehousing datasets into a
central location, and providing adequate
hardware, data management processes and
infrastructure, and domain expertise.
It also supports centralised management and
delivery of data if availability, or conformance
to NEII standards, cannot otherwise be
guaranteed.
2.9.2 Standards-based
To minimise technical risks, the NEII will follow
existing best practice for SDIs. This will not
require harmonisation of individual provider
data management infrastructures, but instead
will achieve a virtual harmonisation through
interoperability. Interoperability will be
achieved by adopting conventional standards
for metadata, web services, and data
exchange. Interoperability is a necessary, but
not sufficient, condition to achieve the NEII’s
eventual aims.
The NEII will also conform to standards
regulated by Australian Government and the
coordinating authority (Bureau). The NEII will
work with the Australian Government
Information Management Office (AGIMO),
data.gov.au, the Office for Spatial Policy
(OSP), and other related technical standards
bodies to ensure conformance to standards
across other domains.
2.9.3 Data re-usability and open licensing
To maximise use of data and information
products, it is essential that users can evaluate
their fitness-for-purpose. This requires
traceable quality indicators to be associated to
datasets. There are a number of international
quality frameworks for environmental and earth
observations data (e.g., ISO 19157:2013 and
QA4EO) that may be relevant for NEII. The
marginal additional cost of including this
information at collection can significantly
enhance data re-usability.
Re-usability is also enhanced through a
common licensing framework. In line with the
OAIC Principles on open public sector
information, a Creative Commons Attribution
(CC-BY) licence is preferred for NEII, with a
wider spectrum of options available if
necessary through AusGOAL. NEII will provide
a mechanism to support re-use of public sector
information.
2.9.4 Multi-purpose
While the initial focus of NEII is on
environmental information for Australian
governments, the infrastructure will ultimately
support a much broader spectrum of users,
including the research community and general
public. NEII should serve multiple purposes
across a varied environmental information
stakeholder community. It may be appropriate
Page 7
NEII Reference Architecture
to develop policies and mechanisms for NEII to
provide differentiated service offerings.
2.9.5 An agile infrastructure
NEII will enable environmental information to
be found, accessed, integrated, compared, and
used in new ways. This may be encapsulated
in the notion of an agile information platform.
First, it should be easy to publish into, and
access information from, NEII. Data providers
should not need to substantially re-engineer
their existing data infrastructures, but should
be able to easily register new datasets into
NEII for discovery, access, and use by others.
NEII should be scalable with respect to both
dataset complexity and size (e.g., supporting
'big data').
Data and information products should be easily
and widely accessible across multiple delivery
channels. New data providers and users
should be supported at low overhead. NEII
should support integration, correlation, and
assimilation of information products and
services, including computational models.
Finally, as an infrastructure, NEII should
support a spectrum of value-added
applications and services that may be
constructed on its foundation.
2.9.6 Secure
NEII should provide secure access to data
providers and users. The security model
should support conventional authentication,
authorisation, and accounting services.
Page 8
NEII Reference Architecture
3.1 Use of Reference Model for Open Distributed Processing
The National Environmental Information
Infrastructure (NEII) Reference Architecture
defines a general environmental information
system, but does not describe a specific
deployment or provider configuration. It adopts
the Reference Model for Open Distributed
Processing (RM-ODP) as an architectural
framework, with the following benefits:
• RM-ODP is widely used internationally for
describing spatial data infrastructure (SDI)
architectures.
• It is also adopted as a framework for
geospatial and SDI-related international
standards (e.g., ISO/TC 211 Geographic
information/Geomatics and the Open
Geospatial Consortium).
The RM-ODP framework factors an architecture
description into five complementary viewpoints:
1. Enterprise: defining the purpose, scope and
policies of the system;
2. Information: describing the semantics of
information and information processing
within the system;
3. Computational: decomposing the system
into computational interfaces;
4. Engineering: describing the system
infrastructure and mechanisms supporting
federation; and
5. Technology: focusing on technology
choices to realise the system.
3 Architectural overview
Page 9
NEII Reference Architecture
4.1 Purpose
The purpose of the National Environmental
Information Infrastructure (NEII) is to enhance
discovery, access, and use of national
environmental information. A value chain
supporting this purpose is identified through
major elements of the architecture (Figure 2).
4.2 Architecture scope
The scope of the NEII reference architecture
includes information providers and users, and
the components, standards, and technologies
required to realise the purpose.
Figure 2: National Environmental Information Infrastructure value chain
4 Enterprise viewpoint
Page 10
NEII Reference Architecture
4.3 Policies
The following policies apply to the NEII
reference architecture:
• The National Plan for Environmental
Information (NPEI) initiative;
• Office of the Australian Information
Commissioner’s Principles on open public
sector information;
• NEII architectural principles (i.e., feasible
and sustainable, standards-based,
supporting data re-use and environmental
intelligence, multi-purpose, secure).
4.4 Roles and functions
Table 1 describes the high-level roles defined
within the NEII. Basic use cases for core NEII
functions are illustrated in Figure 3.
Table 1: High level National Environmental Information Infrastructure roles
Role name Role description
data provider Supplies an environmental information resource for publishing within NEII.
user Discovers and accesses environmental information through NEII.
service provider Publishes a service through an NEII component.
domain authority Supplies community-endorsed information models or vocabularies for adoption within NEII.
coordinating authority
Provides essential centralised integration infrastructure.
Figure 3: National Environmental Information Infrastructure basic high-level use cases
Page 11
NEII Reference Architecture
5.1 ISO 19156 Observations and Measurements model
ISO 19156:2011 defines a conceptual model for
observations and measurements (O&M)
(Figure 4).
In natural language, the model states that an
environmental observation measures an
observed property of (or on) a feature-of-interest
using a procedure and generating a result. The
feature-of-interest may be a so-called domain
feature, reflecting a real-world object measured
in its entirety (river, bio-region, soil zone, etc.),
or more usually a sampling feature arising as an
artefact from an observing strategy (e.g.,
stations, profiles, transects).
The O&M model is generally used as a
conceptual basis for standardised exchange
formats for environmental information types
(e.g., GeoSciML, WaterML and CSML). Within
the National Environmental Information
Infrastructure (NEII) reference architecture,
O&M informs the definition of individual
architectural components and classification of
broad information classes (see Table 2),
regardless of whether it is also adopted for
standardised information exchange models
within the infrastructure. It provides a conceptual
foundation for the architecture as a whole,
beyond the standard spatial data infrastructure
(SDI) pattern. The NEII reference architecture,
therefore, represents an O&M-based extension
to SDI.
Table 2: Observations and Measurements
and National Environmental Information
Infrastructure architecture
O&M element
NEII engineering component
NEII broad information class
observed property
vocabulary service
environmental parameters
feature-of-interest
monitoring sites register
information services
monitoring sites and networks
environmental geographies
procedure observing methods register
observing methods
result information services
information models
Integration between the various components
and information types is required to realise the
maximum value of the architecture. This
integration is achieved most readily by adoption
of O&M-based information exchange models.
However, the architecture is not reliant on O&M
to achieve information exchange and integration
can be completed through ad-hoc mechanisms
(e.g., manual spatial analysis for relating
monitoring sites to geographies).
5 Information viewpoint
Page 12
NEII Reference Architecture
Figure 4: Observation core model [based on ISO 19156:2011]
Page 13
NEII Reference Architecture
5.2 Information types
Figure 5 illustrates the classification of high-level
information types defined in NEII and their
relationship to O&M.
Table 3 lists relevant standards for information
types adopted in NEII.
Table 3: Relevant standards for National
Environmental Information Infrastructure
information classes
NEII information class
Relevant standard
dataset/service metadata
Profile of ISO 19115:2003 (Metadata) [M]
environmental observations
ISO 19156:2011 (Observations and Measurements) [P]
information models
Based on the General Feature Model, ISO 19109:2005 (Rules for Application Schemas) [M]
environmental parameters/ observables
Simple Knowledge Organisation System (SKOS) [M]
species taxonomies
Simple Knowledge Organisation System (SKOS) [P]
Note: M = mandatory; P = preferred
5.2.1 Dataset and service metadata
Dataset and service discovery metadata is
descriptive information about a discrete
environmental information data resource or
network-accessible service. It defines
standardised attributes useful for user searching
and filtering, for example:
• title and abstract;
• reference date;
• point of contact;
• geographic extent of data;
• thematic topic category;
• on-line resource; and
• keywords.
(See also Figure 6)
5.2.2 Environmental observations
Environmental observation data often represent
the ultimate target of a user search process.
These data are the result of observing or
measuring one or more environmental
parameters using a relevant procedure within a
geographic context and temporal frame. The
form of observation data is domain-specific
(Figure 7). Typical examples include time-series,
field samples and surveys, profiles, and
transects.
Page 14
NEII Reference Architecture
Figure 5: NEII information types related to O&M
Page 15
NEII Reference Architecture
Figure 6: Example of a metadata record—Geofabric Groundwater Cartography [Bureau of
Meteorology, accessed 18 March 2014]
Page 16
NEII Reference Architecture
A. Daily climate observations
B. Average annual streamflow
C. Seed mass (Gallagher et al. 2012)
Figure 7: Examples of environmental observations from different domains—A. climate; B.
streamflow; and C. seed mass
Page 17
NEII Reference Architecture
5.2.3 Information models
Due to the domain-specific form of
environmental observation data, a user must
understand the logical structure and semantic
content of the data before it is useful. An
information model is a formalised description of
this structure for a specific environmental data
type (Figure 8). Due to the adoption of SDI
standards, the information model is also a direct
representation of the exchange format, and so
enables querying and interpretation of a data
stream accessed through NEII.
5.2.4 Environmental parameters and observables
To be meaningful, observation data must
reference the environmental phenomenon being
measured (e.g., streamflow, soil moisture,
marine temperature, atmospheric pressure,
pollutant concentration, or a species
occurrence). Environmental parameters or
observables may be characterised through
agreed terms with associated definitions
(Figure 9). They may be arranged hierarchically
reflecting successive refinement of more
abstract phenomena (e.g., temperature,
atmospheric temperature, and atmospheric
potential temperature).
Page 18
NEII Reference Architecture
Figure 8: Information model example in UML
Page 19
NEII Reference Architecture
No. Order Description
1 Anthroposols human made soils
2 Organasols soils dominated by organic material
3 Podosols Bs, Bh or Bhs horizons
4 Vertosols clay > 35%, cracks, slickensides
5 Hydrosols soils that are saturated in the major part of the solum for 2–3 months
6 Kurosols strong texture-contrast, pH <5.5 in B Horizon
7 Sodosols strong texture-contrast, sodic B horizon
8 Chromosols strong texture-contrast, pH >5.5 in B horizon
a) Australian Soil Classification System, Orders of the Australian Soil Classification www.clw.csiro.au/aclep/asc_re_on_line/soilhome.htm (accessed 5 May 2014)
Primary Class Secondary Class
Conservation and Natural Environmental Nature conservation
Strict nature reserves
Wilderness area
National park
Natural feature protection
Habitat/species management
Protected landscape
Other conserved area
b) Australian land use and management classification showing extract of classification www.daff.gov.au/ABARES/aclump/Pages/land-use/alum-classification-version-7-may-2010/default.aspx (accessed 5 May 2014)
Parameter Description Units
temperature still air temperature degrees Celsius
rainfall rainfall millimetres
relative humidity ratio of water content to max amount of moisture in the air before it precipitates
per cent
air pressure air pressure hecto Pascals
wind direction measures where the wind is coming from 0 to 360 degrees
wind speed wind speed knots
c) Meteorological parameters including simple description and units
Figure 9: Examples of observable environmental parameters for—a) soils; b) land use
and management; and c) meteorology
Page 20
NEII Reference Architecture
5.2.5 Monitoring sites and networks
The geographic location where environmental
data are collected is fundamentally important
to their interpretation. Characterisation of
monitoring sites and their locations therefore
provides a primary filtering mechanism for
discovery of associated environmental
information. The notion of a site is interpreted
broadly within NEII, for instance to encompass
not only point geometric locations, but also
linear (e.g., a marine vessel cruise track) and
areal (e.g., ecological survey quadrat). Sites
are often aggregated into identifiable
monitoring networks, subject to similar
observing regimes and measured
environmental parameters (Figure 10). Site
properties include the site type and location,
owner/related party information, and sensitivity
status.
Figure 10: Examples of monitoring sites—(a) tidal, (b) meteorological, (c) ecological, (d) water
quality, (e) soils [images a-e: 2014, iStock]; (f) Australian water monitoring stations [BoM, 2013]
Page 21
NEII Reference Architecture
5.2.6 Gridded representation of remote-sensing, numerical simulations and models, and analyses
Remote-sensing imagery is often conceptually
similar to other environmental observations
(e.g., having a satellite-based radiometer as an
observing procedure, ground
swath/scene/footprint as monitoring site, and
reflected radiance as the observed
environmental parameter). There are, however,
architectural benefits to identifying it as a
separate broad NEII information class in its own
right. Such datasets are generally large,
multidimensional grids or rasters, and often
multi-parameter rather than scalar. They may
also arise as output from numerical models or
analysis (Figure 11).
5.2.7 Environmental geographies
Most environmental observations are made in
the context of one or more specific and relevant
environmental geographies (Figure 12), for
example, catchment boundaries, bioregions, or
coal basins. Typically these geographies may be
characterised by a name and identifier,
geometry, and limited thematic attribution. They
generally provide a broader scale context for
individual monitoring site locations. In addition,
an environmental geography may carry an
implied or explicit reference to a specific
thematic domain (e.g., air, land, water, ocean).
Figure 11: Gridded data examples—(a) digital aerial photography [iStock, 2014], (b) 1 second
digital elevation model for Australia [Geosciences Australia, 2011], (c) model output from ACCESS
weather model [BoM, 2013], (d) synoptic-scale satellite imagery [iStock, 2014]
Page 22
NEII Reference Architecture
Figure 12: Examples of environmental geographies: (a) climate zones for Australia [BoM, 2005] (b)
geological boundaries [iStock, 2014], (c) administrative boundaries [iStock, 2014], (d) drainage
divisions [BoM, 2012], (e) protected area boundaries [Department of the Environment, 2012]
Page 23
NEII Reference Architecture
5.2.8 Observing methods
Human observing protocols, instrument types
and classifications, and analytical procedures
also provide important context to
environmental data. The information may be
relevant to a scientific user, for example, who
wishes to identify only data collected by
specific high-quality instrument types.
Observing method types may be classified
hierarchically (Figure 13).
Figure 13: Example of hierarchical observing methods [NASA Global change master directory,
gcmd.nasa.gov/KeywordSearch/, accessed 29 November 2013]
Page 24
NEII Reference Architecture
5.2.9 Species taxonomies
A species taxonomy for biological classification
may be considered a special case of a
controlled environmental vocabulary where
species names are arranged within a larger
system of hierarchical rank (kingdom, class,
order, family) (Figure 14). They are
nevertheless identified as a specific
information class due to their fundamental
importance for biodiversity information.
Figure 14: Example of hierarchical species taxonomy for Acacia species [Integrated Taxonomic
Information System, 2014; last accessed 30/04/2014]
Page 25
NEII Reference Architecture
5.3 Information dynamics
The static information classes described above
define the key dimensions along which NEII
functionality is constructed. They provide a
structuring world view for environmental
information which creates a foundation for the
dynamic operation of the infrastructure (the form
behind NEII function). At the same time, there
are dynamic aspects of information flow that are
enabled through the NEII components, for
example, federation of discovery metadata, data
querying and retrieval and information
integration.
5.3.1 Environmental information querying
Since NEII extends the SDI pattern, the search
patterns enabled by conventional metadata
catalogues are explicitly supported, for example
the ability to discover individual discrete
datasets, data series or services. This enables
filtering by keyword, dataset geographic extent,
or topic category. The granularity supported
through this mechanism is constrained to that
imposed by data providers in populating
metadata records; discoverability is limited to
those defined datasets or services explicitly
described by a provider. It does not, for
instance, support discovery of user-driven
datasets combining data across multiple
providers (e.g., all groundwater pressure data
from boreholes from five agencies).
Figure 15 illustrates a data discovery scenario
with metadata records describing individual
datasets and services.
In extending the standard SDI approach, the
NEII reference architecture enables value-added
querying by:
• environmental parameter (e.g., find all
marine salinity data);
• environmental geography (e.g., find all data
related to the Channel Country bioregion);
and
• monitoring site (e.g., find all observations
from climate monitoring stations).
Combination queries are also enabled (e.g., find
all river-level data from gauging stations in the
Murray–Darling Basin).
Figure 15: Discovery of individual datasets or services using metadata search
Page 26
NEII Reference Architecture
5.3.2 Information integration and maintenance
To support the rich environmental information
discovery and query model enabled through
NEII, there must be integration between the
information types: monitoring sites must be
associated with environmental geographies
and annotated with available environmental
parameters. Linkages are needed to related
environmental observation datasets and their
discovery metadata descriptions (including
online services and information models).
The most scalable and sustainable way to
achieve this integration is through configuring
data provider services that supply these
relationships at source. This requires:
• adopting O&M-based information models;
• establishing linkages at provider-level
between observational data, sites,
geographies, and observed parameters;
and
• configuring web services to respect and
publish these relationships.
Each condition involves significant complexity
and the full vision is many years from being
realised. The NEII reference architecture does
not rely on full realisation of this vision to
deliver value; integration may be done through
ad-hoc mechanisms (e.g., spatial analysis to
determine the relationship of monitoring sites
to environmental geographies). The trade-off is
with sustainability as ad-hoc mechanisms are
difficult to maintain. The NEII reference
architecture strikes a balance by enabling
initial value in the absence of mature
implementation, but also encouraging greater
maturity to enhance sustainability of the
infrastructure.
Dataset metadata have a key role within an
enhanced SDI architecture. Registers of
monitoring sites, networks, environmental
geographies, environmental parameters, etc.
(each with a unique identifier) will enable
relationships to be asserted through the
metadata records—even in the absence of fully
deployed O&M-based information models and
web services. For instance, a dataset
description could include lists of monitoring
sites, environmental parameters, and
environmental geographies with which it is
associated. This may easily be done through
defined keyword lists for these information
classes (Figure 16).
5.3.3 Metadata federation or harvesting
The standard SDI discovery scenario is implemented across the infrastructure by federating discovery metadata. Through use of standard protocols, metadata from one data provider may be aggregated with that from another provider into a central metadata catalogue enabling searching for datasets across all contributing providers.
Figure 16: Metadata containing keywords for geography, site, and parameters [based on ISO 19115]
Page 27
NEII Reference Architecture
Table 4 below lists the core computational
interfaces adopted by the National
Environmental Information Infrastructure (NEII).
6.1 Catalogue Service for the Web
Catalogue services enable searching over
collections of descriptive information (metadata)
for datasets and services. These collections
contain metadata records with attributes such
as: title, abstract, point of contact, geographic
extent, and keywords. All these attributes may
be subject to search through the catalogue
service, with result sets returned for human
display or further machine processing. Where a
dataset is available through an online service, a
reference to the online service (URL) may be
included in its descriptive metadata, enabling a
user to access the service directly after
discovery.
The OGC Catalogue Service for the Web (CSW)
is adopted as the NEII standard metadata
search interface. It supports metadata federation
and components that implement the interface
may harvest metadata from each other. For
further detail, see OGC 07-006r1.
Table 4: National Environmental Information Infrastructure computational interfaces
Interface name
Standard Mandatory methods Optional methods Description
Catalogue Service for the Web (CSW)
OGC 07-006r1
(CSW v2.0.2)
GetCapabilities
DescribeRecord
GetRecords
GetRecordById
GetDomain
Transaction
Harvest
for searching over collections of descriptive standardised discovery metadata.
Web Feature Service (WFS)
OGC 09-025r1 (WFS 2.0)
GetCapabilities DescribeFeatureType GetFeature
GetGmlObject Transaction LockFeature
for filtering and retrieving data from information providers
Sensor Observation Service (SOS)
OGC 12-006 (SOS 2.0)
GetCapabilities DescribeSensor GetObservation
RegisterSensor InsertObservation GetObservationById GetResult GetFeatureOfInterest GetFeatureOfInterestTime DescribeFeatureType DescribeObservationType DescribeResultModel
for retrieving observation data, especially time-series
Web Map Service
OGC 06-042 (WMS 1.3.0)
GetCapabilities GetMap
GetFeatureInfo for requesting rendered maps of datasets
SISSVoc SISSVoc 3.0 resource conceptscheme collection concept
for accessing standard vocabularies and terms
6 Computational viewpoint
Page 28
NEII Reference Architecture
The core operations defined are:
• GetCapabilities: Returns descriptive
information (service metadata) about the
specific metadata catalogue being queried.
The response includes information on:
o identification information for the
service (CSW version supported,
title, access constraints, etc.);
o service provider (including name
and contact person);
o operations metadata (supported
operations and required
parameters); and
o filter capabilities (the filtering
operations supported for metadata
search—logical, spatial, comparison
operators).
• DescribeRecord: Describes the schema
structure of metadata records supported by
the catalogue; for NEII this is a profile of ISO
19115.
• GetRecords: The core search operation;
retrieves metadata records matching a
selection filter specified in the request.
Filtering is performed against the supported
record schema using the advertised filtering
capabilities and typically constraints (logical,
spatial, comparison) may be specified
against individual schema elements. The
result set may be returned complete, or
passed through a projection process
returning a reduced set of schema elements
for each record (e.g., brief, summary, or full
records may be returned).
• GetRecordById: Similar to GetRecords, but
returns only specific records requested by
their identifiers (rather than a full filter-based
search).
6.2 Web Feature Service
The ‘General Feature Model’ has been adopted
by the standards bodies ISO TC211 and OGC
as an abstract foundation to their standards
programmes. This model regards any real-world
information object (or feature) as having identity,
a type, attributes, and associations with other
objects. Feature types may derive from one
another (by extension or restriction). The
General Feature Model is essentially an object-
based meta-model for real-world information
entities. The Web Feature Service (WFS), then,
acts as a general query interface against an
opaque feature store (or database of information
objects). It may be applied for any environmental
information type for which an information model
is defined.
The OGC standard WFS is therefore adopted by
NEII as the core general data querying and
retrieval interface. Full details are available in
OGC 09-025r1.
The core operations defined are:
• GetCapabilities: Returns descriptive
information (service metadata) about the
specific feature service being queried. The
response includes information on:
o Identification information for the
service (WFS version supported,
title, access constraints);
o service provider (including service
provider name and contact person);
o operations metadata (supported
operations and required
parameters);
o feature types (a list of the feature
types available from the service);
and
o filter capabilities (the filtering
operations supported for feature
querying logical, spatial, arithmetic,
comparison operators).
• DescribeFeatureType: Describes the
schema structure of feature types available
from the service.
• GetFeature: The core query operation;
retrieves features (information objects) from
the feature store (database) based on
matching against filter parameters specified
in the request. At minimum a specific named
Page 29
NEII Reference Architecture
feature type must be requested; however
WFS supports very rich filtering capabilities,
described in OGC 09-026r1. Both selection
(matching features to return based on
specified filter constraints) and projection
(choosing which information elements of
matching features to include in the
response) are supported.
6.3 Sensor Observation Service
The ISO 19156:2011 Observations and
Measurements (O&M) model defines a general
conceptual model for the observation process,
applicable across the full range of observation
types. It is one of a family of sensor web
standards developed by OGC and ISO TC211.
O&M follows the General Feature Model,
modelling observations as features. Therefore
the WFS interface may be used, in principle, for
accessing observation data. There are,
however, benefits to adopting a specialised
interface specifically for the special case of
observational data:
• client queries are simpler to construct;
• time-series observations may be handled in
a more straightforward manner.
The Sensor Observation Service (SOS) enables
specialised queries aligned with the O&M model
for observational data sources that conform to it.
Observations are grouped together within a
service into observation offerings—collections of
observations over a specified time period
(historical or real-time) with a shared set of
observing procedures, observed properties, and
features subject to observation. A user may
reasonably expect observations to be dense
within the parameter space of a given offering;
that is, most combinations of procedure,
observed property, feature-of-interest, and time
period should provide available observations.
This heuristic provides useful guidance in
configuring observation offerings within a
service.
The adoption of the SOS interface in NEII is
limited to querying observational time-series
data. It may be adopted for observation data
more generally as available implementations
mature. The interface is described in detail in
OGC 12-006.
The core operations defined are:
• GetCapabilities: Returns descriptive
information (service metadata) about the
specific observation service being queried.
The response includes information on:
o identification information for the
service (SOS version supported,
title, access constraints);
o service provider (including name
and contact person);
o filter capabilities (the filtering
operations supported for
observation querying and logical,
spatial, arithmetic, comparison
operators); and
o contents (a list of observation
offerings available from the service).
• DescribeSensor: Provides a description of
specific observing procedures (sensors or
sensor systems), generally using SensorML
for the response.
• GetObservation: The core observation
request operation; retrieves observations
from a specific observation offering
according to request parameters. The
operation allows filtering against the O&M
model by specifying one or more required
observed properties, and optionally
observation times (or time periods),
observation procedures, and features-of-
interest. The response contains matching
observations encoded with the O&M
schema [OGC 10-025r1] (or a derivation, for
observation models based on O&M).
6.4 Web Map Service
A user does not always require direct access to
environmental data itself, but may instead prefer
a rendered map of the data. The Web Map
Service (WMS) interface supports this, returning
Page 30
NEII Reference Architecture
a rendered portrayal over some geographic
region of an information layer (typically a specific
feature type). The rendered map is constructed
following the request parameters—with a
specific coordinate reference system or map
projection, rendering style, and image format
and size.
NEII adopts the OGC WMS interface for
requesting mapped environmental information.
Full details are described in OGC 06-042.
The core operations defined are:
• GetCapabilities: Returns descriptive
information (service metadata) about the
specific map service being queried. The
response includes information on:
o identification information for the
service (WMS version supported,
title and access constraints);
o service provider (including name
and contact person);
o operations metadata (supported
operations and required
parameters); and
o map layers (descriptions of all layers
available; including name, title,
available styles, geographic
bounding box, and supported output
format).
• GetMap: A rendered map is returned in
response to this request. The request must
include required layers and styles,
coordinate reference system, geographic
bounding box, width, height, and format of
returned image file.
6.5 SISSVoc (Vocabulary Service)
Standardised vocabularies (e.g., for marine
environmental parameters, soil types, lithology,
species names) are a cornerstone for enabling
interoperable environmental information
exchange (i.e., where the information is able to
be understood and used). In order to adopt
standardised vocabulary terms, they must be
defined, governed, and able to be referenced.
The SISSVoc interface enables vocabularies
and terms to be resolved and their definitions
retrieved. Vocabularies, their terms and term
definitions are structured following the W3C
standard Simple Knowledge Organisation
System (SKOS). This supports the construction
of both hierarchical terms (SKOS concepts) and
simple code lists of terms (SKOS collections),
and aggregated into named vocabularies (SKOS
concept schemes). All items (vocabularies, code
lists, terms) are identified by a uniform resource
identifier (URI), have a text-based label and may
have a description.
NEII adopts SISSVoc 3.0 as a vocabulary
resolution interface. While SISSVoc offers a
general API to the full SKOS data model, we are
concerned here with simple vocabularies of
codelists and terms. SISSVoc continues to be
developed, with future support for publishing
information models in addition to vocabularies.
The core SISSVoc operations are used as
follows for the NEII Vocabulary Service:
• conceptscheme: Returns a list of all
available concept schemes (i.e.
vocabularies) known by the vocabulary
service.
• collection: Returns a list of all available
concept collections (e.g., code lists) within a
vocabulary.
• concept: Returns a list of all vocabulary
concepts (vocabulary terms), or of those
broader or narrower in meaning to a specific
concept within a hierarchy. Concepts are
referenced by their URI identifier, but may
also be specified by matching against their
text-based labels.
• resource: Returns a description of a
specific vocabulary term (or other item)
referenced by URI identifier.
Page 31
NEII Reference Architecture
Environmental information resources in the National Environmental Information Infrastructure (NEII) are federated across nodes, geography, and organisations. This federated approach is achieved by defining specific architectural components that may be deployed across nodes and which ensure the proper functioning of the infrastructure as a whole.
Table 5 lists and describes these components.
While the conventional spatial data infrastructure
(SDI) architecture requires catalogue (NEICat)
and data service (NEIServ) components, the
architectural extension providing environment-
specific value-added capability within NEII is
provided through the components for monitoring
sites (NEMSR), environmental parameters
(NEVS), and observing methods (NEOMR). In
addition, the explorer (NEIExp) component is
required in order to achieve advanced
functionality, even without full maturity of
component implementation and deployment by
providers.
Table 5: National Environmental Information Infrastructure components
Name Short name Description
National Environmental Information Catalogue
NEICat Maintains a repository of dataset and service descriptive metadata, and provides user searching functionality and metadata federation with peer catalogues.
This component provides the key ‘discovery’ capability within a conventional SDI architecture.
National Environmental Monitoring Sites Register
NEMSR A register of national environmental monitoring sites, including limited site metadata (e.g., site type, location, owner, sensitivity). Enables site information to be managed and referenced in a uniform manner.
National Environmental Information Service
NEIServ A component providing network web service access to environmental information sources.
This component provides the core ‘data access’ functionality within NEII.
National Environmental Vocabulary Service
NEVS Standardised vocabularies are published and accessed through this component; these are essential for achieving interoperability within the system. This component provides ‘master data management’ for the federated infrastructure.
National Environmental Observing Methods Register
NEOMR A register of environmental observing methods, protocols, and procedures. Provides standardisation within the infrastructure of information concerning the environmental data collection method.
National Environmental Information Explorer
NEIExp This component provides the integration within NEII —between environmental information sources, services, and components. It provides a rich ‘portal’ interface enabling discovery of and access to environmental information.
7 Engineering viewpoint
Page 32
NEII Reference Architecture
7.1 National Environmental Information Catalogue (NEICat)
The NEICat component manages the storage,
searching, and federation of discovery metadata
for datasets and information services within
NEII. It may be deployed wherever there is a
need to manage or publish metadata. Metadata
storage and federation are independent
metadata management functions and a
catalogue may be deployed to store local
metadata records, or to provide harvesting and
aggregation from other catalogues, or it may
perform both of these functions simultaneously.
In all cases, the records held are available for
search by user applications. Figure 17 illustrates
the communications and information flows with
the NEICat component.
The catalogue component is employed in the
use case for data discovery under the
conventional SDI architecture, and is so here for
NEII. (As discussed elsewhere, however, the
value of this scenario is limited by the granularity
with which metadata records are constructed
and additional value-added information
discovery capability is provided by the National
Environmental Information Explorer component)
Where multiple catalogue components are
deployed within the infrastructure, they may be
configured to federate and harvest metadata
from one another as required. The Bureau will
maintain a central master catalogue for NEII,
providing a single primary entry point to discover
national environmental datasets and services.
This does not reduce the value of additional
harvesting catalogues targeted to specific
applications, domains, and/or providers.
Figure 17: Communication flows between National Environmental Information Catalogue
components
Page 33
NEII Reference Architecture
7.2 National Environmental Monitoring Sites Register (NEMSR)
Environmental monitoring sites are a
fundamental dimension of environmental
information (e.g., for structuring discovery,
access, and use) across almost all domains of
environmental activity. There are several
benefits to maintaining explicit registers of
monitoring sites, including the facilitation of:
• high-level analysis of the overall national
environmental monitoring portfolio;
• uniform site-based discovery and access to
observation data; and
• standardised site metadata across multiple
environmental domains within the
infrastructure.
The NEMSR component is dedicated to
managing site information within NEII. In a fully
mature infrastructure (with O&M-based
information models widely adopted and
deployed), monitoring site information may be
queried dynamically directly through provider
information services. In this case, the role of
NEMSR may be no more than a strong forward
cache of site information (i.e., maintained
externally or forwarded from data providers, but
with strong consistency to source); it will provide
important performance benefits and perhaps a
standardisation of site information, but no
fundamentally novel functionality. In the absence
of fully-developed information services,
however, the component plays a critical role for
integration of data services with sites.
Figure 18 shows the two means of populating
NEMSR and its use by NEI Explorer. For
information services providing access to site
information through O&M-based information
models, an automated process may be used to
ingest site metadata into NEMSR. In other
cases, ad-hoc processes are required to obtain
site metadata, usually directly from data
providers. Once populated, NEMSR may be
used by NEI Explorer to provide site-based
discovery and configure links to associated
information services. A conceptual data model
for the NEMSR is provided in Figure 19.
Page 34
NEII Reference Architecture
Figure 18: Mechanisms for populating the National Environmental Monitoring Sites Register
Figure 19: National Environmental Monitoring Sites Register high-level conceptual model
Page 35
NEII Reference Architecture
7.3 National Environmental Information Service (NEIServ)
Beyond data discovery, NEII provides real value
to users and applications by providing direct
access to environmental information sources. In
order to achieve this with any benefit beyond
existing ad-hoc data access mechanisms
(usually non-standard and provider-specific), a
standardised access mechanism must be
provided to users. The NEI Service component
provides uniform and standards-based data
query and retrieval functionality, and may be
deployed by data or (on their behalf) service
providers. It initially provides access to the
following NEII information types:
• environmental observations;
• environmental geographies; and
• gridded representation of remote sensing,
numerical simulations and model data.
Figure 20 illustrates access by users to
observation and environmental geography data
through the information service component.
The National Environment Information Service
(NEIServ) component provides dynamic access
to environmental observations, together with a
complex filtering and querying capability,
depending on the underlying information model.
Likewise, environmental geography data may be
retrieved through rich filtering queries. Gridded
data may be accessed by sub-setting along its
dimensions. Entire environmental datasets need
not be downloaded, but rather queries may be
formulated for just those data of interest. Where
possible, the information service may also
provide access to rendered portrayal of data, for
example, maps rather than data themselves.
Figure 20: Accessing observation and geographic data through the National Environment
Information Service
Page 36
NEII Reference Architecture
7.4 National Environmental Vocabulary Service (NEVS)
Information interoperability is dependent on
common understanding and interpretation of
data exchanged, for example, ensuring that
water quality data providers adopt common
terminology for chemical species and pollutants.
This in turn requires the adoption of
standardised vocabularies within NEII. Even
where only a single provider is responsible for a
given environmental domain (with no need for
harmonisation across multiple providers),
adoption of standardised terms is needed to
enable users to accurately interpret published
data.
Generally, there is a separation between
governance of terminology and vocabularies,
and provision of infrastructure for publishing and
using agreed standard terms. A ‘domain
authority’ may regulate standard terms and
definitions for a specific environmental domain,
while not having the technical capacity to publish
those standards. In practice, standard
vocabularies are often published in physical
books, or opaque electronic documents (e.g.,
PDF). Even where more machine-readable
formats are used (e.g., CSV), there is no
standardisation of structure across different
domains. This leads to difficulty within
integrating infrastructures like NEII.
The National Environmental Vocabulary Service
(NEVS) provides a uniform mechanism within
NEII for publishing standardised vocabularies. It
supports the ability to:
• query available vocabularies and terms; and
• identify and navigate hierarchies of terms
(e.g., land-use classifications).
Figure 20 shows the role of the vocabulary
service in supporting configuration of information
services and the NEI Explorer. While there are
many examples of standard vocabularies
required within NEII, this diagram illustrates a
typical scenario of vocabularies associated with
standard information models. Environmental
parameters and species taxonomies are
concrete examples of vocabularies that may be
published through a vocabulary service. The
vocabulary service will eventually support
publishing of full information models, not only
vocabularies (e.g., code lists) associated with
them.
Page 37
NEII Reference Architecture
Figure 21: Use of the National Environmental Vocabulary Service by the National
Environmental Information Service and within the National Environmental Information Explorer
Page 38
NEII Reference Architecture
7.5 National Environmental Observing Methods Register (NEOMR)
Observing methods are a fundamental
information type within NEII and provide an
important interpretive context for environmental
observation datasets—especially for ecological
data where the sampling/survey method is
critical for evaluating the data’s fitness-for-
purpose. Within the physical environmental
sciences, it is often very useful to know the
broad instrument type or analysis method used
to make a measurement.
The National Environmental Observing Methods
Register (NEOMR) will manage information
related to the procedure used to collect/generate
data, for example:
• field/human observing protocols;
• instrument classes and types; and
• lab/computer analytical methods.
By establishing an online electronic register of
observing methods (survey protocols, instrument
types, analysis methods), datasets may be
cross-referenced to provide unambiguous
contextual information about the procedure used
to obtain the data. Conversely, for discovery,
available data may be filtered by the observing
method of interest.
The design of the NEOMR is subject to further
analysis and currently scheduled for future
development. It will require a hierarchical
taxonomy or ontology of environmental
observing procedures, monitoring protocols, and
analytical methods.
Examples of existing methods registries and/or
their use for search in different domains are
listed below. NEOMR will catalogue and present
such information in a unified manner.
• US National Environmental Methods Index:
www.nemi.gov
• The CEOS Catalogue of Satellite
Instruments:
database.eohandbook.com/database/instru
menttable.aspx
• NASA Global Change Master Directory
index of datasets by instrument:
gcmd.nasa.gov/KeywordSearch/Keywords.d
o?Portal=GCMD&MetadataType&KeywordP
ath=Instruments
• UK Environmental Change Network
protocols for terrestrial and freshwater
observations:
www.ecn.ac.uk/measurements
• Environment Canada Ecological Monitoring
Protocols: www.ec.gc.ca/faunescience-
wildlifescience/default.asp?n=E19163B6-
1#Ecologicalmonitoringprotocols
• NSW Environment and Heritage Field
survey methods:
www.environment.nsw.gov.au/threatenedsp
ecies/surveymethodsfauna.htm
• SeaDataNet (largest pan-European marine
data infrastructure) supporting data search
by instrument type:
seadatanet.maris2.nl/v_cdi_v3/browse_step.
asp
• ACLEP Guidelines for Surveying Soil and
Land Resources (‘Blue Book’):
www.publish.csiro.au/nid/22/pid/5650.htm
Page 39
NEII Reference Architecture
7.6 National Environmental Information Explorer (NEIExp)
A basic premise of the SDI architecture on
which NEII is founded is that it implements a
federated deployment model. Thus there is
minimal requirement for a centralised
coordinating infrastructure. In principle the
infrastructure is scalable to easily support
integration of new providers and to support
novel value-added applications. While a
primary user-centred portal is often provided
as a visible entry point to the infrastructure, this
by no means prevents the construction of other
portals or user interfaces. Since the federated
components implement web-service based
interfaces, it is possible to integrate their
functionality within other applications and
services.
On the other hand, this model assumes a high
level of implementation maturity by providers.
For instance, the ability to access integrated
observation data of a particular type across
multiple providers requires them all to have
deployed standardised information services
conforming to rich information models and
supporting complex user-filtering requests.
Consider the following user scenario:
Obtain all streamflow measurements from
gauging stations in the Murray–Darling Basin
between 2010 and 2012.
In a fully mature infrastructure this might
proceed as follows:
1. Query metadata catalogue for services
providing streamflow observation data
2. For each discovered service, request
observations between 2010 and 2012
where:
• the observation procedure is a ‘streamflow
gauge’;
• the observed property is ‘streamflow’; and
• the monitoring point explicitly samples
(through its ‘sampled feature’ property) the
Murray–Darling Basin), or is located within
a user-supplied polygon boundary for the
Murray–Darling Basin.
A lot of machinery needs to be in place for this
to work: an O&M-based information model
must be adopted, services must be configured
with appropriate monitoring site metadata and
relationships to relevant geographies, and
standard vocabularies must be agreed and
adopted for environmental parameters and
observation procedures. While this level of
maturity is the ultimate goal of NEII, ad-hoc
mechanisms for configuring these relationships
are necessary to realise value in the interim.
7.6.1 Integration index
The NEI Explorer provides sophisticated
faceted browse capability, allowing users to
navigate the broad spectrum of available
environmental information by successively
refining a selection along dimensions of, for
example:
• monitoring site type and/or location;
• environmental parameter; and
• associated environmental geography.
To implement this, a logical integration index
table is created within the National
Environmental Information Explorer (NEIExp),
enabling ad-hoc associations to be established
between monitoring sites, environmental
geographies, environmental parameters, and
information services (see Figure 22).
This enables the advanced faceted search and
discovery capability within NEII even in the
absence of fully-implemented complex O&M-
based information models. Even in the case of
mature (and fully-deployed) information
models, there are major performance benefits
to caching these relationships within the
National Environmental Information Explorer.
The main (and major) challenge is populating
the integration index and generally this must
proceed on an ad-hoc basis, and is agency or
implementation specific. It should be noted that
such ad-hoc integration is not required for the
Page 40
NEII Reference Architecture
infrastructure to function and by default the
conventional SDI pattern still applies:
searching on discovery metadata for individual
services which may be queried according to
their respective information models.
As well as performing an integration function,
the NEI Explorer provides a user portal for
interacting with the infrastructure. This enables
value-added capability, like data requests to
information services by proxy and reformatting
the response (e.g., to simple CSV or other
formats). Figure 23 shows an example
interaction sequence involving the integration
index for an initial search, together with data
request by proxy and reformatting by the
information explorer.
Figure 22: NEIExp 'integration index' for advanced functionality and performance
Page 41
NEII Reference Architecture
Figure 23: NEIExp interaction with 'integration index'
In summary, the following functionality is
provided by the NEI Explorer:
• a primary entry point to NEII for end users;
• integration of information services with
associated monitoring sites, environmental
geographies, and environmental
parameters;
• rich ‘faceted browse’ of available
environmental information; and
• value-added requests by proxy to
information services on behalf of the user
(including, for instance, reformatting of
data and aggregating responses from
multiple providers).
Page 42
NEII Reference Architecture
Much of the design of the National
Environmental Information Infrastructure (NEII)
reference architecture is informed by pragmatic
decisions on available technology. Since the
infrastructure needs to be deployed by a
number of participating service providers, it is
desirable to identify a low-cost ‘reference
implementation’ software stack.
8.1 Geospatial standards
The technology solution must provide tested
implementations of the adopted geospatial
standards, as listed in Table 6.
Table 6: National Environmental Information Infrastructure geospatial standards
ID Name Description Standard Date
CSW Catalogue Service for the Web
discovery metadata search OGC 07-006r1
(CSW v2.0.2)
2007-02-23
WFS Web Feature Service access to stores of feature-based data
OGC 09-025r1
(WFS 2.0)
2010-11-02
WMS Web Map Service access to rendered maps of data
OGC 06-042
(WMS 1.3.0)
2006-03-15
SOS Sensor Observation Service
access to time series observation data
OGC 12-006
(SOS 2.0)
2012-04-20
8 Technology viewpoint
Page 43
NEII Reference Architecture
8.2 Spatial Information Services Stack
The Spatial Information Services Stack (SISS)
is a suite of open-source software developed
and integrated by CSIRO, based on existing
proven tools, but enhancing and extending
them with additional components where
necessary. Engineering hardening and
integration has been applied by CSIRO to the
suite as a whole. SISS is adopted as a
reference implementation software stack for
implementing NEII components. The main
SISS components are listed in Table 7.
Table 7: Spatial Information Services Stack technology components
Component Description Notes
THREDDS gridded data delivery service
• Sourced from Unidata (USA):
www.unidata.ucar.edu/projects/THREDDS
• Implements OPeNDAP, WCS and WMS interfaces over
netCDF files.
FullMoon* UML-to-GML schema conversion tool, for information model development
• Developed by CSIRO.
GeoNetwork metadata catalogue • Sourced from open-source project:
geonetwork-opensource.org
• Implements CSW interface.
SISSVoc vocabulary publishing service
• Developed by CSIRO.
Geoserver data access service • Sourced from open-source project:
geoserver.org
• Implements WFS, WMS, WCS interfaces.
• CSIRO enhancements for application-schema support
integrated into trunk.
52North Sensor Observation Service
• Implements SOS interface: 52north.org
• Currently being enhanced by CSIRO for application
schema support including WaterML2.
• Not yet integrated officially within the SISS distribution.
• The Bureau of Meteorology developed engineering
improvements now incorporated into release version.
* Any tool that supports the standardised UML-to-GML encoding rules may be substituted; e.g., ShapeChange (shapechange.net) or Enterprise Architect
Page 44
NEII Reference Architecture
The RM-ODP architecture framework provides
complementary viewpoints of a system
architecture. It is important to describe
correspondences between the viewpoints to
ensure consistency. For the National
Environmental Information Infrastructure (NEII)
reference architecture, there is strong
alignment between the various viewpoints as a
result of adopting O&M to inform the
architectural foundation. In particular there is
an almost direct correspondence between the
information types and engineering
components.
9.1 Information—computational consistency
Table 8 shows a matrix of the NEII information
types against computational interfaces that
operate on them.
9.2 Engineering—computational consistency
Figure 24 illustrates the computational
interfaces implemented by the engineering
components within NEII.
Table 8: National Environmental Information Infrastructure computational interfaces and
information types
Information types CSW WFS SOS WMS SISSVoc
metadata ✔
observational data ✔ ✔
information models ✔
environmental parameters ✔
sites/networks ✔ ✔
gridded data ✔
geographies ✔ ✔
observing methods ✔
species taxonomies ✔
9 Viewpoint correspondences
Page 47
NEII Reference Architecture
Figure 24: National Environmental Information Infrastructure components and computational
interface
Page 48
NEII Reference Architecture
9.3 Technology—engineering consistency
Table 9 lists open source technology
components that realise each of the
engineering components.
Table 9: Technologies realising National Environmental Information Infrastructure component
Engineering component Technologies used
NEICat SISS GeoNetwork
NEMSR SISS GeoServer
Postgres
NEIServ for environmental geographies:
SISS GeoServer
Postgres or other relational database
for environmental observation time-series:
52North SOS
Postgres database configured with 52North schema
NEVS SISSVoc v3.0
NEOMR SISSVoc v3.0
NEIExp Postgres
OpenLayers
ExtJS & GeoExt
SISS Geoserver
Page 49
NEII Reference Architecture
10 Acknowledgements
The development of the National Environmental Information Infrastructure (NEII) reference
architecture was achieved through the active contribution of many agencies and individuals. We are
particularly grateful to our colleagues in CSIRO and Geoscience Australia who helped shape key
components of the architecture, our colleagues in the Department of the Environment’s ERIN Branch
for their ongoing guidance around strategic elements of the NEII, and to those who actively
contributed to the consultation process in our forums and through the provision of feedback on earlier
drafts of the architecture.
The technical implementation of the NEII that informed the reference architecture was enabled through
the professionalism and dedication of many staff within the Bureau’s Information Systems and
Services Division. Core components of the NEII reference architecture were also informed by the
earlier efforts of national informatics initiatives, particularly the Australian Government’s National
Collaborative Research Infrastructure Strategy. We are grateful for the sound foundation that these
activities have provided to the NEII.
The ongoing support provided by the members of the Australian Government’s Environmental
Information Advisory Group to the NEII and our team has been invaluable. Finally, the development
of the NEII was made possible by the vision and resources provided by the Australian Government’s
National Plan for Environmental Information initiative.
Page 50
NEII Reference Architecture
11 Glossary: Abbreviations and terms
Term Description
access constraint any restrictions that apply to data, whether for legal, privacy, intellectual property, or other reasons
accounting in relation to information security, the tracking of use of a data service
AGIMO Australian Government Information Management Office
analytical procedure a process of analysis through which environmental information is produced (e.g., a computer or laboratory procedure)
API A software application that specifies how some IT components should interact with each other
application schema a domain-specific information model encapsulated in a standards-based encoding format
architectural pattern a re-usable set of data, application, or technology designs providing an integrated functionality
architecture a formal description of a system which may include structure and relationship of components, and principles or guidelines governing their design
architecture principles a statement of intent that should be met by an architecture
architecture viewpoint a selected, but limited, perspective from which an architecture may be viewed or presented
assimilation integration of observational data with a numerical model to analyse or forecast the state of an environmental system
AusGOAL Australian Governments Open Access and Licensing Framework
Australian Hydrological Geospatial Fabric
a dataset published by the Bureau of Meteorology containing hydrological domain features such as rivers, water bodies, aquifers, and monitoring points
authentication in relation to information security, the verification of the identity of a user
authorisation in relation to information security, the granting of permission to an authenticated user to perform a specific activity
Bureau Bureau of Meteorology
cache a component that stores a duplicate copy of data for more efficient access
classification scheme a hierarchical arrangement of material or other objects based on common properties
community of practice an identifiable group with a shared interest in, and understanding, of a certain information type
comparison operator a function that may be applied in a data querying filter, based on mathematical comparison
Page 51
NEII Reference Architecture
component a discrete encapsulation of functionality within a specific deployed system or on a technology element
computational viewpoint
an architecture viewpoint describing a system based on functional interfaces
concept a fundamental unit of meaning, or abstract conceptual entity, to which a label and definition may be applied
conceptual model see information model
configuration a concrete deployment of architectural components and data comprising a functioning system
configuration management
a systematic framework for managing the controlled configuration of a system, including change control, versioning, etc.
coordinating authority within the National Environmental Information Infrastructure a role responsible for coordinating the development, deployment, and operation of the infrastructure, including any centralised components necessary for the proper functioning of the information platform
correlation joint analysis of multi-source datasets to identify relationships and for hypothesis development and testing
Creative Commons by Attribution (CC-BY)
a set of standardised copyright licences for granting permission to use and access data and other works to: share—copy and redistribute the material in any medium or format; adapt—remix, transform and build upon the material for any purpose, even commercially
CSIRO Commonwealth Scientific and Industrial Research Organisation
CSML Climate Science Modelling Language, a standards-based information model for encoding climate, atmospheric and oceanographic data in terms of geometry-based observation classes such as Points, Profiles, Trajectories and Grids
CSW Catalogue Service for the Web
data access the process of querying and retrieving data through machine interfaces for automated processing, visualisation, integration, etc.
data discovery the process of identifying machine-accessible fit-for-purpose datasets through a search process
data model see information model
data provider the supplier of a dataset to be made available for data discovery and data access through the infrastructure
data querying the process of requesting a subset of a dataset based upon user-specified filter criteria
database a dataset stored in a persistent digital format suitable for data querying through appropriate data management software
dataset an identifiable collection of data
dataset metadata data describing a dataset (e.g., identification/citation information, data quality, content description, availability, licensing constraints)
delivery channel a physical network and digital protocol through which a dataset may be accessed
deployment architecture
physical configuration of components on specific computing nodes at specific geographic locations
Page 52
NEII Reference Architecture
differentiated service a service whose functionality varies with the identity or role class of the user
discovery metadata metadata describing essential aspects of a dataset or service, to facilitate discovery through search; usually conforming to ISO 19115
domain a field of study or learning associated with a specific community of practice; a discipline area
domain authority a point of authority for controlled terms and concepts agreed explicitly or implicitly for shared use within a domain
domain feature a real-world object class (e.g., 'bird', 'river', 'building', 'road') whose characteristics are well-known and agreed within a domain
engineering component
see component
engineering viewpoint an architecture viewpoint focusing on the system infrastructure and federated deployment architecture
enterprise viewpoint an architecture viewpoint focusing on the purpose, scope, and policies of a system
environmental geography
a geographic domain feature providing context to environmental observations (e.g., catchment, bioregion, habitat)
environmental intelligence
conclusions drawn from environmental observations and models for decision-making
environmental observation
the act of measuring or observing an environmental parameter using a defined procedure and generating a result
environmental parameter
a property of an environmental object (e.g., an environmental geography or domain feature) that may be subject to observation or measurement
exchange format a digital data format defined for the purpose of information exchange between systems or components
explorer a web-based software application providing an interactive user interface for data discovery and data access
ExtJS a software application framework for building interactive web applications
faceted browse a paradigm for data discovery based on filtering along multiple dimensions within a faceted classification system; distinct from a hierarchical navigation or direct text search
feature an abstraction of a real-world phenomenon—usually a type of domain feature, or a specific instance
feature store a logical database containing a set of feature instances
feature-of-interest a feature (normally an environmental geography or other domain feature) upon which environmental observations are made
federated of an information platform, where the components are deployed at multiple geographic locations and on different computational nodes
federation logical or physical aggregation of (meta) data harvested from multiple federated data providers
field survey an observing method involving a human observer applying a standardised observing protocol at a specific field location
filter a constraint that may be applied during dataset querying to restrict the returned
Page 53
NEII Reference Architecture
result set
filtering the act of applying a filter during a data querying operation
GCMD Global Change Master Directory
GeoConnections the Canadian spatial data infrastructure (formerly 'Canadian Geospatial Data Infrastructure')
GeoExt a software framework for developing geospatial web applications, building on ExtJS and OpenLayers
Geofabric see Australian Hydrological Geospatial Fabric
GeoNetwork an open-source software database for dataset metadata; implements the ISO 19115 metadata standard and CSW interface standard
GeoSciML Geoscience Markup Language, a standards-based information model for encoding information about geology, with an emphasis on mapped geological features (geologic units and structures, boreholes, earth material, etc.)
Geoserver an open-source software feature store; implements the WFS and WMS interface standards
granularity the degree of composition of a larger dataset or dataset series into smaller datasets each associated with individual dataset metadata descriptions
gridded data data discretised over a raster grid (e.g., remote-sensed imagery or numerical simulation output)
harmonisation structuring data management systems and datasets across multiple providers to ensure uniformity of storage, access, interpretation, etc.
harvest retrieval and duplication of dataset metadata records from a remote metadata catalogue for the purpose of federation
identifier a label for a feature instance, vocabulary term, monitoring site, or other information object which uniquely identifies it within some known scope
information architecture
see architecture
information class a set of information objects with sufficiently similar characteristics that they may be dealt with in a common way within a system
information model a formalised description of the logical structure and semantics of one or more information classes and their relationships; may be controlled by a domain authority
information platform a network of components, datasets, and standardised services that together provide advanced data discovery and data access functionality, and on which value-added applications may be developed
information viewpoint an architecture viewpoint focusing on the semantics of information and information processing within the system
infrastructure see information platform
ingest to load (possibly after transformation) source data into a database according to a defined schema
INSPIRE Infrastructure for Spatial Information in Europe (EC Directive 2007/2/EC)
integration the combining of multiple components or datasets to provide greater functionality or analytical insight
Page 54
NEII Reference Architecture
integration index a component in the information platform providing a database of relationships between objects from different information classes (e.g., monitoring sites, environmental geographies, observing methods)
interface see ‘web interface’ or ‘service interface’
interoperability the ability of two or more systems or components to exchange information and to use the information that has been exchanged
ISO International Organisation for Standardisation
ISO/TC 211 Geographic information/Geomatics
responsible for the ISO geographic information series of standards.
keyword well-known or standardised descriptive word used to describe a dataset within a discovery metadata record
linked-data a next-generation semantic-web-based data publishing technology, using URIs for identifiers and enabling dataset integration through explicit links represented in RDF
machine-readable a digital format suitable for automated software interpretation and processing
map layer a basic geographic information unit (often corresponding to a feature type) that may be rendered as a map by a software system or service
metadata contextual information about data; may refer to discovery metadata, service metadata, operation metadata, or site metadata
metadata catalogue a component providing a searchable repository for metadata records
metadata record a discrete metadata description, applied to a single dataset, site, service, etc.
monitoring network a collection of logically-related monitoring sites
monitoring site a geographic location where environmental monitoring is performed
NEICat National Environmental Information Catalogue
NEIExp National Environmental Information Explorer
NEIServ National Environmental Information Service
NEMSR National Environmental Monitoring Sites Register
NEOMR National Environmental Observing Methods Register
NEVS National Environmental Vocabulary Service
NPEI National Plan for Environmental Information
numerical model a software code for calculating a mathematically-complex model of a physical system (e.g., the climate system)
numerical simulation the process of executing a numerical model and the output data produced
OAIC Office of the Australian Information Commissioner
OASIS Organization for the Advancement of Structured Information Standards (international information standards body)
observation offering a set of environmental observations available for data access through a service, sharing a common set of observing procedures, observed environmental parameters, and observed features
Observations and an international standard (ISO 19156) providing a conceptual model for
Page 55
NEII Reference Architecture
Measurements (O&M) observations and measurements
observing method the mechanism used to perform an environmental observation; usually an observing protocol, instrument type, or analytical procedure
observing protocol a standardised observing procedure, usually involving a human observer and one or more observing instruments
Open Geospatial Consortium (OGC)
an international industry consortium of 471 companies, government agencies and universities participating in a consensus process to develop publicly available interface standards
Open Government Partnership
an international platform for domestic reformers committed to making their governments more open, accountable, and responsive to citizens.
OpenLayers a software framework for displaying interactive maps within a web application
operation a discrete function that may be performed by a service through an interface, usually with some flexibility based on user-supplied parameters
OSP Office of Spatial Policy, Department of Communications
portal an on-line web-based user interface
portrayal rendering of geographic features in a map layer
Postgres an open source object-relational database system
profile a modified version of an information (e.g., metadata) standard, based on extending and/or restricting a base standard
projection a filter based on restricting the elements of a matching result set that are returned
protocol a technical specification defining how to interact with a service over a network
proxy provides indirect access for a user to a service, enabling additional processing before results are returned
publish to provide access to datasets or metadata by configuring infrastructure components
QA4EO Quality Assurance Framework for Earth Observation
quality indicator a standardised measure of data quality (qualitative or quantitative) that may be included in dataset discovery metadata
rank level within a species taxonomy (species, genus, family, class, etc.)
raster a rectangular grid of data points ('pixels' in the case of raster imagery); that may be georeferenced or rectified (transformed to a geographic coordinate system)
reference architecture an architecture that describes generic, rather than a specific deployed, configuration of components
reference implementation
a software implementation of a specification, providing a benchmark for other implementations
register a system designed to hold records of information of a specific type, usually in reference to external objects
RM-ODP Reference Model for Open Distributed Processing (ISO/IEC 10746)
role a class of actor participating in a system
sampling feature a geographic feature arising as an artefact of a sampling strategy in environmental monitoring (e.g., a station, transect, profile)
Page 56
NEII Reference Architecture
schema a formalised description of the physical structure of an information object
SDI see ‘spatial data infrastructure’
security the application of technical mechanisms to protect information where necessary from unauthorised access, modification, use, etc.
selection a filter based on constraining a result set through filter criteria
semantic web a globally interlinked graph of data and information based on web protocols and the 'Resource Description Framework' (RDF) W3C standard
sensitivity property of a monitoring site restricting full and open availability of its site metadata
sensor a device for measuring a physical parameter
sensor system a hardware and software system associated with one or more related sensors
sensor web an interconnected network of sensor systems and data access services
sensorML Sensor Markup Language, an approved OGC standard for modelling and encoding sensor descriptions, including both static and dynamic platforms, and both in-situ and remote sensors
service an electronic, network-accessible system providing access to defined operations
service interface a set of one or more operations provided by a service, logically grouped together
service metadata metadata describing essential aspects of a service, to facilitate use of the interfaces provided; usually conforming to ISO 19115
service provider the supplier of a service to be made available for use through the infrastructure
SISS Spatial Information Services Stack
SISSVoc SISS Vocabulary Service defines a standard interface through which standard vocabularies can be provided to web users
site metadata metadata describing essential aspects of a monitoring site
site type the type of a monitoring site within a suitable classification scheme
SKOS Simple Knowledge Organisation System, a W3C standard for representation of thesauri, classification schemes, taxonomies, subject-heading systems, or any other type of structured controlled vocabulary
solution architecture an architecture domain concerned with the detailed description of discrete components required for a specific business operation, project, or system
SOS Sensor Observation Service
spatial analysis calculation of geospatial relationships (containment, adjacency, overlap, etc.) between geo-referenced information objects
spatial data infrastructure
a coordinated technical and organisational infrastructure supporting data discovery, data access, and use of federated geo-referenced datasets
species taxonomy a hierarchical classification of biological organisms on the basis of shared properties
standards agreed technical specifications developed by a standards body for any aspect of an information system; key standards bodies include ISO, OGC, W3C, and OASIS
Statistical Data and an initiative to foster standards for the exchange of statistical information
Page 57
NEII Reference Architecture
Metadata Exchange
style a named rendering convention that may be applied to a map layer
system deployed information technology that provides defined business functions and services
system architecture see ‘architecture’
Technology Viewpoint an architecture viewpoint focusing on technology choices to realise a system
thematic attribution the identification of standard characteristic properties of a domain feature
time-series an environmental observation type consisting of a sequence of measurements of the same environmental parameter at successive points in time
topic category a category within a broad classification of environmental domains
transect an environmental observation strategy involving a linear monitoring site, with individual observations (e.g., species counts, temperature readings) made along the path
UML Unified Modelling Language
URI identifier an identifier for a digital information object taking the form of a W3C URI (Uniform Resource Identifier)
use case a sequence of actions between an actor and a system aimed at achieving a specific business goal
user a human actor
user interface a component facilitating interaction between a user and a system
value chain a chain of activities building on one another and providing successively increasing business value
viewpoint correspondence
reconciliation between different architecture viewpoints to ensure mutual consistency
vocabulary a set of defined terms or concepts controlled by a domain authority
vocabulary term a specific term from a vocabulary
W3C World Wide Web Consortium
WaterML a standard information model for the representation of water observations data
web interface see ‘portal’
web service a service accessible through standard W3C web protocols
WFS Web Feature Service
WMS Web Map Service
Page 58
NEII Reference Architecture
Australian Government Environmental Information Advisory Group 2012, Statement of Australian
Government requirements for environmental information, Bureau of Meteorology, Canberra.
Bureau of Meteorology 2014a, Metadata record—Geofabric groundwater cartography.
www.bom.gov.au/environment/activities/search/view.shtml?id=ANZCW0503900106
Bureau of Meteorology 2014b, Metadata record—Geofabric groundwater cartography.
www.bom.gov.au/jsp/ncc/cdio/weatherData/av?p_display_type=dataDGraph&p_stn_num=065070&p_
nccObsCode=122&p_month=13&p_startYear=2014
European Parliament 2007, Directive 2007/2/EC of the European Parliament and of the Council of
14 March 2007 establishing an infrastructure for spatial information in the European Community
(INSPIRE), European Union, Brussels.
eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32007L0002:EN:NOT>
Gallagher RV, Hughes L, Leishman MR 2012, Species loss and gain in communities under future
climate change: consequences for functional diversity, Ecography, vol. 35, pp. 24–29.
ISO 2003, ISO 19115:2003, Geographic information: metadata, ISO, Geneva, Switzerland.
ISO 2005, ISO 19109:2005, Geographic information: rules for application schema, ISO, Geneva,
Switzerland.
ISO 2011, ISO 19156:2011, Geographic information: observations and measurements, ISO, Geneva,
Switzerland.
ISO 2013, ISO 19157:2013, Geographic information: data quality, ISO, Geneva, Switzerland.
Integrated Taxonomic Information System 2014, Taxonomic hierarchy for Acacia species ITIS report,
www.itis.gov/servlet/SingleRpt/SingleRpt?search_topic=TSN&search_value=26417
Open Geospatial Consortium 2004, Filter encoding implementation specification OpenGIS standard
09-026r1, www.opengeospatial.org/standards/filter
Open Geospatial Consortium 2005, Web feature service implementation specification, OpenGIS
standard 09-025r1, www.opengeospatial.org/standards/wfs
Open Geospatial Consortium 2005, Web map server implementation specification, OpenGIS standard
06-042, www.opengeospatial.org/standards/wms
Open Geospatial Consortium 2006, Sensor observation service, OpenGIS standard 12-006,
www.opengeospatial.org/standards/sos
Open Geospatial Consortium 2007, Catalogue services specification, OpenGIS standard 07-006r1,
www.opengeospatial.org/standards/wfs
Open Geospatial Consortium 2010, Observations and measurements—XML implementation,
OpenGIS standard 10-025r1, www.opengeospatial.org/standards/om
12 References
www.bom.gov.au/environment