WP-ESIP Federation Interoperability

1. WP-ESIP Federation Interoperability JAMES FREW University of California, Santa Barbara http://www.bren.ucsb.edu/~frew

2. WP-ESIP Federation Interoperability • Background • CAN interoperability requirements • Federation Interoperability Working Group (FIG) • Interoperability criteria • System-wide Interface Layer (SWIL) • Catalog interoperability • Proposed technologies

3. CAN Interoperability Requirements • Specific • Make public-domain products available on Internet • Announce products and services through GCMD • Comply with Federal standards (e.g. FGDC) • Philosophy • Interoperability best resolved experimentally • Federation must decide how much

4. CAN Interoperability Requirements • Process • Each ESIP proposes one of{V0, ECS, CIP, FGDC GEO, custom}as System-Wide Interface Layer (SWIL) • custom: “permits the ESIP to be searched and queried as if it is part of a larger whole” • Federation determines and evolves these standards and interfaces • SWIL-specific funding available

5. What is the SWIL? SWIL A common viewof the Federationthat all its participants agree to support customer ESIP ESIP ESIP ESIP cluster ESIP customer

6. SWIL Elements • Online services • How you can reach us • Vocabularies and models • What language(s) we speak • User interfaces • What we look like

7. Federation Interoperability Working Group (FIG) • May 1998 (1st Federation meeting) • FIG established; charged with coordinating development of SWIL • Kenn Gardels elected chair • Summer/Fall 1998 • Inventory relevant systems, protocols, and standards, and ESIP activities

8. FIG Timeline (cont’d) • Dec 1998 (2nd Federation meeting) • Endorse layered implementation strategy • metadata  data  functions • Endorse clusters of ESIPs as “bottom-up” interoperability mechanism • Winter/Spring 1999 • FIG “tiger team” prepares catalog interoperability(CI) evaluation criteria • April 1999: loss of Kenn Gardels;Yonsook Enloe acting chair

9. FIG Timeline (cont’d) • May 1999 (3rd Federation meeting) • CI evaluation criteria presented and approved • James Frew elected chair • Summer 1999 • CI-level SWIL candidate systems solicited • 4 proposals as of 13 Jul 1999 • Evaluation team forming • 30 Aug - 02 Sep 1999 • FIG at UCLA: synthesize CI SWIL

10. Catalog Interoperability Rationale • Light touch • Just metadata, not data • Satisfies basic requirements • GCMD • FGDC • Satisfies “query larger whole” sub-requirement • max(!/$): best chance to do something quickly • Many existing or pending alternatives

11. Overall Criteria • Allow single, multiple, or composite solutions • Multiple: must be equivalent • Composite: should be seamless • Security and access control • Expose subsets of catalog information • Comply with relevant standards • Discover and describe services as well as data

12. Overall Criteria: Risks • Maturity • Acceptance • By users • By providers • Support • Technological change • Continue to support “obsolete” technologies • Migrate to newer technologies

13. Discovery / search Browse Logical data model User interface Local extensibility Technology Scalability / Bottlenecks Costs Compatibility Catalog Interoperability Criteria

14. Specificity Collection Granule Retrieval capabilities Ranking Relevance extent of search compliance Search capabilities Geospatial “bounding-box” including Z “Fielded search” Free text Temporal Common vs. local attributes Search Discovery

15. Specificity By collection E.g. coverage summaries By granule Options Static Fixed parameters On-demand User-specified parameters Vocabularies Valids / Domains Use applicable standards Inter-attribute relationships Parent-child Thesauri Other TBD Data Model Browse

16. Implementation Web browser Other clients Java app Z39.50 Internet search engines Extensibility APIs Open & complete Encodings XML Attributes Vocabularies Search capabilities Retrieval capabilities Data access Provide access to local extensions Local Extensibility User Interface

17. Portability Platform dependencies Implementation Language communication Persistent connections Non-standard ports and/or protocols Firewalls Number of providers Number of users Volume of data Performance Rates Latencies Asymmetric degradation Fault tolerance Scalability and Bottlenecks Technology

18. “plug-in” Purchase Construction Configuration Administration Distribution Providers Federation Existing systems, clusters, and protocols GCMD V0 Z39.50 Compatibility Costs

19. Proposed Interoperability Technologies • GCMD • Mercury • EOSDIS Version 0 • Big Sur • DIAL • MOCHA

20. Global Change Master Directory (GCMD) • Purpose • Search and discovery tool for Earth science data set descriptions • Metadata services: search • Data services: subscription • Direct links to data through alternative interfaces • Z39.50 access to FGDC Clearinghouse

21. Mercury – Metadata Search and Data Retrieval • Purpose • XML Web-based system providing common view of disparate metadata and data files • Metadata services: directory-level search • Data services: search and access • FGDC and Z39.50 compliant

22. EOSDIS Version 0 – Metadata Publication and Data Ordering • Purpose • Automated search, order, and access for online and nearline archives • Metadata publication: search and access • V0 protocol (PRODUCT_REQUEST message): order and access • Access to local data services

23. Big Sur • Purpose • Integrated, distributed data and metadata for search, browse, and access • Metadata services: input data attributes; data history • Data services: functional processing; links to visualization and access tools • Accessible from platforms connected to a Big Sur database

24. Data and Information Access Link (DIAL) • Purpose • Web-based software tools for organizing and distributing metadata • Metadata services: search, query, browse, and access • Data services: access and order in multiple formats • Dynamic visualization, X-Y plotting, animation, subsetting, etc. • Integrated with EOSDIS V0 and GCMD

25. MOCHA - Middleware for Integrating Distributed Data • Purpose • Java architecture for integrating distributed heterogeneous data • Metadata services: distributed queries using XML & RDF • Data services: executes shipped code at data sources for filtering and aggregation • Java middleware deploys plug & play code to data sources • Use XML to exchange and interpret metadata and code

26. Conclusion • “Bottom-up” interoperability is already happening • Web, clusters, etc. • Federation-wide challenge:synthesize a common view • Cook up a nourishing batch of SWIL without losing the flavors of each ingredient