The master elements are :
- experimenter (contact information of the experimenter)
- documentation (pieces of information to be used at many places)
- dye (dye type, used by targets)
- sample (description of a sample)
- target (description of a targets)
- thermal cycling conditions (description of the cycling conditions)
- experiment (a collection of several qPCR runs)
Each master element has a unique id attribute, by which it can be referenced
In other elements of the file. This allows describing the samples and targets only
once in the file and then reference them in the reactions in a qPCR plate
using the respective ids. We suppose that a laboratory will research
only some targets and therefore will be able to provide this information once. The
software should allow to extract all the master elements (except the experiment
element) from one other file when creating a new file and thereby does not require
the user to fill in all this information by hand.
In an RDML file the concept of a sample is an absolutely identical template solution at the
moment of adding it to the qPCR reaction.
Therefore, different dilutions (e.g. serial dilutions of a standard curve) require different ids.
The only exception would be technical replicates, which would be
considered one sample because they are all made using the solution from one stock.
Also different dilutions would require different ids, because the solutions are at
the moment of adding to the qPCR reaction of different concentration. We suggest
adding the concentration to the id and making it thereby unique (e.g. STDsample-100).
The concept of a target is the primer (and probe) mix added to the sample to specifically amplify the template target.
Targets need to refer to dyes. Identical targets using different dyes are considered different and require different target ids. We suggest adding the dye to the target
name (e.g. Actin_FAM and Actin_Cy5).
Thermal cycling conditions allow describing the steps a thermocycler goes through
to amplify the DNA. It is a very flexible way to model all programs. It can also
be used to describe a regular PCR or a cDNA synthesis program.
The experiment contains the data collected during one or more qPCR runs. Each run contains one or more qPCR reactions. Each
reaction contains
one sample (which is referred to by its id) and one or more data elements (one for each target (also referred by its id)).
Multiple data elements
are only required for a multiplex reaction, in which several
targets are simultaneously measured (using different dyes). If the reactions are measured in different runs, the
data should be stored as separate runs. The data elements require a Cq value and can optionally contain the recorded
fluorescence values. The raw (non-background corrected) fluorescence data should include instrument related corrections
except for
baseline/background correction (in order to allow alternative background correction or Cq value determination methods to be
used for re-evaluation).
In other words, correction for empty wells and corrections for
the loading (as for example using a passive reference dye) are calculated into these fluorescence values according to the
qPCR instrument software algorithm (which is trusted to be good). Importantly, the RDML file aims to
contain data that is comparable across all instruments instead of matching instrument specific data and correction
approaches.
The documentation elements constitute the multi-purpose documentation system in an RDML
file. Such an element is basically a text field that has an unique id.
From many places in the RDML file, a reference can be made to these document element ids, which makes it very versatile and
allows to document almost everything. If for example some samples were treated
differently, the difference can be described in a documentation element and reference in the samples.
Each sample can have an
unlimited number of these elements and because they are referenced by id, the file remains small, even if e.g. a
long description is used for all samples.
The use of documentation elements is not only limited to
samples, it can be used at various places in an RDML file. Some elements have also
description strings. These strings are unique to the element and should be used if
the description is only required to a few elements.
Please be aware that the strings in an RDML file should be in the unicode format
utf-8.
RDML File Compression and File extensions
The xml file containing the RDML data should be stored in a file named
rdml_data.xml. This file should be compressed using pkzip compatible compression
into an archive. The archive can have any name, but instead of having the extension
.zip, it should have the extension .rdml (preferably) or .rdm.
Archives ending in .rdml or .rdm must contain the file rdml_data.xml.
RDML compatible software should be able to read compressed .rdml or .rdm files as well
as uncompressed .xml files.
If third party information needs to be stored in the RDML file, it may be added in a
machine specific format to the archive. We request that the used file name starts
with the third party provider name.
The files below are compliant with the RDML v1.1 Recommendation (November
8, 2010).
