3.1 The <curve/> level

The <curve/> level is the deepest node (leaf) and has no further sub-levels. A curve holds the predefined/simulated or measured output of one single technical component. For example, a typical thermoluminescence measurement may consist of one or many curves.

1. The one curve example: Time against temperature. In this case temperature is a processed quantity, because measurements happen over a time instant. However, for compatibility reasons, this would be allowed although it is not preferred.

2. The three curve example: (a) Time against temperature recorded by a thermocouple (temperature sensor), (b) time against photon counts recorded by a photomultiplier tube, (c) time against a predefined heating ramp.

In both cases, all mentioned <curve/> nodes belong to one parent <record/>. In case 1, the record contains one curve and three in case 2. Ideally, curves represent technical components and not processed quantities.

3.1.1 Value storage

Numerical values in the <curve/> node are stored white space separated. Only quantities detected by a detector/sensor are stored in this node. This includes simulated values. Figure 3.1 shows three types of (luminescence) detectors, distinguished by their capacity to record spatially resolved information. Regardless of the detector, recorded quantities are stored in the <curve/> node separated by white space. Example:

<curve>59.5167 109.5164 149.7003 109.5170 156.2654</curve>

Values in the node are real numbers (-1e-307 \(\leqslant x \leqslant\) 1e+307; \(x \in \mathbb{R}\)). Scientific ‘E’/‘e’ notations of numbers are explicitly allowed, example: 1e+2 for 100 or 1e-2 for 0.01. Decimal separator is a . (dot). Other separators, for instance to separate groups of numbers are not allowed to avoid decimal delimiter problems. Examples:

• 10000.00 -> OK
• 10 000.00 -> NOT OK
• 10,000.00 -> NOT OK

To reduce the size of the file, for instance for image data, the string in <curve/> can be stored using base64 encoding. It is up to the parser to decide whether the string was encoded or not! Encoding in other places (attributes) is not supported and must not be expected by the parser.

Please note that the XSD document does not specify binary encoding because it considers all values in <curve/> strings (which can represent encoded values).

For consistency reasons, the value in the node span an array with dimensions defined through the node attributes xValues, yValues and tValues (see Fig. 3.1).

Figure 3.1: The three cases for data storage depending on the detector. The black solid arrows indicate how the array is constructed from the values stored in the node.

1. The simplest form is a detector that records no spatial information. For instance, a photomultiplier tube only knows about count recorded over time. Alternatively, the detector can be any sensor, measuring, e.g., temperature, pressure or current.

2. A spectrometer (here a camera in front of a spectrograph) is another type of detector with spatial information, here wavelengths split by the spectrograph hitting different pixel areas of the detector.

3. The most complex from is a detector that records events (e.g., luminescence), spatially resolved. Such as a camera.

In the examples and Fig.3.1 the detectors detect luminescence. However, any type of sensor, electronic component recording information of relevance for the measurement of luminescence are suitable. Typical examples:

• Temperature sensor (thermocouple), recording the temperature of the heating element
• Photo diode, monitoring the optical power density at the sample position
• Resistor, measuring the current of a LED
• Pressure sensor, monitoring the atmosphere in the measurement chamber
• Inductive sensor, monitoring closing and opening of a shutter

{...}
  <curve component="heating element" startDate="2021-02-14T22:57:00.0Z" 
    curveType="predefined" duaration="5" 
    offset="0" xValues="NA" yValues="NA" 
    tValues="1 2 3 4 5" xLabel="NA" yLabel="NA"
    tLabel="time" vLabel="temperature" xUnit="NA" yUnit="NA" vUnit="K" tUnit="s">
        293 303 313 323 333
  </curve>
  <curve component="thermo couple" startDate="2021-02-14T22:57:00.0Z" 
    curveType="measured" duaration="5" 
    offset="0" xValues="NA" yValues="NA" tValues="1 2 3 4 5" xLabel="NA" yLabel="NA"
    vLabel="temperature" tLabel="time" xUnit="NA" yUnit="NA" vUnit="K" tUnit="s">
        293 303 313 323 333
  </curve>
  <curve component="EMI 9123QB15" startDate="2021-02-14T22:57:00.0Z" 
    curveType="measured" duaration="5" offset="0" xValues="NA" yValues="NA" 
    tValues="1 2 3 4 5" xLabel="NA" yLabel="NA"
    vLabel="luminescence" tLabel="time" xUnit="NA" yUnit="NA" vUnit="cts" 
    tUnit="s" detectionWindow="380 nm" filter="Hoya U340 + Delta 365/40">
        20 25 32 41 46
  </curve>
{...}

3.2 The <record/> level

A <record> defines one process involving many components, hence <record> may contain \(1\leq n\leq Inf; n \in \mathbb{Z}\) <curve> nodes. A record can also be understood as one step in a measurement sequence, e.g., a TL measurement. All curves within the record should have been detected within the same time frame defined through the attributes <startDate> and the duration of the step.

{...}
    <record recordType="GSL" sequenceStepNumber="1" sampleCondition="NA">
      <curve ...>
        {...}
      </curve>
      <curve ...>
        {...}
      </curve>
    </record>
    <record recordType="bleaching" sequenceStepNumber="2" sampleCondition="NA">
      <curve ...>
        {...}
      </curve>
    </record>
{...}

3.3 The <sequence/> level

A sequence describes multiple measurements sequentially used at one aliquot, for instance as cup/disc with multiple grains or a single grain. Hence, another aliquot from the same sample and the sample sequence needs to be wrapped in a new <sequence/> node. Naturally the information stored an that level can be very verbose, but are limited to
a few required attributes only. In the luminescence context a sequence can fit, e.g., a SAR protocol, but also a succession of protocols measured on one aliquot.

{...}
<sequence position="1" name="SAR measurment" 
  fileName="Testsequence.seq" software="DeviceStudio, 2.37">
  <record ...>
    <curve ...>
      {...}
    </curve>
    {...}
  </record>
  {...}
</sequence>
{...}

3.4 The <sample/> level

The sample constitutes the top level for one particular sample. The sample level may contain an infinite number of sequences measured for one sample.

{...}
  <sample name="LUM-21321" mineral="quartz" latitude="52.4091392" longitude="-4.0702446"
   altitude="50" doi="10.1016/j.radmeas.2017.02.003">
    <sequence ...>
      <record ...>
       <curve ...>
        {...}
       </curve>
       {...}
      </record>
      {...}
    </sequence>
    {...}
  </sample>
{...}

3.5 The <xlum/> level

The <xlum> is the format parent node and it can contain an infinite number of samples. Only this level allows to set a license for the distribution and usage of the data. All data within a particular <xlum> are considered distributed under the license. You have to create new instances of the <xlum> to set different licenses.

{...}
<xlum xmlns:xlum="xlum.org" lang="en" 
  formatVersion="1.0" flavour="generic" author="Marie Curie; Max Planck" 
  license="CC BY 4.0" doi="NA">
  <sample ...>
    <sequence ...>
      <record ...>
        <curve ...>
         {...}
        </curve>
        {...}
      </record>
    </sequence>
    {...}
  </sample>
  {...}
</xlum>
{...}

3.6 General parameters (all nodes)

A few attributes are available on all node levels except the root node <xlum>. These attributes are mainly of technical nature to ease the sequential data storage during the measurement process (such as parentID).

4.1 Pulsing data (optional)

In measurements with pulsed light stimulation, data processing usually requires summations of photon counts on the hardware level using so-called field-programmable gate arrays (FPGA). It is neither meaningful nor feasible to store single counts in separate curves for photon arrival times of \(10^{-6} \leq \tau \leq 10^{-3}\) s. Hence, multiple detectors <curve/> data may be stored per <record/>, one for each (x) pulse(-s). In those cases, the <record/> node contains additional metadata that may help understand the data and pre-processing by the hardware level better. All attributes are optional.

Also the curves contain additional metadata

6.1 Risø BIN/BINX to XLUM metadata argument matching

Risø BIN/BINX files consist of a metadata header block and a data block. Some of the metadata serves the sole purpose of describing the structure of the data block, others return the specific equipment status but are non-relevant for the data analysis.

Most BIN/BINX metadata is covered by the XLUM format by design and hence finds their expression implicitly. The following argument list contains all possible arguments in BIN/BINX files, however, not all BIN/BINX file versions support all arguments. Covered here are BIN/BINX files between versions 03 to 08.

Note: metadata tagged with “considered non-relevant” or “usage unknown” indicate that they are not considered (yet) as relevant enough for long-term data preservation and are hence not to be included as a compulsory argument in the XLUM format definition. However, they can still be stored in the XLUM format regardless.

6.2 Freiberg Instruments XSYG argument matching

The XYSG file format by Freiberg Instruments is already an XML-based file format . It can be somewhat considered the predecessor of the XLUM format. The structure was developed in February 2013 but never formally published, and attributes are not necessarily followed. The main differences are:

• The XSYG file format consists of only four nodes instead of five. Parent node xlum exists only for the XLUM format
• Nodes start with a capital letter (e.g., <Sample>, instead of <sample> in XLUM)
• The individual curves values are stored as a pair-list with values separated by a semicolon ;, in the <Curve> node, i.e., x0 , y0 ; x1 , y1 ; x2 , y2 ; x3 , y3. XLUM uses attributes instead, and values are stored separately through white space
• For spectrometer data, the XSYG format defines an alternative storage format of values in the <Curve> node of form 1.0 ,[554|555|559|553|556|550| {...}. Contrary, XLUM maintains a consistent storage format.
• The chosen date format was not ISO conform yyyyMMddhhmmss instead of ISO 8601-1:2019: YYYY-MM-DDThh:mm:ss[.mmm]Z recalculated to Zulu time.

In the following, the XYSG to XLUM argument matching is listed node-wise.

6.3 SUERC PSL argument matching

PSL files are produced by portable luminescence readers produced by the Scottish Universities Environmental Research Centre (SUERC). PSL files are loosely structured ASCII files without format descriptions.

Measured values are stored in essentially five columns (three columns, but total count and count values per cycle include uncertainties), example:

Time (s)        Total Count           Counts per Cycle  
--------   ---------------------   ---------------------
   1              0 +/-    4              0 +/-    4
   2             -2 +/-    6             -2 +/-    4
   3             12 +/-    8             14 +/-    5

These values can be represented in the XLUM format using <curve/> nodes, one <curve/> for the counts per cycle and another for the uncertainties. This solution is safer than adding uncertainties as attributes and more consistent because the uncertainties must have been estimated using a component.

Columns under “Total Count” represent cumulative data that can be recalculated from the values under “Counts per Cycle” should not be stored explicitly in XLUM.

Additionally, PSL provides arguments that can be extracted from those files. The matching listed below is non-exhaustive and represents the current state-of-knowledge about the PSL format.

Please note: as for the data formats above, in principle, all arguments can be carried over directly. However, for the sake of consistency, the matching should be applied.