1. Architectural enhancements for GEOSS Douglas Nebert February 2011

2. GEOSS Architecture GEOSS Clearinghouse GEO Web Portal GEOSS Common Infrastructure Components & Services Standards and Interoperability Best Practices Wiki User Requirements Registries Main GEO Web Site Registered Community Resources Community Portals Client Applications Client Tier Mediation Tier Community Catalogues Alert Servers Workflow Management Processing Servers Access Tier GEONETCast Product Access Servers Sensor Web Servers Model Access Servers Test Facility Mediation Servers

3. 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)

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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