"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

SEEgrid Roadmap - Technology Viewpoint



Overview

Available choices

The SEEGrid RoadMap does not prescribe a complete suite of specific technologies for a homogoneous network. Nevertheless, a set of technology choices is required to establish an initial capability and demonstrate the potential value.

The available technology options and practical examples of their implementation are given in Figure 1, using the components described in the Notional Component Architecture (Computational Viewpoint - Fig 3). The table gives implementers and end users of services some guidance as to possible technology options, but it should be noted this is not an exhaustive nor comprehensive list.

Figure 1: Technological options and examples from Computational Viewpoint

Domain model & profiles

SEEGrid adopts the pragmatic approach of building in capability to integrate legacy technologies, whilst preserving the maximum semantic interoperability for the future applications. A consequence of this is a requirement for partial implementations of application schema using limited profiles of the GML technology, compatible with the limited search interfaces available through current software implementations. For example, the "GML Profile Level 0", recently adopted by OGC, is designed to make simple geometry centric WFS's more consistent. This particular tool won't resolve the challenges facing SEEGrid, but does point the way to an acceptable approach.

SEEGrid will thus need to establish, per application domain (i.e. many such activities with overlapping resources)

  • scope of GML application schemas
  • Feature Type Catalog (including additional relationships) for target schemas (i.e. the normative "Domain Model")
  • Governance framework for Domain Model
  • permitted simplified profiles ("information products")
  • data access services, including custodial and service level agreement provisions
  • mappings to relevant overlapping domains
  • conformance testing arrangements
  • sample queries and/or responses for development of interoperable

Reference Implementation

Publishing to an interoperable schema from a private storage schema

Data sources for a WFS implemetation can potentially be from either databases, typically relational, or existing GIS data sets. However existing GIS data sets are in many cases likely to be based upon data held in relational databases and best practice suggests that storing original or source data in a controlled database is a better management strategy than trying to maintain data in a format that is prone to uncontrolled mutation. Additionally, in the context of geosciences, target community schemas are complex and can not be effectively represented in a flat GIS data structure. Thus the following discussion focuses on relational databases as a data source, although the principles may also apply to other sources.

For interoperability within the community, it is critical to avoid proliferation of undocumented "profiles" that amount only to the dumping of "private" storage schema (table designs) into the Web environment. A basic capability required is the ability to deploy a WFS that sources data from an arbitrary relational database schema and publishes it according to a community endorsed GML schema (see discussion in InformationViewpoint#Service_interface_to_Features_wh). This step may be seen of as creating an abstraction layer between the WFS response and storage schema.

The WFS specification is agnostic about the relationship between the data sources and the public schema, and most existing WFS software does not make this distinction. Effectively, this means to publish according to a community schema requires copying data from an established corporate system into a schema that mirrors the community schema, and deploying the WFS on top of that instead of the corporate system. The SEEGrid project is sponsoring enhancements to the open source WFS reference implementation ("GeoServer" - http://cite.occamlab.com/reference/) to support live mappings instead. This will provide a basic capability to establish interoperable WFS services supporting community GML application schemas, such as using the "observations and measurements" pattern.

Query and Response: real-world queries against complex databases

Another extension is required to link the search (query) schema and the response (public) schema. It may be critical to understand which types of queries can be efficiently supported by the underlying database. This is not currently part of the WFS specification, but can be supported in a number of ways, including registering "query profiles" of Feature Types.

(An example from another domain: A WFS might support a "phone book entry" feature type, but the simple query profile might be limited to allow only name and suburb to be used as query parameters. This is necessary to prevent use of the service to do reverse lookups, which is illegal in Australia. The client should find query profiles of "phone book entry" and then use these to construct permissible queries against a WFS that advertises just "phone book entry" response types.)

Another typical scenario of more direct relevance is the ability to handle some types of queries against complex data structures efficiently, where other queries might cause unacceptable load or not provide useful responsiveness.

In this case query profiles may be managed simply through a catalogue, so this is another example of using a registry to maintain an ontology of related objects, which can then be used to construct service chains. There is a strong semantic mapping between the possible service chains and the relationships in the ontology design, but the whole approach is quite simple and extensible.

Within the SEEGrid demonstrator phase query profiles will be used to initiate service chains - i.e. the user will be asked to interact with a specific query form, not a complex data object. This will be implemented in a scalable implementation, driven by semantics of registered objects within the WebMap Composer spatial portal toolkit, which provides all the tools required for this type of user-focussed workflow management.


Back to RoadmapDocument
Topic revision: r8 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).