System Concept Evaluation Criteria

1. System Concept Evaluation Criteria FTT (FIG Tiger Team) (Federation Interoperability Group)

2. SWIL customer ESIP ESIP ESIP ESIP cluster ESIP customer What is a Federation “System Concept”? A common view of the Federation that all its participants agree to support

3. Common View Elements • Online services • You can reach us this way • Vocabularies and models • We speak this language • User interfaces • We look like this

4. Common View Requirements and Criteria • CAN requirements • What we must do • FIG criteria • What we should do

5. CAN Interoperability Requirements • Interoperability best resolved experimentally • Federation must decide degree of integration and system interoperability • Interoperability funds may be used as determined by the WP-Federation

6. CAN Interoperability Requirements cont’d • For the purposes of proposing, include support for one of {V0, ECS, CIP, FGDC GEO, custom} System-Wide Interface Layers • custom: permits the ESIP to be searched and queried as if it is part of a larger whole • Successful proposers will jointly determine and evolve these standards and interfaces

7. CAN Interoperability Requirements cont’d • Public-domain products of this CAN [will be made] available on an Internet-accessible server • WP-ESIPs will use the Global Change Master Directory to announce their products and services

8. FTT Interpretation • It’s all up to us (the Federation) • Minimal interop requirements • GCMD • FGDC • But, we must do something • Pressures to do it soon • Fiscal: spend it or lose it • Political: What are you guys doing? • Technical: field-test various options

9. FTT Interpretation cont’d • max(!/$) is catalog interoperability • Light touch • Just metadata,not data • Satisfiesbasic requirements • GCMD • FGDC • Satisfies“query larger whole”almost-a-requirement • Best chance todo something quickly • Many existing or pending alternatives

10. Criteria vs. Requirements • Requirements • “Thou shalt” • Must fulfill, else not acceptable • Criteria • “Tell us” • Must explain how proposed solution addresses

11. Responding to Criteria • Qualitative • How does candidate system address the criterion? • Quantitive • Is there a minimum level of compliance with the criterion? • Does the candidate system meet it? • Work in progress • Your feedback is crucial

12. Overall Criteria • Allow single, multiple, or composite solutions • Multiple: must be equivalent • All the ESIPs, all the metadata • Composite: should be seamless • “functionally equivalent”

13. Overall Criteria cont’d • Security and access control • Expose subsets of catalog information • Use of / compliance with any relevant standards • Discovery and description of services as well as data products

14. Overall Criteria cont’d • Risks • Maturity • Acceptance • By users • By providers • Support • Technological change • Continuing support for obsolete technologies • Migration to newer technologies

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

16. 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 Discovery and Search

17. Browse • Specificity • By collection • E.g. coverage summaries • By granule • Options • Static • Fixed parameters • On-demand • User-specified parameters

18. Logical Data Model • Vocabularies • Valids / Domains • Use applicable standards • Inter-attribute relationships • Parent-child • Thesauri • Other TBD

19. Implementation Web browser Other clients Java app Z39.50 Internet search engines … Extensibility APIs Open & complete Encodings XML … User Interface

20. Local Extensibility • Attributes • Vocabularies • Search capabilities • Retrieval capabilities • Data access • Provide access to local extensions

21. Technology • Portability • Platform dependencies • Implementation • Language • Special communication requirements • Persistent connections • Non-standard ports and/or protocols • Interactions with firewalls

22. Scalability / Bottlenecks • Number of providers • Number of users • Volume of data • Performance • Rates • Latencies • Differential degradation of capabilities • Fault tolerance

23. Costs • Distribution of costs • Providers • Minimal vs optional • Federation • What happens to Type 3s? • “plug-in” • Purchase • Construction • Configuration • Administration and maintenance

24. Compatibility • Strategy for accommodating existing systems/clusters/protocols • GCMD • V0 • Z39.50 • …

25. Appendix Interoperability Language from the WP-ESIP CAN

26. CAN Requirements(from the Book of Martha) • NASA concluded that the issues of federation governance and interoperability would be bestresolvedexperimentally using a WP-Federation.

27. BoM cont’d • …it is the WP-Federation that mustdecide upon a consensus approach to the organizational interfaces, degree of integration and system interoperability.

28. BoM cont’d • The WP-ESIPs, acting for the WP-Federation, will be expected to… submit a proposal to NASA early in the first year of performance to… fund interoperability activities… These funds may be used for incremental developments needed to achieve the level of interoperability and/or data interuse as determined by the WP-Federation and their maintenance, and system-wide metrics collection and reporting.

29. BoM cont’d • For the purposes of proposing to be a WP-ESIP, proposers are instructed to include in their implementation plans support for one of the following System-Wide Interface Layer (SWIL) interoperability options [custom, V0, ECS, CIP, FGDC GEO]… • [custom:] A selection from emerging set of technologies that permit the ESIP to be automatically searched and queried from remote clients as if it is part of a larger whole (i.e., a "Federation").

30. BoM cont’d • Proposals will be evaluated for compliance with this requirement…, but following selection, successful WP-ESIP proposers will work with other members of the Working Prototype Federation to jointly determine and evolve these standards and interfaces.

31. BoM cont’d • data products and algorithms made available by all WP-ESIPs… must meet all U.S. Government-mandated standards. Presently these comprise applicable Federal Geographic Data Committee (FGDC) standards

32. BoM cont’d • To facilitate the dissemination of any public-domain products of this CAN, the WP-ESIPs will make them available on an Internet-accessible server… • the WP-ESIPs will usethe Global Change Master Directory and/or the Advertising Service provided by EOSDIS… to announce the availability of their products and services.