1. WP-ESIP Federation Interoperability J AMES F REW 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. cluster What is the SWIL? ESIP SWIL customer A common view of the Federation that all its participants agree to support

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 (1 st 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 (contd) Dec 1998 (2 nd 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 (contd) May 1999 (3 rd 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. 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 Catalog Interoperability Rationale

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. Catalog Interoperability Criteria Discovery / search Browse Logical data model User interface Local extensibility Technology Scalability / Bottlenecks Costs Compatibility

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

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

16. User Interface 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

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

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

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