eReefs Information Architecture Documentation

Last modified by Terrell, Linda (IM&T, Waite Campus) on Jun 20, 2017

eReefs Architecture

Table of Contents

  1. Overview
  2. Enterprise Viewpoint
  3. Information Viewpoint
  4. Computational Viewpoint
  5. Engineering Viewpoint
  6. Technology Viewpoint

Introduction

About eReefs

eReefs - a collaborative project focused on the Great Barrier Reef - will provide products akin to that provided by the Bureau of Meteorology for weather. This information will benefit government agencies, Reef managers, policy makers, researchers, industry and local communities.

Using the latest technologies to collate data, and new and integrated modelling, eReefs will produce powerful visualisation, communication and reporting tools.

This five year project, which commenced in January 2012, is the first step in building comprehensive coastal information systems for Australia and will also serve as a pilot project for future Australian interoperable environmental information systems under the National Plan for Environmental Information (NPEI) and, within that, the National Environmental Information Architecture (NEII).

eReefs' Information Platform design is also influencing the design of larger, generic, information platforms such as CSIRO's OzNome Initiative.

About this documentation

Aim

The aim of this documentation is to describe the eReefs Interoperable Data-Infrastructure Reference Model (eReefs-IDIRM) which is an architecture of the information technology and computing systems to be used to realise the eReefs vision. It is both a reflection of what already exists in the eReefs space and also a blueprint for what will be implemented.

It is intended that the eReefs-IDIRM implement, and thus be entirely compatible with, the NEII Reference Architecture also documented on this same wiki site. If there are differences between the NEII Reference Architecture and this architecture, assume the NEII Reference Architecture is correct and please alert the authors. Minor adjustments will be made continuously to move towards full compliance.

This document is the second deliverable in the 2.1 component of Work Package 2's which is entitled Interoperable data and information systems following on from a scoping study (see Related Documentation below). It will be followed by engineering work undertaken by Work Package 2 staff and other eReefs staff demonstrating aspects of this system design.

Structure

This documentation is organised following the Reference Model for Open Distributed Processing RM-ODP and is organised by pages into its concept of viewpoints. These viewpoints are:

These viewpoints are described in great detail in the standard ISO/IEC 10746-3, are available online at http://www.joaquin.net/ODP/Part3/toc.html and in summary in the Documentation Organisation for Information Infrastructure section of this wiki. Their adoption in the geographic information domain has been the subject of much work by CSIRO staff and is expressed in the Water Resources Observation Network Reference Model technical report WRON-RM and they have also be used for the NEII reference Architecture.

This documentation follows on from the eReefs Work Package 2 Scoping Study which is equivalent to the Enterprise Viewpoint of the RM-ODP with additional information about existing cyber infrastructure components of eReefs. Therefore Enterprise viewpoint concepts are not addressed here. Recommendations from the Scoping Study are re-listed under the Enterprise Viewpoint page's Scoping Study Recommendations section. The recommendation that there be a reference architecture for eReefs at all is R2.4.7.

It is also 'live' documentation meaning it will be continuously added to over the life of the eReefs project. Ultimately it specifies the system that will be built/implemented by the eReefs Work Package 2 team over the lifetime of eReefs. Changes will be made to this documentation in place and PDF snapshots may be taken at times to preserve developmental stages.

Authors

The authors of this documentation are members of the eReefs Work Package 2: Data Standards and Architecture team.

The Work Package 2 team is:

  • David Lemon (Product Owner)
  • Nicholas Car (Project Leader)
  • Simon Cox
  • Peter Fitch
  • Bruce Simons
  • Jonathan Yu

This documentation has also received much input from members of other eReefs Work Packages as well as members of the NE2I and the Information Platform for Bioregional Assessments (IPBA) projects' staff.

Related documentation

Architecture Implementation

After initial delivery of this documentation in December, 2012, it will continue to be worked on as both the NEII Reference Architecture is developed and as other components of the eReefs project are developed. The authorship team will work with other eReefs Work Package team members to implement both the eReefs Community Node and some of the expected eReefs Data Provider Nodes. It is expected that a CSIRO Data Provider Node will be implemented very early in 2013 followed by a non-CSIRO Data Provider Node housed by one of the other eReefs partner organisations.

In addition to this architecture and implementations of it, the authors of this document are also contracted to deliver:

  • an extended Water Quality feature model (RAppC);
  • an implementation of WaterML (RAppD);
  • software to integrate models;
  • key eReefs workflows.

eReefs Enterprise Viewpoint

This architecture documentation follows on from the eReefs WP2 Scoping Study which is equivalent to the Enterprise Viewpoint of the RM-ODP with additional information about existing cyber infrastructure components of eReefs, therefore Enterprise Viewpoint concepts are not addressed here.

The Scoping Study made recommendations which are considered Enterprise Viewpoint requirements and are re-listed verbatim in the section below.

Scoping Study Recommendations

The following recommendations are copied from pages 41 to 44  of the the eReefs WP2 Scoping Study which comprises the Enterprise Viewpoint of this documentation.


Recommendation 2.4.1: WP2 team should advise other eReefs work packages on how already implemented subcomponents, implemented using non eReefs approaches can be made eReefs compliant.


Recommendation 2.4.2: The eReefs-IDIRM must consider how the processing of datasets may change over time and what metadata needs to be reported to ensure that such changes are understood by end users or downstream systems if they affect data interpretation. This would be by way of an architecture that was amenable to the inclusion of a prevenance system at a suitable point in time.


Recommendation 2.4.3: The eReefs-IDIRM defined architecture should be allow for growth of data and use.


Recommendation 2.4.6: Since the main goal of eReefs to “quantify and assess water quality issues impacting the reef”, it is imperative that eReefs-IDIRM attend specifically to water quality data and metadata requirements. Consistent with the overall approach of the eReefs systems, It is proposed this be implemented existing using the international data formats such as WaterML2.0. Appendix C: Data exchange format for water quality data investigates technical aspects of this issue.


Recommendation 2.4.7: To avoid the proliferation of hidden private contracts between eReefs subsystems particularly when they are entirely contained within a single agency, the eReefs-IDIRM should  specify a compliance framework for testing the compliance of such systems and components.


Recommendation 2.4.8: eReefs-IDIRM must make recommendations as to how new services are to be added or deprecated i.e. how the system will evolve gracefully, by the provision of a governance roadmap.


Watchpoint 2.5.1.a: WP2 team needs to stay engaged with the Citizen Science component of eReefs collaborative project and where possible ensure that the emerging approaches are consistent with eReefs-IDIRM.


Watchpoint 2.5.1.b: WP2 needs to stay engaged with the User Reference Group as further definitions of the end-user User Requirements become available.


Watchpoint 2.5.4.a: WP2 must continue to watch for scope changes in future eReefs project documentation.


Recommendation 2.5.4.b: The WP2 team must investigate further articulations of RM-ODP derivative RMs created since the WRON-RM v0.1 and the AWRIS35 system which implements much of the WRON-RM’s theory in order to better understand the breadth of Use Cases that can be expected in these generic Use Case categories.


Recommendation 2.5.4.c: The eReefs-IDRIM should specify a methodology for subsequent use case capture and inclusion of those requirements into the eReefs system. This methodology will be applied on subsequent phases of the eReefs project expanding the capability so that it can deliver on those identified needs. The additional use cases captured by this methodology must:

  1. a. be bounded by continued consideration of eReefs goals.
  2. b. consider how Use Cases in the Enablement and Governance, Cross-business Domain Integration and System Maintenance generic Use Case categories should be handled or if Reference Models beyond the WRON-RM are needed
  3. c. consult with the full range of Use Case sources.
  4. d. provide templates or direction to Use Case providers that enable them to return usefully formulated Use Cases
  5. e. list lodged Use Cases from all sources and actions against them so that they may be an on- going reference for the project.


Recommendation 3.1.a: WP2 team to create an index of the data types, exchange formats and, most importantly, the level of standards-compliant, service-delivered data adoption used by the major external systems relevant to eReefs as a reference for eReefs’ technical teams and users.


Recommendation 3.1.b: expectations of eReefs’ function should be sought from the external systems’ stakeholders through a WP2 workplan in collaboration with eReefs project management to ensure good relations. This should involve detailing External System Use Cases.


Recommendation 3.1.1.a: eReefs-IDIRM must ensure eReefs is compliant with the NEII.


Recommendation 3.1.1.b: eReefs should aim for the maximal reuse of the technologies identified as part of NEII such as SISS.


Watchpoint 3.2.1.a: WP2 should work with TERN and its subcomponents (ACEF: Jonathan Hodge, AusCover: Matt Paget, data synthesis in general: Siddeswara Guru) to facilitate compatibility.


Watchpoint 3.2.1.b: The provision of river gauge data from QG to CSIRO is currently done using non-standard methods. Delivery of this data using eReefs standards compliant methods is of high priority and should be scheduled as soon as possible and the eReefs team, including WP2 should facilitate this.


Recommendation 3.2.1.c: WP2 should reference all geospatial feature indexes against an eReefs geofabric which references the Australian Hydrological Geospatial Fabric.


Recommendation 3.2.1.d: WP2 implementation team should work with QG to enable the reporting of gauge and WQ data with against eReefs Geofabric Contracted Catchment identifiers, rather than local catchment identifiers or names.


Recommendation 3.2.1.e: The eReefs-IDIRM should allow for the future delivery of MODIS-equivalent imagery from successor satellites ensuring continued use of this imagery within eReefs.


Watchpoint 3.2.1.f: WP2 team keep an open dialogue with WP1 and other Citizen Science components of eReefs to ensure the interoperability of datasets through standards compliance when they become available.


Watchpoint 3.2.1.g: when higher resolution tide data is made available to the BoM, it should be delivered through service architecture. If the data is not for public consumption, service architecture with appropriate security should be used.


Recommendation 3.2.1.h: eReefs should address the private contract between QG and the BoM and aim for service data delivery. If data in its raw form is not to be made available to the public, a security layer should be implemented as with tide data above.


Watchpoint 3.2.1.i: WP2 needs to ensure that the information infrastructure design is made available to TERN.


Recommendation 3.2.1.j: The eReefs-IDIRM should consider the delivery of private data delivery using standardised service data services with additional security layers.


Recommendation 3.2.1.k: Since altimetry and SST data are delivered to projects outside eReefs, for example to the GHRSST, and since they are also core eReefs data sets, those data need to be delivered as standardised services rather than as ‘private contracts’. Service delivery will reduce both the effort of delivering the data to multiple locations shortly (GHRSST & eReefs) and potentially further locations in the future as well as the risk of new services wishing to use the data facing unacceptable delivery establishment costs. This delivery should be done once and done correctly. WP2 must document current processes in more detail and determine a roadmap to standardisation.


Recommendation 3.2.1.l: It is unclear if SST data used by different eReefs projects, particularly ReefTemp & WP3, is the same data. WP2 needs to convene a meeting between WP1 & WP3 to reach clarity.


Recommendation 3.2.1.m: The eReefs-IDIRM design should allow delivery of measured and computed loads data referenced to Geofabric catchments and ensure that effort by TERN to place data online, when they occur, use both service and standards best practice and Geofabric referencing.


Recommendation 3.2.1.n: At the time of writing this study, the reef report card data and system are out of scope for including in the eReefs-IDRIM.


Recommendation 3.2.1.o: WP2 more formally require of the other WP’s that they list not only their current data inputs and outputs but also potential future inputs.


Recommendation 3.2.1.p: WP2 must seek clarification from eReefs project management regarding changing project scope which determines Use Cases boundaries. This will determine which particular data streams need to be considered.


Recommendation 3.2.1.q: eReefs-IDIRM must make data format recommendations and data ingestion processes clear that are in line with NPEI expectations and publicly available in order to allow data streams not explicitly catered for in the initial eReefs project to be able to be handled/ingested in the future.


Recommendation 3.2.2.a: WP2 must ensure that the delivery formats already chosen for the operational datasets (CF-compliant netCDFetc.) are both best practice within their community and are able to be translated into best practice formats used by the general community.


Recommendation 3.2.2.b: Data quality and governance arrangements for ReefTemp need to be formalised within the eReefs project lifetime. WP2 must work with WP1 & WP4 to ensure that governance for ReefTemp and its parent, the Marine Water Quality Dashboard, are finalised within Phase 1.


Recommendation 3.2.2.c: WP2 must work with the GBRF to ensure that the citizen science component of eReefs is compatible with the eReefs-IWDIRM.


Recommendation 3.2.2.d: WP2 must require that the Bureau and the CSIRO WP3 team outline the output formats of the hydrodynamic model as expected to be implemented.


Recommendation 3.2.2.e: In addition to specifying formats for specific, existing eReefs data output streams, eReefs-IDIRM needs to specify which standards and formats are to be used for other data streams if they are to be considered eReefs data streams.


Watchpoint 3.2.3.a: To ensure spatial compatibility, and enable correct integration, eReefs should have available both terrestrial and coastal geofabrics.


Recommendation 3.2.3.b: WP2 must document the spatial coordinate systems used by the various eReefs datasets and models and estimate a timeframe and cost for conversion to or a translation of reference to the AHGF and its derivatives.


Recommendation 3.2.3.c: It is proposed that WaterML 2.0 is used for water-related timeseries data.


Recommendation 3.2.3.d: eReefs consortium create or coordinate vocabulary services that provide authoritative definitions for data and metadata terms used by data providers within eReefs. Vocabulary service reuse should occur if such services that can be authoritative for eReefs from external projects already exists (such as NPEI or BoM vocabulary services). WP2 will need to initiate activity with the CSIRO IPBA team and also the Bureau’s vocabulary staff.


Recommendation 3.2.3.e: eReefs consortium create a catalogue of data and services for data and service discovery and use. WP2 will need to initiate activity with the CSIRO IPBA team to standardise the catalogue efforts with others working under the NPEI auspices and also the Bureau’s vocabulary staff.


Recommendation Appendix C:

  1. Establish a vocabulary resolution service for returning further information on relevant NetCDF ‘tokens’ and WaterML2.0 URIs: Further enabling the resolution of the content of the NetCDF responses will increase the usefulness of the NeTCDF data outside immediate users and facilitate establishing interoperable WaterML web-based services;
  2. Develop a mapping between the NetCDF hydrology datasets and WaterML: A NetCDF to WaterML mapping will allow data providers to deliver stored NetCDF hydrology data as WaterML to the broader eReef community. Encouraging data providers to establish WaterML services, rather than only NetCDF services, ensures the delivery of comprehensive metadata in standard ISO formats;
  3. Develop a set of best practices that allows WaterML time-series to be represented as NetCDF documents.

This is a longer term goal that will ensure software applications and archives that are dependent on NetCDF standards are able to access services based on WaterML.


Recommendation Appendix D:

  • Extend and validate WaterML 2.0 and/or Observations and Measurements for water quality data, suitable for use within the eReefs project;
  • Evaluate sensor description language for describing water quality sensor metadata for WaterML 2.0;
  • Map WaterML2 water quality observation metadata to netCDF metadata ‘tokens’ (see Appendix C );
  • Reconcile water quality support in WaterML2.0 with WDTF 1.x or WDTF 2.x through input into WDTF implementation.

eReefs Information Viewpoint

Requirements from the Information Viewpoint are identified as IVXX where 'XX' is a requirement number.

eReefs Information

     

eReefs will consist of many types of spatial data from a range of owner agencies delivered using a range of services. It must provide the an authoritative listing of services provided as part of eReefs (a service register) (IV01), gazeteers and vocabulary services to facilitate data fusion amongst those services (IV02), access to those services from a single location (IV03) and the flexibility to allow for new services to be added (IV04, based on R2.4.8, R2.5.4.a) over time. Data services provided to eReefs should also be able to be consumed by any other non-eReefs entity that can handle the standards used by those data services.

eReefs architecture overview

In the most abstracted case, the eReefs information architecture consists of a series of "Data Provider Nodes" that deliver datasets and metadata about those datasets publicly and an eReefs  "Community Node" (CN) that both indexes information supplied by the Data Provider Nodes (DPNs) relevant to eReefs, provides some overarching datasets to enable data provider node data fusion and supplies tools for data delivery. Platforms that deliver (visualise or make available in other forms) data from the DPNs through the CN and original CN data connect to the CN but are separate from it. Figure 1 shows this most abstracted architecture.


Figure 1: eReefs Information Architecture in its most abstracted form.

Data Provider Nodes (DPNs) are self-sufficient entities that need not have any knowledge of the eReefs Community Node. DPNs may be shared between eReefs and other projects that also use a distributed information architecture. Figure 2 shows eReefs using some DPNs through its CN and another project, Project X, also consuming the River Gauge DPN.

Figure 2: The eReefs Community Node sharing Data Provider Nodes with another project.

** SC - Maybe insert here, or after the inventory, an overview on the standard information viewpoints - features, coverages, observations, metadata records, vocabulary items - the GIGAS report has some of this.

eReefs datasets

Some of the specific datasets to be use in eReefs already exist and this architecture must both cater for them and provide a pathway for non-service-based data, which is the majority of it, to implement data services. Based on Table 4 in the WP2 Scoping Study, the following table, Table 1, shows an incomplete listing of the current eReef data, who owns it and some notes about formats. This table, as with its base Scoping Study Table 4, is neither final nor complete but is presented to give a starting point, or a minimum requirements set, for the eReefs required data services.

Table 1: Existing eReefs datasets adapted from the WP2 Scoping Study.

Data Custodian(s)

Feature/Properties

Information Standard

Delivery standard

Service Interfaces

Comments

DERM (DSITIA)

Water Quality/River Gauge/ River sediment & nutrient loads

Local standard

Html, csv

Web browser
File download

Data could be delivered using WaterML2

DERM (DSITIA)

Estuarine and Marine Ecosystem Health Monitoring Program Water Quality

File download

DERM (DSITIA)

Central Queensland Ambient Water Quality Monitoring Data

Pdf,

Is this part of “Water Quality/River Gauge/ River sediment & nutrient loads”?

DERM (DSITIA)

Wave monitoring

DERM (DSITIA)

Storm tide monitoring

BoM (NMOC)

Marine Remote Sensing MODIS

MODIS raw data (HDF-EOS)

Binary file

File download

Currently being operationalised

BoM (NMOC)

Ocean altimetry

MODIS

Currently being operationalised

BoM (NMOC)

Sea surface Temperature

MODIS

Currently being operationalised

BoM

Ocean Colour

netCDF4(CF)

OpenDAP

Thredds

Currently being operationalised

BoM

Reef Temperature

netCDF4(CF)

OpenDAP

Thredds

Currently being operationalised

BoM

Atmospheric Numerical Weather Prediction, global (ACCESS G)

netCDF 3
netCDF 4

BoM

Atmospheric Numerical Weather Prediction, regional (ACCESS R)

netCDF 3
netCDF 4

BoM (potential only)

Hydrodynamic model output layers

netCDF 4 (CF)

OpenDAP

Thredds

QG/ NRM Boards

Seagrass mangrove extent

AIMS

Sea Temperature

CSIRO

Ocean circulation

netCDF

Web browser

CSIROHydrodynamic model output layersnetCDF 4 (CF)OpenDAPHyraxCurrent

QG-DAFF

Land practice data

Word/csv

QG-NRM/ CSIRO

Paddock monitoring

QG-DSITIA

Catchment Indicators

QG-NRM

Catchment Loads

Word/Excel/CSV

 

AIMS / JCU / UQ Entox

Inshore Water Quality

Excel

14 water quality sites plus one long-term transect

QG-DAFF / JCU

Seagrass exten/health

16 sites between Hervey Bay and Cooktown

AIMS

Inshore Coral Reef Health

Focused on inshore reefs between the Keppel Islands in the southern Great Barrier Reef and Snapper Island to the north of Cairns

CSIRO / JCU

Flood Plume Dynamics

UQ/QG

Reef Report Card

html

Web browser

GBRMPA

Marine Monitoring Program

Excel

Collaborative collection from GBRMPA, AIMS, University of Qld, James Cook University, DAFF and CSIRO. Datasets include 1. inshore water quality, 2. intertidal seagrass, 3. inshore coral reef monitoring and 4. flood plume dynamics.

These datasets listed in Table 1 will not represent the final range of types of eReefs datasets as not listed are datasets that facilitate the interoperability of other datasets, such as vocabularies of term definitions, but they do represent the range of scientific base datasets that eReefs will produce.

The Table 1 above includes spatial datasets containing features, raster/grid coverages, timeseries/observations and map images. The semantic web services required to deliver the spatial datasets in Table 1 are respectively feature, coverage, observation and map portrayal services which are described in detail in section "eReefs required services" below.

eReefs community data flow

The data provider agencies and their particular datasets already identified as being part of eReefs and listed in Table 4 of the eReefs WP2 Scoping Study and in Table 1 above is below drawn as a data flow diagram in Figure 3.

Figure 3: eReefs Data Flow Diagram.

The data flow diagram above in Figure 3 shows the data interrelations between the eReefs data custodians. This diagram is used as the starting point to determine where (or by whom) Data Provider Nodes should be established.

eReefs architecture details

SC- Again, this section is more about operations and services than information. Better in the CV, though it is true that 'architecture' is somewhat overarching.

The following eReefs architecture diagrams have built upon a diagram that were generated during discussions about the Information Platform Bioregional Assessments (IPBA) Architecture held on the 12 September 2012. At that meeting, a top-level sketch, Figure 4, was drawn.

Figure 4: eReefs Information Architecture top-level sketch from the IPBA architecture meeting, 12 Sep 2012.

Figure 5 below is the component diagram representing the eReefs Architecture, informed by Figure 4.

Figure 5: eReefs top-level component diagram representing the eReefs Architecture.

Node infrastructure components

SC- Components is Engineering view?

The eReefs community infrastructure contains infrastructure components needed to facilitate eReefs Use Cases using the eReefs Data Nodes. eReefs Use Cases must be able to be met using only eReefs Data Nodes and eReefs Community Infrastructure (IV27).

Since DPNs need to be fully self-described but have a narrow domain (i.e. they detail only their own data) and since Community Nodes generally aggregate metadata from DPNs (i.e. have a requirement for a much broader and richer set of metadata), there are some differences but the functionality however many of the components needed by DPNs are also needed by the Community Node. Where the functionality is the same, it should be met with identical external appearance (i.e. adhear to the same standards as given in the Computational Viewpoint section).

Service / System aggregator

A system and or service aggregator, while perhaps necessary for a Community Node or a DPNs to function does not, by itself, generate any requirements. As long as the functions that a Community Node needs to provide are provided, the background implementation of their aggregation does not appear at the Information Viewpoint level.

Service master catalog

The establishment of a eReefs service master catalog (IV29) allows clients to query eReefs Data Nodes for locations of services of interest. The catalogue must gather all services relevant eReefs to provide this functionality. It is the first  port-of-call for clients wanting to find services of interest.

Other catalogs, caches, brokers

Caching DPN Vocabularies

The idea of a caching DPN vocabularies is that it allows those of interest to be presented alongside other relevant vocabularies. This cached vocabulary service (IV30)  would host these vocabularies and provide service interfaces for the entire eReefs community in a  one-stop shop.

Gazetteer service

Recommendation 3.2.1.c says that eReefs DPNs should reference all geospatial features against an eReefs geofabric (geospatial gazetteer). Such an authoritative gazetteer service or collection of services should be:

  • expressed as a Data Node or have its constituent parts expressed as Data Nodes;
  • either the authoritative service for all eReefs regions of interest or able to identify and redirect queries to those services which are (i.e. act as an index);
  • able to handle changing authoritative gazetteers for all/part of the eReefs regions of interest;
  • based on an underlying Information Model for the system as a whole or facilitate linking between partial IMs;
    • If the gazetteer is a collection of services, it is not sufficient for each service to have its own Information Model. There must be system that allows for interoperability between services, even if it is just a simple spatial/temporal relation.

Having a gazetteer service is IV31.

Key Gazetteers

Terrestrial: Regarding Watchpoint 3.2.3.a, eReefs DPNs must reference any terrestrial water feature observations to the Australian Hydrological Geospatial Fabric (AHGF) (IV32). 

Coastal/reef: The AIMS eAtlas is currently the most authoritative gazetteer for GRB coastal research data. It currently delivers OGC standards-compliant spatial data using the GBRMPA reef locations dataset and data from the Wet Tropics Management Authority and the Torres Strait Regional Authority.  Work will need to be done to either establish the eAtlas as the authoritative coastal/reef gazetteer or derive such from it. If the eAtlas were able to be made authoritative is would need to:

  • be approved to be authoritative regarding administrative reef and other boundaries;
  • collect and deliver the Queensland Government's coastal location data;
  • reference it's catchment draining points to the AHGF;
  • use the same coordinate system as the AHGF (Recommendation 3.2.3.b);
  • ensure compliance with an eReefs/NEII Data Node structure

It is most likely that the eAtlas will be able to grow to take on more non-terrestrial gazetteer roles but unlikely that it will be able to be authoritative as the Queensland and/or Federal Governments will need to enable the supply the authoritative administrative spatial layers. The key gazetteer for this, or if it is indeed to have a single one, cannot be identified or described until an agreement as to who will provide this, and in what form, is reached. Establishing a coastal geofabric, either from eAtlas or elsewhere is IV33.

Information Modelling

Model registry

The Information Models for eReefs will be a set of community-agreed models that apply to the eReefs domain. These models are domain-specific and determine the relationship between features within the eReefs domain. Models considered to be part of eReefs must be stored in a Model Registry.

The establishment of a model registry within the Community Node that will act as a single point-of-truth for eReefs users to obtain the Information Models used in eReefs is IV28. It needs to list both models delivered by Data Provider Nodes and any other models needed in order to facilitate eReefs Use Cases using eReefs Data Nodes.

Note: it is currently unknown as to what the arrangement between DPNs and Community Nodes with regard to model sharing will be.

Feature type catalog

A Feature Type Catalog (FTC) is a registry that represents the semantics of geographic feature types including relationships between features and the operations on and attributes of features. Within eReefs, a FTC allows look-ups of all the feature types within the eReefs community that are presented by the eReefs Data Provider Nodes.

Having an FTC is IV34.

eReef Geographic Features

Initial Great Barrier Reef Marine Park Authority (GBRMPA) features of interest are those provided by AIMS through e-Atlas (http://eatlas.org.au/data/uuid/ac8e8e4f-fc0e-4a01-9c3d-f27e4a8fac3c). These are limited to:

  • Reef boundaries,
  • QLD Mainland,
  • Islands,
  • Cays,
  • Rocks, and
  • Dry Reefs

Options to develop a Feature Type Catalog (FTC) for this data include:

  1. Develop a simple stand-alone FTC that consists of these GBRMPA features of interest;
  2. Use a previously published vocabulary ontology, such as Agrovoc (http://aims.fao.org/agrovoc#.VE2sl2dZtl5), to develop a FTC for the GBRMPA features,
  3. Use a previously published FTC, such as the INSPIRE Technical specifications (http://inspire.ec.europa.eu/index.cfm/pageid/2), and map the GBRMPA features to their equivalents.

There are advantages and disadvantages to each of these approaches. Some of the issues to consider are:

  • Overheads associated with managing a stand-alone FTC;
  • Limited relationships in many vocabulary based ontologies. For example Agrovoc is a simple hierarchical thesaurus that has the terms "Coasts", "Marine areas", "Islands", "Coral reefs", "Reefs" but with no, or limited (for example"Atolls" is considered a narrower term for "Islands" that are composed of "Coral Reefs"), relationships specified between these terms;
  • Existing FTCs may be incomplete (for example the INSPIRE 'Hydro', 'Sea regions' or  'Geomorphology' do not specify 'reef', 'island' features), contain superfluous but mandatory features and/or properties (e.g. inspireID) or are ambiguous (e.g. INSPIRE contains both "InterTidalArea" classes and "mud flats" as types of "NaturalGeomorphologicalFeature", INSPIRE has 'Hydro:Shore', 'Hydro:LandWaterBoundary',  and 'Sea regions:Shoreline');

INSPIRE feature models

Figure: INSPIRE UML for 'Hydro' domain features



Figure: INSPIRE UML for 'Sea Regions' domain features



Figure: INSPIRE UML for Geomorphologic domain features

eReef feature models

The eReefs domain feature model uses the European INSPIRE and Australian Foundation Spatial Data Framework (FSDF) models, with minor modifications to allow for delivery of the features and properties delivered by the AIMS Web Feature Service.

Figure: eReefs domain features

Value-add brokers

These brokers would repackage some of the underlying data products to provide some value-added products, such as aggregated data sets, or products which apply some filter queries on a dataset. Data and services from these value-add brokers may ultimately be provided through a stand-alone eReefs Data Provider Node that is a separate entity from the eReefs Community Node.

Requirements for specific value-add brokers cannot be made until test implementations of this architecture are available but the generic requirement to allow for them is IV35.

Provenance management

Provenance management is required to allow for the storage, querying and publication of provenance information which describe the inputs to and processes upon output data products that describe those products' lineage.

The requirement for a provenance management system is IV36.

Note: at the time of this documents first release, most of the details of a provenance service have not been finalized.

eReefs Computational Viewpoint

Requirements from the Computational Viewpoint are identified as CVXX where 'XX' is a requirement number.

The Computational Viewpoint lists the particular standards needed to facilitate the required services and architectural components listed in the eReefs Information Viewpoint.

Many of these standards are chosen as they represent generally accepted best practice within the geospatial community and most are authorised standards of the Open Geospatial Consortium (OGC), the geospatial community's international industry standards body. OGC standards are noted as being such.

Other standards are de-facto standards already in wide use within communities related to the eReefs community

eReefs required services

** SC - This looks like Computational Viewpoint to me. These are descriptions of specific services that could be moved to the CV pages, and inserted after the general introduction there. Combined with my suggestion for a generic information meta-model introduction above, this refactoring would make the IV and CV pages be symmetric, each with a short general intro followed by a longer specific application in eReefs context.

Web data services are the part of a Service Oriented Architecture that allows for the sharing of data over the Internet which is required by the eReefs project since eReefs data is owned by many agencies and stored in many different locations. Delivering data via services over the Internet allows fast access to that data and, in most cases, querying for subsets of data allowing data users to request subsets of datasets which can be far too large to use in their entirety.

The following listed services will each provide access to data of certain types; mostly certain types of geospatial data. They will need to be implemented within Data Provider Nodes when those DPNs have data of the form they are designed for to deliver. DPNs may not necessarily implement all of the services, only those of relevance to their particular data.

Feature data service

A feature service allows requests for geographical features across the web using platform-independent calls. This type of service will be used to facilitate the transfer of features (polygons, lines, points) of interest to eReefs. From the eReefs WP2 Scoping Study, examples of features already known to be required by eReefs are:

  • reef extent boundaries (from AIMS);
  • GBR administrative boundaries (from Queensland Government);
  • vegetation extent (from NRM authorities);
  • catchment drainage points (from BoM/Queensland Government).

Such a feature service in general needs to allow for complex geographic features, be standards-based (for underlying mark-up), have been sufficiently tested and be sufficiently mature instil confidence in its adoption and have reference implementations to allow for ease of adoption. 

The requirement for a feature service is termed IV05, the requirement that it be standards based IV06, that it be mature IV07 and that it have reference implementations IV08.

Coverage data service

A coverage service allows requests for gridded (raster) data over geographic areas. Gridded data is a common output of many kinds of scientific models and in the eReefs context is delivered by the:

  • hydrodynamic models (from CSIRO/BoM);
  • ocean colour remote sensing (from CSIRO/BoM);
  • numerical weather predictions (BoM).

Such a coverage service needs to allow for complex and large datasets, be standards based (for underlying file formats), contain metadata as well as data and, as with the feature service, be both mature and have reference implementations.

     

The requirement for a coverage service is termed CV09, the requirement that it be standards based CV10, that it be mature CV11 and that it have reference implementations CV12.

Observation data service

An observation service allows requests of observations of features. A series of observations of a feature or features, if it has a time dimension, can be termed a time series thus an observation service is the mechanism used for the transport of timeseries data.

Such an observation service needs to allow for reasonably scale ('scale' with respect to the dataset size (number of observations) and 'reasonable' with respect to the expectations of the eReefs timeseries datasets currently used without services and prospect for their growth over the next few years).

   

The requirement for an observation service is termed IV13, the requirement that it be standards based IV14, that it be mature IV15 and  that it have reference implementations IV16.

Map portrayal service

A map portrayal service is a service used to visually represent geospatial data on the web, within web browsers, and are often the fist point of contact for people manually searching for data and services. Map portrayal services must be able to display visually useful data at different scales and be standards based.

     

The requirement for a map portrayal service is termed IV17, the requirement that it be standards based IV18, that it work in all modern web browsers IV19.

Metadata catalog service

A catalog service allows a client to discover and retrieve information about the data and other services that a DPN or a Community Node delivers. It presents metadata of those other services that can be harvested and stored elsewhere. A Community Node may be expected to harvest the metadata of the DPNs within its domain thus allowing it to provide a catalog service of all the data and other services (including the metadata catalog services themselves) within the domain. A DPN whose data is of interest to multiple communities may see its catalog service harvested by multiple Community Nodes.

 

The requirement for a catalog service is termed IV20 and that it be standards-based IV21.

Vocabulary linking service

A vocabulary service allows for the publication of 'controlled vocabularies' which are formalized lists of terms with particular meaning within a domain. A vocabulary service lets a user discover definitions for terms and also how terms are ontologically related. The service should delivery vocabulary terms as resolvable ("de-referencable") URIs allowing for universal resolution.

The requirement for a vocabulary service is termed IV22, that it deliver terms via URIs IV23.

Persistent Identifier resolution

A persistent identifier service (PID Service) allows URIs for multiple objects - both geospatial and non-geospatial - hosted on multiple, perhaps distributed, underlying systems to be resolved ("de-referenced") from a single point of access. This allows a node (either a DPN or a Community Node) to host multiple services and objects from them and both present them as coming from one place (similar to a portal) and allow for stale cross-linking identifiers. This simplifies service discovery and identity resolution of objects within service-delivered datasets. It also allows for a separation of concerns between dataset/service implementation technology and object identification which enables system change without breaking a discovery or usability contract and for multiple URIs for objects.

Apart from allowing distributed underlying systems, the PID Service needs to allow for multiple service views of the the same object, specifically a metadata view (resolvable perhaps to the medata catalog entry for the object) and also an index view listing other view of the object, i.e. the specific data services through which is it available.

The PID Service needs to implement a consistent structure of URIs for a range of service-delivered objects and needs to allow for the efficient resolution of a large number of URIs. It must also provide strong governance over its URI resolution system to enable multiple users (perhaps staff within a Community Domain or a DPN ownership organization) to manage the delivery of multiple and changing underlying systems' URIs through the node base domain.

The requirement for a persistent identifier service is termed IV24, that it be fit for the domain's requirements (be efficient and provide strong governance)  IV25 and that it provide for URI resolution to multiple views (metadata and index view at least) of objects IV26.

Node service integration

Node service integration (within Community Nodes and Data Provider Nodes (DPNs)) does not require a standard - standards are used for each of the various data services that a Data Provider Node or a Community Node need deliver - thus it does not generate requirements.

NC: Actually, on second thoughts (in 03/13) the above is incorrect. Integration either requires standards or procedures or some other form of common procedure to ensure that DPNs all look the same or rather are accessed in similar ways. The requirement this generates is that DPNs are presented in a consistent manner (data services relate to metadata entries in a consistent way, regardless of the DPN agency or particular data or particular metadata catalogue used).

Service Standards

The following standards are all Open Geospatial Consortium standards. These service choices are inherited from the NEII Reference Architecture's Computational Viewpoint.

Feature service: WFS

The OGC's Web Feature Service (WFS) is chosen at the standard for a feature service.

This satisfies requirements IV05, IV06 & IV07. That it has a reference implementation in GeoServer satisfies IV08. Implementation of the WFS by nodes is requirement CV01.

Coverage service WCS

The OGC's Web Coverage Service (WCS) is chosen at the standard for a coverage service.

This satisfies requirements IV09, IV10 & IV11. That it has a reference implementation in GeoServer satisfies IV12. Implementation of the WFS by nodes is requirement CV02.

Observation service: SOS

The OGC's Sensor Observation Service (SOS) is chosen at the standard for an observation (timeseries) service.

Ongoing review of time series storage and delivery

This satisfies requirements IV13, IV14 & IV15. That it (SOS 1.0) has a reference implementation in 52° North SOS satisfies IV16. Implementation of the SOS by nodes is requirement CV03.

Map portrayal service: WMS

The OGC's Web Map Service (WMS) is chosen at the standard for a map portrayal service.

This satisfies requirements IV17 & IV18. Additionally, it does has a reference implementation in deegree. Implementation of the WMS by nodes is requirement CV04.

Catalog Service: CSW

The Catalog Service for the Web (CSW) is chosen as the standard for exposing a catalog of geospatial records on the Internet. CSW is a profile of the OGC Catalog Service.

This satisfies requirements IV20 & IV21. Additionally, it does has a reference implementation in GI-cat. Implementation of the CSW by nodes is requirement CV05.

Vocabulary Service: SISSVoc

Vocabulary services currently have no OGC standards to govern them. For this reason, eReefs will implement SISSVoc as a de facto standard. This is in accordance with the NEII Reference Architecture's Vocabulary Service implementation.

This satisfies requirements IV22 & IV23. SISSVoc is both the Computation Viewpoint's Vocabulary Service standard (de facto) and the Technology Viewpoint's implementation. Implementing SISSVoc for nodes' Vocabulary Services is CV06.

Service security

Some organisations likely to host DPNs identified a requirement to have some data services implement security as the datasets are privately owned and not for free public access. Recommendation 3.2.1.j read "The eReefs-IDIRM should consider the delivery of private data delivery using standardised service data services with additional security layers." Determining what standards apply to a standardised service-delivered data is CV10.

 

Node infrastructure components

Not all of the infrastructure components identified in the Information Viewpoint's Node infrastructure components section have standards that may be used for them. Those that do are listed below

Persistent Identifier Service

Persistent ID services have no standards associated with them yet. For this reason, there are no Computational Viewpoint requirements for them yet. The PID Service will be required to support a Linked Data API (perhaps ELDA) but this has not been decided yet as Linked Data API testing has not yet taken place.

Service master catalog: CSW

As for a node's catalog service, the Catalog Service for the Web (CSW) is chosen as the standard for exposing a master catalog of geospatial records. Its implementation by Community Nodes is CV07.

Caching DPN Vocabularies: SISSVoc

As for vocabulary services in general, SISSVoc is the de facto standard for a cached vocabulary service. Its implementation by Community Nodes is CV08.

Provenance Management System: PROV-O

The PROV-O Ontology is chose as the ontological representation that provenance management systems must implement to deliver provenance data. This is CV09.

eReefs Engineering Viewpoint

Requirements from the Engineering Viewpoint are identified as EVXX where 'XX' is a requirement number.

Node infrastructure components

Persistent Identifier dispatcher

Live systems are to be deployed at web addresses (URLs) which are strongly coupled to their current implementation platforms and hosting arrangements. These may include machine names, technology names, and other information related to the internal organization arrangements, which are of no real significance to users of the resources. Furthermore, any or all of these aspects are likely to change during the lifetime of infrastructure, even though the actual semantics and utility of the resources and the interface standard and signature remain constant. For this reason it is desirable to denote long-living resources with persistent URIs, which do not change during the life of the resource even though the physical URL does. The persistent URI is the public interface, and must be mapped to the actual resource location at the current moment in time.

Each Data Provider Node will implement a PID service which will operate for that node and will be used in the same fashion by all users of that node. For example, the BoM Other node may be used both in eReefs and in the IPBA projects. In both cases, the data products delivered by that node will be presented using identical URIs. PID-delivered URIs will thus exist independently of project such as eReefs and depend only on the Data Provider node's life.

Service master catalog

Service catalogs will need to be implemented by both DPNs and the Community Node. The DPN catalogs will list only their service-delivered dataset while the Community Node will list all services within that community. It is so-far unknown how service catalogs will operate with Linked Data delivered from a PID Service as double entries (at a individual product's URI and in the catalog) need to be avoided.


That the "eReefs consortium create a catalogue of data and services for data and service discovery and use" is Recommendation 3.2.3.e. That the Community Node's catalog be created by harvesting DPNs' catalogs to achieve this is thus EV01.

Vocabulary service and vocabulary cache

A vocabulary service defines an interface or an API through which controlled vocabularies can be accessed by users.The interface or API is a set of protocols through which vocabulary resources can be queried and returned to the user, e.g. RESTful HTTP interfaces. For the purposes of eReefs, a controlled vocabulary is a set of terms that have been specified explicitly by an authoritative organisation using a specification formalism, such as RDF-based schemas like SKOS or OWL (see this article for a discussion on the differences between controlled vocabularies, ontologies, thesauri, taxonomy). These allow for terms used in a community to be referenced consistently across dependent applications and systems.

It is expected that a data provider would stand up an authoritative vocabulary service which exposes any of their controlled vocabularies for their community of interest. In some cases, a data provider node's vocabulary service may load and cache other controlled vocabularies for the purpose of convenience, reliability and performance.

SISSVoc is an implementation of a vocabulary service that allows controlled vocabularies expressed in SKOS/RDF to be hosted and queried through RESTful HTTP APIs.


Recommendation 3.2.3.d requires that the eReefs consortium "create or coordinate vocabulary services that provide authoritative definitions for data and metadata terms used by data providers within eReefs". That is does and populated the Community Node's vocabulary service with the results is EV02.

The Vocabulary Service hosted by the Community Node should fill in gabs between DPNs vocabularies needed to allow for their use within the eReefs community. It is a requirement that, as much as possible, vocabulary hosting be done by DPNs and that, over time, the Community Node's Vocabulary Service reduces as DPNs' grow. This principle of handover is EV03.

Provenance management system

Recommendation 2.4.2 necessitates the inclusion of a provenance management system in DPNs but it is probably not necessary for a Community Node to implement one.
 

In order to trust eReefs end-point data products, one needs to be able to back-trace their generation through processing workflows through to the base input data products. In order to store this provenance information, eReefs Data Provider nodes will have to have a Provenance Management System (PMS) component which stores product-specific information and is universally discoverable through the node's Persistent ID service alongside the nodes actual data products.

It it not yet known whether a single eReefs PMS instance will be created which will then require provenance reports from eReefs DPNs or whether each DPN will be required to host their own PMS for their own datasets or whether even a PMS will be required at all. For these reasons, the diagrams below do not currently contain PMS components but future versions of this Architecture may well do so.

The determination of the node-level location and mechanism of the/a PMS is EV04.

A prototype PMS is being developed by CSIRO for AWRA and the Geofabirc and an extended version of it should be available for use by eReefs Data Nodes in Phase 2 if eReefs chooses to support this development. Design of and discussion about the prototype PMS is detailed at https://wiki.csiro.au/display/PMS/Home.

Node Implementations

Community Node

A domain node or community node provides a central point for the community or domain of interest for a catalog of services, and resolution of resource identifiers. A community node follows the same architecture as a Data Provider Node, that is, it will include services for object types that would be used by DPNs for those same object types.

Figure 6: The eReefs Community Node

The Community Node does not host any data services itself but only caches those hosted by the eReefs DPNs. This architecture will be able to satisfy Recommendation 2.4.8 in allowing the eReefs IDIRM to add or remove services as they are added or removed by the underlying eReefs DPNs if an additional system is built to flag DPN services for inclusion. This additional system, the requirement for which is EV05, is needed as DPNs will host lots of data, some of which may not be of interest to eReefs therefore the Community Node will need to know how to know list those services for inclusion within the eReefs service master catalog.

Data Provider Nodes

Data Provider Nodes (DPN) are one of the two types of nodes in within eReefs information architecture. Nodes would be owned or managed by an agency that wishes to deliver data in accordance with the eReefs requirements outlines in the Enterprise and Information Viewpoints. The nodes role is to provide all of the services and metadata that eReefs determines is necessary for data discovery, data access and to provide the data via services for ease of use. these roles are taken from the eReefs Scoping Study (see the Enterprise Viewpoint) and the WRON Reference Model (see the eReefs Architecture main page).

DPNs will also need some sort of "Service Level Agreement" with eReefs in order to be considered eReefs compliant. This SLA will specify the minimum availability of the DPN mandated services. This requirement for an SLA is EV06. A Community Node infrastructure component will need to be created to test compliance with this SLA, the requirement for which is EV07.

DPN binding to standard vocabularies

DPNs should not 'know' that they are part of eReefs. Since they will be providing metadata and data services that fully describe their data, any Community Node from any project (eReefs, Bioregional Assessments or others) should be able to harvest the data services and metadata they need from the DPNs, apply the specific community information models and requirements on top of that and start utilizing the DPNs data without any private contract between the individual Community Node and the DPN.

To specifying appropriate metadata in the datasets, each DPN should link their data to the respective vocabulary terms (using URIs) to ensure their data is fully described. By doing so, the DPN delegates the definition of the data semantics to a set of standard vocabularies. eReefs will implement a set of conventions for binding vocabulary terms for the set of data services. For example, a mechanism for binding vocabulary terms to a netCDF dataset may use the following convention in the netCDF headers.

Example

float Nap_MIM(time, latitude, longitude) ;
   Nap_MIM:_FillValue = -999.f ;
   Nap_MIM:long_name = "TSS, MIM SVDC on Rrs" ;
   Nap_MIM:units = "mg/L" ;
   Nap_MIM:valid_min = 0.01209607f ;
   Nap_MIM:valid_max = 226.9626f ;

In this example, the data provider adds annotations to the parameter definition in the netCDF header, with resource identifiers to the relevant standardised vocabulary definition. For example, the property identifier is added to the appropriate water quality vocabulary definition.

This method does not require the DPN to define any terms which have been standardised/formalised (except perhaps the DPN specific ones). Additional attributes are added to annotate the relevant identifiers. For interoperability across DPNs, this practice will need to be adopted by the participating DPNs, so a community will need to define what netCDF attributes are required up front.

Refer to DPN Vocabulary Methodology for more information.

Template node

This template node, Figure 7 below, shows the components of a theoretical DPN. It is provided to indicate which services a DPN owner should implement. In order to follow Recommendation 3.2.1.o, WP2 staff will require formal lists of the current and potential data inputs and outputs of the various organizations within the other eReefs Work Packages and match them to the services in Figure 7.

Figure 7: The eReefs Template Data Provider Node

The choices of the standards used for the node components are detailed in the Computational Viewpoint and the reference implementations in the Technology Viewpoint. Implementations of this template node will force the use of certain (mainly OGC) data formats which satisfies Recommendation 3.2.1.q and Recommendation 3.2.2.e. WP2 may help with the implementation of DPN services if the DPN owners wish to use the reference implementations. Those reference implementations are shown in Figure 8.

Figure 8: Data Provider Node reference implementation technologies.

eReefs Data Provider Nodes

Below are Data Provider Node component diagrams of various existing DPNs already considered part of eReefs. Included on the diagrams are the interfaces that each component exposes based on Table 4 in the WP2 Scoping Study (see the Enterprise Viewpoint). Recommendations from the Scoping Study that relate to specific DPNs are given underneath the diagram for that DPN.

BOM (NMOC)

Figure 9: Data Provider Node for the Bureau of Meteorology's National Meteorological Operations Centre (NMOC).

Recommendation 3.2.2.b: Data quality and governance arrangements for ReefTemp need to be formalised within the eReefs project lifetime. WP2 must work with WP1 & WP4 to ensure that governance for ReefTemp and its parent, the Marine Water Quality Dashboard, are finalised within Phase 1.


 

WP2 requires feedback on Node diagram to clarify NMOC datasets (as opposed to BoM (Other) datasets) at this stage - EV08.

 

Recommendation 3.2.2.d: WP2 must require that the Bureau and the CSIRO WP3 team outline the output formats of the hydrodynamic model as expected to be implemented.

 


Work required for Recommendation 3.2.2.d needs to be re-phrased since eReefs hydrodynamic model outputs may be delivered by the CSIRO Hydrodynamic team as well of, or instead of, the BoM NMOC. That work for this recommendation be rephrased is EV09.


EV10 is for the WP2 team to determine the nature of the link between the Sediment & BGC and Hydrodynamic Modeling components of this node or the corresponding CSIRO Hydrodynamic node.

BOM (Other)

Figure 10: Proposed Bureau of Meteorology (Other) Data Provider Node. Other refers to non-NMOC.

The unknown service interfaces in the figure above deliver MODIS Raw and MODIS data from the respective components. It is currently unknown how this will be delivered and finding out is EV11.

Watchpoint 3.2.1.g: when higher resolution tide data is made available to the BoM, it should be delivered through service architecture. If the data is not for public consumption, service architecture with appropriate security should be used.


Handling of higher resolution tide data is EV12.

Recommendation 3.2.1.k: Since altimetry and SST data are delivered to projects outside eReefs, for example to the GHRSST, and since they are also core eReefs data sets, those data need to be delivered as standardised services rather than as ‘private contracts’. Service delivery will reduce both the effort of delivering the data to multiple locations shortly (GHRSST & eReefs) and potentially further locations in the future as well as the risk of new services wishing to use the data facing unacceptable delivery establishment costs. This delivery should be done once and done correctly. WP2 must document current processes in more detail and determine a roadmap to standardisation.

 For WP2 to define 'Unknown2' with help from WP3  is EV13.

Recommendation 3.2.1.l: It is unclear if SST data used by different eReefs projects, particularly ReefTemp & WP3, is the same data. WP2 needs to convene a meeting between WP1 & WP3 to reach clarity.


For WP2 to define 'Unknown1' with help from WP3  is EV14.

Recommendation 3.2.1.e : The eReefs-IDIRM should allow for the future delivery of MODIS-equivalent imagery from successor satellites ensuring continued use of this imagery within eReefs.

For WP2 to work with WP3 to allow this (which conforms to Recommendation 2.4.8 also) is EV15.

DNRM Node

Figure 11: Proposed Queensland Government's Department of Science, Information Technology, Innovation and the Arts Data Provider Node.

 

Watchpoint 3.2.1.b: The provision of river gauge data from QG to CSIRO is currently done using non-standard methods. Delivery of this data using eReefs standards compliant methods is of high priority and should be scheduled as soon as possible and the eReefs team, including WP2 should facilitate this. (EV16)


Recommendation 3.2.1.d: WP2 implementation team should work with QG to enable the reporting of gauge and WQ data with against eReefs Geofabric Contracted Catchment identifiers, rather than local catchment identifiers or names. (EV17)

Recommendation 3.2.1.m: The eReefs-IDIRM design should allow delivery of measured and computed loads data referenced to Geofabric catchments and ensure that effort by TERN to place data online, when they occur, use both service and standards best practice and Geofabric referencing.  


The portion of the above related to geofabric use is catered for in Information and Computational Viewpoints but the portion relating to working with TERN is EV18.


Recommendation 3.2.1.h: eReefs should address the private contract between QG and the BoM and aim for service data delivery. If data in its raw form is not to be made available to the public, a security layer should be implemented as with tide data above. (EV19)

 

CSIRO Hydrodynamic Node

<CSIRO-HY DPN image not yet available>

 

 

Figure 12: Proposed CSIRO Hydrodynamic Data Provider Node.

Implementing R2.4.1: communication will start between WP2 and WP3 regarding the implementation of the CSIRO Hydrodynamic Node in Nov 2011 with an expected date for node establishment of Jan 2013. (EV20)

AIMS Node

<AIMS DPN image not yet available>

Figure 13: Proposed AIMS Data Provider Node.

In addition to the research data spatial layers delivered through eAtlas, AIMS produces service-delivered data from an number of sources including weatherstations and lists their data sources in a data catalog online. In constructing the AIMS Node, one will need to add to the existing service delivery set and ensure that what is delivered is in the formats specified by the Template Node. Implementing the AIMS DPN with a re-deployment of a current, service-delivered dataset, is EV21.

DSITIA Spatial Layers Node

<DSITIA DPN image not yet available>

Figure 14: Proposed Queensland Government's Spatial Layers Data Provider Node.

eReefs Node

This proposed node will fulfill a different role to that of the eReefs Community Node. It will house and deliver eReefs data generated through eReefs Use Case enactment (people using 'eReefs'). This could include derived datasets that people make by fusing data from other eReefs Data Provider Nodes with data that they upload to a Work Package 4 eReefs portal.

<eReefs DPN image not yet available>

Figure 15: Proposed eReefs Data Provider Node.

Citizen Science Node

<Citizen Science DPN image not yet available, ETA Mid Dec, 2012 after consultation with WP1>
Figure 16: Proposed Citizen Science Provider Node.

Reef Report Card Data Node

Recommendation 3.2.1.n: At the time of writing this study, the reef report card data and system are out of scope for including in the eReefs-IDRIM. 

A re-investigation of the Reef Report Card datasets for future versions of this architecture documentation is EV22.

eReefs Technology Viewpoint

Requirements from the Technology Viewpoint are identified as TVXX where 'XX' is a requirement number.

Much of the information in this section is copied from the Spatial Information Services Stack documentation.

Service technologies

Feature service: WFS: Geoserver

Geoserver, delivered through the SISS is chosen as the reference implementation of a feature service. Geoserver is certified OGC Compliant for its implementations of WFS 1.0, and is the reference implementation of WFS 1.1.

This choice satisfies CV01.

Coverage service: WCS: THREDDS

THREDDS, delivered through the SISS is chosen as the reference implementation of a coverage service. The THREDDS WCS Server implements the OGC Web Coverage Service 1.0.0 specification. It serves out gridded data in GeoTIFF or NetCDF format.

This choice satisfies CV02.

Observation service: SOS:52 North

The 52 North implementation of SOS is chosen as the reference implementation of an observation (timeseries) service.This choice is inspired by the  NEII Reference Architecture's SOS choice.

It is expected that SISS will shortly implement either the 52 North SOS2 implementation or implement SOS via a WFS transformation. SISS SOS 2 delivery progress is documented at SISS's Proposed Solution for SOS 2.0 Development page.

This choice satisfies CV03.

Map portrayal service: WMS: Geoserver

Geoserver, delivered through the SISS is chosen as the reference implementation of a map portrayal service. Geoserver is certified OGC Compliant for its implementations of WMS 1.1.1.

This choice satisfies CV04.

Catalog Service: CSW: GeoNetwork

GeoNetwork, delivered through SISS is chosen as the reference implementation of a catalog service.

This choice satisfies CV05.

Vocabulary Service: SISSVoc: SISSVoc

As discussed in the Computational Viewpoint, SISSVoc acts as the de facto standard for a vocabulary service. It also acts as the reference implementation since it is a specific technology choice. Figure 17 below shows SISSVoc internals.

Figure 17: SISSVoc internal components

At an implementation level, the current SISSVoc (version 3), uses an implementation of a Linked Data API, ELDA - Epimorphics Linked Data API Implementation, which provides a configurable way to access RDF data using simple RESTful URLs that are translated into queries to a SPARQL endpoint. SISSVoc requires a configuration which specifies how to translate URLs into queries to the RDF Triple Store. This configuration also allows templates to be specified for the various encoding formats, such as HTML for the human readable interface, and the JSON format used as a target machine readable format.

Further information about using SISSVoc V3 is available at SISSVoc 3's API documentation.

The use of SISSVoc satisfies CV06.

Persistent identifier service: SISS PID Service

SISS's Persistent ID Service is as the reference implementation of a persistent identifier service.

This platform can handle many requests (it has been tested into the tens of thousands of patterns) and has a strong system of pattern authorship recording thus this choice satisfies IV25 & IV26.

Service security implementation

Choosing a technology to implement service security to satisfy CV10 is TV10.

Node infrastructure components

System / service integrator: SISS

From the SISS documentation home page:

"The Spatial Information Services Stack (SISS) is an architecture and suite of tools for spatial data interoperability using the OGC standards, GML application schema development and registries".

The SISS stack is chosen as the reference node service integration platform. It will be used for both the Community Node service and in reference implementations of the Data Provider Nodes. Many of the above data services come "out of the box" with SISS.

The use of SISS follows Recommendation 3.1.1.b.

Model registry: Solid Ground

The Solid Ground Toolset is chosen as the reference implementation of a model registry.

The use of Solid Ground by nodes will satisfy IV28.

Service master catalog: CSW: GeoNetwork

As with individual DPN's service catalogs, the GeoNetworks implementation of the Catalog Service for the Web (CSW) is chosen as the service master catalog reference implementation. The use of GeoNetworks satisfies CV07.

Caching DPN Vocabularies: SISSVoc

The SISSVoc de facto standard is chose as the reference implementation of a caching DPN vocabulary service which satisfies CV08.

Gazetteer service: AHGF & Unknown

The Australian Hydrological Geospatial Fabric (AHGF) will be used as the Key Gazetteer for land hydrology thus eReefs node components relating to land hydrology must reference it.

The requirement for hydrological dataset providers to reference the AHGF is TV01.

That a coastal gazetteer service be established for eReefs is termed TV02. That it be referenced by coastal datasets is TV03.

The implementation of TV01, TV02 & TV03 will satisfy IV31, IV32 & IV33.

Feature type catalog: SISS

The SISS implements a feature type catalog through its use of the GML Application Schema for oa set of feature types and property definitions thus the use of SISS by nodes will satisfy IV34.

Provenance Management System: PROV-O: Unknown

No technology choice for a PMS can be made at this stage since there are no examples of such systems available yet. The requirement for the discovery or construction of one is termed TV04.

Reference service technology versions

The versions of standards and the versions of the technologies used to implemented them are defined by the NEII Standards and Versions page. The table from that page is reproduced as Table 2 below:

Table 2: A reproduction of NEII Standards and Versions

Error rendering macro 'excerpt-include'

User 'null' does not have permission to view the page.

Comments

    Add new comment