BODC Parameter Dictionary or A Tale of Topsy

1
BODC Parameter DictionaryorA Tale of Topsy

• Roy Lowry
• BODC Project Data Management

2
The Prologue

• Once upon a time (in 1987) the organisation MIAS
  had a parameter dictionary
• It covered 129 parameters
• 44 of these were wave statistics
• 31 of these were meteorological parameters
• The rest covered basic hydrography plus various
  flavours of sea level

3
The Prologue

• The dictionary was implemented as part of a
  Codasyl database
• It was maintained through monthly updates by the
  DBA
• Change was driven by the need to handle different
  types of long time series data

4
The Prologue

• The dictionary was based on 8-byte parameter code
  which comprised
• A 4-byte parameter code
• A 2-byte parameter subgroup
• A 2-byte parameter discriminator

5
The GF3 Era

• As part of the GF3 format development a parameter
  code table was developed
• This was doomed to failure because the
  maintenance overheads (as a printed manual) were
  prohibitive
• The code table was based on an 8-byte code, four
  of which described the parameter

6
GF3 Standardiation

• GF3 provided international standard 4-byte
  parameter codes
• Many of these differed from the MIAS dictionary
  codes
• So the MIAS dictionary was updated to bring it
  into line with GF3

7
Unexpected Problems

• However, the pre-GF3 codes were in widespread use
• Updating the codes in the data holdings was an
  impossible task
• Fifteen years on and we still have two different
  codes in our data holdings for sea temperature

8
MORAL

• Dont mess around with an operational dictionary
  unless it is absolutely ESSENTIAL

9
Project Data Management

• Early projects managed by BODC (North Sea Project
  and BOFS) broadened our horizons beyond time
  series and CTDs
• However, they were supported by databases using
  simple non-parameterised data structures

10
Project Data Management

• BOFS exposed the weaknesses of the simple data
  structures
• Significant work went into database and
  associated documentation maintenance
• OMEX threatened even more parameter diversity
• A normalised approach was therefore adopted

11
A Dictionary is Born

• A normalised database is based on parameter codes
• Parameter codes need a parameter dictionary
• No suitable dictionaries were available off the
  shelf
• So, in 1994 I set about building one

12
Design Constraints

• Two dictionaries in one organisation is madness
• The dictionary had to be compatible with the MIAS
  dictionary, which meant
• Parameter codes had to be 8 bytes (-)
• Codes had to conform to the code/subgroup/discrimi
  nator model ()
• Units linked to first four bytes ()

13
Design Principles

• Systematic code naming is a secondary
  consideration (its nice to be consistent but)
• Multiple units for a single parameter is avoided
  if at all possible (which brings us to..)

14
The Curse of the Kilogram

• All water column parameters in the dictionary are
  defined in units of per litre and NOT per
  kilogram
• Why?
• Measurements are made per litre
• T/S data are not always available
• Consequently fixed factor conversions are used

15
How do We Get Away With it?

• Wherever the T/S data are available an additional
  parameter is stored in the database that effects
  the per litre to per kilogram conversion
• Consequently, we can always deliver per litre,
  but can also deliver per kilogram wherever this
  is possible

16
Enter Topsy
17
Putting it Another Way
18
How has it Been Done?

• Dictionary maintenance is the responsibility of a
  single individual
• The science is the important part, not the
  hieroglyphics
• Great care is taken to ensure that the data are
  understood before they are coded

19
Dictionary Implementation

• Implemented as four tables in a relational
  database
• 8-byte code definitions (ZUSG)
• 4-byte parameter name definitions (ZUPM)
• Parameter category grouping (ZUCT)
• Units definitions (ZUNT)

20
Dictionary Interrogation

• Several tools available within BODC
• ProFortran Search Tool
• Oracle 2000 Form
• Access Forms Interface
• All tools support wildcard searches

21
Dictionary Availability

• The four tables that make up the dictionary are
  available by FTP
• ASCII (CSV) dumps of the dictionary tables
• Data files are automatically updated every Sunday
  (contrast with GF3)
• Updates are restricted to BODC areas of interest

22
Conclusion

• A parameter dictionary has been built containing
  over 6000 codes
• It is successfully underpins the most diverse
  oceanographic database in the world
• It is freely available to anyone who wants to use
  it providing they dont expect BODC to modify it
  to their requirements