4. The DALF header

4.1.1. The macro-location path of a letter: <country>, <region>, <settlement>, <institution> and <repository>

These elements give a top-down description of the location path of a letter, from the country where the holding institution is located to the most specific unit within that institution that can be distinguished for the place where the letter is located.

The elements <country>, <region> and <settlement> are all standard TEI elements carrying the attributes of the names and typed attribute classes. The elements <institution> and <repository> are adapted from the Master encoding scheme; since they have similar semantics, they have been uniformed with the TEI elements. This means that they all may contain elements of the phrase.seq element class. The elements defined by that class are too numerous to list here; they are listed exhaustively at http://www.tei-c.org/P4X/ref-PHRSEQ.html. All elements expressing the macro-location path of a letter may contain the following attributes, apart from the global ones (defined in 3.3. Global attributes):

from the TEI attribute class names (defined at http://www.tei-c.org/P4X/ref-NAMES.html):

key

Provides an alternative identifier for the object being named, such as a database record key. This is an optional attribute, with CDATA as value type.

reg

Gives a normalised or regularised form of the name used, in the form of CDATA. This is an optional attribute.

from the TEI attribute class typed (defined at http://www.tei-c.org/P4X/ref-TYPED.html):

type

Characterises the element in some sense, using any convenient classification scheme or typology. It is an optional attribute, with as value type CDATA.

subtype

Provides a sub-categorisation of the element, if needed. It is an optional attribute with as value type CDATA.

The following example illustrates a more extensive location path for the letter of the previous example, that is located in the AMVC in Antwerp, Flanders, Belgium. Here, the region where the settlement is located is given, the institution to which the repository belongs is identified and typed as a municipal department, and the repository is provided with a database record key and a regularised form of its name:

<country>Belgium</country>
<region>Flanders</region>
<settlement>Antwerp</settlement>
<institution type="municip_department">Dept. of Culture, Antwerp</institution>
<repository key="loc01_AMVC" reg="AMVC">AMVC</repository>

The unique DALF elements <institution> and <repository> are declared as follows in the file DALFExtns.dtd:

<!ELEMENT institution %om.RR; 
          (%phrase.seq;)> 
<!ATTLIST institution
          %a.global; 
          %a.names;
          %a.typed;> 

<!ELEMENT repository %om.RR; 
          (%phrase.seq;)> 
<!ATTLIST repository
          %a.global;
          %a.names;
          %a.typed;>

4.1.2. The micro-location path of a letter: <collection>, <idno> and <altName>

The identification of a letter continues to the micro-level: the identification of the letter within its repository. The collection to which the letter belongs must be identified in the <collection> element. The identification code that is used within the repository to indicate the letter must be specified in the <idno> element. If a letter may be known under another name or identification code, this can be recorded in <altName>.

The <collection> and <altName> elements are closely related to the TEI name class elements. Therefore, they too can contain the elements of the phrase.seq class (see http://www.tei-c.org/P4X/ref-PHRSEQ.html). Their attributes, apart from the global ones (see 3.3. Global attributes), are:

from the TEI attribute class names (defined at http://www.tei-c.org/P4X/ref-NAMES.html):

key

Provides an alternative identifier for the object being named, such as a database record key. This is an optional attribute, with CDATA as value type.

reg

Gives a normalised or regularised form of the name used, in the form of CDATA. This is an optional attribute.

from the TEI attribute class typed (defined at http://www.tei-c.org/P4X/ref-TYPED.html):

type

Characterises the element in some sense, using any convenient classification scheme or typology. It is an optional attribute, with as value type CDATA.

subtype

Provides a sub-categorisation of the element, if needed. It is an optional attribute with as value type CDATA.

The <idno> element, which is a standard TEI element (see http://www.tei-c.org./P4X/ref-IDNO.html), can contain an identification code in plain PCDATA format, and has one attribute apart from the global ones (see 3.3. Global attributes):

type

Characterises the element in some sense, using any convenient classification scheme or typology. It is an optional attribute, with as value type CDATA.

The following example shows a full micro-identification in the <letIdentifier> part of a DALF letter that is member of the Streuvels-Lannoo collection identified by the code S 935/62295, in which it carries the ID 71373/2882, and has a former identification code number and an alternative nickname:

<collection>S 935/62295</collection>
<idno>71373/2882</idno>
<altName type="former_id">SL410811/b</altName>
<altName type="nickname">the birthday letter</altName></repository>

The unique DALF elements <collection> and <altName> are declared as follows in the file DALFExtns.dtd:

<!ELEMENT collection %om.RR; 
          (%phrase.seq;)> 
<!ATTLIST collection
          %a.global;
          %a.names;
          %a.typed;> 

<!ELEMENT altName %om.RR;
          (%phrase.seq;)> 
<!ATTLIST altName
          %a.global;
          %a.names;
          %a.typed;>

4.2.1. The communicative participants: <author>, <addressee> and <respStmt>

The participants in the communicative act of letter writing are the writer(s) and reader(s) involved. Their communicative roles are reflected in the names of the elements <author> and <addressee>, that the encoder must use to record the author, respectively addressee of the letter. Most often, they are stated explicitly in the letter; otherwise the encoder can use other sources of evidence that can provide a plausible indication of their identities. When a letter is written by several authors, and their contributions are not encoded as separate <letPart>s in the header (see 4.8. Distinct letter parts: <letPart>), these can be identified in several <author> elements. Also, when a letter has been written to more than one addressee, several <addressee> elements can be used to enumerate all of them. Optionally, people other than the author that are responsible for some aspects of the contents can be identified in zero or more <respStmt> elements.

Note that the identification of multiple authors for a letter may arouse questions regarding the compositional structure of the letter. The encoder must decide whether the letter should be considered a whole, with distinct authors identified internally in several <author> elements within <letHeading>; or should be considered to have distinct parts, with their characteristics encoded in separate <letPart> elements within <letDesc> (see 4.8. Distinct letter parts: <letPart>).

The <author> and <addressee> elements are closely related to the TEI name class elements. Therefore, they can contain the elements of the phrase.seq class (see http://www.tei-c.org/P4X/ref-PHRSEQ.html), and the attributes from the names and typed attribute classes. Most often, the author and addressee are explicitly identified in a letter. In other cases, the encoder must try to identify them from other pieces of evidence, like the envelope or for example other letters in the correspondence chain. Therefore, the <author> and <addressee> elements have two additional attributes that can record the status of the evidence on which the identification was based. Together with the names and typed class attributes, these elements can have following attributes (besides the global ones defined in 3.3. Global attributes):

attested

Indicates the status of the contents of the element on which it appears. This is an optional attribute with one of four predefined values. The encoder can indicate whether the abstraction is made on the basis of evidence inside the letter, with value ‘yes’; additional material accompanying the letter (e.g. the envelope), with value ‘added’; derived from external evidence (e.g. a reply letter), with value ‘no’; or if the feature is unknown, with value ‘unk’.

accepted

Indicates whether the attribution made in the element is generally accepted. This is an optional attribute with one of following three values. Generally accepted attributions are encoded with value ‘yes’; attributions that are not generally accepted with ‘no’; when no claim can be made regarding this status, the value ‘unk’ is used.

from the TEI attribute class names (defined at http://www.tei-c.org/P4X/ref-NAMES.html):

key

Provides an alternative identifier for the object being named, such as a database record key. This is an optional attribute, with CDATA as value type.

reg

Gives a normalised or regularised form of the name used, in the form of CDATA. This is an optional attribute.

from the TEI attribute class typed (defined at http://www.tei-c.org/P4X/ref-TYPED.html):

type

Characterises the element in some sense, using any convenient classification scheme or typology. It is an optional attribute, with as value type CDATA.

subtype

Provides a sub-categorisation of the element, if needed. It is an optional attribute with as value type CDATA.

The <respStmt> element can be used to describe any person other than the author proper, that has contributed something to the contents of the letter, be it conceptually or physically. It must be stressed that the tracing of such contributions (non-material ones in particular) is not the most straightforward task, and should be done with meticulous care (as is the case with all aspects of the electronic edition of DALF letters, of course). It may not always be easy to distinguish between elements that are present on the document but are totally unrelated/unimportant to its contents and thus can hardly be considered as contributions, or elements that are so important they can be considered as much more than just a contribution and thus be encoded in a different way. As a rule, the encoder can safely use the <respStmt> element within <letHeading> to identify a person who typed in the letter, or provided some ideas for the contents (supposed this can be traced at all). Yet, the encoder should keep a consistent practice concerning the use of the <respStmt> for the identification of persons who made some additions to the letter. For plain additions, their author can also be identified within the scribe attribute of the <hand> element inside the <profileDesc> element of the heading (see http://www.tei-c.org./P4X/ref-HAND.html). For very lengthy and substantial contributions the encoder should consider whether their authors shouldn't better be encoded as separate authors, or even in separate <letPart> elements (see 4.8. Distinct letter parts: <letPart>). Perhaps the TEI definition of <respStmt> (see http://www.tei-c.org/P4X/ref-RESP.html) should give a good indication regarding its use: ‘(statement of responsibility) supplies a statement of responsibility for someone responsible for the intellectual content of a text, edition, recording, or series, where the specialized elements for authors, editors, etc. do not suffice or do not apply’ [italics added].

The attributes of the <respStmt> element are those defined as the global attributes (see 3.3. Global attributes). It can contain a standard TEI <resp> element (see http://www.tei-c.org/P4X/ref-ROLE.html), naming the nature of the responsibility of the person identified in a standard TEI <name> element (see http://www.tei-c.org./P4X/ref-NAME.html), and can furthermore contain the elements of the Incl element class (see Incl).

The following example illustrates the extensive identification of the communicative participants within the <letHeading> part of a DALF letter written by Streuvels to De Meyer. Here, it could be stated that Streuvels dictated the letter to his wife, who typed it in. Thus, Streuvels can be considered the intellectual author of the letter, while his wife can be attributed responsibility as scribe. Also, an idea in the letter could be attributed by the encoder to Joris Lannoo. As indicated in the attributes, both sender and addressee are identified from evidence inside the letter:

<author attested="yes">Stijn Streuvels</author>
<addressee attested="yes">Maurice De Meyer</addressee>
<respStmt>
   <resp>scribe</resp>
   <name>Alida Staelens</name>
</respStmt>
<respStmt>
   <resp>idea for the suggestion to use an instalment system of publication</resp>
   <name>Joris Lannoo</name>
</respStmt>

The unique DALF elements <author> and <addressee> are declared as follows in the file DALFExtns.dtd:

<!ELEMENT author %om.RR; 
          (%phrase.seq;)> 
<!ATTLIST author
          %a.global;
          %a.names;
          attested (yes | added | no | unk) #IMPLIED
          accepted (yes | no | unk) #IMPLIED>

<!ELEMENT addressee %om.RR;
          (%phrase.seq;)>
<!ATTLIST addressee
          %a.global;
          %a.names;
          attested (yes | added | no | unk) #IMPLIED
          accepted (yes | no | unk) #IMPLIED>

4.2.2. The place and time of writing: <placeLet> and <dateLet>

The place and time of writing can be identified respectively with <placeLet> and <dateLet>. As can be assumed that a letter is written in a short time span and at one place only, these elements can occur only once. Should the encoder wish to make some elaborations regarding this assumption for a certain letter, this can be done in the concluding <note> element of the <letHeading> element (as is the case for all DALF header elements). Often the place and time of writing are included in the salutation part of the letter; otherwise the encoder can use place and time information from the envelope or from other sources of evidence.

The <placeLet> element is closely related to the TEI name class elements. Therefore, it can contain the elements of the phrase.seq class (see http://www.tei-c.org/P4X/ref-PHRSEQ.html), and the attributes from the names and typed attribute classes. The source of evidence for the identification of the place of writing may be given in the special attested attribute. Apart from the global attributes listed in 3.3. Global attributes, <placeLet> can have following attributes:

attested

Indicates the status of the contents of the element on which it appears. This is an optional attribute with one of four predefined values. The encoder can indicate whether the abstraction is made on the basis of evidence inside the letter, with value ‘yes’; additional material accompanying the letter (e.g. the envelope), with value ‘added’; derived from external evidence (e.g. a reply letter), with value ‘no’; or if the feature is unknown, with value ‘unk’.

from the TEI attribute class names (defined at http://www.tei-c.org/P4X/ref-NAMES.html):

key

Provides an alternative identifier for the object being named, such as a database record key. This is an optional attribute, with CDATA as value type.

reg

Gives a normalised or regularised form of the name used, in the form of CDATA. This is an optional attribute.

from the TEI attribute class typed (defined at http://www.tei-c.org/P4X/ref-TYPED.html):

type

Characterises the element in some sense, using any convenient classification scheme or typology. It is an optional attribute, with as value type CDATA.

subtype

Provides a sub-categorisation of the element, if needed. It is an optional attribute with as value type CDATA.

The <dateLet> element can contain the elements of the phrase.seq class that are listed in http://www.tei-c.org/P4X/ref-PHRSEQ.html. Apart from the global attributes (see 3.3. Global attributes, the special attribute attested is provided to supply the source of the identification of the place of writing:

attested

Indicates the status of the contents of the element on which it appears. This is an optional attribute with one of four predefined values. The encoder can indicate whether the abstraction is made on the basis of evidence inside the letter, with value ‘yes’; additional material accompanying the letter (e.g. the envelope), with value ‘added’; derived from external evidence (e.g. a reply letter), with value ‘no’; or if the feature is unknown, with value ‘unk’.

The following example illustrates the extensive identification of the place and time of writing of a letter written by Stijn Streuvels to Maurice De Meyer in Ingooigem, on 13 January 1945. As indicated in the attributes, the place of writing is derived from evidence on the envelope, and the date of the letter is derived from external evidence.

<placeLet attested="added">Ingooigem</placeLet>
<dateLet attested="no">1945-01-13</dateLet>

The unique DALF elements <placeLet> and <dateLet> are declared as follows in the file DALFExtns.dtd:

<!ELEMENT placeLet %om.RR;
          (%phrase.seq;)> 
<!ATTLIST placeLet
          %a.global;
          %a.names;
          attested (yes | added | no | unk) #IMPLIED> 

<!ELEMENT dateLet %om.RR;
          (%phrase.seq;)>
<!ATTLIST dateLet
          %a.global;
          attested (yes | added | no | unk) #IMPLIED>

4.3.1. Formal characterisation: <type>

As it is imaginable that letters can be written in virtually any format, the formal characterisation of the letter can be given in a prose description. The encoder should develop a consistent typology in order to guarantee retrieval possibilities for this category. Typical values can be ‘letter’, ‘postcard’ etc. When for example for very recent authors and composers it is thought theoretically sound to include saved E-mail messages too in an electronic edition of correspondence, a format like ‘E-mail’ may be specified for <type>. The <type> element has only the global attributes (3.3. Global attributes).

The following example illustrates the <type> encoding for a postcard:

<type>
   postcard
</type>

The <type> element is declared in the DALFExtns.dtd file as follows:

<!ELEMENT type %om.RR; 
          (#PCDATA) > 
<!ATTLIST type
          %a.global;>

4.3.2. Support material: <support>

The materials that were used to write the letter on must be characterised in one or more <p> elements inside <support>. This description may cover the material of the support material (e.g. ‘paper’), the number of pages and the sides that are used.

The <support> element has no other than the global attributes (see 3.3. Global attributes), and can contain following elements:

<p>

Contains the description of the material on which the letter is written. This is a standard TEI element (see http://www.tei-c.org/P4X/ref-P.html).

For a letter written on a very thin piece of paper, the following may be a legal encoding:

<support>
   <p>very thin, semi-transparent paper</p>
</support>

The <support> element is declared in the DALFExtns.dtd file as follows:

<!ELEMENT support %om.RR; 
          (p+) > 
<!ATTLIST support 
          %a.global;>

4.3.3. Size: <extent>

The size of a letter must be described in the <extent> element, which is a standard TEI element (see http://www.tei-c.org/P4X/ref-EXTENT.html). This element may hold a plain prose description of the size of the letter, or elements from the element class that is defined in TEI P4 as phrase.seq (see http://www.tei-c.org/P4X/ref-PHRSEQ.html). A common way to express the size of the document in the header, is to use the <dimensions> tag inside <extent>. That phrase-level element can provide a structured description of the height and width of the item it represents, as well as a unit of measure.

The following example illustrates how the size of a letter can be described, using the <dimensions> element within <extent>:

<extent>
   <dimensions>
      <height units="mm">214</height>
      <width units="mm">276</width>
   </dimensions>
</extent>

4.3.4. Layout aspects: <layout>

Specific layout aspects, like the use of columns and all kinds of outstanding visual features may be expressed in <p>s inside <layout>.

The <layout> element has no other than the global attributes (see 3.3. Global attributes), and can contain following elements:

<p>

Contains the description of the layout of the letter. This is a standard TEI element (see http://www.tei-c.org/P4X/ref-P.html).

The following example illustrates how the <layout> element can be used to record that a letter has 3 columns that read from right to left:

<layout>
   <p>written in 3 columns, starting with the rightmost and continuing to the left</p>
</layout>

The <layout> element is declared in the DALFExtns.dtd file as follows:

<!ELEMENT layout %om.RR; 
          (p+) > 
<!ATTLIST layout 
          %a.global;>

4.3.5. Musical notation: <musicNotation>

Considering the outline of DALF as a Digital Archive of Letters in Flanders, focusing on letters written by authors and composers from the 19th and 20th century, it is very likely that fragments of musical notation can appear in letters. With the <musicNotation> element, the encoder can provide a typology of the notation employed. This can be done inside one or more paragraphs.

The <musicNotation> element has no other than the global attributes (see 3.3. Global attributes), and can contain following elements:

<p>

Contains the description of the kind of musical notation in the letter. This is a standard TEI element (see http://www.tei-c.org/P4X/ref-P.html).

For example, a letter containing 2 different instances of musical notation, consisting of 3 and 2 staves respectively, may be encoded as follows:

<musicNotation>
   <p>theme of "Struggle for Pleasure" in 3 staves</p>
   <p>theme of "The Scene" in 2 staves</p>
</musicNotation>

The <musicNotation> element is declared in the DALFExtns.dtd file as follows:

<!ELEMENT musicNotation %om.RR; 
          (p+) > 
<!ATTLIST musicNotation 
          %a.global;>

4.3.6. Decorative elements: <decoration> and <paraphernalia>

Letters can contain all sorts of ‘less-textual’ contents (so called because they have a non-textual nature, but still are part of the text). Although it's a theoretical issue whether or not to regard accompanying materials or ‘objets trouvés’ as a part of the letter, the DALF header provides the means to do so. A distinction is made between decorations, i.e. less-textual materials that can be regarded to have originated within the writing act, and paraphernalia, materials that did not originate within the writing act. Decorations can include drawings, schemes etc., whereas paraphernalia can include newspaper articles, hair curls, dried flowers etc. It has to be pointed out that the DALF scheme also provides the means to mark another category of material that has a somewhat closer formal (but not necessarily intellectual) bond with the letter, namely printed text that was already on the paper before the letter was written (e.g. form text), or that has been added afterwards (e.g. stamps). When these elements are not regarded as decorative elements that need meta-description in the header, they can be marked in the document itself with the <print> element discussed in 5.4. Pre- and post-printed material: <print>.

The inclusion of specific descriptive elements for these less-textual materials in the DALF header is motivated because of the potential importance of decorations and paraphernalia for genetic studies. In view of the size and diversity of the DALF textbase, it could be very interesting to have the means to search the archive for specific instances of less-textual materials.

Both the <decoration> and <paraphernalia> elements have the same structure. They can either contain a loose prose description in one or more <p>s, or a structured description per decorative item concerned. The latter is conceived as a list, consisting of a <decoList>, respectively <paraphList> element. These must contain one or more <decoItem> or <paraphItem> elements, one per decorative item in the document. Those list items must contain a description of the decorative item, in <decoDesc> or <paraphDesc>. Optionally, also text appearing within the decorative item can be recorded in <decoText> or <paraphText>. Both the description and the recording of the text must go in one or more paragraphs. The following list gives a more formal overview of the contents of the structured descriptions inside <decoration> and <paraphernalia>. Although both systems are clearly distinct, they do have a similar structure, which is the only reason why they are discussed alongside each other.

<decoList> and <paraphList>

Contains a list of structured descriptions for each of the decorations, respectively paraphernalia in a letter.

<decoItem> and <paraphItem>

Contains a structured description of a decoration, respectively paraphernalia in a letter.

<decoDesc> and <paraphDesc>

Contains a description of a decoration, respectively paraphernalia in a letter, inside one or more <p> elements (see http://www.tei-c.org/P4X/ref-P.html).

<decoText> and <paraphText>

Contains a rendering of text found as the contents of a decoration, respectively paraphernalia. This has to be done within one or more <p> elements (see http://www.tei-c.org/P4X/ref-P.html).

<p>

Contains a loose description of the decorations, respectively paraphernalia in the letter. This is a standard TEI element (see http://www.tei-c.org/P4X/ref-P.html).

All of these elements have only the global attributes (see 3.3. Global attributes). The following example shows how a letter containing two drawings (one of which containing text) and a dried flower attached to it, can be encoded in the DALF header:

<decoration>
   <decoList>
      <decoItem id="fig1">
         <decoDesc>
            <p>small black/white drawing of a tree</p>
         </decoDesc>
      </decoItem>
      <decoItem id="fig2">
         <decoDesc>
            <p>small color drawing of suggested page layout, containing some text</p>
         </decoDesc>
         <decoText>
            <p>Eerste paragraaf Hier</p>
            <p>voetnoten!</p>
         </decoText>
      </decoItem>
   </decoList>
</decoration>
<paraphernalia>
   <paraphList>
      <paraphItem id="obj1">
         <paraphDesc>
            <p>dried petal of a poppy</p>
         </paraphDesc>
      </paraphItem>
   </paraphList>
</paraphernalia>

This list construction is modelled after the TEI mechanism of identifying and referring to different document hands (see http://www.tei-c.org./P4X/ref-HAND.html). This means that in the header the definitions discussed above are provided for less-textual elements in the text. When doing so, the encoder must provide each of the <decoItem> and <paraphItem> elements with a unique value for the id attribute. When those instances are encoded in the text, the specific empty DALF elements <deco /> and <paraph /> can indicate their occurrence, and refer to the description in the header. These text elements are explained in the next section (5.5. Decorative elements: <deco /> and <paraph />), but the following example illustrates how the decorations and paraphernalia that were identified in the previous example can be referred to:

<text>
   ...
   <p>Een grote boom stond daar <deco decoRef="fig1" />, 
   met aan zijn voet een mooie papaver <paraph paraphRef="obj1" />.</p>
   ...
   <p>Ik stel mij de pagina zo voor: <deco decoRef="fig2" /></p>
   ...
</text>

The <decoration> and <paraphernalia> elements and their unique DALF child elements are declared in the DALFExtns.dtd file as follows:

<!ELEMENT decoration %om.RR; 
          (decoList | p+)> 
<!ATTLIST decoration 
          %a.global;> 

<!ELEMENT decoList %om.RR;
          (decoItem+)> 
<!ATTLIST decoList 
          %a.global;> 

<!ELEMENT decoItem %om.RR;
          (decoDesc, decoText?)>
<!ATTLIST decoItem
          %a.global;>

<!ELEMENT decoDesc %om.RR;
          (p+)>
<!ATTLIST decoDesc 
          %a.global;>

<!ELEMENT decoText %om.RR;
          (p+)>
<!ATTLIST decoText 
          %a.global;>

<!ELEMENT paraphernalia %om.RR; 
          (paraphList | p+)> 
<!ATTLIST paraphernalia 
          %a.global;> 

<!ELEMENT paraphList %om.RR; 
          (paraphItem+)> 
<!ATTLIST paraphList 
          %a.global;> 

<!ELEMENT paraphItem %om.RR;
          (paraphDesc, paraphText?)>
<!ATTLIST paraphItem
          %a.global;>

<!ELEMENT paraphDesc %om.RR;
          (p+)>
<!ATTLIST paraphDesc
          %a.global;>

<!ELEMENT paraphText %om.RR;
          (p+)>
<!ATTLIST paraphText 
          %a.global;>

4.3.7. The physical condition: <condition>

The physical condition of the letter can be encoded inside one or more <p> elements in the <condition> element. There are no other than the global attributes for this element (3.3. Global attributes).

<p>

Contains the description of the physical condition of the letter. This is a standard TEI element (see http://www.tei-c.org/P4X/ref-P.html).

The following example illustrates how the <condition> element can be used to record that a letter has the right corner missing, and has places on the folding lines that are torn:

<condition>
   <p>topright corner is missing</p>
   <p>the folding lines have caused some tears</p>
</condition>

The <condition> element is declared in the DALFExtns.dtd file as follows:

<!ELEMENT condition %om.RR; 
          (p+) > 
<!ATTLIST condition 
          %a.global;>

4.7.1. Administrative information: <adminInfo>

This element is used to record statements about the availability of a letter, its custodial history and possible additional remarks regarding the cataloguing description the encoder would like to make.

The <adminInfo> element has only the global attributes (see 3.3. Global attributes) and can contain the following elements:

<availability>

Supplies information about the availability of a letter. This is a standard TEI element (see http://www.tei-c.org/P4X/ref-AVAIL.html).

<custodialHist>

Contains a description of the custodial history of a letter, inside one or more <custEvent> elements:

<custEvent>

Describes a single event related to the custodial history of a letter.

<note>

Contains additional remarks, not yet covered in the preceding elements. This is a standard TEI element (see http://www.tei-c.org/P4X/ref-NOTE.html).

<remarks>

Contains any comments or remarks not forming part of the description proper, for use by the cataloguer.

<note>

Contains additional remarks, not yet covered in the preceding elements. This is a standard TEI element (see http://www.tei-c.org/P4X/ref-NOTE.html).

None of these elements is required in particular; yet at least one of <availability>, <custodialHist> or <remarks> must be present. When some (or all) are used, they must occur in the order specified. The final descendants of each of these elements all have the same structure. Their respective descriptions have to be included in one or more paragraphs:

(Content model for <availability>, <custEvent> and <remarks>:)

<p>

Contains the description of a the availability status, respecively an event in the custodial history, or additional cataloguing remarks for a letter. This is a standard TEI element (see http://www.tei-c.org/P4X/ref-P.html).

All of the child elements of <adminInfo> can have the global attributes (see 3.3. Global attributes). Two of them have special attributes:

<availability>

status

Supplies a code indicating the current availability of a letter. This is an optional attribute with one of three predefined values. When a letter is freely available, this can be coded with the value ‘free’; when it is not, the value ‘restricted’ can be used; when the availability status is unknown, the value ‘unknown’ can be used.

<custEvent>

type

Characterises the element in some sense, using any convenient classification scheme or typology. It is an optional attribute, with as value type CDATA.

Because <adminInfo> requires just the presence of one of its child elements without specifying any in particular, a minimal description of additional administrative information for the letter in the following example could lack any of the child elements, provided that at least one remains and that the order in which they appear is respected:

<adminInfo>
   <availability status="restricted">
      <p>Available for academic research purposes only.</p>
   </availability>
   <custodialHist>
      <custEvent type="loan">
         <p>from 13 January 1955 to 3 March 1956, the letter was given on loan to
         the university of Amsterdam</p>
      </custEvent>
   </custodialHist>
   <remarks>
      <p>maybe this letter can turn out significant for the retracing of the
      missing letters by Streuvels to Excelsior between 1926 and 1928</p>
   </remarks>
</adminInfo>

The <adminInfo> element and its unique DALF child elements are declared in the DALFExtns.dtd file as follows:

<!ELEMENT adminInfo %om.RR; 
          ((availability, custodialHist?, remarks?, note*) |
          (custodialHist, remarks?, note*) | (remarks, note*))> 
<!ATTLIST adminInfo 
          %a.global;> 

<!ELEMENT custodialHist %om.RR; 
          (custEvent+, note*)> 
<!ATTLIST custodialHist 
          %a.global;> 

<!ELEMENT custEvent %om.RR; 
          (p+)> 
<!ATTLIST custEvent 
          %a.global;
          type CDATA #IMPLIED> 

<!ELEMENT remarks %om.RR; 
          (p+)> 
<!ATTLIST remarks
          %a.global;>

4.7.2. Other representations: <surrogates>

If a letter has incarnations in other representation formats, those can be described in the optional <surrogates> element. Typically, this will be digital or photographic copies of the letter.

The <surrogates> element has only the global attributes (see 3.3. Global attributes), and contains a description of the representation in one or more paragraphs:

<p>

Contains the description of a representation in another form of a letter. This is a standard TEI element (see http://www.tei-c.org/P4X/ref-P.html).

The following example illustrates the description of a digital facsimile of a letter:

<surrogates>
   <p>
      <bibl>
         digital facsimile, saved as JPEG image file
         <title type="filename">LS081141.jpg</title>
         <idno>AMVC 911/5 jpg</idno>
         <date>September 1996</date>
      </bibl>
   </p>
</surrogates>

The <surrogates> element is declared in the DALFExtns.dtd file as follows:

<!ELEMENT surrogates %om.RR;
          (p+)> 
<!ATTLIST surrogates 
          %a.global;>

4.7.3. Accompanying materials: <accMat>

Sometimes, some external materials can be very closely related to a letter. They can accompany a letter in the same envelope, or can be stored together in an archive for some reason. Such accompanying materials can be described with the optional <accMat> element.

The <accMat> element has one special attribute apart from the global ones (see 3.3. Global attributes):

type

Characterises the element in some sense, using any convenient classification scheme or typology. It is an optional attribute, with as value type CDATA.

It provides a description for each piece of accompanying material in at leas one paragraph:

<p>

Contains the description of a piece of material which accompanies or is closely related to a letter. This is a standard TEI element (see http://www.tei-c.org/P4X/ref-P.html).

The following example shows the description of a copied tax form which accompanied a letter:

<accMat type="external_document">
   <p>A copy of a tax form from 1947 is included in the envelope 
   with the letter. It is not catalogued separately.</p>
</accMat>

The <accMat> element is declared in the DALFExtns.dtd file as follows:

<!ELEMENT accMat %om.RR;
          (p+)> 
<!ATTLIST accMat 
          %a.global;
          type CDATA #IMPLIED>

4.7.4. Appearance in published materials: <listBibl>

The last optional element inside <additional> is <listBibl>. This is a standard TEI element that in this context should hold information about representations of the letter available within any published works. When for example a letter has been included in an existing edition, a bibliographical record for that edition can be provided inside one or more <bibl> or <biblFull> elements inside <listBibl> (for an exhaustive listing of the possible contents and attributes of <listBibl>, see http://www.tei-c.org/P4X/ref-LISTBIBL.html). The purpose of this <listBibl> element is thus clearly distinct from that of the <surrogates> and <accMat> elements described earlier: <surrogates> (see 4.7.2. Other representations: <surrogates>) only describes other forms in which the letter is stored, and <accMat> describes materials accompanying the letter.

For a letter that has been included in a previously published edition, the following example illustrates how the <listBibl> element inside <additional> is the right place for a bibliographical description of this edition. Note that for illustrative purposes, two editions are described: an electronic and an ‘analog’ one:

<listBibl>
   <bibl>This letter is included in
      <author>Marcel De Smedt &amp; Edward Vanhoutte</author>
      <title>Stijn Streuvels, De Teleurgang van den Waterhoek.
      Elektronisch-kritische editie/electronic-critical edition.</title>
      <pubPlace>Amsterdam</pubPlace>
      <publisher>Amsterdam University Press/KANTL</publisher>
      <date>2000</date>
      <idno type="ISBN">90-5356-441-1 (CD-Rom)</idno>
   </bibl>
   <bibl>This letter is included in
      <author></author>
      <title>Uitgeverij Lannoo, de vroege jaren</title>
      <pubPlace>Tielt</pubPlace>
      <publisher>Lannoo uitgeverij</publisher>
      <date>2001</date>
   </bibl>
</listBibl>