Resource Content

Data Table Descriptions

Table Information

Field

Best Practice

Example

Table or File Name

Enter the literal name of the stored object represented by the table. For something like a csv, this would be the filename, while for a single file in a database, this would be the saved name or code of the individual table described.

2016_2017_arcticCodAges_JQScientist.csv

Table Title

Enter a longer, descriptive, and more human-readable title for the dataset

Arctic Cod Age and Growth Data 2016-2017

Table Description

Use this field to describe the data in the table. This should be human-readable and be useful for helping a would-be user understand if the data is appropriate for their intended use.

Arctic cod age and growth data, including vessel and haul information, and specimen collection age, sex, fork length, and species information.

Attribute Information

Field

Best Practice

Example

Attribute Code

Use this field to document the attribute code or label as it appears in the data file. When the data file is a csv, the Research Workspace will populate this field for you.

  • ‘temp_C’

  • ‘cpue’

Attribute Name

Use this field to provide a human-readable name for the attribute.

  • ‘Sea water temperature at depth (degrees Celsius)’

  • ‘Catch per Unit Effort’

Attribute Definition

Definition of the attribute or column, including descriptions of any formatting or codes in the values.

  • ‘Sea water temperature as measured by the Seabird 19plus V2 at depths through each cast.’

  • ‘Total biomass of all species caught per kilometer of surface trawl.’

Unit

Use this field to document the units of measurement for the values in the attribute.

  • ‘degrees celsius’

  • ‘g/km2’

Data Types

Document the data type of the values in each attribute. In the Research Workspace Metadata Editor, this field provides a drop-down of suggested data types, though any other type can be entered by the ambitious metadata author.

Data Type

Best Practice

Example

character

Data are of this type when all attribute values are single letters, numbers, or symbols. If character values are codes for classes or categories, it may be more accurate to call your attribute categorical.

Character values:

  • ‘S’

  • ‘5’

  • ‘r’

string

String typed data are plain text, often with formatting restrictions but sometimes without (as in the case of a ‘notes’ or ‘comments’ attribute).

String values:

  • ‘SKQ201804’

  • ‘rough’

  • ‘T800’

  • ‘Extremely high winds prohibited the deployment of the sail drone.’

boolean/binary

Attributes with only two possible values.

Typical boolean value pairs:

  • yes|no

  • true|false

  • 1|0

integer

Numeric data have are integer-typed when values can be only positive or negative whole numbers. It is considered best practice to describe the range of actual values in the attribute description

Integer values:

  • ‘1’

  • ‘-505’

  • ‘11’

  • ‘0’

  • ‘69’

decimal

Numeric data have are decimal-typed when they have a period in the middle in the middle of the numeric value. It is considered best practice to describe the range of actual values in the attribute description, and it’s just irresponsible to fail to document the number of significant figures approriate for the value. Also called ‘real’, ‘floating point’, or ‘double’, which mean different things in different places, but all fall under the ‘decimal’ type used here.

Decimal values:

  • ‘0.001’

  • ‘11.23’

  • ‘500.45’

  • ‘-45.00003’

date/time

Any attribute with values describing dates or times, whatever the format, is of the type ‘date/time’. A best practice for this type of data is to document the format used for date and time information in the attribute definition for the field. The very best practice is to always format date/time values in ISO 6801 format (YYYY-MM-DDTHH:MM:SS+HH:MM), like all the examples in the next column.

ISO 6801 formatted date/time values:

  • ‘2018-09-18T12:01:00Z’

  • ‘2010’

  • ‘19940808’

  • ‘20090918230000+0900’

categorical

Any attribute with values that represent categories or groups into which all values can be sorted, or has a distinct list of possible values. Best practice is to document possible values for categorical attributes using the ‘possible values’ fields described below.

Fields that are likely categorical:

  • ‘Vessel’

  • ‘net type’

  • ‘season’

Possible Values

Field

Best Practice

Example

Value Name

Use this field to enter a human-readable name for the value.

  • Not Sampled 1

  • Climbing

Value Code

Use this field to enter the value as it appears in the data. This may be the same as the ‘Value Name’ but often this will be coded or shortened in some way.

  • ns1

  • cl

Definition

Use this field to provide a useful definition for the value.

  • Not sampled reason 1: high seas prohibited deployment of the instrument

  • Bear was observed in the process of climbing up or down

Data Dictionary Info

Field

Best Practice

Example

Data Dictionary Title

Use this field to enter a human-readable name for the value.

  • Data dictionary for [data type] (e.g., seabird count data, Seward Line CTD data)

Data Dictionary Scope

Describe the scope or descriptive coverage of the data dictionary. If the dataset contains many tables or entities, use multiple ‘Data Dictionary Scope’ blocks to make scopes for specfic table(s) less ambiguous.

  • This data dictionary describes entities and attributes in the data table(s) from this dataset, which describe [data type]: data-table-name-1.csv, data-table-name-2.csv, etc.

Entity and Attributes Overview

An overview of all the tables and their contents.

  • The contents of this field can by copy-pasted from the Data Dictionary Scope field above.

External Data Dictionaries

Field

Best Practice

Example

Data Dictionary Citation

The reference information for the data dictionary, if citable. If not citable, include data dictionary file with dataset and provide the name of that file here.