AUKEGGS Architecturally Significant Issues (that we need to solve)

Architectural Issues We have some experience building systems, and designing data Following ISO TC211 conceptual framework is looking good… But a few implementation issues require common solution –Soluble –but must be solved collaboratively

Progress Report Architectural decomposition of Publish- Find-Bind paradigm against real data services –Peer review of Oceans Portal implementation of SDI concepts –Proposed as basis of scalable UN SDI implementation strategy

The USER… discovers DATA… and ACCESSES it (from distributed Authoritative sources) Typical requirements

Separation of Roles Many Roles => Simple Tasks + Reusable objects + Interoperable services

Progess (continued…) Support for relational database exposed as GML objects –“community schema support” in Geoserver Open source “reference implementation” for WFS 75% complete Wide variety of domains –Ability to handle n-D coverages via WFS (delivering a handle to asynchronous and streaming data delivery)

Last Millenium Challenges Relationships between services and data standards –Service profiles –“Processing affordances” Profile specifications issues –ISO 19115/139 validation –UML idiom –Vocabulary binding –Mapping of terms Vocabulary references in instance documents Common registry formats (and APIs?) for: –Data specifications –Query models –Vocabularies

UML Idiom: mapping attributes More complex mappings via association classes

Implementation Models

What makes a service useful? A deployed service instance is interoperable in practice if: –The service can be invoked using a known “protocol binding” –The service semantics are known –The content returned can be understood –The client can ask a meaningful question of the service instance (relating to the content available) OGC defines service types that: –Define how protocol bindings –Define service semantics –Define a small set of mandatory behaviours –Define a range of optional behaviours –Define the way the service can deliver metadata to a client (the getCapabilities() operation)

Instance vs Type Service instance is not the same as a service type Service Type Standards Service Instance Service Metadata Service Metadata Standards Dataset Metadata Dataset Metadata Standards Dataset Product Standards Dataset

Role of Profiles Profiles constrain generic types to meet interoperability expectations –I.e. Constrain which technical options are to be supported For example, deliver specific content from multiple sources –A Cadastral Service Profile might constrain a OGC WFS to deliver a particular Cadastral data standard. And implement metadata standards –Eg ANZLIC profile of ISO 19115

What might be constrained? Service Type options Service metadata content Data/Content exposed Vocabularies used in content Queries supported Quality of Service expectations

Governance Realities Technology Realities Data Realities Profile Hierarchies OGC WMS WFS Gazetteer ANZLIC ICSM Cadastre Place Names Cadastre WMS PlaceNames Server Whole of Govt Service standards Data Access OGC Services Authoritative Source Business Function Display WMS

Profile Hierarchy Examples ANZLIC/ISO Metadata Applies to all resources, provides guidance for a set of options GEA ServicesDefines GEA terminology, governance rules GEA Data ServicesDefines Quality of Service for data provision GEA OWS ServicesDefines GEA metadata binding to common OGC service metadata GEA WMS ServiceConstrains map projections, metadata linkages, legends GEA WMS DisplayDefines performance targets for on-demand map products GEA WMS service Defines data specification for service instance

Metadata Documents Traditional metadata has some problems –Low level of utility (discovery…) –Low level of cohesion with rest of systems –Low level of content interoperability –Low level of semantic value (bind…) –High level of complexity of eac –High level of effort Failure to map metadata to interoperability expectations –One-size-fits all profile isn’t good enough A cure or a worse disease? –Giving a starving man an elephant Refactor it

Metadata refactoring Already implied in ISO packaging –CI_Responsible party Inherit from access arrangement Replace description with link Support ORG_A = ORG_B ! Support query –Data Product Specification (ISO19131) Covers most of the other 90% Observation parameters Metadata entry reduced to a few configuration choices when establishing a service