Rich, standardised metadata is essential to ensure archived data can be effectively reused. The Tree-Ring Data Standard provides a robust data model around which this metadata can be stored. A full description of the TRiDaS data model along with all the fields that it supports, can be found in the original publication by Jansma et al (2010).

While the more metadata the better, there may not be the time and resources to comprehensively store all metadata. This is often especially true when attempting to retrospectively archive existing collections where the metadata is not easily accessible or perhaps completely missing.

To be as accommodating as possible few of the many data fields defined in TRiDaS are marked as mandatory. However, there are a number of optional fields that are considered extremely desirable when archiving dendroarchaeological data. A list of all mandatory and strongly recommend fields are provided in table 3.

Table 3 – Metadata fields that are mandatory or strongly recommended when archiving dendrochronological data.

Field	Mandatory	Definition
project.title	Yes	Name of the project
project.identifier	Yes	Laboratory project identification such as a report number
project.type	Yes	Examples include: dating; provenance; wood technology, vegetation reconstruction; climate study
project.laboratory	Yes	Name of the dendrochronological research laboratory
project.category	Yes	One of: former vegetation; archaeology; building history; ship’s archaeology; art/furniture; actual vegetation
project.investigator	Yes	Name of the principal investigator
project.period	Yes	When the dendrochronological project took place
object.title	Yes	Name of the object being analysed e.g. the name of a ship, archaeological site, building or painting.
object.type	Yes	Functional description: building (church, house etc.) water well, painting, musical instrument (and type), ship (and type), forest
object.latitude	No	Latitude of the object in WGS84 decimal degrees
object.longitude	No	Longitude of the object in WGS84 decimal degrees
element.title	Yes	Name of the element
element.taxon	Yes	The most detailed taxonomic name known: species, genus, family etc, preferably from the Catalogue of Life
element.latitude	No	Latitude of the element in WGS84 decimal degrees
element.longitude	No	Longitude of the element in WGS84 decimal degrees
sample.title	Yes	Name of the sample
sample.type	Yes	Method that was used to take a sample from the element e.g. core, section.
sample.samplingdate	No	Date the sample was taken
radius.title	Yes	Name of the radius
radius.pith	Yes	Whether the pith is present or absent
radius.sapwood	Yes	One of: n/a; absent; complete or incomplete
radius.bark	Yes	Whether the bark is present or absent
measurementSeries. title	Yes	Name of the measurement series
measurementSeries.measuringmethod	Yes	What method was used to measure the sample
measurementSeries. variable	Yes	Measured variable e.g. ring-width, earlywood, latewood etc
derivedSeries.type	Yes	If the series has been derived from other series, what type of series is it e.g. chronology, object curve etc

Although the TRiDaS data model (i.e. the structure and data fields) is typically implemented as XML files that comply to the TRiDaS XML schema, it can also be followed in other less formal ways. For instance the Heidelberg data format enables users to store user-defined metadata fields so it is possible to use the TRiDaS fields definitions as additional user-defined fields within a Heidelberg file. If you are using the TRiDaS data model in such a manner, take time to get to know the structure of the model along with its deliberately introduced formatting restrictions. For example, TRiDaS extends the Geography Markup Language (GML) for storing location information. If you are storing coordinates, take care to format them in a logical and consistent manner and to record associated information such as the datum. TRiDaS also defines a number of dictionaries for common terms. These dictionaries should be followed wherever possible.