System Concept Evaluation Criteria

1
System Concept Evaluation Criteria

• FTT
• (FIG Tiger Team)
• (Federation Interoperability Group)

2
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 contd

• 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 contd

• 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

• Its 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 contd

• max(!/) is catalog interoperability

• Light touch
• Just metadata,not data
• Satisfiesbasic requirements
• GCMD
• FGDC

• Satisfiesquery larger wholealmost-a-requiremen
  t
• 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 contd

• 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 contd

• Risks
• Maturity
• Acceptance
• By users
• By providers
• Support
• Technological change
• Continuing support for obsolete technologies
• Migration to newer technologies

15
Catalog Interoperability Criteria

• Discovery / search
• Browse
• Logical data model
• User interface

• Local extensibility
• Technology
• Scalability / Bottlenecks
• Costs
• Compatibility

16
Discovery and Search

• 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

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

• Implementation
• Web browser
• Other clients
• Java app
• Z39.50
• Internet search engines

• Extensibility
• APIs
• Open complete
• Encodings
• XML

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 best
  resolved experimentally using a WP-Federation.

27
BoM contd

• it is the WP-Federation that must decide upon a
  consensus approach to the organizational
  interfaces, degree of integration and system
  interoperability.

28
BoM contd

• 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 contd

• 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 contd

• 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 contd

• 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 contd

• 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 use the Global Change Master
  Directory and/or the Advertising Service provided
  by EOSDIS to announce the availability of their
  products and services.