The Earth System Information Partner (ESIP) Federation Interoperability Group (FIG) held a meeting from August 30th to September 1st, 1999,  to present the FIG "Tiger Teams" selection recommendations for a Software Interoperability Layer (SWIL) for the Federation.

You may find a copy of Jim Frew's notes (the FIG Chairperson), taken during the meeting, here, though this copy was taken just before the group considered how it would help the proposers of the recommended systems improve their proposals.

You can find a copy of our proposal here.

Some highlights of this commentary:

• Summary
• Lack of results: criteria, evaluations
• Tiger Team recommendations
• Our recommendation
• Some miscellaneous notes

Summary

The FIG Tiger Teams recommendation is for V0/Dial, and Mercury (GCMD is a given). The most significant result of the meeting was that a reasonable methodology for a SWIL was devised, in particular for capturing "Collection" data in a manner in which multiple SWIL players can participate. "Inventory" data is relegated to V0/Dial.

These choices have some advantages, in particular Mercury's search engine technology appears useful and innovative, however other aspects of these choices, in particular the situation regarding Inventory data and V0/Dial, will prove to be burdensome. Given the dialogues during the meeting it would clearly have been an advantage to have had a true database expert among the evaluators.

These comments are purely my own. I would like to have seen the evaluation results, and at least a hand-waving over ratification of the proposed criteria would have been nice.

>>back to top<<

Lack of Results

There was no review of the proposed Software Interoperability Layer (SWIL) evaluation criteria. There were no system evaluation results compiled of the five systems the new "Tiger Team" indicates it has reviewed against published criteria: GCMD, V0/Dial, Mercury, Mocha, and BigSur (contrary to the list published on Chairperson Jim Frew's web site). There was no report from the Tiger Team to the FIG on the results of the evaluations and no dialogue with the FIG on the decisions based on said evaluations. Instead, we were presented conclusions based upon these evaluations, with occasional commentary that speed of deployment was in fact the chief criterion in the evaluation process. One can hardly believe that these evaluations were thorough: There were critical aspects of at least two systems which were germane to the stated reasons some systems were chosen over others which were not known by the Tiger Team until brought out in dialogue with the FIG, including important misunderstandings regarding the technology and functioning of Mercury by Jim Frew, FIG chairperson, Mercury's most visible proponent. In other cases, one had to wonder if the Tiger Team had even read the proposals since key data was provided in them which was apparently overlooked.

>>back to top<<

Tiger Team Recommendation

The decision of the Tiger Team was to endorse GCMD (a non-selection), Mercury, which is a web search-engine technology, and V0/Dial. Of the others, Mocha, and BigSur, little was said except that BigSur is "worthy of support", and "purports to do all the SWIL might require," but they think it would not be deployable fast enough, despite the fact that it has already been deployed in production use for over two years.

Importantly, it was indicated that V0/Dial was chosen for recommendation because "it was the only system deployed now which can handle 'inventory' (granules)", in apparent ignorance of BigSur.  Handling inventory meta-data is a requirement of Federation Interoperability, and Mercury is unable to provide this access as it stands today. Virtually everyone who commented on it (at the meeting and otherwise) remarked that they don't like V0; "we can and must do better." The FIG chairperson made numerous comments that this is just a first pass system, and he actively pursued ensuring that the definition of the SWIL does not come to depend on, nor handicap its design based upon the existence or participation of V0 in the SWIL.

Though strong statements were made supporting Mercury based upon the premise that it is deployable by the Federation now, the means by which it interconnects with other systems, such as GCMD. are clearly wanting. (It was incorrectly believed by the Tiger Team that Mercury would submit "GCMD DIFS" during its nightly harvesting of information on web-sites, for example. It would have been interesting to see what a formal evaluation against the proposed criteria would have said about its compatibilities, especially regarding GCMD.) Several changes were proposed, none by its representative at the meeting except in reaction to these requests for Mercury to do something else. In addition, while we are told by proponents of Mercury that it can index inventory (granule) data, a point not denied by its representative, serious questions yet remain regarding its ability to scale, especially given its established modality of (nightly) ingestion of data.(Even if Mercury were to be scaled appropriately, existing ESIP Member systems would likely not be thankful for the load.) And again, the indexing of inventory data by Mercury would require considerable additional expenditure of effort. Discounting inventory meta-data, this system is not deployable now as it was envisaged by the Tiger Team.

V0/Dial was recognized by all to have a substantial installed base who largely find it useful, but distasteful. And it was recognized by all to not be able to handle many kinds of data-sets. It cannot, as a practical matter, be used to manage the Federations inventory data because of the large gaps in what data it can support and because of the substantial installation cost of doing what it can in fact do. No proposals were made to modify it for this role. Further, its means of ingesting data require that it must be installed in all environments that wish to present their inventory meta-data to the Federation, unlike other proposed systems, such as BigSur. In addition, to use it as a system to manage collection level meta-data, flow of information from other data-providers into a V0 installation is decidedly inefficient, though it was suggested that the additional burdens all data-providers will have to endure to accommodate this system could perhaps be used to make a silk purse out of a sow's ear.

>>back to top<<

The agenda moved through the questions of how the chosen systems would cooperate. It was not at all a given that multiple-SWIL players would be able to participate beyond those chosen by the Tiger Team. At one key point it was proposed that the data-flow would require flow through Mercury in order that its inability to interact with competing systems could be overcome. Argument was successfully made to keep the flow open and only require the GCMD-based DIF format for ESIP data providers as the only true requirement for sharing meta-data. (The agreed architecture for data-capture and synchronization is an email list for DIF submission to which SWIL systems subscribe.) Thankfully, Mercury's representative supported an alternative approach. The surprising comment was made by the FIG Chairperson during this dialogue that, "I'm looking out for my own interests and I expect each of the others to do the same." It's a good thing that there were some others involved who wanted to keep a multiplicity of SWIL solutions possible and who are well versed in database technology and systems design.

>>back to top<<

Our Recommendation

"BigSur", a proposed system, would provid a database for inventory, access via an API, and an application/web site tailored to the Federation, along with some tools to manage keeping meta-data up to date without the drawbacks of V0/Dial or Mercury. The Federation should fund BigSur as it is inexpensive and can help fill in the gaps of the presently recommended systems. We believe that the best course of action is for the Federation to accept our BigSur proposal because:

• It's inexpensive.
• It can perform all the tasks the Federation requires of it as a SWIL. In particular it can manage all the Federations data, including inventory (granule) level meta-data in a scalable fashion.
• It does not require you to install it on your system to manage your granule level meta-data.
• It handles all data-types, unlike V0.
• It has been deployed in production use at ESIP member sites for over two years.
• The application(s) required to be written are of a modest scale, and have very little risk.
• It satisfies the desire to "do more" and "do it better."

Miscellaneous notes:

In attendance were: James Frew (FIG Chairperson), Jim Gallagher (Tiger Team), Silvia Nittel (Tiger Team), Yonsook Enloe (Tiger Team), Richard Troy, Helen Conover, Robert Raskin, Rory ONeal, Matt Schwaller, Paul Kanciruk, David Kendig, Mike, Jim (from UMD), and Frank. (Apologies for mistakes and omissions.)

GCMD is a non-selection because its use is a requirement of the CAN.

Mercury is not a database solution, and should not be viewed as one. Yes, it has a database hidden in there somewhere, but the relational power is not available for ESIP use.

With V0/Dial, to support granules, you must install on your system!

The Tiger Team claims Mercury is "deployed now" – so is BigSur. It is clear that Mercury will need "enhancements" to be useful as desired, not only for "inventory", but also for fundamental loading of the database.

[end of document]

website contact: Webmistress