Folder structure and file naming conventions should be decided upon and well documented before work begins. Documentation should be kept in the base of the folder structure for reference. For ease of access we strongly recommend a folder structure that follows the TRiDaS data model. For instance a top level folder for each project, followed by one sub-folder for each ‘object’ (site), and nested sub-folders to handle sub-objects if necessary. Within these folders are folders for elements, samples etc. The folder structure may be simplified and stopped at sites or trees, but in such cases it is essential to explicitly follow the file naming scheme outlined below.

File naming conventions should also follow the TRiDaS data model. This, however, can be problematic if you need to maintain compatibility with legacy (typically DOS-based) programs that have restrictions on file name length. DOS programs can only handle file names with 8 characters plus a 3 character file extension. If 8 character names are required then we recommend:

• 3 alpha character code for object e.g. ABC
• 3 digit code for element e.g. 001
• 1 character code for sample e.g. A
• 1 digit sequential number to distinguish between files

Note that this unfortunately necessarily excludes the concept of a TRiDaS radius. This would result in a Tucson file being named: ABC001A1.rwl. This naming convention can also serve as a guide for the concept of a ‘keycode’. A number of legacy file formats use the concept of an 8 character ‘keycode’ for identifying a series. When using these short file names it is more important to maintain the deep nested folder structure described above.

If backwards compatibility with DOS programs is not required, then the file naming convention should be longer and more explicit. We recommend delimiting the TRiDaS entities within the file name using the hyphen and to include all levels of the TRiDaS data model. For example: ABC-1-B-A-1.rwl would refer to the first measurement series, from radius A, of sample B, of element 1 from object ABC.

We do not support the use of the file extension characters for anything other than identifying the format of the file. This is a widely understood use for these characters and altering them to compensate for file length limitations can lead to confusion. File extensions should follow established conventions e.g. .fh for Heidelberg, .rwl for Tucson etc. If the format does not have a widely agreed upon file extension, then .txt should be used instead.

If deviations are necessary from the naming and structuring proposals outlined above, then it is essential that detailed documentation be made and stored with the data files. These conventions must be adhered to, to ensure that those that follow can understand exactly what each data file refers to.