Status of this article

Draft. Public peer review in progress.

We kindly invite you to review and/or comment this article! Please do so via the web annotation service Hypothes.is or with an e-mail to encoding-correspondence@bbaw.de.

This article remains stable and citable in the first version of this manual. The revised article will be published in the second edition of the manual.

Table of Content

Addresses

Marjam Trautmann

Introduction

  1Regarding the current Guidelines of the Text Encoding Initiative P5, the element <address> contains a postal address, e.g. of a publisher, an organization or an individual.[1] Several children of the <address> element are available, depending on the modules which are integrated in the schema. When applying the <address> element and its inherent attributes and child elements, there are three central and problematic issues regarding the encoding of addresses in letters and postcards.

Issue 1: Missing attribute @type for the <address> element

  2Letters, postcards or telegrams have a sender and an addressee. In some cases both addresses are mentioned in the correspondence and are part of the transcription, not only of the metadata. Here, it would be convenient to be able to distinguish the address of the sender from the one of the addressee, or of any other person mentioned in the text. Furthermore, it might be necessary to distinguish between a private address and a business address, or between postal and e-mail address.

  3For the metadata, the <correspAction> element can be used that has a type attribute either with the value 'sent' or 'received'.[2] In the transcription, however, there is the need of the attribute @type for the <address> element, which is not allowed according to the TEI P5 Guidelines. One possibility could be to add the element <address> to the class 'att.typed'. Currently, this lack can only be filled with several constructions, often by adding an attribute @type to structural elements like <div> or <ab>.

Example 1: Field postcard (source: Franz Marc to Herwarth Walden, 13 November 1914, in: Der STURM. Digitale Quellenedition zur Geschichte der internationalen Avantgarde, https://sturm-​edition.de/id/Q.01.19141113.FMA.01.

  4The addresses of both sender and recipient in example 1 could be encoded like this:[3]

  5


<div type="address">
<ab type="sender">
<address>
<addrLine>U. Off. Marc</addrLine>
<addrLine>Bayr. Ersatz Division</addrLine>
<addrLine>1. Ers. Abt. (Schilling)</addrLine>
<addrLine>des 1. Feld-A. Rgt.</addrLine>
<addrLine>Leichte-Munitions-Kolonne</addrLine>
</address>
</ab>
<ab type="recipient">
<address>
<addrLine>Herrn</addrLine>
<addrLine>Herwarth W<hi rend="underline">ald</hi>en</addrLine>
<addrLine>Verlag „Sturm“</addrLine>
<addrLine>Berlin W. 9.</addrLine>
<addrLine>134/a Potsdamerstrasse</addrLine>
</address>
</ab>
</div>

  6In this example, the addresses of sender and recipient are distinguished from one another by using the <ab> element with a @type attribute containing the values 'sender' and 'recipient'. The <div> element, however, is used to differentiate between parts of the texts like the address and the content of the postcard, again with a @type attribute.

  7This leads to the second issue, the problem of the <address> element being not allowed before <opener> or after <closer>. Finally, we want to discuss the encoding of address transcriptions within the elements <opener> or <closer> in order to implement the current standard.

Issue 2: <address> before <opener> and after <closer>

  8The <address> element is not part of the content model of <div>. This means that it cannot appear directly inside a <div> and this also means that it is not allowed before model.divTopPart or after model.divBottomPart elements, e.g. <opener> or after <closer>. So, if the encoder wants to model the addresses of recipient(s) and sender(s) as a separate structural block within the <text> element and wants to put the addresses before the <opener> or after <closer> of a letter, he or she needs to construct an elaborate data model with the addresses and the <opener>/<closer> encoded in several <div> elements:

  9


<body>
<div type="address">
<ab type="sender">
<address>
<addrLine>U. Off. Marc</addrLine>
<addrLine>Bayr. Ersatz Division</addrLine>
<addrLine>1. Ers. Abt. (Schilling)</addrLine>
<addrLine>des 1. Feld-A. Rgt.</addrLine>
<addrLine>Leichte-Munitions-Kolonne</addrLine>
</address>
</ab>
<ab type="recipient">
<address>
<addrLine>Herrn</addrLine>
<addrLine>Herwarth W<hi rend="underline">ald</hi>en</addrLine>
<addrLine>Verlag „Sturm“</addrLine>
<addrLine>Berlin W. 9.</addrLine>
<addrLine>134/a Potsdamerstrasse</addrLine>
</address>
</ab>
</div>
<pb xml:id="S.193r" n="193r" facs="http://resolver.staatsbibliothek-berlin.de/SBB0000DAB200000002"/>
<div type="content">
<opener>
<dateline> Ha - - <date when="1914-11-13">13 XI/14</date>
</dateline>
<salute>Lieber <persName>Walden</persName>, </salute>
</opener>
</div>
</body>

10In the encoding example above, the <address> element is part of an <ab> element inside a <div> element with the attribute @type="address". In order to place the transcription of the addresses and the transcription of the remaining content at the same semantic level, the separation of the transcriptions in <div> siblings was chosen. Instead of <div> one could choose the element <ab> but in the example the <ab> element is used to identify the sender or addressee.

11To avoid such an unnecessary elaborate encoding, it would be convenient to be able to use <address> directly inside a <div>. Could a possible solution be to assign the element <address> to a suitable additional class, like model.divTopPart and model.divBottomPart?[4] We would like to put this question to the community for further discussion.

12What other actual coding possibilities could be used to label the address transcriptions of correspondence without separating them from the transcription of the remaining letter by <div> structures? A proposal for discussion is given in the following section.

Issue 3: <address> within <opener> or <closer>

13Another solution could be to include the transcription of the address in the <opener> or <closer>. Here, the <address> element is allowed. The <opener> "combines date line, author, salutation and similar phrases that are used at the beginning of a section, especially in a letter".[5] The <closer> contains "greeting formulas, date lines and similar phrases that appear at the end of a section, especially in a letter".[6] This variant would make the division of the transcribed correspondence text into individual <div> and/or <ab> elements obsolete and would be a slimmer version of the above issue.

14Example 1 with <address> encoded within <opener>:


<body>
<opener>
<address type="sender">
<addrLine>U. Off. Marc</addrLine>
<addrLine>Bayr. Ersatz Division</addrLine>
<addrLine>1. Ers. Abt. (Schilling)</addrLine>
<addrLine>des 1. Feld-A. Rgt.</addrLine>
<addrLine>Leichte-Munitions-Kolonne</addrLine>
</address>
<address type="recipient">
<addrLine>Herrn</addrLine>
<addrLine>Herwarth W<hi rend="underline">ald</hi>en</addrLine>
<addrLine>Verlag "Sturm"</addrLine>
<addrLine>Berlin W. 9.</addrLine>
<addrLine>134/a Potsdamerstrasse</addrLine>
</address>
<dateline> Ha - - <date when="1914-11-13">13 XI/14</date>
</dateline>
<salute>Lieber <persName>Walden</persName>,</salute>
</opener>
<p><!--text of letter--></p>
</body>

15For establishing a standard for encoding postal addresses in <opener> or <closer>, a modification of the definition of these two elements remains to be considered. As it is now, the postal addresses are interpreted as 'similar phrases'. In view of the concrete and also frequent use case a reformulation would be welcome (e.g. 'combines postal addresses, date line, author, salutation and similar phrases')—should it be decided to use this way as standard of address encoding. To distinguish the addresses of recipients and senders it is recommended to introduce an @type for <address>—as already explained in Issue 1.

Proposal

16Considering the discussed issues, editing of the TEI Guidelines regarding the <address> element seems to be recommended concerning the inclusion of the attribute @type for the <address> element with indivually chosen values (possibly 'sender', 'recipient'/'receiver', 'private_address' or 'business_address' etc.). Furthermore, it should probably be added to the class 'att.typed'.

17For the development of a TEI standard for encoding the transcription of addresses, we first considered the idea of using the <address> element directly within an <div> element to avoid the use of further child elements inside <div>. Here we want to discuss whether it would be useful to assign it to suitable classes, for example model.divTopPart and model.divBottomPart.

18To get around the separation of transcriptions into different <div> structures according to the current Guidelines, we propose in Issue 3 as an alternative to code the addresses of sender and receiver within <opener> or <closer>. For this, we propose to adapt the definition of <opener> and <closer> for the application to postal addresses. We are looking forward to further suggestions and proposals by the community for the development of a standard to encode addresses in correspondences.

Citation

Marjam Trautmann: Addresses. In: Encoding Correspondence. A Manual for Encoding Letters and Postcards in TEI-XML and DTABf. Edited by Stefan Dumont, Susanne Haaf, and Sabine Seifert. Berlin 2019–2020. URL: https://encoding-correspondence.bbaw.de/v1/addresses.html URN: urn:nbn:de:kobv:b4-20200421172505303-5921001-2Zotero

 Download TEI-XML source of this article on GitHub