Post on 11-Jan-2016
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