1The Oxford English Dictionary defines postscript as:
A paragraph or passage written at the end of a letter, after the signature, containing an afterthought or additional matter.(OED, entry 148663)
2This definition may be read in two ways: First, it may mean that the existence of a postscript is tied to the place where it stands; second, “written at the end” and “after” might be temporal expressions, referring to the time when the postscript was written rather than its actual place. In any case, a postscript is recognized as a text additional to the main text of a letter, written some time after the “main” letter was finished and put somewhere behind the main text.
3For the concept of postscript, the TEI offers an element <postscript> which is defined without any restrictions to where it is located:
<postscript> contains a postscript, e.g. to a letter.(TEI P5 3.6.0: ref-postscript
4This explanation does not say a lot but the more detailed TEI documentation offers more information:
A postscript is a passage added after the signature of a letter or, less frequently, the main portion of the body of a book, article, or essay. In English a postscript is often abbreviated as P.S. or PS, and postscripts are often introduced by labels with one of these abbreviations [...].(TEI P5 3.6.0, ch. 4.2.3: Arguments, Epigraphs, and Postscripts)
5While the short description does not mention any restrictions, the more elaborate documentation also specifies that a postscript is “added after the signature”. Indeed, the formal TEI specification then adds restrictions by making the element <postscript> a member of the class model.divBottomPart. Restrictions have already been loosened in 2011 after a discussion about problems using postscript in real world examples. Compared to the options back then, the element <postscript> is much more flexible by now. However, there are still cases which raise insecurities on how to handle their encoding properly or which even cannot be handled sufficiently with the current TEI toolbox. These problems, a range of possible solutions and some recommendations will be presented in the following parts of this chapter.
Encoding of Postscripts—State of the Art
6For the encoding of simple postscripts, the TEI offers the <postscript> element. This element belongs to the models model.divTopPart and model.divBottomPart, which means it can be inserted at the beginning or end of a devision. A frequent and usual case is a postscript behind a closing salutation, as in example 1.
7The encoding of this example is quite simple and straightforward:
<div type="letter"> [...] <p>Amüſire Dich recht gut und ſei luſtig, denn wer<lb/> lacht, kann keine Todſünd' thun.</p><lb/> <closer> <signed>Deine Freundin<lb/> Eliſabeth Goethe.</signed> </closer> <postscript> <p>Nach dem Wolfgang frägſt Du ja gar nicht; ich<lb/> hab' Dir's ja immer geſagt: wart' nur bis einmal ein<lb/> andrer kommt, ſo wirſt Du ſchon nicht mehr nach ihm<lb/> ſeufzen.</p> </postscript> </div>
8The <postscript> element may contain a couple of elements for internal structuring, as e.g. <p>, <label>, and even <opener>, <closer>, or <signed>.
Issue 1: Postscript in/with Complex Text Structure
Description of Issue 1
9As mentioned before, postscripts are not always represented by simple paragraphs without any structure. Very often, they contain salutations, datelines, or even more elaborate structures. They can also be accompanied by other postscripts with different potential relations: there can be several postscripts lined up after a letter which are related to the respective letter; a subsequent postscript might be referring to the preceding postscript; or a postscript can be part of a superordinate postscript. Example 2 illustrates some of the possible variation with regard to postscripts.
Solutions to Issue 1
10The TEI already allows for the usage of more than one postscript in a <div> structure. So, in case there are subsequent postscripts following a letter as in example 2, these can simply be encoded each with its own <postscript> element. It is also already possible to subordinate postscripts to one another. The encoding of the above example could then be as follows:
11If the internal structure of a postscript becomes very elaborate, it might be reasonable to yield to div type="postscript" in order to properly represent the structures contained by the postscript. In a TEI mailing list discussion of such cases, this was already stated by the TEI Council to be the preferred encoding solution. Several writing sessions each with its own postscript can be represented in subordinate <div> elements within the <div> that contains the whole letter:
<div type="letter"> <div type="writingSession"> <p>[...]</p> <closer><salute>[Salutation here]</salute></closer> <postscript><p>[Postscript here]</p></postscript> <postscript><p>[Another postscript here]</p></postscript> </div> <div type="writingSession"> <p>[...]</p> <postscript><p>[...]</p></postscript> </div> </div>
12An example for such encoding can be found in a letter by Carl Maria von Weber’s correspondents to the composer (example 3). The letter was written by two authors and was encoded in two separate writing session divisions.
Encoding problems around Postscript
13As already mentioned above, “behind” or “after” a written text does not always have to mean “at the bottom of” that text. In fact, the postscript may have been written somewhere along the pages where there was still some space left, it may occur in front of other items of the letter, e.g. a dateline, even in front of the whole letter, it may have been divided into several parts if space was limited, it may have evolved into a quite elaborate text with more complex structures, and – probably the most irritating case – it may even contain the main information of the letter.
Issue 2: Locations of Postscripts
Description of Issue 2
14As stated above the postscript can be found at locations other than the bottom of a letter. The first case is illustrated in Example 3. Here, the postscript is scribbled on the left margin of one (not the last) page of a letter. The conclusion of that letter can be found on one of the following pages.
15Secondly, a probably very rare (though existing) case is that a postscript was written at the beginning of a letter, as cited in Example 4.
16This second case was discussed on the TEI mailing list and the person raising the issue stated: “isn't this a postscript, regardless of its position? And presumably it was placed there after the body of the letter had been written.”
17So, the argument for calling the text a postscript here is the time when, not the place where it presumably was written.
18A third case is a postscript written behind the final salutation but in front of the dateline (Example 5).
Discussion of Issue 2
19There are two obvious ways how one might want to handle Examples 3 and 4.
20(1) First, the postscript could be transcribed at the end of the letter because ‘it is meant as’ final remark and was probably written down after the letter was finished. An editor’s comment could then specify where the text was originally found. However, if an edition uses <pb> elements to indicate the pages of the original document, the postscript text would need a separate <pb> or else it would be formally assigned to the last page of the letter. The latter would be incorrect with regard to the source document. The former would mean, page break elements have to be linked among each other and would result in a higher number of <pb> elements than there are pages in the source document. This is a possible scenario, but it would have to be communicated quite clearly to the users in order to avert errors in further processing.
21(2) Another possibility would be to transcribe and tag the postscript on the page where it was written. This approach, however, is not yet supported by the TEI Guidelines, neither if a postscript was written somewhere in the middle of a letter text (ex. 12), nor, if it is entered at the beginning of a letter (ex. 13): the <postscript> element is part of the TEI Guidelines class model.divBottomPart. A workaround could be to use the <note> element, e.g. as note type="postscript". But can a postscript really be characterized as a note? And if so, why not use <note> for it everywhere? It seems that there should be another way given that the TEI Guidelines already contain a <postscript> element.
22As for Examples 3 and 4, closeness to the source seems to be an important argument in favor of the handling proposed in (2). Example 5 raises the question if it were semantically correct to assign a postscript to the <closer> element, or if, in contrast, it interrupts the closer in the current case, or if the dateline is not part of the closer here, or anywhere, or if it belongs to the closer. So here, an area of interpretation is reached where decision taking might better be delegated to the editor, while the format is purposely designed to allow for the different possible ways of encoding.
Solutions to Issue 2
23For the issue described here, we propose two modifications of the TEI Guidelines:
24<postscript> should become a possible subelement of <p>. Formally, it could have a distribution similar to the <note> element, i.e. in encoding, <postscript> may interrupt running text. Thus, in this scenario, <postscript> might become member of the class model.noteLike.
25This way, it would e.g. easily be possible to annotate postscripts scribled at the margin of a page (Example 3). This handling is preferred to using the <note> element for this case, which would be misleading with regard to the text type under consideration, or to using <seg>, which would be too unspecific, given that the element <postscript> already exists in the TEI Guidelines.
26Furthermore, the <postscript> element should be supplied with an attribute @place to indicate the place where the postscript is entered on the page. So, the <postscript> element should become a member of class att.placement. These modifications are accompanied with some proposed ground rules for transcription:
27If the postscript is found at the left margin of a page, it should be transcribed in front of the line at the height of which it was entered; if it is found at the right margin, it should be transcribed at the end of that line. Postscripts at the top/bottom margin of a page should be transcribed before/after the running text of the page, respectively.
Issue 3: Discontinuous Parts of one Postscript
Description of Issue 3
28Issue 2 showed, that postscripts in letters may have been put wherever there was space left on the pages of the letter, which is not necessarily at the bottom of a letter. Given this fact, it is probably not surprising that if the available space was filled, a postscript could be continued at other places in the letter. Thus, the editor of a text may have to deal with discontinuous parts of postscripts which occur at various places in the letter and have to be transcribed and connected somehow. Example 6 illustrates this case. Here, a letter is written accross 4 pages (2 sheets), and then continued by writing vertically on the first page across the letter’s primary text. It is finished with a salutation and a postscript is started on the same page and in the same manner which is then continued on a new, third sheet of paper. This postscript is then followed by a second postscript on the last page.
Discussion of Issue 3
29There are several discontinuous parts of the letter in example 6. First, the letter is somehow disrupted between first and second page by content inserted on the first page. Second, there are several letter pages between the start and end of the postscript. The TEI offers several ways of dealing with discontinuity. First, it is possible to use the <seg> element with an attribute @part for each part of a discontinuous structure. The TEI proposes a small set of values for @part, i.e. ‘I’ for ‘initial’, ‘M’ for ‘medium’ and ‘F’ for ‘final’. This tagging has some disadvantages, though: With the values at hand, the current case could not be tagged unambiguously, because in fact, the segments representing parts of the letter body and the postscript would overlap just as the source text does.
<div><seg part="I">Beginning of the letter</seg> <seg part="M">Ending of the letter <postscript>Beginning of the postscript</postscript></seg> <pb/> <seg part="I">Continuation of the letter <pb/>... <pb/>... </seg> <seg part="F">Continuation and ending of the postscript</seg> </div>
30With only the values "I", "M", "F", //seg and //seg cannot be tagged unambiguously. The //seg[@part="I"] is not correct because //seg is not the initial part of the chain. However, if the tagging was //seg[@part="M"], it would not be clear, that //seg actually comes before //seg in the sequence of the letter.
31So, the <seg> chain in a way forces linerarity to the text where this can’t be guaranteed. The problem gets even worse if we considered the letter body and the postscript as two separate structures, each represented by its own chain of segments.
32Thus, if <seg> was chosen, a more elaborate vocabulary for naming of the parts would have to be introduced. Since the only connection between the <seg> structures is their naming of the @part values, these could be further differentiated but actually would have to remain actual names indicating the position of a segment in the chain (e.g. "I", "M1", "M2", "M3", ..., "F"). So, with this tagging it would always be costly to add seg parts (if needed) to the chain at a later point in time.
33By introducing and chaining <seg>s, those structures which really are interrupted are not taken care of. In our case, e.g. the paragraph which starts on the first page and is continued on the second page, would be closed, interrupted by other text parts, and reopened. Here, the two parts of the paragraph should be connected somehow.
34Another more flexible way of indicating discontinuous parts of texts is the set of @xml:id, @prev, @next attributes, as presented in the following section.
Solution to Issue 3
35For discontinuous parts of letters and postscripts, we recommend the application of the @xml:id (class att.global), and @prev, @next (class att.global.linking) attribute set. A structure, that is interrupted, can be connected with its followers by usage of unambiguous identifiers. For example 6, this could be encoded as follows:
<div> <p xml:id="p1a" next="p1b">Beginning of the letter</p> <p xml:id="p2b" prev="p2a">Ending of the letter</p>... <postscript xml:id="p3a" next="p3b">Beginning of the postscript</postscript> <pb/> <p xml:id="p1b" prev="p1a">Continuation of the letter<pb/>... <pb/> </p> <p xml:id="p2a" next="p2b">Continuation of the letter</p> <pb/> <postscript xml:id="p3b" prev="p3a"> Ending of postscript </postscript> <postscript>2nd postscript</postscript></div>
Issue 4: Variation of the Postscript’s Location on the Page
Description of Issue 4
36We have seen before that postscripts do not necessarily have to be written down at the bottom of a letter nor even continuously in one place. Here we discuss cases where parts of one postscript are written down at different positions of a page. Example 7 illustrates the issue: the postscript was started in the bottom half of the (folded) sheet and continued on the left side of the upper half of that sheet.
Discussion of Issue 4
37(1) One possible solution might be to add <postscript> to the attribute class att.placement, so that the attribute @place becomes usable within <postscript>. This way, it could be encoded where exactly the <postscript> was written on the page. However, if that place changes, it would be hard to encode that change. A possible solution could then be to close the <postscript>, reopen it with a new indication of @place and connect the two <postscript> elements with @xml:id, @prev, @next.
38(2) Another approach could include <seg> elements to enclose text segments according to the places where they were found. In that scenario, it would be the <seg> element which has to carry the information about the text segment’s placement. So, <seg> would have to be added to the att.placement class.
39(3) An elegant way could also be to introduce a new milestone element <placeShift> (analoguous to e.g. <handShift>) which is member of att.placement. That way, the change of placement could be indicated by <placeShift> without interrupting the running text (as in 1) and without introducing artificial structures (as in 2). The <placeShift> element would still have to be provided with an attribute @new or an attribute set @from/@to to indicate the destination of the shift. Between the two proposals for attribute, @new would be a solution consistent with the practice for other “shift” elements, i.e. <handShift> and <shift>, whereas @from/@to would have the advantages of (a) conceptually carrying the concept of location (change) and (b) allowing not only to define the destination of the shift but also the starting point.
40(4) It might be considered sufficient to introduce a new attribute @placeShift rather than the element (in 3). This attribute would have to be carried by the first <lb> element after the change of place. Since the change of place always involves a linebreak, this seems to be a straightforward solution. However, technically the place shift of a whole text segment is not (just) tied to its first linebreak as this encoding might suggest.
Solution to Issue 4
41From the possible solutions discussed above we recommend the introduction of a new element <placeShift> with an attribute @new or an attribute set @from/@to to indicate the destination of the shift (solution 3).
42In the 2011 discussion referred to above, Lou Burnard mentioned:
When <postscript> was introduced, it was agreed to reserve it for simple postscripts (sic!) only, and to represent other more complex structures either with <ab> or with <div>. It is hard to see why a "postscript" should get its own special tag and a "chapter" not—they are both divs.TEI Repository: Comment to issue 280
43Martin Mueller’s counterargument was:
I see the force of this argument, but it's an even stronger argument for not having postscript in the first place. "postscript" is a part of "letter", and if there is no letter tag why should there be a postscript.TEI Repository: Comment to issue 280
44Following that discussion, the content model of postscript was adapted in a way that it was not changed to hold elaborate, div-like structures but that more flexibility was added in some ways. For instance, it became possible to add a postscript at the top of a div structure. Back then, the discussion had come to the result that for elaborate structures in postscripts one would have to use div type="postscript" elements rather than changing the content model of postscript to include div-like structures. With our proposals, we respect this decision and chosen path. However, even the rather simple <postscript> element would need the proposed addition of flexibility, so that editors do not have to resort to more, other TEI solutions (like note type="postscript", etc.), introducing even more ambiguity to the application of the TEI-Guidelines.
- Jobst, Anne, ed. 2019. Alexander von Humboldt - Christian Gottfried Ehrenberg: Briefwechsel. Berlin. http://telota.bbaw.de/AvHBriefedition.Zotero
- Arnim, Bettine von. 1835. Goethe’s Briefwechsel mit einem Kinde. Vol. 1. Deutsches Textarchiv. Berlin. http://www.deutschestextarchiv.de/arnimb_goethe01_1835. Zotero
- Carl-Maria-von-Weber-Gesamtausgabe (CMWG). Digital Edition. 2019. Version 3.5.1. http://weber-gesamtausgabe.de. Zotero
- Trautmann, Marjam, and Torsten Schrade, eds. 2019. DER STURM. Digitale Quellenedition Zur Geschichte Der Internationalen Avantgarde. 2nd ed. Mainz: Akademie der Wissenschaften und der Literatur. https://sturm-edition.de/. Zotero
- Prell, Martin, and Julia Schmidt-Funke, eds. 2017-2019. Digitale Edition Der Briefe Erdmuthe Benignas von Reuß-Ebersdorf (1670-1732). Jena. http://erdmuthe.thulb.uni-jena.de. Zotero
CitationChristian Forney, Susanne Haaf, Linda Kirsten: Postscripts of Letters. 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/postscripts.html URN: urn:nbn:de:kobv:b4-20200110163840406-3753902-5Zotero
In this article, the following obvious misprints were corrected on 24 April 2020: § 11: Wrong attribute in code example. In all other respects the article is unchanged in content and statement.