Formatting data for the JGOFS system


The JGOFS Data Management System was designed to be able to read any format that the investigator used for storing his/her data. Because it is object-oriented*, the only part of the System's software that needs to be able to read the data storage format is the 'method', or translation program. To be more precise, 10 routines that are called by the main part of the method must be customized for each data storage format. Another way to view this concept is that the JGOFS software offers unlimited flexibility if someone writes those few routines which make up the 'inner' portion of the method.

However, if the originator of the data, or the people who work for the originator, are not able to write this translator (because of time/money/priority/interest constraints), there are some methods already written. The formats that can be read as part of the JGOFS Data Management System, are listed below. The translation programs (methods) are noted, as well. As new methods are written and, therefore more data formats are JGOFS-readable, we will place them here on the list:

Single flat file, using the def method.
this format is also known as a table, where some of the values (ex: sta, cruise, etc.) might be repeated on consecutive records because the values of these parameters change more slowly than the values of most of the other parameters.

Single file, multiple level format, using the nm method.
this format resembles the above format, except that the more slowly-changing parameters form header records and do not appear in the table records.

Multiple flat files, with top-level header file, using the def method.
this format enables the system to read many simple flat files and, by using a header file, combine them into one logical object.
* Object-oriented means that the data is always used, in combination with a method that can read its storage format, as an OBJECT.


[ <-- ]To the Data Management Page

[Home] Return to U.S. JGOFS Home Page