Architectural enhancements for GEOSS

Douglas Nebert

February 2011

GEOSS Architecture

GEOSSClearinghouse

GEO Web Portal

GEOSS Common Infrastructure

Components & Services

Standards andInteroperability

Best PracticesWiki

User Requirements

Registries

Main GEOWeb Site Registered Community Resources

Community Portals

Client Applications

Client Tier

Mediation Tier

CommunityCatalogues

AlertServers

WorkflowManagement

ProcessingServers

Access Tier

GEONETCastProduct AccessServers

Sensor WebServers

Model AccessServers

Test Facility

MediationServers

Requirements

•Inventory/Assessment of SBA and Community needs•Standardization needs•Core capabilities•Gap analysis for data and services•User Requirements Registry

Architectural Analysis

•Prototyping•Architectural design•Deployment

EO Publication and Search

•Data and Service Registry•Search / Evaluate / Access•Data policies (?)•User management

Information Access and Integration•Data policy tags (Data-CORE, “full and open”)•Streamlined access to data/services•Model integration with EO assets•Data model, schema, data dictionary•Data transformation•Sensor Web

Capacity Building

•Documentation•Manuals•Reporting•Training

Quality Management

•Service Quality monitoring including anomaly detection•Data quality assessment and reporting•Service level agreements

Interoperability

•Standards Registry•Best Practices Wiki•Ontologies•EO Data structure and format•Web protocols

Dissemination (Publishing)

•Push (Satellite broadcast)•Interactive (fixed)•Interactive (mobile)

Key Architecture Functionality

• Requirements– Inventory/Assessment of SBA and

Community needs– Gap analysis for data and services– Standardization needs– Core capabilities– User Requirements Registry

• Architectural Analysis– Prototyping– Architectural design– Deployment

• EO Publication and Search– Asset registration– Asset type definition (data, service,

model, schema, feed, portal, etc.)– Simple and advanced search– Evaluation for fitness of use– User management

• Interoperability– Standards Registry– Best Practices Wiki– Ontologies– EO Data structure and format– Web protocols

• Quality Management– Service Quality monitoring including anomaly

detection– Data quality assessment and reporting– Error propagation– Service level agreements

• Information Access and Integration– Data policy tags (Data-CORE, “full and

open”)– Streamlined access to data/services– Model integration with EO assets– Data model, schema, data dictionary– Data transformation– Web 2.0/3.0– Sensor Web

• Dissemination (publishing)– Push (Satellite broadcast)– Interactive (fixed)– Interactive (mobile)

• Capacity Building– Documentation– Manuals– Reporting

Key Architecture Functionality - Highlights• Requirements

– Inventory/Assessment of SBA and Community needs

– Gap analysis for data and services– Standardization needs– Core capabilities– User Requirements Registry

• Architectural Analysis– Prototyping– Architectural design– Deployment

• EO Publication and Search– Asset registration– Asset type definition (data, service,

model, schema, feed, portal, etc.)– Simple and advanced search– Evaluation for fitness of use– User management

• Interoperability– Standards Registry– Best Practices Wiki– Ontologies– EO Data structure and format– Web protocols

• Quality Management– Service Quality monitoring including anomaly

detection– Data quality assessment and reporting– Error propagation– Service level agreements

• Information Access and Integration– Data policies (Data-CORE, “full and open”)– Streamlined access to data/services– Model integration with EO assets– Data model, schema, data dictionary– Data transformation– Web 2.0/3.0– Sensor Web

• Dissemination (publishing)– Push (Satellite broadcast)– Interactive (fixed)– Interactive (mobile)

• Capacity Building– Documentation– Manuals– Reporting– Training and outreach

Streamlined access to data and services

• Simple and advanced search, Web 2.0• GEOSS resource type definition• Enhanced data metadata, Web 3.0• Service quality monitoring• Data policy tagging

Item: Simple and advanced search, Web 2.0• Comment: Users want a Google-like experience for GEOSS and yet need to find

data with specific properties and structures• Discussion:

– Geoportal + Clearinghouse together do not yet provide a single set of results that are ranked based on content and geo-temporal fit

– Items that are harvested from remote catalogs have different origins and vocabularies

– OpenSearch API can be used to manage simple Google-like queries– CSW API can be used to support complex or advanced search– Ranking of results needs to account for data content (matching of words) and

the spatial and temporal extent• Impact:

– Specify use of both OpenSearch-geo and CSW interfaces– Investigate and adopt common result-ranking strategies– Enable exposure of Clearinghouse to commercial search engines and

viewers

Item: GEOSS resource type definition• Comment: The content registered in GEOSS is highly diverse and not

systematically defined which makes it difficult to discover, evaluate, and access

• Discussion:– Current resource types include Components as: data, service, model,

schema, portal, and Services of specific types– There is a loose linkage between the data, the standards, and the

services• Impact:

– Component and Service types should be reviewed and consolidated in support of greater interoperability and to flag items like Data-CORE

– Consolidation of the CSR and Clearinghouse functions should be considered as a common search facility for GEOSS

– More robust metadata model should be adopted for registered items

Item: Enhanced data metadata, Web 3.0• Comment: the User Requirements Registry has high expectations for the type and

structure of metadata on observational resources that would enable gap analysis of data and services

• Discussion:– Current metadata has little or no data definition information forthe data or

services they describe (observation parameters)– GEO is composed of diverse communities/SBAs with different vocabularies– Work has begin in AIP on composition of ontologies for GEO and with brokers

to match users and resources (EuroGEOSS)– Gap analysis for data and services will require rigor on defining and adopting a

common set of critical observation parameters• Impact:

– Data model, schema, or data dictionary should be collected and managed (as RDF/OWL) to augment traditional metadata

– Ontologies should promptly move from research to application to support a common and linked view of the EO world

Item: Service quality monitoring• Comment: GEOSS has promoted a service-oriented architecture

(SOA) with the ability for end-users to connect to data via services directly, and yet service quality and availability are unknown

• Discussion:– AIP-2 demonstrated two Web service testing environments that

can probe and validate web services on a scheduled basis– Building trust for use/re-use of Web services is a critical need for

uptake of GEO and SOA– Service level agreements may be predicated on QoS monitoring

• Impact:– Web service status and validation checker capability should be

added to the GCI for all registered services– Define the domain of services to be tested– Develop tutorial/advertising resources to suit

Item: Data Policy tagging

• Comment: DSTF and GEO have been identifying common data access policies that should be flagged in GEO

• Discussion:

– DSTF has defined “full-and-open,” “unrestricted,” and “Data-CORE”

– Unrestricted data still may be encumbered by an online user registration requirement, licensing, and assessing reasonable fees

– Although these are not restrictions, per se, they are obstacles to easy data access

• Impact:

– Implement appropriate fields in provider metadata, the CSR and/or Clearinghouse where data price, licensing, and Data-CORE classification are managed/flagged

– Deploy search capabilities to exploit these tags to segregate the data

– Investigate feasibility of single-sign-on capabilities resulting from AIP-3

Architecture Strategy Input

• As with data, ADC should facilitate and schedule the online hosting of high-availability Web services for strategic data inventories (i.e. in support of ECV, ETV, Data-CORE) within a short timeframe:– Engage providers on documenting data access,

transformation, and extraction service interfaces and data structure, fields, schema

– Assist providers to enable Web services on legacy resources

– Demonstrate availability and mash-up via the GEO Web Portal and clients

Workplan Task Suggestions: 2012-15

• GCI Operations and Enhancements Task should be the primary focus of reworked task AR-09-01a

• Ontology Task should assemble a union ontology from existing ontologies that supports field-level data provision, discovery, and gap analysis through AIP-4 and updated Task successor to AR-09-01d - essential to supporting integration

• User Requirements Registry (URR) is being piloted by US-09-01 and needs to be integrated into GCI with key collaboration on the ontology item above to support gap analysis and discovery. URR ops and enhancements would be under top Task above

Suggestions, continued

• Continue AIP Task but adjust focus of AIP-4 to provide tactical support to convert/adapt major systems to provide standard service interfaces on critical systems and to publicize techniques and tools for re-deployment

• New Task to expand SIF activities to proactively facilitate systems integration/deployment in GEOSS for all GEO Tasks

• Encourage registration and publicity regarding software and online services that are developed within GEOSS, AIP, etc that can be re-purposed