SIG:Correspondence/task-force-correspDesc/summary of the recent discussion

<- back to SIG:Correspondence/task-force-correspDesc

<ct:correspDesc>

pros & cons

There seems to be a general agreement on the necessity of such a container element. - James C.: “<ct:correspDesc> – This generally makes sense as an enclosing element. Having option for model.pLike+ makes sense and is in keeping with general TEI structured vs unstructured descriptions.“

questions

• Lou B.: „The assumption seems to be that there will be only one correspDesc in a header, and hence that each header will document a single letter, email, etc. If you have decided to treat a whole batch of letters as a single <text>, perhaps with each letter as a <.div>, and therefore have a single <teiHeader>, would you use a listCorrespDesc or some such? And how is each correspDesc associated with the relevant div (or whatever) (use @decls?)“

comment task force: → to be discussed

• Lou B.: „The placement of <correspDesc> at the top level of <sourceDesc> components, as a sibling of <msDesc> worries me slightly. Is the *act* of sending a letter really the source of the letter? There's a risk of quite a lot of redundancy here. Since it is clearly about "the intellectual content of a manuscript" could it not be a child (or maybe a sibling) of <msContents>? Placing it within <msDesc> would make it easier to have all the relevant information in one place. And might also handle the multiple-letters-in-one-text problem better, since there are already ways of handling multiple msDesc elements.“

comment task force: First, there could be different witnesses for one letter (draft version, typed version, reworked version...) – so <msDesc> would not be appropriate. Second, the proposal states that „the scope of ‚correspondence’ in this proposal covers not only letters, postcards, telegrams, and similar ‚material’ pieces of correspondence but also electronic communications, e.g. e-mails and text messages“ – genuine born digital material – so again <msDesc> would not be appropriate. Third, <correspDesc> is ‚bibliographic’ in some sense, that’s why we proposed it to be model.biblLike – and therefore becomes part of the <sourceDesc>.

• Fabio C.: "I feel a little bit puzzled by the insertion of this kind of metadata inside sourceDesc (in general I think the uses of this section in TEI are rather diverse e semantically non coherent). Why not in profileDesc (maybe I'm missing something though)?"

comment task force (Peter S.): No, that’s a good point and I know e.g. the "TEI Legal Encoding Extensions" have gone with <profileDesc>. Still, we believe the information to be captured within <correspDesc> is of bibliographic nature (at least to some extent … e.g. letters are frequently cited by date, sender and addressee). So, we made <correspDesc> member of model.biblLike which as a consequence makes <correspDesc> appear in <sourceDesc> (but not only!).

<ct:sender> vs. <author>

general statement task force

The underlying concept of our proposal ist not to cover everything that has to do with letters, postcards etc. (for a lot of the relevant information can already be encoded with existing TEI elements) – since our approach is not focused on the object – but to provide a possibility to cover the communicative act of corresponding. Most of the time the sender of a text will be the same as the author of the text – but it is also possible to send a Shakespeare poem instead of writing an original love letter, it is possible for a writer to send a publishing contract in order to discuss it with a friend, it is possible to send a cut ear in order to threaten an enemy instead of writing a text at all. Still correspondence, communication happens. That’s why we want to differentiate between author an sender (<sender sameAs=“#author“/>)

questions

• Lou B.: „I am not sure that I understand fully the implications of distinguishing ‚sender’ and ‚author’. If my wife writes a postcard and we both sign it, I guess that my wife is the author and we are both senders: is that right?“

comment task force: Yes.

• Lou B.: „The mention of ‚pre-formulated greeting cards’ reminds me that the current proposal provides no guidance on how (or where) to represent metadata about the original publication of a postcard, i.e. before it was used as a piece of correspondence. That *does* seem to me to belong in the <sourceDesc>, where I would record it using <bibl>.“

comment task force: Yes – but since this phenomenon focuses on the material object instead of the communicative act we didn’t address it in our proposal and we don’t see it as a part of <correspDesc> (although it should be mentioned elsewhere). After the SIG has managed to install a container element we want to concentrate on a best practice model for correspondence where we would like to cover questions like these.

<ct:sender>, <ct:adressee>/<recipient>/<receiver>, <ct:dateSender>, <ct:placeSender>…

pros & cons

+ practical considerations

• Joachim V.: „Concerning the question of new elements versus established ones specified by some attributes I remember that we started with our Weber-edition exactly by following this last route which does not ‚disturbe’ the fixed catalogue of TEI-elements. But on the long way we decided to introduce new elements because they were better (or should I say: easier?) ‚manageable’ in many surroundings (especially when moving to transformation and rendering processes etc.). Discussions with other editors dealing with letters showed that the tendency to introduce some letter-specific markup on the level of elements was clearly perceptible when big corpora of letters claimed for markup (and I refer to the success of DALF within P4).“

- syntactic sugar/concerns about the multitude of new elements

• James C.: Possibilities for using existing TEI elements:

 <ct:sender> = <persName role="sender">
 <ct:dateSender> = <date type="sender">
 <ct:placeSender> = <placeName role="sender">
 <ct:addressee> = <persName role="addressee">
 <ct:dateAddressee> = <date type="delievery">
 <ct:placeAddressee> = <placeName role="addressee"> 

comment task force: The fundamental difference is that these elements are specifically designed for meta data which is usually more constrained than those elements that can occur within running text. E.g. <editor> or <author> are very similar in this respect to our <ct:sender>, being somehow syntactic sugar for <persName role=„editor|author|sender“> but with only a subset of attribute classes and a limited usage (i.e. the contexts in which those elements may occur). I’m not trying to say „Because we have <editor> I want <sender>“ but want to make the point that <ct:sender> is not like <persName>, rather it’s more like <editor|author|principal|…>. Having a clear divide between metadata elements and text elements is IMHO a very good thing as other discussions have already shown.

suggestion: <party> or <participant> instead of <sender> and <addressee>/<receiver>

• Martin H.: „[Peter S.’s examples]

 <ct:addressee type=„intended-by-addressee“/> 
 <ct:addressee type=„wrong-delivery“/> 
 <ct:addressee type=„snoop“/> …

– with the exception of the first one – [...] don't look like addressees at all. This looks like three different parties to the correspondence, each with a distinct role. I would want to do something like this:

 <ct:party role="addressee"><persName>...</persName></ct:party>
 <ct:party role="unintended-recipient"><persName>...</persName></ct:party>
 <ct:party role="snoop"><persName>...</persName></ct:party>

You could have @role=author, sender, signer, co-signer... and many other variants -- presumably a semi-open list with some key suggested values, which are fixed in the interchange format.“

• Joachim V.: “Why not use <persName role="addressee"/> in this case? Correspondence is something moving from A - - > to: B, or written by A ---> and read by B. These two sides of the communication process should be reflected in two corresponding (or correspondence...;-) ) element names. Sender and addressee are the primary categories in this process and I would prefer to differentiate starting from this opposition. What's with <sender role/type="signer"/> or something similar?“

comment task force (Marcel I.): Within the task force we actually have not finally discussed the possibilities of attributes to the <addressee>-element (we had @type for places though). There may be good reasons for Peter’ S.s examples – but as far as I can see they also cause semantic problems and made room for a discussion that led astray from the task force’s focus on the Shannon-Weaver communication model. We were never sure whether to call the ‚opposite side’ of the sender ‚addresse’ or ‚receiver’ or ‚recipient’ – because it may happen that a letter (etc.) does not reach the intended person. Still, in most of the editions (most of the time) the situation is quite simple: A wants to get in contact to B – so he writes a letter. That’s why we said that correspondence is regarded as an act of communication, in which the message of a sender reaches – mediated and time-delayed – an addressee at a different place. Very often a particular message is sent in order to trigger an answer (in form of one more piece of correspondence); a single message therefore is normally not a secluded entity but a (written) act of communication in a communication continuum (Bohnenkamp/Richter 2013, p.4), in which it is defined by its relative position between messages sent ‚before’ and ‚after’. An act of communication generally has no unknown audience or unspecified recipient but one or more (intended, maybe even fictional) addressess (<adressee>), spoken to by the piece of correspondence. To put it in a nutshell: In the <addressee> (or what have you) element we mainly focus on the ‚other side’ oft he communicative act and (to use Syd’s words) don’t give a hoot about the other parties maybe involved in the process. There may good reasons to cover information like this in the <addressee> (or what have you) element but very often the <transmission> element will be more suitable. Another option could be to use <msDesc> to cover people/functions like typists etc. I see that there 1. are difficulties that should be considered and 2. will probably remain different views on <addressee>/<receiver>/<recipient> after a decision will have been made.

comment task force (Peter S.): … part of the confusion might be due to terminological imprecision so I will try to elaborate on our conceptual model: Given that we already have all means to describe the responsibilities related to the creation of (the intellectual content of) a text (editor, author, handNote, respStmt, etc.), we wanted to add a genuinely new feature with the adoption of the Shannon-Weaver model which in its simplest form can be described as a message originating from a sender, being transmitted via a channel and received by a receiver. (Our terminology is a hybrid between traditional letter editions and this more technical approach, thus ct:addressee equals receiver.) That said, all agents "to the left" of the channel (willingly, unwillingly) are called senders, all agents "to the right“ (spying or falsely receiving) are called addressees.

• Elena P.: [seems to have something similar in mind when she says]: “Furthermore <sender> is not, I think, a type of name, but the identification of an agency, of a function.“ → “In fact if you say <place type="sender"> the issue is that "sender" is not a type of place, which is therefore semantically incorrect. In order to be semantically correct you need a different attribute, say, @ofWhom. Furthermore <sender> is not, I think, a type of name, but the identification of an agency, of a function. For the date I'm a bit more reluctant in the sense that I'm not sure that <dateSender> is a good label to begin with, since it is not dating the sender, but when the letter was sent, so it could be better labeled as <dateSent> or <sentDate> (or am I missing something?); if we do not want an element, then we need another attribute since it dante of sending a letter is not a type of date, but the dating of an action (@ofWhat ?)."

• Martin H.: „There's a large number of different potential parties to a correspondence, including sender, recipient, addressee (these two may differ), signer, co-signer, typist, etc. This list is potentially very long, but there are some core roles which we know about. My suggestion was to create a single new element:

 <ct:party> (or perhaps <ct:correspParty>)

with @role to differentiate them. The Guidelines could provide a suggested value list covering all the core, known requirements (sender, recipient etc.) and yet still allow for further extension. Interoperability would be served by the suggested values being formalized in the interchange format.

 <ct:party role="addressee"><persName>...</persName></ct:party>
 <ct:party role="unintended-recipient"><persName>...</persName></ct:party>
 <ct:party role="snoop"><persName>...</persName></ct:party>

You could have @role=author, sender, signer, co-signer ... and of course you could have <orgName> and so on in place of <persName> in the content of <ct:party>. This seems more straightforward to me than arguing about which roles deserve their own syntactic sugar elements and which don't. I picked the element name "party" because it tends to be used in formal and legal contexts to mean "participant", but I know that it has other connotations which might make it unsuitable. <participant> would do too, or any other generic term. <sender role="signer"> sort of makes sense (assuming the signer sent the letter, or the letter was actually sent); but what about <sender role="typist">? Is the typist really a sort of sender? Or, taking the example from the previous discussion of a "snoop" (someone spying on the correspondence: this is clearly not the <addressee>; in one sense it might be a <recipient>, but maybe not (perhaps they just photographed a postcard as it went through the post sorting office). All this ambiguity suggested to me that something like <participant> would be a good, general, extensible solution (and extensibility is generally good, right?). ... I'm also aware that a TEI element <participant> may be very useful in other contexts, which is also a plus. A transcription of a radio interview might have two participants, an interviewer and an interviewee; we would currently do that with <respStmt>, but <participant> might be more elegant if it existed. We're not trying to create a little island of unique elements purely for the purposes of describing correspondence; we're trying to develop the overall TEI schema so that it can better respond not only to this but to other, related-but-different needs."

comment task force (Marcel I.): It all makes sense to me – and maybe we will end up by using this idea – but for me it is not an alternative to <sender> and <addressee> but an addition. Using <participant> would only help us to ‚avoid’ one more new element: instead of <sender> and <addresse> we would use <participant> + attribute. All the other elements of our proposal would not be affected. Furthermore the simpilicity of the Shannon-Weaver-modell would not be depicted.

• Peter B.: „Another issue that we've frequently grappled with in correspondence projects is that a letter may be addressed to a single person but really in his capacity of e.g. secretary of a certain body, because he works at a publishing firm, or similar. Do we need an addresseeBody or secondaryAddressee or addresseeOnBehalfOf? Or would this be another case for multiple addressees, perhaps with a type attribute? In any case, it is an issue that a proposal for correspondence metadata should discuss.“

comment task force (Marcel I.): Yes, we should.

• + practical considerations (pro <participant>): „When it comes to automated processing, there is no practical difference for a harvester between searching for <participant role="sender"> and searching for <sender>; the latter is shorter, but it has the disadvantage that if you don't know the full list of all the elements which categorize participants (<addressee>, <recipient>, <typist> etc.) then you won't necessarily be able to retrieve all the participants easily. If you have a single element for all participants, distinguished by @role, then even if you don't know all the roles that are involved in a correspondence, you can still retrieve all the participants.“

<ct:transmission>

pros & cons

There seems to be a general agreement on such an element.

suggestion: needs more structure

• Example (James C.): „Any transmission may have multiple stages of transmission. (I hand write you a letter, someone types it up for me, they send it by fax, someone takes the fax printout and puts it in an envelope, where some hotel staff deliver it to you while you sip margaritas.) So either one uses multiple transmission elements or it has a need for more structure inside it for different stages of transmission. As far as I can conceive any stage in transmission might have a change of three major parts, the format/material of the correspondence (paper, MIME, smoke), the method of delivery (postal delivery, email, smoke signalling relay), and the agency responsible (courier company, a person, etc.). As well also each has changes in dateTime or location.“

comment task force (Peter S.): „I hand write you a letter“: James is the <author> (as I assume he is creating a text of his own) and the <sender> (as he is trying to communicate with me), the „letter“ as a document is the first <witness> of the text - 2. someone types it up for me: „someone“ is not part of the communicative act but is creating a second <witness> of the text. Nothing needs to be added to <ct:correspDesc>. - 3. they send it by fax: That’s the first <ct:transmission> where „They“ and „fax“ should be mentioned. That’s one of the weaknesses of the current <ct:transmission> since it conflates the method and the agency of transmission. That has been done on purpose to keep things simple but I see the point that it is over simplistic. - 4. someone takes the fax printout and puts ii in an envelope: That’s a nice nice one, since the fax printout != (the electronic) fax message. Keeping things simple I'd dare to only add a <witness> (for the fax printout) to the <listWit>. - 5. where some hotel staff deliver it to you: That’s the second <ct:transmission>. The <sourceDesc> might look like:

 <sourceDesc>
  <listWit>
   <witness>
    <title>James' manuscript</title>
   </witness>
   <witness>
     <title>The typoscript</title>
    </witness>
   <witness>
    <title>The fax printout</title>
   </witness>
  </listWit>
  <correspDesc xmlns="http://wiki.tei-c.org/index.php/SIG:Correspondence/task-force-correspDesc">
   <sender>James</sender>
   <addressee>Peter</addressee>

<transmission n="1">

they sent the typoscript by fax

</transmission> <transmission n="2">

some hotel staff delivered the fax printout to Peter

</transmission>

  </correspDesc>
 </sourceDesc>

So, while to my mind the format/material of the correspondence should be encoded outside of <ct:correspDesc>, we clearly need a method of linking a <witness> to a <ct:transmission>. Second, we need to differentiate between the method of delivery and the agency responsible within <ct:transmission>. (I guess not many letter projects will do that or even be able to collect that information, but hey, we are the TEI!)

• Lou B.: “I dont think @type and @subtype are strong enough to handle the full complexity of information one might want to record under <ct:transmission>. […] It might also be useful in this context to look at the work of the CMC sig, as I think I mentioned before.”

<ct:correspClass>

• Peter S.: "The function of <ct:correspClass> could easily be replaced with the generic textClass/keywords mechanism. Do we need to provide for extra classification within <ct:correspDesc>?"

• Lou B.: „I don't see the need for a <correspClass> distinct from the existing (and already quite elaborate) text classification mechanisms in the TEI header. It seems to overlap entirely with the existing mechanism @class attribute on <msContents>.“

• James C.: „<ct:correspClass> = <keywords> (using inside <ct:correspDesc> gives heirarchy to know it is relating to correspondence.)“

comment task force: Right. We should be able to live without <correspClass>.

<ct:context>

• Peter S.: „The function of <ct:context> looks very similar to the existing <linkGrp>. While the proposed <ct:context> is more flexible (it allows e.g. for paragraphs and <.ref>s) it could as well be an option to loosen the content model of <linkGrp> and use this within <ct:correspDesc>“

• Lou B.: „As regards <ct:context>, I can see the obvious utility of being able to say "this letter is in reply to this other one" or even "this letter got no reply", but I am worried that this proposal confuses the *archival* context with the semantic one -- the fact that this letter was bundled together with these ten others and bound up in pink ribbon at some time in the past surely belongs in the physDesc, not in the correspDesc? Or if it's just about temporal sequence, isn't that implicit in (e.g.) the origDate?“

comment task force (Marcel I.): I cannot find any sentence in our proposal that confuses the archival context and the context of communication – but maybe our non-native-English allows such an interpretation. Sorry ’bout that. We just wanted to say that an act of written communication becomes manifest in a piece of correspondence, that is generally part of a communication continuum. As such it often has an antecessor/successor, a preciding and following act of communication in the same communication continuum, in which it is locatable by its position between the messages sent ‚before’ and ‚after’. So we didn’t think of any archival context at all for that could never be part of the communication process – it’s all really just about a temporal sequence. – But that’s actually more difficult than it may seem: Let’s say we work on a critical edition of all the letters of person A – so on Monday, the 1st of January 1901 he writes ten letters to ten different people. On Wednesday he receives five answers to his letters, on Thursday four, and the last one two months later. Of course the user of our webplattform could sort the letters by person and find all the information he needs (person K’s answer to person A’s letter from the 1st of January was received in March 1901) – but it could also be handy to have this information gathered in one place. Especially when the delivery of letters overlaps – and the answer to a letter by person A is not person B’s letter of the next day but maybe the one three weeks later because one of the letters got stuck. The situation becomes more difficult if your edition only covers the letters written by person A – without answers. Or if an edition of all the letters written by person A already exists and you only want to combine these letters with the ones written by person B. If you think about interchangeability it could also be of interest to find out who was discussing a specific topic at a specific time – in which communicative networks... And so on... the date could be helpful – but to find out the correct chronology is part of the editing process and should be given in a specific element. That all is due to the fact that correspondence is communication – sending and receiving!

• James C.:„<ct:context> maybe appropriate existing mechanisms for standoff but not sure, otherwise generally looks ok. I'm assuming content model of correspDesc means context repeatable for multiple contexts. While one could use context/ref/date, is there a need for context to claim membership of att.datable?“

• Syd B.: "While it bears some similarity to <linkGrp> (and to <listRef>), I think <ct:context> brings more to the table than these existing TEI elements permit."

Interchange / Syd’s model

Syd B.: "I simply disagree with Peter that highly specialized elements like <ct:placeSender> will make interchange easier. (And I don't give a hoot about interoperability[1].) However, I think elegating the special nature of the information to a generic attribute (like type=) would make interchange harder.[2] I suggest simple specialized container elements, e.g., <ct:sender> and <ct:addressee>, that would contain (mostly) "normal" TEI elements. E.g., something like

  <ct:addressee>
   <persName>Peter Stadler</persName>
   <date when="2014-07-12"/>
   <location>
    <address>
     <addrLine>110 Southmoor Road</addrLine>
     <addrLine>Oxford</addrLine>
     <addrLine>OX26RB</addrLine>
     <addrLine>UK</addrLine>
    </address>
   </location>
  </ct:addressee>
  <ct:sender>
   <persName ref="people.xml#sbauman.emt"/>
   <date when="2014-07-07"/>
   <location>
    <geo>41.827428 71.400503</geo>
   </location>
  </ct:sender>

The use of <location> allows several different ways of specifying where something originated or to where it was sent:

• with latitude and longitude
• with hierarchical description (some combination of <settlement>, <region>, <country>, and <bloc>)
• in relation to a geographic feature (<geogName>Walden Pond</geogName)
• using an <address>, either generically encoded with <addrLine> (as above), or more precisely using elements like <street>, <settlement>, <region>, <postCode>, and <country>. I think this system is at least as expressive as the current proposal, is more flexible, and takes advantage of existing TEI elements better."

comment task force (Peter S.): That […] facilitates not that level of interoperability I’d like to have — and I disagree with Syd because I not only think it’s possible to achieve interoperability but that it’s our duty to provide interoperability on the meta data level (and not touch the freedom of encoding of text)!

• Stefan D.: „...as Peter noted in the last face-to-face meeting of the council, we (TELOTA) are launching a beta version of the web service "correspSearch" in a few days, which bases upon the proposed ct:correspDesc format. For this reason I'm looking on this proposal from the perspective of implementation, i.e. further use and processing of TEI files. I think it's important to distinguish between the (not correspondence-specific) text creation and the communication process of letters (and postcards etc). To encode the first, with sourceDesc and profileDesc we have adequate possibilities within the TEI. To encode the second, currently there are different "workarounds" from different letter editions. All these workarounds are more or less practicable and suitable, but they all differ from each other and are partly encoded by usage of non-TEI-elements. This itself, I think, would be a good reason for a correspDesc module. I know that the TEI is a not a standard, but a guideline. I also know that there are often many ways to encode text with TEI and that interchange/interoperability between different digital TEI editions is very problematic. But I think it isn't impossible to make little parts of the TEI ready for interchange. And in my point of view the description of correpondence is worth to fulfill this purpose, because letters & co are the prime example for texts which can make human networks visible. Despite this fact we generally look only at a little part of these networks, if we create scholarly editions of correpondences (i.e. focused on one person or even only two persons). To preserve the TEI from bloating is a worthy and important objective. But I think in this case (!) it's justified (for the above-mentioned reasons) to focus a little bit more on the possibilities of interchange. This implies 1) to take a simple but strong communication model as a basis, 2) to constrain the correspDesc module as much as possible to the correspondence process, 3) to keep an eye on the possibility of interchange when developing the correspDesc module. The strictness and simplicity should also assure that multiple TEI encoders can easily and safely apply this module.“

Other aspects

• Lou B.: „Where do I record metadata about other aspects of the transmission of the letter e.g. the type or design of the postage stamps? the presence or absence of publicity stamps in addition to the postmark proper?“

• comment tastk force: Information like this is not part of the communicative process as in the Shannon-Weaver-model so we don’t want to cover it in <correspDesc>. For most of these things there are existing elements within the TEI. We want to attend to these aspects in our best practice model.