-
Notifications
You must be signed in to change notification settings - Fork 0
/
addresses.xml
234 lines (234 loc) · 16.2 KB
/
addresses.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
<?xml version="1.0" encoding="UTF-8"?><TEI xmlns="http://www.tei-c.org/ns/1.0" xml:id="addresses">
<teiHeader>
<fileDesc>
<titleStmt>
<title>Addresses</title>
<author key="trautmann">Marjam Trautmann</author>
</titleStmt>
<publicationStmt>
<publisher>Berlin-Brandenburg Academy of Sciences and Humanities</publisher>
<date when="2020-01-28"/>
<idno type="urn">urn:nbn:de:kobv:b4-20200421172505303-5921001-2</idno>
<idno type="url">https://encoding-correspondence.bbaw.de/v1/addresses.html</idno>
<idno type="zotero">https://www.zotero.org/groups/2248469/encoding_correspondence/items/itemKey/TFR6AZQS</idno>
</publicationStmt>
<seriesStmt>
<title type="main">Encoding Correspondence.</title>
<title type="sub">A Manual for encoding letters and postcards in TEI-XML and
DTABf</title>
<editor>Stefan Dumont</editor>
<editor>Susanne Haaf</editor>
<editor>Sabine Seifert</editor>
<idno type="urn">urn:nbn:de:kobv:b4-20200110163329488-8695229-7</idno>
<idno type="url">https://encoding-correspondence.bbaw.de/v1/</idno>
<biblScope unit="edition">v1</biblScope>
</seriesStmt>
<sourceDesc>
<p>Born digital.</p>
</sourceDesc>
</fileDesc>
<revisionDesc>
<listChange>
<change n="1" when="2020-01-28" status="draft">Initial Version</change>
</listChange>
</revisionDesc>
</teiHeader>
<text>
<body>
<div xml:id="c-1">
<head>Introduction</head>
<p n="1">Regarding the current Guidelines of the Text Encoding Initiative P5, the element
<gi>address</gi> contains a postal address, e.g. of a publisher, an organization
or an individual.<note n="1" xml:id="fn1"><ref target="https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-address.html">https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-address.html</ref>.</note>
Several children of the <gi>address</gi> element are available, depending on the
modules which are integrated in the schema. When applying the <gi>address</gi>
element and its inherent attributes and child elements, there are three central and
problematic issues regarding the encoding of addresses in letters and postcards.</p>
</div>
<div xml:id="c-2">
<head>Issue 1: Missing attribute @type for the <gi>address</gi> element</head>
<p n="2">Letters, 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.</p>
<p n="3">For the metadata, the <gi>correspAction</gi> element can be used that has a type
attribute either with the value 'sent' or 'received'.<note n="2" xml:id="fn2"><ref target="https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-correspAction.html">https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-correspAction.html</ref>.</note>
In the transcription, however, there is the need of the attribute @type for the
<gi>address</gi> element, which is not allowed according to the TEI P5 Guidelines.
One possibility could be to add the element <gi>address</gi> 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 <gi>div</gi> or
<gi>ab</gi>.</p>
<figure>
<head>Example 1: Field postcard (source: Franz Marc to Herwarth Walden, 13 November
1914, in: Der STURM. Digitale Quellenedition zur Geschichte der internationalen
Avantgarde, <ref target="https://sturm-edition.de/id/Q.01.19141113.FMA.01">https://sturm-edition.de/id/Q.01.19141113.FMA.01</ref>.</head>
<graphic url="../images/addresses/example1.png"/>
</figure>
<p n="4">The addresses of both sender and recipient in example 1 could be encoded like
this:<note n="3" xml:id="fn3">Encoding taken from <ref target="https://sturm-edition.de/api/files/Q.01.19141113.FMA.01.xml">https://sturm-edition.de/api/files/Q.01.19141113.FMA.01.xml</ref>.</note>
</p>
<p n="5"><egXML xmlns="http://www.tei-c.org/ns/Examples">
<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>
</egXML></p>
<p n="6">In this example, the addresses of sender and recipient are distinguished from one
another by using the <gi>ab</gi> element with a @type attribute containing the values
'sender' and 'recipient'. The <gi>div</gi> 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.</p>
<p n="7">This leads to the second issue, the problem of the <gi>address</gi> element being not
allowed before <gi>opener</gi> or after <gi>closer</gi>. Finally, we want to discuss
the encoding of address transcriptions within the elements <gi>opener</gi> or
<gi>closer</gi> in order to implement the current standard.</p>
</div>
<div xml:id="c-3">
<head>Issue 2: <gi>address</gi> before <gi>opener</gi> and after <gi>closer</gi></head>
<p n="8">The <gi>address</gi> element is not part of the content model of <gi>div</gi>. This
means that it cannot appear directly inside a <gi>div</gi> and this also means that
it is not allowed before model.divTopPart or after model.divBottomPart elements, e.g.
<gi>opener</gi> or after <gi>closer</gi>. So, if the encoder wants to model the
addresses of recipient(s) and sender(s) as a separate structural block within the
<gi>text</gi> element and wants to put the addresses before the <gi>opener</gi> or
after <gi>closer</gi> of a letter, he or she needs to construct an elaborate data
model with the addresses and the <gi>opener</gi>/<gi>closer</gi> encoded in several
<gi>div</gi> elements:</p>
<p n="9"><egXML xmlns="http://www.tei-c.org/ns/Examples">
<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>
</egXML></p>
<p n="10">In the encoding example above, the <gi>address</gi> element is part of an <gi>ab</gi>
element inside a <gi>div</gi> 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
<gi>div</gi> siblings was chosen. Instead of <gi>div</gi> one could choose the
element <gi>ab</gi> but in the example the <gi>ab</gi> element is used to identify
the sender or addressee.</p>
<p n="11">To avoid such an unnecessary elaborate encoding, it would be convenient to be able to
use <gi>address</gi> directly inside a <gi>div</gi>. Could a possible solution be to
assign the element <gi>address</gi> to a suitable additional class, like
model.divTopPart and model.divBottomPart?<note n="4" xml:id="fn4"><ref target="https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-model.divTopPart.html">https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-model.divTopPart.html</ref>,
<ref target="https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-model.divBottomPart.html">https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-model.divBottomPart.html</ref>.</note>
We would like to put this question to the community for further discussion.</p>
<p n="12">What 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 <gi>div</gi> structures? A proposal for discussion is given
in the following section.</p>
</div>
<div xml:id="c-4">
<head>Issue 3: <gi>address</gi> within <gi>opener</gi> or <gi>closer</gi>
</head>
<p n="13">Another solution could be to include the transcription of the address in the
<gi>opener</gi> or <gi>closer</gi>. Here, the <gi>address</gi> element is allowed.
The <gi>opener</gi> "combines date line, author, salutation and similar phrases that
are used at the beginning of a section, especially in a letter".<note n="5" xml:id="fn5"><ref target="https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-opener.html">https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-opener.html</ref>.</note>
The <gi>closer</gi> contains "greeting formulas, date lines and similar phrases that
appear at the end of a section, especially in a letter".<note n="6" xml:id="fn6"><ref target="https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-closer.html">https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-closer.html</ref>.</note>
This variant would make the division of the transcribed correspondence text into
individual <gi>div</gi> and/or <gi>ab</gi> elements obsolete and would be a slimmer
version of the above issue.</p>
<p n="14">Example 1 with <gi>address</gi> encoded within <gi>opener</gi>:</p>
<egXML xmlns="http://www.tei-c.org/ns/Examples">
<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>
</egXML>
<p n="15">For establishing a standard for encoding postal addresses in <gi>opener</gi> or
<gi>closer</gi>, 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 <gi>address</gi>—as already explained in Issue 1.</p>
</div>
<div xml:id="c-5">
<head>Proposal</head>
<p n="16">Considering the discussed issues, editing of the TEI Guidelines regarding the
<gi>address</gi> element seems to be recommended concerning the inclusion of the
attribute @type for the <gi>address</gi> 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'.</p>
<p n="17">For the development of a TEI standard for encoding the transcription of addresses, we
first considered the idea of using the <gi>address</gi> element directly within an
<gi>div</gi> element to avoid the use of further child elements inside
<gi>div</gi>. Here we want to discuss whether it would be useful to assign it to
suitable classes, for example model.divTopPart and model.divBottomPart.</p>
<p n="18">To get around the separation of transcriptions into different <gi>div</gi> structures
according to the current Guidelines, we propose in Issue 3 as an alternative to code
the addresses of sender and receiver within <gi>opener</gi> or <gi>closer</gi>. For
this, we propose to adapt the definition of <gi>opener</gi> and <gi>closer</gi> 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.</p>
</div>
</body>
</text>
</TEI>