Some specific problems in coding EDF+

In the last chapter we saw some methods to encode information in EDF-XML notes. This chapter tries to face some problems in coding EDF-XML notes.

The identical and the different

The normative document includes the next paragarph

 
In order to support automatic averaging and superimposition, 
identical events or stimuli that occur several times in one 
file must be coded each time by the same, unique annotation. 
Annotations (the part between <20> and the next <20>) of different 
events/stimuli (or the same stimulus at a different location) 
must differ from this unique annotation.

We could ask a somewhat philosophycal question. What is identical and what is different? Obviously, the answer depends on our goals. Imagine that we are going to give different supramaximal stimulus to get an F-response. The stimulator produces small differences in intensity or voltage that can be annotated. However, we want to superimpose the traces as thought the stimulus were identical. For us, they are identical in the sense that they are supramaximal.

A more complex example. Imagine that we have a person hearing different words. Some of them are names of colors (yellow, green...) and some of them are different things (chair, table...). We are interested in the evoked response with different categories. All the names are different but responses to non-color-names and color-names have to be separately averaged. They are different but we consider them as equal because we group stimulus in only two sets.

Many similar cases could be described. In the last example we could consider the encoding as something similar to:

 
+200<20>color<20>yellow<20>
+260<20>color<20>green<20>
+310<20>non-color<20>chair<20>
+370<20>color<20>blue<20>

or even in a simpler way

+200<20>A<20>yellow<20>
+260<20>A<20>green<20>
+310<20>B<20>chair<20>
+370<20>A<20>blue<20>

We could extract all the annotations from the file and decide our criteria of averaging/superimposition and then apply different averages (e.g., rare vs frequent, right vs. wrong, etc.) with the same acquisition.

Relating plain text annotations to EDF-XML annotations

You have noticed that several systems of annotations can coexist in the same file. On one side you have a simple method (using plain text e.g. +0<20>stim<20>) and on the other a powerful but complex system of annotations allowing nesting, definition of fields, units... in a more or less standard way. You can use both of them simultaneously by relating a label as follows:

+0
<20>
    A
<20>
    <EDF_XMLnote>
    ...
        <stimulus label="A">
	   ...
	</stimulus>
    ...
    </EDF_XMLnote>
<20>
<0>

Carriage returns and tabulation have been introduced for clarity. This is a TAL (Time Annotation List) that includes a mark for the stimulus as well as a XML annotation. The relation between them is not built in the format. As a matter of fact, they are different annotations that happen simultaneously. We relate both annotations by using the label as an attribute of the stimulus.

We could summarize this procedure as: The plain annotation acts as a trigger. It is very simple and contains very little information: it indicates that something happened at this time. It is equivalent to a digital input. The EDF-XML note describes the characteristic of the phenomenon described by the trigger.

Creating a XML document that mirrors the structure of an EDF+ file

In the previous chapters, we define EDF-XML annotations as subdocuments that could be included in a true document. The whole structure of an EDF+ document can be easily translated into a XML document. The next example illustrates this method. Notice that annotations have been included as a set of TALs. Since the internal structure of EDF-XML annotations is well-done, it can be nested inside the document as in the following example:

<?xml version="1.0" encoding="UTF-8"?>
<EDF File="../../data/destiny/medi_m/NLHSR_020101_1_MNC.edf">
  <Version>0</Version>
  <PatientId>X X X X X</PatientId>
  <RecordId>Startdate 01-JAN-2002. X X X X</RecordId>
  <StartDate>01.01.02</StartDate>
  <StartTime>10.00.00</StartTime>
  <BytesHeader>768</BytesHeader>
  <ReservedHea>EDF+D</ReservedHea>
  <NumDataRecordsInHeader>2</NumDataRecordsInHeader>
  <Duration>0.05</Duration>
  <NumSignals>2</NumSignals>
  <Label>
    <signal number="0">R APB</signal>
    <signal number="1">EDF-Annotations</signal>
  </Label>
  <Transducer>
    <signal number="0">AgAgCl</signal>
    <signal number="1"/>
  </Transducer>
  <PhysDim>
    <signal number="0">mV</signal>
    <signal number="1"/>
  </PhysDim>
  <PhysMin>

  ...
  ...

  <Annotations>
    <signal number="1" record="0">
      <TAL number="0">
        <Time>0.0<Start/></Time>
        <EDF_XMLnote>
          <temperature unit="degree C">
            33.2
          </temperature>
          <distance>...

        </EDF_XMLnote>
      </TAL>
    </signal>
    <signal number="1" record="1">
      <TAL number="0">
        <Time>30.0<Start/>
        ...
      </TAL>
    </signal>
  </Annotations>
</EDF>

This form of representation is less compact than an EDF+ file and to be handled, it requires that the programming language support XML. Even considering this feature, I think that having an standard XML document with the same content than an EDF+ file is not worthless because:

• It makes possible the creation of programs such as edf2xml and xml2edf allowing a direct translation between these formats.
• It is possible to define DTD or Schema allowing the validation of the EDF-XML annotations. Once defined, different neurophysiological methods can be directly compared.
• It is possible to extract different reports (e.g., administrative, external reports...) using standard tools.
• Some or all ordinary signals could also be included by binary data coded as base-64.
• Several files (e.g., the full session of a patient) can be nested in the same file.