TEIWiki - User contributions [en]

SIG:Correspondence/minutes-evanston

2014-11-10T13:03:27Z

Illetschko Marcel: /* TEI SIG on Correspondence - Minutes Evanston, Oct 22, 2014 */

==TEI SIG on Correspondence - Minutes Evanston, Oct 22, 2014==

Status: draft --[[User: Marcel Illetschko]] 14:03, 10 November 2014 (EST)

===Attendees===
Attendees very briefly introduced themselves and their ongoing and/or planned projects:
* Marcel Illetschko: [http://www.onb.ac.at/sammlungen/litarchiv/literaturarchiv_projekte.htm#seuffert Literature Archive of the Austrian National Library, Correspondence Sauer – Seuffert]
* Andy Jewell: [http://cdrh.unl.edu/about/faculty/jewell University of Nebraska-Lincoln], [http://cather.unl.edu Willa Cather Archive]
* Angelika Kreh: [http://exilnetz33.de/de/projektteam/ German Literature Archive Marbach, Epistolary Networks]
* Anne Lorenz: [http://exilnetz33.de/de/projektteam/ German Literature Archive Marbach, Epistolary Networks]
* Elena Pierazzo: Université de Grenoble 3 'Stendhal', King’s College London ([http://www.elenapierazzo.org elenapierazzo.org])
* Sabine Seifert: [http://tei.ibi.hu-berlin.de/berliner-intellektuelle/ Humboldt University Berlin, Berlin Intellectuals 1800-1830]
* Peter Stadler: [http://www.weber-gesamtausgabe.de/de/A009001 University of Paderborn, Carl Maria von Weber Collected Works]
* Magdalena Turska: University of Oxford, DiXiT ([https://oxford.academia.edu/MagdalenaTurska Magdalena Turska @academia.edu])
* Laura Weakly: [http://unlcms.unl.edu/cas/center-for-digital-research-in-the-humanities/about/staff/weakly University of Nebraska-Lincoln ], [http://www.codyarchive.org William F. Cody Archive], [http://neihardt.unl.edu Interdisciplinary Life and Letters of John G. Neihardt]

===Discussion of <correspDesc>===
The SIG meeting took place right after the presentation of the proposed new <correspDesc> element by Sabine, Marcel and Peter ([https://prezi.com/e70bkx9iqiib/towards-a-correspondence-module-in-the-tei/ Towards a Correspondence Module in the TEI])

It started – actually before a short introduction by Peter and a brief insight in ongoing projects by the attendees – with Andrew’s question about the general procedure to include new elements in the TEI. Elena pointed out the importance of doing first things first: The new proposal should focus on the most important parts of <correspDesc>, other elements could be implemented afterwards. In general it was very useful to inform the council quite early or to invite members of the council to participate in the development of new elements since on the one hand their experience is helpful and on the other hand the council gets first-hand information.

We also discussed minor topics as the encoding of envelopes and address lines and the different views on these questions (Elena: envelopes sometimes get re-used and therefore have a “life themselves”, Magdalena: in the 16th century there were no envelopes at all so the usage of <div> is appropriate, Elena and Peter: one needs to clearly distinguish between the metadata (e.g. dates) derived from the envelopes and the text on the envelope itself).

Andy expressed his hope that minor issues concerning the encoding of correspondence could be implemented more quickly. After all one could see that there is a strong international demand for the implementation of the proposed <correspDesc> element.

Laura provided an example from the Neihardt collection for testing with the current correspDesc proposal.

===Organisational matters===
Please add editions to our [http://wiki.tei-c.org/index.php/SIG:Correspondence#Correspondence_Projects wiki]!
The TEI small grant initiative is still active – maybe a workshop for the development of a best practice model for correspondence would be helpful.

SIG:Correspondence/minutes-evanston

2014-11-10T13:02:54Z

Illetschko Marcel: /* Discussion of */

==TEI SIG on Correspondence - Minutes Evanston, Oct 22, 2014==

Status: draft --[[User: Marcel Illetschko]] 13:52, 10 November 2014 (EST)

===Attendees===
Attendees very briefly introduced themselves and their ongoing and/or planned projects:
* Marcel Illetschko: [http://www.onb.ac.at/sammlungen/litarchiv/literaturarchiv_projekte.htm#seuffert Literature Archive of the Austrian National Library, Correspondence Sauer – Seuffert]
* Andy Jewell: [http://cdrh.unl.edu/about/faculty/jewell University of Nebraska-Lincoln], [http://cather.unl.edu Willa Cather Archive]
* Angelika Kreh: [http://exilnetz33.de/de/projektteam/ German Literature Archive Marbach, Epistolary Networks]
* Anne Lorenz: [http://exilnetz33.de/de/projektteam/ German Literature Archive Marbach, Epistolary Networks]
* Elena Pierazzo: Université de Grenoble 3 'Stendhal', King’s College London ([http://www.elenapierazzo.org elenapierazzo.org])
* Sabine Seifert: [http://tei.ibi.hu-berlin.de/berliner-intellektuelle/ Humboldt University Berlin, Berlin Intellectuals 1800-1830]
* Peter Stadler: [http://www.weber-gesamtausgabe.de/de/A009001 University of Paderborn, Carl Maria von Weber Collected Works]
* Magdalena Turska: University of Oxford, DiXiT ([https://oxford.academia.edu/MagdalenaTurska Magdalena Turska @academia.edu])
* Laura Weakly: [http://unlcms.unl.edu/cas/center-for-digital-research-in-the-humanities/about/staff/weakly University of Nebraska-Lincoln ], [http://www.codyarchive.org William F. Cody Archive], [http://neihardt.unl.edu Interdisciplinary Life and Letters of John G. Neihardt]

===Discussion of <correspDesc>===
The SIG meeting took place right after the presentation of the proposed new <correspDesc> element by Sabine, Marcel and Peter ([https://prezi.com/e70bkx9iqiib/towards-a-correspondence-module-in-the-tei/ Towards a Correspondence Module in the TEI])

It started – actually before a short introduction by Peter and a brief insight in ongoing projects by the attendees – with Andrew’s question about the general procedure to include new elements in the TEI. Elena pointed out the importance of doing first things first: The new proposal should focus on the most important parts of <correspDesc>, other elements could be implemented afterwards. In general it was very useful to inform the council quite early or to invite members of the council to participate in the development of new elements since on the one hand their experience is helpful and on the other hand the council gets first-hand information.

We also discussed minor topics as the encoding of envelopes and address lines and the different views on these questions (Elena: envelopes sometimes get re-used and therefore have a “life themselves”, Magdalena: in the 16th century there were no envelopes at all so the usage of <div> is appropriate, Elena and Peter: one needs to clearly distinguish between the metadata (e.g. dates) derived from the envelopes and the text on the envelope itself).

Andy expressed his hope that minor issues concerning the encoding of correspondence could be implemented more quickly. After all one could see that there is a strong international demand for the implementation of the proposed <correspDesc> element.

Laura provided an example from the Neihardt collection for testing with the current correspDesc proposal.

===Organisational matters===
Please add editions to our [http://wiki.tei-c.org/index.php/SIG:Correspondence#Correspondence_Projects wiki]!
The TEI small grant initiative is still active – maybe a workshop for the development of a best practice model for correspondence would be helpful.

SIG:Correspondence/minutes-evanston

2014-11-10T13:01:53Z

Illetschko Marcel: /* Discussion of */

==TEI SIG on Correspondence - Minutes Evanston, Oct 22, 2014==

Status: draft --[[User: Marcel Illetschko]] 13:52, 10 November 2014 (EST)

===Attendees===
Attendees very briefly introduced themselves and their ongoing and/or planned projects:
* Marcel Illetschko: [http://www.onb.ac.at/sammlungen/litarchiv/literaturarchiv_projekte.htm#seuffert Literature Archive of the Austrian National Library, Correspondence Sauer – Seuffert]
* Andy Jewell: [http://cdrh.unl.edu/about/faculty/jewell University of Nebraska-Lincoln], [http://cather.unl.edu Willa Cather Archive]
* Angelika Kreh: [http://exilnetz33.de/de/projektteam/ German Literature Archive Marbach, Epistolary Networks]
* Anne Lorenz: [http://exilnetz33.de/de/projektteam/ German Literature Archive Marbach, Epistolary Networks]
* Elena Pierazzo: Université de Grenoble 3 'Stendhal', King’s College London ([http://www.elenapierazzo.org elenapierazzo.org])
* Sabine Seifert: [http://tei.ibi.hu-berlin.de/berliner-intellektuelle/ Humboldt University Berlin, Berlin Intellectuals 1800-1830]
* Peter Stadler: [http://www.weber-gesamtausgabe.de/de/A009001 University of Paderborn, Carl Maria von Weber Collected Works]
* Magdalena Turska: University of Oxford, DiXiT ([https://oxford.academia.edu/MagdalenaTurska Magdalena Turska @academia.edu])
* Laura Weakly: [http://unlcms.unl.edu/cas/center-for-digital-research-in-the-humanities/about/staff/weakly University of Nebraska-Lincoln ], [http://www.codyarchive.org William F. Cody Archive], [http://neihardt.unl.edu Interdisciplinary Life and Letters of John G. Neihardt]

===Discussion of <correspDesc>===
The SIG meeting took place right after the presentation of the proposed new <correspDesc> element by Sabine, Marcel and Peter ([https://prezi.com/e70bkx9iqiib/towards-a-correspondence-module-in-the-tei/ Towards a Correspondence Module in the TEI])
It started – actually before a short introduction by Peter and a brief insight in ongoing projects by the attendees – with Andrew’s question about the general procedure to include new elements in the TEI. Elena pointed out the importance of doing first things first: The new proposal should focus on the most important parts of <correspDesc>, other elements could be implemented afterwards. In general it was very useful to inform the council quite early or to invite members of the council to participate in the development of new elements since on the one hand their experience is helpful and on the other hand the council gets first-hand information.
We also discussed minor topics as the encoding of envelopes and address lines and the different views on these questions (Elena: envelopes sometimes get re-used and therefore have a “life themselves”, Magdalena: in the 16th century there were no envelopes at all so the usage of <div> is appropriate, Elena and Peter: one needs to clearly distinguish between the metadata (e.g. dates) derived from the envelopes and the text on the envelope itself).
Andy expressed his hope that minor issues concerning the encoding of correspondence could be implemented more quickly. After all one could see that there is a strong international demand for the implementation of the proposed <correspDesc> element.
Laura provided an example from the Neihardt collection for testing with the current correspDesc proposal.

===Organisational matters===
Please add editions to our [http://wiki.tei-c.org/index.php/SIG:Correspondence#Correspondence_Projects wiki]!
The TEI small grant initiative is still active – maybe a workshop for the development of a best practice model for correspondence would be helpful.

SIG:Correspondence

2014-11-10T12:58:45Z

Illetschko Marcel: /* Evanston, Oct 22, 2014 */

== News ==

* Task Force Paper "Towards a Correspondence Module in the TEI", held at the TEI conference in Evanston: [http://tei.northwestern.edu/files/2014/10/Seifert-Illetschko-Stadler-2f2zhn3.pdf Abstract], [https://prezi.com/e70bkx9iqiib/towards-a-correspondence-module-in-the-tei/ Prezi], [https://docs.google.com/document/d/16DTp789wkrhPXH_79zexSy8wHWZId7W-RZkO4e1BAGM/edit?usp=sharing Talk] --[[User:Pstadler|pstadler]] 14:52, 7 November 2014 (CET)
* SIG MEETING at TEI conference in Evanston, Oct 22, Wednesday --[[User:Pstadler|pstadler]] 14:52, 7 November 2014 (CET)
* New page for the [[SIG:Correspondence/task-force-correspDesc|correspDesc task force]] --[[User:Pstadler|pstadler]] 10:22, 11 November 2013 (EST)

== Introduction ==
The TEI Special Interest Group on Correspondence seeks to bring together scholars interested in creating digital scholarly editions of correspondence. The goal of the SIG will be to discuss and develop sample tagsets (including suggesting additions/modifications to the TEI Guidelines) for varying forms of correspondence as well as to create tutorials and best practice models.

Because the initiative for this SIG emerged from editorial work with 19th century letters, the organizers of this SIG have focused on these types of materials. However, we want this SIG to be more encompassing, embracing varying types of historical and literary correspondence including epistles, telegrams, postcards, etc., and perhaps other types of documents that share features with physical written correspondence like diaries, diary entries, letters to the editor, e-mail, blogs, etc.

The common feature of these sorts of text is a generally formalized physical appearance (e.g., an envelope for letters) and structure of content (i.e. address field, special formulas for opener and closer). [http://www.tei-c.org/Activities/Projects/da03.xml DALF] was one of the best documented projects in this area developing specific DTDs for those needs in P4: this may be a starting point for further work in P5.

Initial topics for the SIG Correspondence may include:
* the handling of the envelope and postal addresses
* the formal description of correspondence as a written dialogue between an author and an addressee
* correspondence-specific bibliographical data within the metadata section

== Activities ==

The SIG runs a mailing list, which you can join by visiting http://listserv.brown.edu/tei-corresp-sig.html .

=== Topics currently under discussion ===
* The content of a special '''correspDesc''' element (see [[SIG:Correspondence/ODD_work]])
* Discussion of different P5-customizations for correspondence (see [[SIG:Correspondence/EncodingComparisons]])
--> For this, see the work of the [[SIG:Correspondence/task-force-correspDesc|correspDesc task force]] for current developments.
* The content model of '''postscript''': look at the [[Collection of Postscript-Examples]] and the contributions to the [[ps-discussion]].
* How to deal with '''enclosures''' or '''attachements''' to a letter
* The content model of opener/closer and their connection with salute, signed, dateline, etc.
* diary entries
* definition of <signed> does not correspond with its actual use in the P5 guidelines
* address now in but not in <div>: maybe not a good idea
* notification of addresses (different in different parts of the world). Could this be handled more adequately than just with datelines?
* [[SIG:Correspondence/pre-printed_text|pre-printed text]] (e.g. letterhead, postcard captions)

=== Meetings ===

==== Evanston, Oct 22, 2014 ====

Exhaustive minutes at [http://wiki.tei-c.org/index.php/SIG:Correspondence/minutes-evanston SIG meeting Evanston]

==== TEI Tweet Chat, Oct 9, 2014 ====

The first TEI Tweet Chat on [https://twitter.com/ Twitter] ever was hosted by the social media coordinator, Paul O’Shea, and the SIG Correspondence for one hour (from 16 GMT+2 to 17 GMT+2) ([https://twitter.com/TEIconsortium/status/519047322098204672 twitter announcement]). It was meant as an attempt to include the public online community, apart from the people on the TEI mailing lists.

Topics discussed/mentioned include:
* recent work of the SIG on the new <ct:correspDesc> element and when it will be part of the official TEI Guidelines, names of the proposed new elements, e.g. placeSender vs. senderPlace, placeAddressee vs. Addressee, etc.
* some digital editions of correspondence/projects were mentioned, e.g. [http://www.weber-gesamtausgabe.de/de/Index Carl Maria von Weber-Collected Works], [http://dh.tcd.ie/letters1916/ Letters of 1916], [http://dh.ucc.ie/boole George Boole Collection software transcription desk], [http://tei.ibi.hu-berlin.de/berliner-intellektuelle/?en Letters and Texts. Intellectual Berlin around 1800]
* list of projects on this very wikipage for people to add their own projects
* the new webservice [http://correspsearch.bbaw.de/index.xql CorrespSearch] (making metadata of currently 3 different correspondence projects searchable), BEACON and CorrespSearch
* [http://tei.northwestern.edu/ TEI Conference 2014 in Chicago]
* [http://dhd2015.uni-graz.at/ Dhd Conference 2015] in Graz, Austria
* letter transcription as an undergrad class project, teaching XML and TEI for undergrads, MAs and PhDs
* choice of XML editors, [http://www.oxygenxml.com/ oXygen XML editor], eXist built-in exIDE editor, straight up text editor vs. interface that hides the XML
* Is a tweet a letter? Where are the boundaries of correspondence? one-to-one communication and many-to-many correspondence, meaning and intentionality, trees nobody heard falling that may have intentions

There is a [https://docs.google.com/document/d/1i7CcnoGJVDWxKj4uTExzUrTRXOaQkeCgtt6mbR37FLE chat report], a [https://t.co/jUl8cMJcxJ Twitter archive] and a [http://t.co/mB2GQ1STkS TAGS Explorer Visualisation].

==== Rome, Oct 3, 2013 ====

Exhaustive minutes at [[SIG:Correspondence/minutes-rome]]

==== College Station, Nov 9, 2012 ====

09-12:30PM at Rudder Tower 302

'''Agenda''':

# Report on last year's activities
# [[SIG:Correspondence/RequestForModule|Request for a correspondence module and a wrapper element for correspondence meta data]]
# AOB

'''Minutes'''

Short summary/Outcome: [[SIG:Correspondence/ODD_work|A second draft for a correspondence ODD]]

Details: [[Minutes College Station]]

==== Wuerzburg, Oct 15, 2011 ====

Agenda of the meeting during the Wuerzburg MM (on Oct 15, 2011 from 9am to 10:30am in room 1.003):
* 1. New members / projects / demands
* 2. Short survey of the development of the SIG and the topics discussed
* 3. Views of the group about proposing a <correspDesc> (or similar) element or not
* 4. Future activities of the SIG: P5-Customizations for Correspondence ("Dalfy" et al.) / Special Guidelines (TEI by example) / Proposals / Next Steps
* 5. Roadmap for 2012
* 6. Website and Wiki

===== Minutes / Results / Goals =====

For more detailed minutes see [[SIGcorresp Minutes 20111015|Minutes Wuerzburg]], the main results of the discussions and the goals for the near future are summed up here:

* Preliminary goal: initiate a comparison between several customized or non-customized TEI versions for correspondence (to be published on the WiKi)
* Middle-term goal: propose "official" customization(s) for correspondence
* Middle-term goal: ask people to make some or their examples available and find out in which way they used TEI for correspondence
* Middle-term goal: develop best practice models
* Long-term goal: develop a compressed proposal for handling correspondence within TEI

==== Zadar, Nov 13, 2010 ====

Participation: around 5 people

1. Peter gave a report on last year's activities
* Task force ‘Dalfy’ was established after the Ann Arbor Meeting: Markus Flatscher, Bert Van Raemdonck, Peter Stadler
* Goal: Mapping of DALF (P4) to TEI P5 as a basis for further work on a correspondence customization
* But: Momentum got lost …
* Further: Some discussion on TEI-L about "signed vs. salute"

2. A brief look on open questions
* Correspondence meta data: correspDesc?
* The content model of postscript (cf. the Collection of Postscript-Examples and the contributions to the ps-discussion.)
* The content model of opener/closer and their connection with salute, signed, dateline, byline etc.

3. Attempt to create a roadmap for 2011
* Peter suggested a second attempt for a grant to achieve the mapping of DALF to P5
* Discussion about possible fundings for such an attempt
* review of the last failed TEI grant proposal: it was criticized by the present panel members that no preliminary work was (visibly) carried out
* Susan suggested to first initiate a survey on the correspondence list

4. AOB
* nothing

==== Ann Arbor, Nov 14, 2009 ====

Business and working meeting during the annual members meeting.
'''Participants''': Syd Bauman (SB), Markus Flatscher (MF), Elena Pierazzo (EP), Malte Rehbein (MR), Paul Schaffner (PSc), Peter Stadler (PSt), Bert Van Raemdonck (BV)

The business meeting was attended by MF, PSc, PSt and BV and - since the number of participants allowed it - was an informal talk about the different projects, the last meeting at London and the "correspDesc" PS had proposed there as well as the question whether editing correspondence from printed (secondary) material needs to treated differently than correspondence from manuscript source material. Work on the roadmap was postponed to the working meeting.

The working meeting was attended by all above mentioned participants who agreed on the need for a customization of some of the P5 elements (and element classes) for encoding correspondence. Question is of course: how?
* P5 has introduced some elements that were inspired by what had been done earlier in DALF (P4), but not all P4 customizations in DALF are actually rendered in P5 (and vice versa). Hence, a comparison of both should be a good starting point to eventually come to a new ODD for encoding correspondence, and maybe even for introducing an actual module for future TEI Guidelines.
* MF, PSt and BV agree on doing such a mapping together. Since BV is like the only DALF original left, he will coordinate this: he will split the work up, and will be contacting MF and PSt for further arrangements. [UPDATE: Edward Vanhoutte and Ron Van den Branden agreed to work on this with BV face to face and then get back to MF and PSt afterwards. --[[User:Pstadler|pstadler]] 07:04, 27 November 2009 (EST)]
* Before X-mas, there should be a conference call to catch up on how the mapping proceeds. PSt will contact Dan O'Donnell for funding.
* Bugs and absurdities in P5 regarding correspondence should be posted on Sourceforge. Elena Pierazzo will be the liaison between the SIG and the TEI Council. She will help SIG members to report our findings through Sourceforge or otherwise.
* The mapping should result in a new ODD. SB is willing to help us create it. The new ODD should somehow be more or less DALF-like. Hence, the working title of the ODD is 'Dalfy'. Dalfy will be an oddified version of DALF where obviously identical concepts will already be mapped to their P5 equivalents (therefore Dalfy != DALF).
* After the mapping is done, useful elements (or concepts, structures) that are neither in DALF or in P5 yet, should be listed. Members of the SIG are welcome to suggest their own 'favourite missing elements'.
* With Dalfy as starting point we can than try to rearrange and modify it to come to a new Correspondence ODD (no code name yet!) that should resolve all problems and satisfy all needs...
* Issues that came up during the meetings concern <address> (and multiple addresses within one letter) (SB and EP), <signed> (everyone), endorsements as well as correspondence by committee (PSc)
* Besides the work on Dalfy PSt shall finish his work on oddifying his <correspDesc>.
'''Roadmap/Milestones''':
* Before Christmas: Teleconference about the mapping (MF, PSt, BV)
* Febr. 10, 2010: Mapping done
* July, 2010: Next SIG meeting at Digital Humanities conference (London) on new ODD

[Minutes PSt and BV]

==== London, Nov 8, 2008 ====

The first section (14-15:30) saw short presentations of current projects by:
* Tim McLoughlin: James Barry's letters
* Hilde Bøe: eMunch project (assisted by Ellen Nessheim Wiger with the Henrik Ibsen correspondence)
* Peter Boot: correspondence of Vincent van Gogh
* David Sewell: correspondence projects published via ROTUNDA
* Deborah K. Wright: correspondence of Matthew Prior
* Peter Stadler: correspondence of Carl Maria von Weber

The second section (16-16:45) had to be shortened due to organisational necessities but saw general discussion about
* the content model of postscript which is rather restricted and does not allow for an i.e. '''head''' element. Everyone was encouraged to send examples via the list. [Let me add that the same holds true for '''address''' --[[User:Pstadler|pstadler]]]
* the need and the possible content for an '''correspDesc''' element within '''sourceDesc'''. I will try to create an odd file with the necessary additions to the schema as a starting point for further expertise. --[[User:Pstadler|pstadler]].
* correspondence as an event. Lou pointed this out as similar topics were discussed in the ontologies SIG.

== Correspondence Projects ==

Please add your projects alphabetically with link and (if possible) a short description!

=== Ongoing Projects ===

* [http://gams.uni-graz.at/fedora/get/container:rollett/bdef:Container/get The Letters of Alexander Rollett]. A project of the Center for Information Modeling in the Humanities (ZIM) at the University of Graz.
* Alfred Escher Correspondence. A project of the Alfred Escher Foundation, Zurich [http://www.alfred-escher.ch (Alfred Escher-Stiftung)]. Edition of the correspondence of Alfred Escher, influential 19th century Swiss politician and entrepreneur (e.g. Credit Suisse, Gotthard railway), comprising several thousand letters. At first, an edition of selected letters to and from Escher will be published in book form, including rich annotations. The first volume of the series is already available. Later on, the correspondence of Alfred Escher will be made available online. The correspondence covers topics as diverse as politics, economics, education, railways, banks, insurance. [http://www.briefedition.alfred-escher.ch/ Alfred Escher-Briefedition]
* Digital Archive of Letters in Flanders authors and composers from the 19th & 20th century, [http://www.kantl.be/ctb/project/dalf/ DALF]
*''Complete Letters of Willa Cather'', a new digital scholarly edition of the American author's complete correspondence, scheduled for initial publication in January 2018 on the [http://cather.unl.edu Willa Cather Archive]
* ''Emily Dickinson's Correspondences'' (public version not yet online), to be published under the [http://rotunda.upress.virginia.edu Rotunda] imprint by University of Virginia Press. An edition of selected correspondence to and from American poet Emily Dickinson, with MS facsimiles and rich metadata capturing physical details of the manuscripts.
* Gundolf-Elli. Correspondence between Friedrich Gundolf and Elisabeth Salomon (George-Kreis). Project at the German Literature Archive. There is no website, yet. For more information use the mailing list.
* eMunch. Edvard Munch's written material: Complete letters, diaries and writings, [http://www.emunch.no/eng/index.htm] (Updated and expanded 15.06.2009)
* Schleiermacher, Friedrich - Edition of the correspondence at Berlin-Brandenburg Academy of Sciences and Humanities ([http://www.bbaw.de/ BBAW]). At the moment the new work environment (with TEI) is in development.
* Weber, C.M.v.: Complete letters, diaries, writings and compositions, [http://www.weber-gesamtausgabe.de/ Carl-Maria-von-Weber-Gesamtausgabe] (at the moment german only)
* Digital edition [http://141.20.126.175/berliner-intellektuelle/?language=de 'Letters and texts. The intellectual Berlin around 1800'.] Realized by the project 'Berlin Intellectuals 1800-1830' at Humboldt University Berlin. Publication of letters and work manuscripts of Berlin-based writers and scholars from the late 18th and early 19th century. Manuscript facsimiles, transcriptions with annotation, XML files made available. Web presence launched in April 2012 with a first set of texts. Will be progressively enriched during the upcoming years.
* [http://elec.enc.sorbonne.fr/dubourg/ Correspondance of the chancellor Antoine Du Bourg]. A project of the École nationale des chartes. Certainly one of the richest administrative and political correspondence for the France of the Renaissance, it evokes all matters a chancellor has to manage: royal finances, monitoring the printed production, economic politics, .... The whole corpus contains around 1200 letters; for the moment, one hundred has been published online, the edition is still regularly increased. The edition is part of a bigger project of digital editions of modern correspondences (15th-18th century): the aim is to build a model and interface which could be usable and shared to every non literary correspondences for early modern history.
* [http://dantiscus.al.uw.edu.pl Texts & Correspondence of Ioannes Dantiscus]. Launched in 2010 and building upon material recorded since 1989 at the University of Warsaw Ioannes Dantiscus’ correspondence forms Central-Eastern Europe’s largest collection of letters (over 6,000 letters, mostly Latin and German) related to the Polish royal court and its partners in Renaissance Europe.

=== Completed Projects ===
* [http://rotunda.upress.virginia.edu/dmde The Dolley Madison Digital Edition], part of the University of Virginia Press's [http://rotunda.upress.virginia.edu/ Rotunda] series. This is an ongoing publication, but the first two "volumes" are online. Currently the underlying data is tagged using the [http://adh.sc.edu/ Model Editions Partnership] variant of TEI (P4), but we are also exporting and transforming the documents to TEI P5 for interoperability with other material. (Contact: [mailto:dsewell@virginia.edu David Sewell])
* [http://www.vnsbrieven.org/VNS/?lang=en Van Nu en Straks: Brieven / Letters], Online edition of the correspondence concerning the literary journal 'Van Nu en Straks' (1419 letters). The annotated letters contain references to ca 2500 persons, 500 places, 1000 titles of books, 650 journal articles and 350 poems. A network of 3600 hyperlinks facilitates intuitive and associative consulting. Project at the [http://www.ctb.kantl.be Centre for Scholarly Editing and Document Studies] / Royal Academy of Dutch Language and Literature (KANTL-CTB, Ghent-Belgium) and Ghent University (Belgium). This project is part of the broader [http://www.kantl.be/ctb/project/dalf/ DALF-project].
* [http://www.vangoghletters.org/vg/ Vincent van Gogh, The letters]. A full edition of all the extant correspondence of Vincent van Gogh (900 letters). The edition includes full transcriptions (in Dutch and French), translation into English, facsimiles, extensive annotations and about 2000 illustrations.

[[Category:SIG|Correspondence]]

SIG:Correspondence

2014-11-10T12:58:35Z

Illetschko Marcel: /* Evanston, Oct 22, 2014 */

== News ==

* Task Force Paper "Towards a Correspondence Module in the TEI", held at the TEI conference in Evanston: [http://tei.northwestern.edu/files/2014/10/Seifert-Illetschko-Stadler-2f2zhn3.pdf Abstract], [https://prezi.com/e70bkx9iqiib/towards-a-correspondence-module-in-the-tei/ Prezi], [https://docs.google.com/document/d/16DTp789wkrhPXH_79zexSy8wHWZId7W-RZkO4e1BAGM/edit?usp=sharing Talk] --[[User:Pstadler|pstadler]] 14:52, 7 November 2014 (CET)
* SIG MEETING at TEI conference in Evanston, Oct 22, Wednesday --[[User:Pstadler|pstadler]] 14:52, 7 November 2014 (CET)
* New page for the [[SIG:Correspondence/task-force-correspDesc|correspDesc task force]] --[[User:Pstadler|pstadler]] 10:22, 11 November 2013 (EST)

== Introduction ==
The TEI Special Interest Group on Correspondence seeks to bring together scholars interested in creating digital scholarly editions of correspondence. The goal of the SIG will be to discuss and develop sample tagsets (including suggesting additions/modifications to the TEI Guidelines) for varying forms of correspondence as well as to create tutorials and best practice models.

Because the initiative for this SIG emerged from editorial work with 19th century letters, the organizers of this SIG have focused on these types of materials. However, we want this SIG to be more encompassing, embracing varying types of historical and literary correspondence including epistles, telegrams, postcards, etc., and perhaps other types of documents that share features with physical written correspondence like diaries, diary entries, letters to the editor, e-mail, blogs, etc.

The common feature of these sorts of text is a generally formalized physical appearance (e.g., an envelope for letters) and structure of content (i.e. address field, special formulas for opener and closer). [http://www.tei-c.org/Activities/Projects/da03.xml DALF] was one of the best documented projects in this area developing specific DTDs for those needs in P4: this may be a starting point for further work in P5.

Initial topics for the SIG Correspondence may include:
* the handling of the envelope and postal addresses
* the formal description of correspondence as a written dialogue between an author and an addressee
* correspondence-specific bibliographical data within the metadata section

== Activities ==

The SIG runs a mailing list, which you can join by visiting http://listserv.brown.edu/tei-corresp-sig.html .

=== Topics currently under discussion ===
* The content of a special '''correspDesc''' element (see [[SIG:Correspondence/ODD_work]])
* Discussion of different P5-customizations for correspondence (see [[SIG:Correspondence/EncodingComparisons]])
--> For this, see the work of the [[SIG:Correspondence/task-force-correspDesc|correspDesc task force]] for current developments.
* The content model of '''postscript''': look at the [[Collection of Postscript-Examples]] and the contributions to the [[ps-discussion]].
* How to deal with '''enclosures''' or '''attachements''' to a letter
* The content model of opener/closer and their connection with salute, signed, dateline, etc.
* diary entries
* definition of <signed> does not correspond with its actual use in the P5 guidelines
* address now in but not in <div>: maybe not a good idea
* notification of addresses (different in different parts of the world). Could this be handled more adequately than just with datelines?
* [[SIG:Correspondence/pre-printed_text|pre-printed text]] (e.g. letterhead, postcard captions)

=== Meetings ===

==== Evanston, Oct 22, 2014 ====

Exhaustive minutes at [http://wiki.tei-c.org/index.php/SIG:Correspondence/minutes-evanston SIG meeting Evanston]
----

==== TEI Tweet Chat, Oct 9, 2014 ====

The first TEI Tweet Chat on [https://twitter.com/ Twitter] ever was hosted by the social media coordinator, Paul O’Shea, and the SIG Correspondence for one hour (from 16 GMT+2 to 17 GMT+2) ([https://twitter.com/TEIconsortium/status/519047322098204672 twitter announcement]). It was meant as an attempt to include the public online community, apart from the people on the TEI mailing lists.

Topics discussed/mentioned include:
* recent work of the SIG on the new <ct:correspDesc> element and when it will be part of the official TEI Guidelines, names of the proposed new elements, e.g. placeSender vs. senderPlace, placeAddressee vs. Addressee, etc.
* some digital editions of correspondence/projects were mentioned, e.g. [http://www.weber-gesamtausgabe.de/de/Index Carl Maria von Weber-Collected Works], [http://dh.tcd.ie/letters1916/ Letters of 1916], [http://dh.ucc.ie/boole George Boole Collection software transcription desk], [http://tei.ibi.hu-berlin.de/berliner-intellektuelle/?en Letters and Texts. Intellectual Berlin around 1800]
* list of projects on this very wikipage for people to add their own projects
* the new webservice [http://correspsearch.bbaw.de/index.xql CorrespSearch] (making metadata of currently 3 different correspondence projects searchable), BEACON and CorrespSearch
* [http://tei.northwestern.edu/ TEI Conference 2014 in Chicago]
* [http://dhd2015.uni-graz.at/ Dhd Conference 2015] in Graz, Austria
* letter transcription as an undergrad class project, teaching XML and TEI for undergrads, MAs and PhDs
* choice of XML editors, [http://www.oxygenxml.com/ oXygen XML editor], eXist built-in exIDE editor, straight up text editor vs. interface that hides the XML
* Is a tweet a letter? Where are the boundaries of correspondence? one-to-one communication and many-to-many correspondence, meaning and intentionality, trees nobody heard falling that may have intentions

There is a [https://docs.google.com/document/d/1i7CcnoGJVDWxKj4uTExzUrTRXOaQkeCgtt6mbR37FLE chat report], a [https://t.co/jUl8cMJcxJ Twitter archive] and a [http://t.co/mB2GQ1STkS TAGS Explorer Visualisation].

==== Rome, Oct 3, 2013 ====

Exhaustive minutes at [[SIG:Correspondence/minutes-rome]]

==== College Station, Nov 9, 2012 ====

09-12:30PM at Rudder Tower 302

'''Agenda''':

# Report on last year's activities
# [[SIG:Correspondence/RequestForModule|Request for a correspondence module and a wrapper element for correspondence meta data]]
# AOB

'''Minutes'''

Short summary/Outcome: [[SIG:Correspondence/ODD_work|A second draft for a correspondence ODD]]

Details: [[Minutes College Station]]

==== Wuerzburg, Oct 15, 2011 ====

Agenda of the meeting during the Wuerzburg MM (on Oct 15, 2011 from 9am to 10:30am in room 1.003):
* 1. New members / projects / demands
* 2. Short survey of the development of the SIG and the topics discussed
* 3. Views of the group about proposing a <correspDesc> (or similar) element or not
* 4. Future activities of the SIG: P5-Customizations for Correspondence ("Dalfy" et al.) / Special Guidelines (TEI by example) / Proposals / Next Steps
* 5. Roadmap for 2012
* 6. Website and Wiki

===== Minutes / Results / Goals =====

For more detailed minutes see [[SIGcorresp Minutes 20111015|Minutes Wuerzburg]], the main results of the discussions and the goals for the near future are summed up here:

* Preliminary goal: initiate a comparison between several customized or non-customized TEI versions for correspondence (to be published on the WiKi)
* Middle-term goal: propose "official" customization(s) for correspondence
* Middle-term goal: ask people to make some or their examples available and find out in which way they used TEI for correspondence
* Middle-term goal: develop best practice models
* Long-term goal: develop a compressed proposal for handling correspondence within TEI

==== Zadar, Nov 13, 2010 ====

Participation: around 5 people

1. Peter gave a report on last year's activities
* Task force ‘Dalfy’ was established after the Ann Arbor Meeting: Markus Flatscher, Bert Van Raemdonck, Peter Stadler
* Goal: Mapping of DALF (P4) to TEI P5 as a basis for further work on a correspondence customization
* But: Momentum got lost …
* Further: Some discussion on TEI-L about "signed vs. salute"

2. A brief look on open questions
* Correspondence meta data: correspDesc?
* The content model of postscript (cf. the Collection of Postscript-Examples and the contributions to the ps-discussion.)
* The content model of opener/closer and their connection with salute, signed, dateline, byline etc.

3. Attempt to create a roadmap for 2011
* Peter suggested a second attempt for a grant to achieve the mapping of DALF to P5
* Discussion about possible fundings for such an attempt
* review of the last failed TEI grant proposal: it was criticized by the present panel members that no preliminary work was (visibly) carried out
* Susan suggested to first initiate a survey on the correspondence list

4. AOB
* nothing

==== Ann Arbor, Nov 14, 2009 ====

Business and working meeting during the annual members meeting.
'''Participants''': Syd Bauman (SB), Markus Flatscher (MF), Elena Pierazzo (EP), Malte Rehbein (MR), Paul Schaffner (PSc), Peter Stadler (PSt), Bert Van Raemdonck (BV)

The business meeting was attended by MF, PSc, PSt and BV and - since the number of participants allowed it - was an informal talk about the different projects, the last meeting at London and the "correspDesc" PS had proposed there as well as the question whether editing correspondence from printed (secondary) material needs to treated differently than correspondence from manuscript source material. Work on the roadmap was postponed to the working meeting.

The working meeting was attended by all above mentioned participants who agreed on the need for a customization of some of the P5 elements (and element classes) for encoding correspondence. Question is of course: how?
* P5 has introduced some elements that were inspired by what had been done earlier in DALF (P4), but not all P4 customizations in DALF are actually rendered in P5 (and vice versa). Hence, a comparison of both should be a good starting point to eventually come to a new ODD for encoding correspondence, and maybe even for introducing an actual module for future TEI Guidelines.
* MF, PSt and BV agree on doing such a mapping together. Since BV is like the only DALF original left, he will coordinate this: he will split the work up, and will be contacting MF and PSt for further arrangements. [UPDATE: Edward Vanhoutte and Ron Van den Branden agreed to work on this with BV face to face and then get back to MF and PSt afterwards. --[[User:Pstadler|pstadler]] 07:04, 27 November 2009 (EST)]
* Before X-mas, there should be a conference call to catch up on how the mapping proceeds. PSt will contact Dan O'Donnell for funding.
* Bugs and absurdities in P5 regarding correspondence should be posted on Sourceforge. Elena Pierazzo will be the liaison between the SIG and the TEI Council. She will help SIG members to report our findings through Sourceforge or otherwise.
* The mapping should result in a new ODD. SB is willing to help us create it. The new ODD should somehow be more or less DALF-like. Hence, the working title of the ODD is 'Dalfy'. Dalfy will be an oddified version of DALF where obviously identical concepts will already be mapped to their P5 equivalents (therefore Dalfy != DALF).
* After the mapping is done, useful elements (or concepts, structures) that are neither in DALF or in P5 yet, should be listed. Members of the SIG are welcome to suggest their own 'favourite missing elements'.
* With Dalfy as starting point we can than try to rearrange and modify it to come to a new Correspondence ODD (no code name yet!) that should resolve all problems and satisfy all needs...
* Issues that came up during the meetings concern <address> (and multiple addresses within one letter) (SB and EP), <signed> (everyone), endorsements as well as correspondence by committee (PSc)
* Besides the work on Dalfy PSt shall finish his work on oddifying his <correspDesc>.
'''Roadmap/Milestones''':
* Before Christmas: Teleconference about the mapping (MF, PSt, BV)
* Febr. 10, 2010: Mapping done
* July, 2010: Next SIG meeting at Digital Humanities conference (London) on new ODD

[Minutes PSt and BV]

==== London, Nov 8, 2008 ====

The first section (14-15:30) saw short presentations of current projects by:
* Tim McLoughlin: James Barry's letters
* Hilde Bøe: eMunch project (assisted by Ellen Nessheim Wiger with the Henrik Ibsen correspondence)
* Peter Boot: correspondence of Vincent van Gogh
* David Sewell: correspondence projects published via ROTUNDA
* Deborah K. Wright: correspondence of Matthew Prior
* Peter Stadler: correspondence of Carl Maria von Weber

The second section (16-16:45) had to be shortened due to organisational necessities but saw general discussion about
* the content model of postscript which is rather restricted and does not allow for an i.e. '''head''' element. Everyone was encouraged to send examples via the list. [Let me add that the same holds true for '''address''' --[[User:Pstadler|pstadler]]]
* the need and the possible content for an '''correspDesc''' element within '''sourceDesc'''. I will try to create an odd file with the necessary additions to the schema as a starting point for further expertise. --[[User:Pstadler|pstadler]].
* correspondence as an event. Lou pointed this out as similar topics were discussed in the ontologies SIG.

== Correspondence Projects ==

Please add your projects alphabetically with link and (if possible) a short description!

=== Ongoing Projects ===

* [http://gams.uni-graz.at/fedora/get/container:rollett/bdef:Container/get The Letters of Alexander Rollett]. A project of the Center for Information Modeling in the Humanities (ZIM) at the University of Graz.
* Alfred Escher Correspondence. A project of the Alfred Escher Foundation, Zurich [http://www.alfred-escher.ch (Alfred Escher-Stiftung)]. Edition of the correspondence of Alfred Escher, influential 19th century Swiss politician and entrepreneur (e.g. Credit Suisse, Gotthard railway), comprising several thousand letters. At first, an edition of selected letters to and from Escher will be published in book form, including rich annotations. The first volume of the series is already available. Later on, the correspondence of Alfred Escher will be made available online. The correspondence covers topics as diverse as politics, economics, education, railways, banks, insurance. [http://www.briefedition.alfred-escher.ch/ Alfred Escher-Briefedition]
* Digital Archive of Letters in Flanders authors and composers from the 19th & 20th century, [http://www.kantl.be/ctb/project/dalf/ DALF]
*''Complete Letters of Willa Cather'', a new digital scholarly edition of the American author's complete correspondence, scheduled for initial publication in January 2018 on the [http://cather.unl.edu Willa Cather Archive]
* ''Emily Dickinson's Correspondences'' (public version not yet online), to be published under the [http://rotunda.upress.virginia.edu Rotunda] imprint by University of Virginia Press. An edition of selected correspondence to and from American poet Emily Dickinson, with MS facsimiles and rich metadata capturing physical details of the manuscripts.
* Gundolf-Elli. Correspondence between Friedrich Gundolf and Elisabeth Salomon (George-Kreis). Project at the German Literature Archive. There is no website, yet. For more information use the mailing list.
* eMunch. Edvard Munch's written material: Complete letters, diaries and writings, [http://www.emunch.no/eng/index.htm] (Updated and expanded 15.06.2009)
* Schleiermacher, Friedrich - Edition of the correspondence at Berlin-Brandenburg Academy of Sciences and Humanities ([http://www.bbaw.de/ BBAW]). At the moment the new work environment (with TEI) is in development.
* Weber, C.M.v.: Complete letters, diaries, writings and compositions, [http://www.weber-gesamtausgabe.de/ Carl-Maria-von-Weber-Gesamtausgabe] (at the moment german only)
* Digital edition [http://141.20.126.175/berliner-intellektuelle/?language=de 'Letters and texts. The intellectual Berlin around 1800'.] Realized by the project 'Berlin Intellectuals 1800-1830' at Humboldt University Berlin. Publication of letters and work manuscripts of Berlin-based writers and scholars from the late 18th and early 19th century. Manuscript facsimiles, transcriptions with annotation, XML files made available. Web presence launched in April 2012 with a first set of texts. Will be progressively enriched during the upcoming years.
* [http://elec.enc.sorbonne.fr/dubourg/ Correspondance of the chancellor Antoine Du Bourg]. A project of the École nationale des chartes. Certainly one of the richest administrative and political correspondence for the France of the Renaissance, it evokes all matters a chancellor has to manage: royal finances, monitoring the printed production, economic politics, .... The whole corpus contains around 1200 letters; for the moment, one hundred has been published online, the edition is still regularly increased. The edition is part of a bigger project of digital editions of modern correspondences (15th-18th century): the aim is to build a model and interface which could be usable and shared to every non literary correspondences for early modern history.
* [http://dantiscus.al.uw.edu.pl Texts & Correspondence of Ioannes Dantiscus]. Launched in 2010 and building upon material recorded since 1989 at the University of Warsaw Ioannes Dantiscus’ correspondence forms Central-Eastern Europe’s largest collection of letters (over 6,000 letters, mostly Latin and German) related to the Polish royal court and its partners in Renaissance Europe.

=== Completed Projects ===
* [http://rotunda.upress.virginia.edu/dmde The Dolley Madison Digital Edition], part of the University of Virginia Press's [http://rotunda.upress.virginia.edu/ Rotunda] series. This is an ongoing publication, but the first two "volumes" are online. Currently the underlying data is tagged using the [http://adh.sc.edu/ Model Editions Partnership] variant of TEI (P4), but we are also exporting and transforming the documents to TEI P5 for interoperability with other material. (Contact: [mailto:dsewell@virginia.edu David Sewell])
* [http://www.vnsbrieven.org/VNS/?lang=en Van Nu en Straks: Brieven / Letters], Online edition of the correspondence concerning the literary journal 'Van Nu en Straks' (1419 letters). The annotated letters contain references to ca 2500 persons, 500 places, 1000 titles of books, 650 journal articles and 350 poems. A network of 3600 hyperlinks facilitates intuitive and associative consulting. Project at the [http://www.ctb.kantl.be Centre for Scholarly Editing and Document Studies] / Royal Academy of Dutch Language and Literature (KANTL-CTB, Ghent-Belgium) and Ghent University (Belgium). This project is part of the broader [http://www.kantl.be/ctb/project/dalf/ DALF-project].
* [http://www.vangoghletters.org/vg/ Vincent van Gogh, The letters]. A full edition of all the extant correspondence of Vincent van Gogh (900 letters). The edition includes full transcriptions (in Dutch and French), translation into English, facsimiles, extensive annotations and about 2000 illustrations.

[[Category:SIG|Correspondence]]

SIG:Correspondence

2014-11-10T12:53:11Z

Illetschko Marcel: /* Evanston, Oct 22, 2014 */

SIG:Correspondence/minutes-evanston

2014-11-10T12:52:18Z

Illetschko Marcel: /* TEI SIG on Correspondence - Minutes Evanston, Oct 22, 2014 */

==TEI SIG on Correspondence - Minutes Evanston, Oct 22, 2014==

Status: draft --[[User: Marcel Illetschko]] 13:52, 10 November 2014 (EST)

===Attendees===
Attendees very briefly introduced themselves and their ongoing and/or planned projects:
* Marcel Illetschko: [http://www.onb.ac.at/sammlungen/litarchiv/literaturarchiv_projekte.htm#seuffert Literature Archive of the Austrian National Library, Correspondence Sauer – Seuffert]
* Andy Jewell: [http://cdrh.unl.edu/about/faculty/jewell University of Nebraska-Lincoln], [http://cather.unl.edu Willa Cather Archive]
* Angelika Kreh: [http://exilnetz33.de/de/projektteam/ German Literature Archive Marbach, Epistolary Networks]
* Anne Lorenz: [http://exilnetz33.de/de/projektteam/ German Literature Archive Marbach, Epistolary Networks]
* Elena Pierazzo: Université de Grenoble 3 'Stendhal', King’s College London ([http://www.elenapierazzo.org elenapierazzo.org])
* Sabine Seifert: [http://tei.ibi.hu-berlin.de/berliner-intellektuelle/ Humboldt University Berlin, Berlin Intellectuals 1800-1830]
* Peter Stadler: [http://www.weber-gesamtausgabe.de/de/A009001 University of Paderborn, Carl Maria von Weber Collected Works]
* Magdalena Turska: University of Oxford, DiXiT ([https://oxford.academia.edu/MagdalenaTurska Magdalena Turska @academia.edu])
* Laura Weakly: [http://unlcms.unl.edu/cas/center-for-digital-research-in-the-humanities/about/staff/weakly University of Nebraska-Lincoln ], [http://www.codyarchive.org William F. Cody Archive], [http://neihardt.unl.edu Interdisciplinary Life and Letters of John G. Neihardt]

===Discussion of <correspDesc>===
The SIG meeting took place right after the presentation of the proposed new <correspDesc> element by Sabine, Marcel and Peter. It started – actually before a short introduction by Peter and a brief insight in ongoing projects by the attendees – with Andrew’s question about the general procedure to include new elements in the TEI. Elena pointed out the importance of doing first things first: The new proposal should focus on the most important parts of <correspDesc>, other elements could be implemented afterwards. In general it was very useful to inform the council quite early or to invite members of the council to participate in the development of new elements since on the one hand their experience is helpful and on the other hand the council gets first-hand information.
We also discussed minor topics as the encoding of envelopes and address lines and the different views on these questions (Elena: envelopes sometimes get re-used and therefore have a “life themselves”, Magdalena: in the 16th century there were no envelopes at all so the usage of <div> is appropriate, Elena and Peter: one needs to clearly distinguish between the metadata (e.g. dates) derived from the envelopes and the text on the envelope itself).
Andy expressed his hope that minor issues concerning the encoding of correspondence could be implemented more quickly. After all one could see that there is a strong international demand for the implementation of the proposed <correspDesc> element.
Laura provided an example from the Neihardt collection for testing with the current correspDesc proposal.

===Organisational matters===
Please add editions to our [http://wiki.tei-c.org/index.php/SIG:Correspondence#Correspondence_Projects wiki]!
The TEI small grant initiative is still active – maybe a workshop for the development of a best practice model for correspondence would be helpful.

SIG:Correspondence/minutes-evanston

2014-11-10T12:51:49Z

Illetschko Marcel: /* Organisational matters */

==TEI SIG on Correspondence - Minutes Evanston, Oct 22, 2014==

Status: draft --[[User: Marcel Illetschko]] 13:45, 10 November 2014 (EST)

===Attendees===
Attendees very briefly introduced themselves and their ongoing and/or planned projects:
* Marcel Illetschko: [http://www.onb.ac.at/sammlungen/litarchiv/literaturarchiv_projekte.htm#seuffert Literature Archive of the Austrian National Library, Correspondence Sauer – Seuffert]
* Andy Jewell: [http://cdrh.unl.edu/about/faculty/jewell University of Nebraska-Lincoln], [http://cather.unl.edu Willa Cather Archive]
* Angelika Kreh: [http://exilnetz33.de/de/projektteam/ German Literature Archive Marbach, Epistolary Networks]
* Anne Lorenz: [http://exilnetz33.de/de/projektteam/ German Literature Archive Marbach, Epistolary Networks]
* Elena Pierazzo: Université de Grenoble 3 'Stendhal', King’s College London ([http://www.elenapierazzo.org elenapierazzo.org])
* Sabine Seifert: [http://tei.ibi.hu-berlin.de/berliner-intellektuelle/ Humboldt University Berlin, Berlin Intellectuals 1800-1830]
* Peter Stadler: [http://www.weber-gesamtausgabe.de/de/A009001 University of Paderborn, Carl Maria von Weber Collected Works]
* Magdalena Turska: University of Oxford, DiXiT ([https://oxford.academia.edu/MagdalenaTurska Magdalena Turska @academia.edu])
* Laura Weakly: [http://unlcms.unl.edu/cas/center-for-digital-research-in-the-humanities/about/staff/weakly University of Nebraska-Lincoln ], [http://www.codyarchive.org William F. Cody Archive], [http://neihardt.unl.edu Interdisciplinary Life and Letters of John G. Neihardt]

===Discussion of <correspDesc>===
The SIG meeting took place right after the presentation of the proposed new <correspDesc> element by Sabine, Marcel and Peter. It started – actually before a short introduction by Peter and a brief insight in ongoing projects by the attendees – with Andrew’s question about the general procedure to include new elements in the TEI. Elena pointed out the importance of doing first things first: The new proposal should focus on the most important parts of <correspDesc>, other elements could be implemented afterwards. In general it was very useful to inform the council quite early or to invite members of the council to participate in the development of new elements since on the one hand their experience is helpful and on the other hand the council gets first-hand information.
We also discussed minor topics as the encoding of envelopes and address lines and the different views on these questions (Elena: envelopes sometimes get re-used and therefore have a “life themselves”, Magdalena: in the 16th century there were no envelopes at all so the usage of <div> is appropriate, Elena and Peter: one needs to clearly distinguish between the metadata (e.g. dates) derived from the envelopes and the text on the envelope itself).
Andy expressed his hope that minor issues concerning the encoding of correspondence could be implemented more quickly. After all one could see that there is a strong international demand for the implementation of the proposed <correspDesc> element.
Laura provided an example from the Neihardt collection for testing with the current correspDesc proposal.

===Organisational matters===
Please add editions to our [http://wiki.tei-c.org/index.php/SIG:Correspondence#Correspondence_Projects wiki]!
The TEI small grant initiative is still active – maybe a workshop for the development of a best practice model for correspondence would be helpful.

SIG:Correspondence/minutes-evanston

2014-11-10T12:51:28Z

Illetschko Marcel: /* Attendees */

==TEI SIG on Correspondence - Minutes Evanston, Oct 22, 2014==

Status: draft --[[User: Marcel Illetschko]] 13:45, 10 November 2014 (EST)

===Attendees===
Attendees very briefly introduced themselves and their ongoing and/or planned projects:
* Marcel Illetschko: [http://www.onb.ac.at/sammlungen/litarchiv/literaturarchiv_projekte.htm#seuffert Literature Archive of the Austrian National Library, Correspondence Sauer – Seuffert]
* Andy Jewell: [http://cdrh.unl.edu/about/faculty/jewell University of Nebraska-Lincoln], [http://cather.unl.edu Willa Cather Archive]
* Angelika Kreh: [http://exilnetz33.de/de/projektteam/ German Literature Archive Marbach, Epistolary Networks]
* Anne Lorenz: [http://exilnetz33.de/de/projektteam/ German Literature Archive Marbach, Epistolary Networks]
* Elena Pierazzo: Université de Grenoble 3 'Stendhal', King’s College London ([http://www.elenapierazzo.org elenapierazzo.org])
* Sabine Seifert: [http://tei.ibi.hu-berlin.de/berliner-intellektuelle/ Humboldt University Berlin, Berlin Intellectuals 1800-1830]
* Peter Stadler: [http://www.weber-gesamtausgabe.de/de/A009001 University of Paderborn, Carl Maria von Weber Collected Works]
* Magdalena Turska: University of Oxford, DiXiT ([https://oxford.academia.edu/MagdalenaTurska Magdalena Turska @academia.edu])
* Laura Weakly: [http://unlcms.unl.edu/cas/center-for-digital-research-in-the-humanities/about/staff/weakly University of Nebraska-Lincoln ], [http://www.codyarchive.org William F. Cody Archive], [http://neihardt.unl.edu Interdisciplinary Life and Letters of John G. Neihardt]

===Discussion of <correspDesc>===
The SIG meeting took place right after the presentation of the proposed new <correspDesc> element by Sabine, Marcel and Peter. It started – actually before a short introduction by Peter and a brief insight in ongoing projects by the attendees – with Andrew’s question about the general procedure to include new elements in the TEI. Elena pointed out the importance of doing first things first: The new proposal should focus on the most important parts of <correspDesc>, other elements could be implemented afterwards. In general it was very useful to inform the council quite early or to invite members of the council to participate in the development of new elements since on the one hand their experience is helpful and on the other hand the council gets first-hand information.
We also discussed minor topics as the encoding of envelopes and address lines and the different views on these questions (Elena: envelopes sometimes get re-used and therefore have a “life themselves”, Magdalena: in the 16th century there were no envelopes at all so the usage of <div> is appropriate, Elena and Peter: one needs to clearly distinguish between the metadata (e.g. dates) derived from the envelopes and the text on the envelope itself).
Andy expressed his hope that minor issues concerning the encoding of correspondence could be implemented more quickly. After all one could see that there is a strong international demand for the implementation of the proposed <correspDesc> element.
Laura provided an example from the Neihardt collection for testing with the current correspDesc proposal.

===Organisational matters===
Please add editions to our wiki ([http://wiki.tei-c.org/index.php/SIG:Correspondence#Correspondence_Projects])!
The TEI small grant initiative is still active – maybe a workshop for the development of a best practice model for correspondence would be helpful.

SIG:Correspondence/minutes-evanston

2014-11-10T12:51:13Z

Illetschko Marcel: /* Attendees */

==TEI SIG on Correspondence - Minutes Evanston, Oct 22, 2014==

Status: draft --[[User: Marcel Illetschko]] 13:45, 10 November 2014 (EST)

===Attendees===
Attendees very briefly introduced themselves and their ongoing and/or planned projects:
* Marcel Illetschko: [http://www.onb.ac.at/sammlungen/litarchiv/literaturarchiv_projekte.htm#seuffert Literature Archive of the Austrian National Library, Correspondence Sauer – Seuffert])
* Andy Jewell: [http://cdrh.unl.edu/about/faculty/jewell University of Nebraska-Lincoln], [http://cather.unl.edu Willa Cather Archive]
* Angelika Kreh: [http://exilnetz33.de/de/projektteam/ German Literature Archive Marbach, Epistolary Networks]
* Anne Lorenz: [http://exilnetz33.de/de/projektteam/ German Literature Archive Marbach, Epistolary Networks]
* Elena Pierazzo: Université de Grenoble 3 'Stendhal', King’s College London ([http://www.elenapierazzo.org elenapierazzo.org])
* Sabine Seifert: [http://tei.ibi.hu-berlin.de/berliner-intellektuelle/ Humboldt University Berlin, Berlin Intellectuals 1800-1830]
* Peter Stadler: [http://www.weber-gesamtausgabe.de/de/A009001 University of Paderborn, Carl Maria von Weber Collected Works]
* Magdalena Turska: University of Oxford, DiXiT ([https://oxford.academia.edu/MagdalenaTurska Magdalena Turska @academia.edu])
* Laura Weakly: [http://unlcms.unl.edu/cas/center-for-digital-research-in-the-humanities/about/staff/weakly University of Nebraska-Lincoln ], [http://www.codyarchive.org William F. Cody Archive], [http://neihardt.unl.edu Interdisciplinary Life and Letters of John G. Neihardt]

===Discussion of <correspDesc>===
The SIG meeting took place right after the presentation of the proposed new <correspDesc> element by Sabine, Marcel and Peter. It started – actually before a short introduction by Peter and a brief insight in ongoing projects by the attendees – with Andrew’s question about the general procedure to include new elements in the TEI. Elena pointed out the importance of doing first things first: The new proposal should focus on the most important parts of <correspDesc>, other elements could be implemented afterwards. In general it was very useful to inform the council quite early or to invite members of the council to participate in the development of new elements since on the one hand their experience is helpful and on the other hand the council gets first-hand information.
We also discussed minor topics as the encoding of envelopes and address lines and the different views on these questions (Elena: envelopes sometimes get re-used and therefore have a “life themselves”, Magdalena: in the 16th century there were no envelopes at all so the usage of <div> is appropriate, Elena and Peter: one needs to clearly distinguish between the metadata (e.g. dates) derived from the envelopes and the text on the envelope itself).
Andy expressed his hope that minor issues concerning the encoding of correspondence could be implemented more quickly. After all one could see that there is a strong international demand for the implementation of the proposed <correspDesc> element.
Laura provided an example from the Neihardt collection for testing with the current correspDesc proposal.

===Organisational matters===
Please add editions to our wiki ([http://wiki.tei-c.org/index.php/SIG:Correspondence#Correspondence_Projects])!
The TEI small grant initiative is still active – maybe a workshop for the development of a best practice model for correspondence would be helpful.

SIG:Correspondence

2014-11-10T12:47:03Z

Illetschko Marcel: /* Evanston, Oct 22, 2014 */

== News ==

* Task Force Paper "Towards a Correspondence Module in the TEI", held at the TEI conference in Evanston: [http://tei.northwestern.edu/files/2014/10/Seifert-Illetschko-Stadler-2f2zhn3.pdf Abstract], [https://prezi.com/e70bkx9iqiib/towards-a-correspondence-module-in-the-tei/ Prezi], [https://docs.google.com/document/d/16DTp789wkrhPXH_79zexSy8wHWZId7W-RZkO4e1BAGM/edit?usp=sharing Talk] --[[User:Pstadler|pstadler]] 14:52, 7 November 2014 (CET)
* SIG MEETING at TEI conference in Evanston, Oct 22, Wednesday --[[User:Pstadler|pstadler]] 14:52, 7 November 2014 (CET)
* New page for the [[SIG:Correspondence/task-force-correspDesc|correspDesc task force]] --[[User:Pstadler|pstadler]] 10:22, 11 November 2013 (EST)

== Introduction ==
The TEI Special Interest Group on Correspondence seeks to bring together scholars interested in creating digital scholarly editions of correspondence. The goal of the SIG will be to discuss and develop sample tagsets (including suggesting additions/modifications to the TEI Guidelines) for varying forms of correspondence as well as to create tutorials and best practice models.

Because the initiative for this SIG emerged from editorial work with 19th century letters, the organizers of this SIG have focused on these types of materials. However, we want this SIG to be more encompassing, embracing varying types of historical and literary correspondence including epistles, telegrams, postcards, etc., and perhaps other types of documents that share features with physical written correspondence like diaries, diary entries, letters to the editor, e-mail, blogs, etc.

The common feature of these sorts of text is a generally formalized physical appearance (e.g., an envelope for letters) and structure of content (i.e. address field, special formulas for opener and closer). [http://www.tei-c.org/Activities/Projects/da03.xml DALF] was one of the best documented projects in this area developing specific DTDs for those needs in P4: this may be a starting point for further work in P5.

Initial topics for the SIG Correspondence may include:
* the handling of the envelope and postal addresses
* the formal description of correspondence as a written dialogue between an author and an addressee
* correspondence-specific bibliographical data within the metadata section

== Activities ==

The SIG runs a mailing list, which you can join by visiting http://listserv.brown.edu/tei-corresp-sig.html .

=== Topics currently under discussion ===
* The content of a special '''correspDesc''' element (see [[SIG:Correspondence/ODD_work]])
* Discussion of different P5-customizations for correspondence (see [[SIG:Correspondence/EncodingComparisons]])
--> For this, see the work of the [[SIG:Correspondence/task-force-correspDesc|correspDesc task force]] for current developments.
* The content model of '''postscript''': look at the [[Collection of Postscript-Examples]] and the contributions to the [[ps-discussion]].
* How to deal with '''enclosures''' or '''attachements''' to a letter
* The content model of opener/closer and their connection with salute, signed, dateline, etc.
* diary entries
* definition of <signed> does not correspond with its actual use in the P5 guidelines
* address now in but not in <div>: maybe not a good idea
* notification of addresses (different in different parts of the world). Could this be handled more adequately than just with datelines?
* [[SIG:Correspondence/pre-printed_text|pre-printed text]] (e.g. letterhead, postcard captions)

=== Meetings ===

==== Evanston, Oct 22, 2014 ====

Exhaustive minutes at [[http://wiki.tei-c.org/index.php/SIG:Correspondence/minutes-evanston Minutes Evanston]]

==== TEI Tweet Chat, Oct 9, 2014 ====

The first TEI Tweet Chat on [https://twitter.com/ Twitter] ever was hosted by the social media coordinator, Paul O’Shea, and the SIG Correspondence for one hour (from 16 GMT+2 to 17 GMT+2) ([https://twitter.com/TEIconsortium/status/519047322098204672 twitter announcement]). It was meant as an attempt to include the public online community, apart from the people on the TEI mailing lists.

Topics discussed/mentioned include:
* recent work of the SIG on the new <ct:correspDesc> element and when it will be part of the official TEI Guidelines, names of the proposed new elements, e.g. placeSender vs. senderPlace, placeAddressee vs. Addressee, etc.
* some digital editions of correspondence/projects were mentioned, e.g. [http://www.weber-gesamtausgabe.de/de/Index Carl Maria von Weber-Collected Works], [http://dh.tcd.ie/letters1916/ Letters of 1916], [http://dh.ucc.ie/boole George Boole Collection software transcription desk], [http://tei.ibi.hu-berlin.de/berliner-intellektuelle/?en Letters and Texts. Intellectual Berlin around 1800]
* list of projects on this very wikipage for people to add their own projects
* the new webservice [http://correspsearch.bbaw.de/index.xql CorrespSearch] (making metadata of currently 3 different correspondence projects searchable), BEACON and CorrespSearch
* [http://tei.northwestern.edu/ TEI Conference 2014 in Chicago]
* [http://dhd2015.uni-graz.at/ Dhd Conference 2015] in Graz, Austria
* letter transcription as an undergrad class project, teaching XML and TEI for undergrads, MAs and PhDs
* choice of XML editors, [http://www.oxygenxml.com/ oXygen XML editor], eXist built-in exIDE editor, straight up text editor vs. interface that hides the XML
* Is a tweet a letter? Where are the boundaries of correspondence? one-to-one communication and many-to-many correspondence, meaning and intentionality, trees nobody heard falling that may have intentions

There is a [https://docs.google.com/document/d/1i7CcnoGJVDWxKj4uTExzUrTRXOaQkeCgtt6mbR37FLE chat report], a [https://t.co/jUl8cMJcxJ Twitter archive] and a [http://t.co/mB2GQ1STkS TAGS Explorer Visualisation].

==== Rome, Oct 3, 2013 ====

Exhaustive minutes at [[SIG:Correspondence/minutes-rome]]

==== College Station, Nov 9, 2012 ====

09-12:30PM at Rudder Tower 302

'''Agenda''':

# Report on last year's activities
# [[SIG:Correspondence/RequestForModule|Request for a correspondence module and a wrapper element for correspondence meta data]]
# AOB

'''Minutes'''

Short summary/Outcome: [[SIG:Correspondence/ODD_work|A second draft for a correspondence ODD]]

Details: [[Minutes College Station]]

==== Wuerzburg, Oct 15, 2011 ====

Agenda of the meeting during the Wuerzburg MM (on Oct 15, 2011 from 9am to 10:30am in room 1.003):
* 1. New members / projects / demands
* 2. Short survey of the development of the SIG and the topics discussed
* 3. Views of the group about proposing a <correspDesc> (or similar) element or not
* 4. Future activities of the SIG: P5-Customizations for Correspondence ("Dalfy" et al.) / Special Guidelines (TEI by example) / Proposals / Next Steps
* 5. Roadmap for 2012
* 6. Website and Wiki

===== Minutes / Results / Goals =====

For more detailed minutes see [[SIGcorresp Minutes 20111015|Minutes Wuerzburg]], the main results of the discussions and the goals for the near future are summed up here:

* Preliminary goal: initiate a comparison between several customized or non-customized TEI versions for correspondence (to be published on the WiKi)
* Middle-term goal: propose "official" customization(s) for correspondence
* Middle-term goal: ask people to make some or their examples available and find out in which way they used TEI for correspondence
* Middle-term goal: develop best practice models
* Long-term goal: develop a compressed proposal for handling correspondence within TEI

==== Zadar, Nov 13, 2010 ====

Participation: around 5 people

1. Peter gave a report on last year's activities
* Task force ‘Dalfy’ was established after the Ann Arbor Meeting: Markus Flatscher, Bert Van Raemdonck, Peter Stadler
* Goal: Mapping of DALF (P4) to TEI P5 as a basis for further work on a correspondence customization
* But: Momentum got lost …
* Further: Some discussion on TEI-L about "signed vs. salute"

2. A brief look on open questions
* Correspondence meta data: correspDesc?
* The content model of postscript (cf. the Collection of Postscript-Examples and the contributions to the ps-discussion.)
* The content model of opener/closer and their connection with salute, signed, dateline, byline etc.

3. Attempt to create a roadmap for 2011
* Peter suggested a second attempt for a grant to achieve the mapping of DALF to P5
* Discussion about possible fundings for such an attempt
* review of the last failed TEI grant proposal: it was criticized by the present panel members that no preliminary work was (visibly) carried out
* Susan suggested to first initiate a survey on the correspondence list

4. AOB
* nothing

==== Ann Arbor, Nov 14, 2009 ====

Business and working meeting during the annual members meeting.
'''Participants''': Syd Bauman (SB), Markus Flatscher (MF), Elena Pierazzo (EP), Malte Rehbein (MR), Paul Schaffner (PSc), Peter Stadler (PSt), Bert Van Raemdonck (BV)

The business meeting was attended by MF, PSc, PSt and BV and - since the number of participants allowed it - was an informal talk about the different projects, the last meeting at London and the "correspDesc" PS had proposed there as well as the question whether editing correspondence from printed (secondary) material needs to treated differently than correspondence from manuscript source material. Work on the roadmap was postponed to the working meeting.

The working meeting was attended by all above mentioned participants who agreed on the need for a customization of some of the P5 elements (and element classes) for encoding correspondence. Question is of course: how?
* P5 has introduced some elements that were inspired by what had been done earlier in DALF (P4), but not all P4 customizations in DALF are actually rendered in P5 (and vice versa). Hence, a comparison of both should be a good starting point to eventually come to a new ODD for encoding correspondence, and maybe even for introducing an actual module for future TEI Guidelines.
* MF, PSt and BV agree on doing such a mapping together. Since BV is like the only DALF original left, he will coordinate this: he will split the work up, and will be contacting MF and PSt for further arrangements. [UPDATE: Edward Vanhoutte and Ron Van den Branden agreed to work on this with BV face to face and then get back to MF and PSt afterwards. --[[User:Pstadler|pstadler]] 07:04, 27 November 2009 (EST)]
* Before X-mas, there should be a conference call to catch up on how the mapping proceeds. PSt will contact Dan O'Donnell for funding.
* Bugs and absurdities in P5 regarding correspondence should be posted on Sourceforge. Elena Pierazzo will be the liaison between the SIG and the TEI Council. She will help SIG members to report our findings through Sourceforge or otherwise.
* The mapping should result in a new ODD. SB is willing to help us create it. The new ODD should somehow be more or less DALF-like. Hence, the working title of the ODD is 'Dalfy'. Dalfy will be an oddified version of DALF where obviously identical concepts will already be mapped to their P5 equivalents (therefore Dalfy != DALF).
* After the mapping is done, useful elements (or concepts, structures) that are neither in DALF or in P5 yet, should be listed. Members of the SIG are welcome to suggest their own 'favourite missing elements'.
* With Dalfy as starting point we can than try to rearrange and modify it to come to a new Correspondence ODD (no code name yet!) that should resolve all problems and satisfy all needs...
* Issues that came up during the meetings concern <address> (and multiple addresses within one letter) (SB and EP), <signed> (everyone), endorsements as well as correspondence by committee (PSc)
* Besides the work on Dalfy PSt shall finish his work on oddifying his <correspDesc>.
'''Roadmap/Milestones''':
* Before Christmas: Teleconference about the mapping (MF, PSt, BV)
* Febr. 10, 2010: Mapping done
* July, 2010: Next SIG meeting at Digital Humanities conference (London) on new ODD

[Minutes PSt and BV]

==== London, Nov 8, 2008 ====

The first section (14-15:30) saw short presentations of current projects by:
* Tim McLoughlin: James Barry's letters
* Hilde Bøe: eMunch project (assisted by Ellen Nessheim Wiger with the Henrik Ibsen correspondence)
* Peter Boot: correspondence of Vincent van Gogh
* David Sewell: correspondence projects published via ROTUNDA
* Deborah K. Wright: correspondence of Matthew Prior
* Peter Stadler: correspondence of Carl Maria von Weber

The second section (16-16:45) had to be shortened due to organisational necessities but saw general discussion about
* the content model of postscript which is rather restricted and does not allow for an i.e. '''head''' element. Everyone was encouraged to send examples via the list. [Let me add that the same holds true for '''address''' --[[User:Pstadler|pstadler]]]
* the need and the possible content for an '''correspDesc''' element within '''sourceDesc'''. I will try to create an odd file with the necessary additions to the schema as a starting point for further expertise. --[[User:Pstadler|pstadler]].
* correspondence as an event. Lou pointed this out as similar topics were discussed in the ontologies SIG.

== Correspondence Projects ==

Please add your projects alphabetically with link and (if possible) a short description!

=== Ongoing Projects ===

* [http://gams.uni-graz.at/fedora/get/container:rollett/bdef:Container/get The Letters of Alexander Rollett]. A project of the Center for Information Modeling in the Humanities (ZIM) at the University of Graz.
* Alfred Escher Correspondence. A project of the Alfred Escher Foundation, Zurich [http://www.alfred-escher.ch (Alfred Escher-Stiftung)]. Edition of the correspondence of Alfred Escher, influential 19th century Swiss politician and entrepreneur (e.g. Credit Suisse, Gotthard railway), comprising several thousand letters. At first, an edition of selected letters to and from Escher will be published in book form, including rich annotations. The first volume of the series is already available. Later on, the correspondence of Alfred Escher will be made available online. The correspondence covers topics as diverse as politics, economics, education, railways, banks, insurance. [http://www.briefedition.alfred-escher.ch/ Alfred Escher-Briefedition]
* Digital Archive of Letters in Flanders authors and composers from the 19th & 20th century, [http://www.kantl.be/ctb/project/dalf/ DALF]
*''Complete Letters of Willa Cather'', a new digital scholarly edition of the American author's complete correspondence, scheduled for initial publication in January 2018 on the [http://cather.unl.edu Willa Cather Archive]
* ''Emily Dickinson's Correspondences'' (public version not yet online), to be published under the [http://rotunda.upress.virginia.edu Rotunda] imprint by University of Virginia Press. An edition of selected correspondence to and from American poet Emily Dickinson, with MS facsimiles and rich metadata capturing physical details of the manuscripts.
* Gundolf-Elli. Correspondence between Friedrich Gundolf and Elisabeth Salomon (George-Kreis). Project at the German Literature Archive. There is no website, yet. For more information use the mailing list.
* eMunch. Edvard Munch's written material: Complete letters, diaries and writings, [http://www.emunch.no/eng/index.htm] (Updated and expanded 15.06.2009)
* Schleiermacher, Friedrich - Edition of the correspondence at Berlin-Brandenburg Academy of Sciences and Humanities ([http://www.bbaw.de/ BBAW]). At the moment the new work environment (with TEI) is in development.
* Weber, C.M.v.: Complete letters, diaries, writings and compositions, [http://www.weber-gesamtausgabe.de/ Carl-Maria-von-Weber-Gesamtausgabe] (at the moment german only)
* Digital edition [http://141.20.126.175/berliner-intellektuelle/?language=de 'Letters and texts. The intellectual Berlin around 1800'.] Realized by the project 'Berlin Intellectuals 1800-1830' at Humboldt University Berlin. Publication of letters and work manuscripts of Berlin-based writers and scholars from the late 18th and early 19th century. Manuscript facsimiles, transcriptions with annotation, XML files made available. Web presence launched in April 2012 with a first set of texts. Will be progressively enriched during the upcoming years.
* [http://elec.enc.sorbonne.fr/dubourg/ Correspondance of the chancellor Antoine Du Bourg]. A project of the École nationale des chartes. Certainly one of the richest administrative and political correspondence for the France of the Renaissance, it evokes all matters a chancellor has to manage: royal finances, monitoring the printed production, economic politics, .... The whole corpus contains around 1200 letters; for the moment, one hundred has been published online, the edition is still regularly increased. The edition is part of a bigger project of digital editions of modern correspondences (15th-18th century): the aim is to build a model and interface which could be usable and shared to every non literary correspondences for early modern history.
* [http://dantiscus.al.uw.edu.pl Texts & Correspondence of Ioannes Dantiscus]. Launched in 2010 and building upon material recorded since 1989 at the University of Warsaw Ioannes Dantiscus’ correspondence forms Central-Eastern Europe’s largest collection of letters (over 6,000 letters, mostly Latin and German) related to the Polish royal court and its partners in Renaissance Europe.

=== Completed Projects ===
* [http://rotunda.upress.virginia.edu/dmde The Dolley Madison Digital Edition], part of the University of Virginia Press's [http://rotunda.upress.virginia.edu/ Rotunda] series. This is an ongoing publication, but the first two "volumes" are online. Currently the underlying data is tagged using the [http://adh.sc.edu/ Model Editions Partnership] variant of TEI (P4), but we are also exporting and transforming the documents to TEI P5 for interoperability with other material. (Contact: [mailto:dsewell@virginia.edu David Sewell])
* [http://www.vnsbrieven.org/VNS/?lang=en Van Nu en Straks: Brieven / Letters], Online edition of the correspondence concerning the literary journal 'Van Nu en Straks' (1419 letters). The annotated letters contain references to ca 2500 persons, 500 places, 1000 titles of books, 650 journal articles and 350 poems. A network of 3600 hyperlinks facilitates intuitive and associative consulting. Project at the [http://www.ctb.kantl.be Centre for Scholarly Editing and Document Studies] / Royal Academy of Dutch Language and Literature (KANTL-CTB, Ghent-Belgium) and Ghent University (Belgium). This project is part of the broader [http://www.kantl.be/ctb/project/dalf/ DALF-project].
* [http://www.vangoghletters.org/vg/ Vincent van Gogh, The letters]. A full edition of all the extant correspondence of Vincent van Gogh (900 letters). The edition includes full transcriptions (in Dutch and French), translation into English, facsimiles, extensive annotations and about 2000 illustrations.

[[Category:SIG|Correspondence]]

SIG:Correspondence/minutes-evanston

2014-11-10T12:41:43Z

Illetschko Marcel: /* Organisational matters */

==TEI SIG on Correspondence - Minutes Evanston, Oct 22, 2014==

Status: draft --[[User: Marcel Illetschko]] 13:45, 10 November 2014 (EST)

===Attendees===
Attendees very briefly introduced themselves and their ongoing and/or planned projects:
* Marcel Illetschko: Literature Archive of the Austrian National Library, Correspondence Sauer – Seuffert ([http://www.onb.ac.at/sammlungen/litarchiv/literaturarchiv_projekte.htm#seuffert])
* Andy Jewell: University of Nebraska-Lincoln ([http://cdrh.unl.edu/about/faculty/jewell]), Willa Cather Archive ([http://cather.unl.edu])
* Angelika Kreh: German Literature Archive Marbach, Epistolary Networks ([http://exilnetz33.de/de/projektteam/])
* Anne Lorenz: German Literature Archive Marbach, Epistolary Networks ([http://exilnetz33.de/de/projektteam/])
* Elena Pierazzo: Université de Grenoble 3 'Stendhal', King’s College London ([http://www.elenapierazzo.org])
* Sabine Seifert: Humboldt University Berlin, Berlin Intellectuals 1800-1830 ([http://tei.ibi.hu-berlin.de/berliner-intellektuelle/])
* Peter Stadler: ([[http://www.weber-gesamtausgabe.de/de/A009001]]) University of Paderborn, Carl Maria von Weber Collected Works
* Magdalena Turska: University of Oxford, DiXiT ([https://oxford.academia.edu/MagdalenaTurska])
* Laura Weakly: University of Nebraska-Lincoln ([http://unlcms.unl.edu/cas/center-for-digital-research-in-the-humanities/about/staff/weakly]), William F. Cody Archive ([http://www.codyarchive.org]), Interdisciplinary Life and Letters of John G. Neihardt ([http://neihardt.unl.edu])

===Discussion of <correspDesc>===
The SIG meeting took place right after the presentation of the proposed new <correspDesc> element by Sabine, Marcel and Peter. It started – actually before a short introduction by Peter and a brief insight in ongoing projects by the attendees – with Andrew’s question about the general procedure to include new elements in the TEI. Elena pointed out the importance of doing first things first: The new proposal should focus on the most important parts of <correspDesc>, other elements could be implemented afterwards. In general it was very useful to inform the council quite early or to invite members of the council to participate in the development of new elements since on the one hand their experience is helpful and on the other hand the council gets first-hand information.
We also discussed minor topics as the encoding of envelopes and address lines and the different views on these questions (Elena: envelopes sometimes get re-used and therefore have a “life themselves”, Magdalena: in the 16th century there were no envelopes at all so the usage of <div> is appropriate, Elena and Peter: one needs to clearly distinguish between the metadata (e.g. dates) derived from the envelopes and the text on the envelope itself).
Andy expressed his hope that minor issues concerning the encoding of correspondence could be implemented more quickly. After all one could see that there is a strong international demand for the implementation of the proposed <correspDesc> element.
Laura provided an example from the Neihardt collection for testing with the current correspDesc proposal.

===Organisational matters===
Please add editions to our wiki ([http://wiki.tei-c.org/index.php/SIG:Correspondence#Correspondence_Projects])!
The TEI small grant initiative is still active – maybe a workshop for the development of a best practice model for correspondence would be helpful.

SIG:Correspondence/minutes-evanston

2014-11-10T12:40:51Z

Illetschko Marcel: /* Organisational matters */

==TEI SIG on Correspondence - Minutes Evanston, Oct 22, 2014==

Status: draft --[[User: Marcel Illetschko]] 13:45, 10 November 2014 (EST)

===Attendees===
Attendees very briefly introduced themselves and their ongoing and/or planned projects:
* Marcel Illetschko: Literature Archive of the Austrian National Library, Correspondence Sauer – Seuffert ([http://www.onb.ac.at/sammlungen/litarchiv/literaturarchiv_projekte.htm#seuffert])
* Andy Jewell: University of Nebraska-Lincoln ([http://cdrh.unl.edu/about/faculty/jewell]), Willa Cather Archive ([http://cather.unl.edu])
* Angelika Kreh: German Literature Archive Marbach, Epistolary Networks ([http://exilnetz33.de/de/projektteam/])
* Anne Lorenz: German Literature Archive Marbach, Epistolary Networks ([http://exilnetz33.de/de/projektteam/])
* Elena Pierazzo: Université de Grenoble 3 'Stendhal', King’s College London ([http://www.elenapierazzo.org])
* Sabine Seifert: Humboldt University Berlin, Berlin Intellectuals 1800-1830 ([http://tei.ibi.hu-berlin.de/berliner-intellektuelle/])
* Peter Stadler: ([[http://www.weber-gesamtausgabe.de/de/A009001]]) University of Paderborn, Carl Maria von Weber Collected Works
* Magdalena Turska: University of Oxford, DiXiT ([https://oxford.academia.edu/MagdalenaTurska])
* Laura Weakly: University of Nebraska-Lincoln ([http://unlcms.unl.edu/cas/center-for-digital-research-in-the-humanities/about/staff/weakly]), William F. Cody Archive ([http://www.codyarchive.org]), Interdisciplinary Life and Letters of John G. Neihardt ([http://neihardt.unl.edu])

===Discussion of <correspDesc>===
The SIG meeting took place right after the presentation of the proposed new <correspDesc> element by Sabine, Marcel and Peter. It started – actually before a short introduction by Peter and a brief insight in ongoing projects by the attendees – with Andrew’s question about the general procedure to include new elements in the TEI. Elena pointed out the importance of doing first things first: The new proposal should focus on the most important parts of <correspDesc>, other elements could be implemented afterwards. In general it was very useful to inform the council quite early or to invite members of the council to participate in the development of new elements since on the one hand their experience is helpful and on the other hand the council gets first-hand information.
We also discussed minor topics as the encoding of envelopes and address lines and the different views on these questions (Elena: envelopes sometimes get re-used and therefore have a “life themselves”, Magdalena: in the 16th century there were no envelopes at all so the usage of <div> is appropriate, Elena and Peter: one needs to clearly distinguish between the metadata (e.g. dates) derived from the envelopes and the text on the envelope itself).
Andy expressed his hope that minor issues concerning the encoding of correspondence could be implemented more quickly. After all one could see that there is a strong international demand for the implementation of the proposed <correspDesc> element.
Laura provided an example from the Neihardt collection for testing with the current correspDesc proposal.

===Organisational matters===
Please add editions to our wiki [http://wiki.tei-c.org/index.php/SIG:Correspondence#Correspondence_Projects]!
The TEI small grant initiative is still active – maybe a workshop for the development of a best practice model for correspondence would be helpful.

SIG:Correspondence/minutes-evanston

2014-11-10T12:40:35Z

Illetschko Marcel: /* Organisational matters */

==TEI SIG on Correspondence - Minutes Evanston, Oct 22, 2014==

Status: draft --[[User: Marcel Illetschko]] 13:45, 10 November 2014 (EST)

===Attendees===
Attendees very briefly introduced themselves and their ongoing and/or planned projects:
* Marcel Illetschko: Literature Archive of the Austrian National Library, Correspondence Sauer – Seuffert ([http://www.onb.ac.at/sammlungen/litarchiv/literaturarchiv_projekte.htm#seuffert])
* Andy Jewell: University of Nebraska-Lincoln ([http://cdrh.unl.edu/about/faculty/jewell]), Willa Cather Archive ([http://cather.unl.edu])
* Angelika Kreh: German Literature Archive Marbach, Epistolary Networks ([http://exilnetz33.de/de/projektteam/])
* Anne Lorenz: German Literature Archive Marbach, Epistolary Networks ([http://exilnetz33.de/de/projektteam/])
* Elena Pierazzo: Université de Grenoble 3 'Stendhal', King’s College London ([http://www.elenapierazzo.org])
* Sabine Seifert: Humboldt University Berlin, Berlin Intellectuals 1800-1830 ([http://tei.ibi.hu-berlin.de/berliner-intellektuelle/])
* Peter Stadler: ([[http://www.weber-gesamtausgabe.de/de/A009001]]) University of Paderborn, Carl Maria von Weber Collected Works
* Magdalena Turska: University of Oxford, DiXiT ([https://oxford.academia.edu/MagdalenaTurska])
* Laura Weakly: University of Nebraska-Lincoln ([http://unlcms.unl.edu/cas/center-for-digital-research-in-the-humanities/about/staff/weakly]), William F. Cody Archive ([http://www.codyarchive.org]), Interdisciplinary Life and Letters of John G. Neihardt ([http://neihardt.unl.edu])

===Discussion of <correspDesc>===
The SIG meeting took place right after the presentation of the proposed new <correspDesc> element by Sabine, Marcel and Peter. It started – actually before a short introduction by Peter and a brief insight in ongoing projects by the attendees – with Andrew’s question about the general procedure to include new elements in the TEI. Elena pointed out the importance of doing first things first: The new proposal should focus on the most important parts of <correspDesc>, other elements could be implemented afterwards. In general it was very useful to inform the council quite early or to invite members of the council to participate in the development of new elements since on the one hand their experience is helpful and on the other hand the council gets first-hand information.
We also discussed minor topics as the encoding of envelopes and address lines and the different views on these questions (Elena: envelopes sometimes get re-used and therefore have a “life themselves”, Magdalena: in the 16th century there were no envelopes at all so the usage of <div> is appropriate, Elena and Peter: one needs to clearly distinguish between the metadata (e.g. dates) derived from the envelopes and the text on the envelope itself).
Andy expressed his hope that minor issues concerning the encoding of correspondence could be implemented more quickly. After all one could see that there is a strong international demand for the implementation of the proposed <correspDesc> element.
Laura provided an example from the Neihardt collection for testing with the current correspDesc proposal.

===Organisational matters===
Please add editions to our wiki ([http://wiki.tei-c.org/index.php/SIG:Correspondence#Correspondence_Projects])!
The TEI small grant initiative is still active – maybe a workshop for the development of a best practice model for correspondence would be helpful.

SIG:Correspondence/minutes-evanston

2014-11-10T12:39:25Z

Illetschko Marcel: Created page with "==TEI SIG on Correspondence - Minutes Evanston, Oct 22, 2014== Status: draft --User: Marcel Illetschko 13:45, 10 November 2014 (EST) ===Attendees=== Attendees very briefly ..."

==TEI SIG on Correspondence - Minutes Evanston, Oct 22, 2014==

Status: draft --[[User: Marcel Illetschko]] 13:45, 10 November 2014 (EST)

===Attendees===
Attendees very briefly introduced themselves and their ongoing and/or planned projects:
* Marcel Illetschko: Literature Archive of the Austrian National Library, Correspondence Sauer – Seuffert ([http://www.onb.ac.at/sammlungen/litarchiv/literaturarchiv_projekte.htm#seuffert])
* Andy Jewell: University of Nebraska-Lincoln ([http://cdrh.unl.edu/about/faculty/jewell]), Willa Cather Archive ([http://cather.unl.edu])
* Angelika Kreh: German Literature Archive Marbach, Epistolary Networks ([http://exilnetz33.de/de/projektteam/])
* Anne Lorenz: German Literature Archive Marbach, Epistolary Networks ([http://exilnetz33.de/de/projektteam/])
* Elena Pierazzo: Université de Grenoble 3 'Stendhal', King’s College London ([http://www.elenapierazzo.org])
* Sabine Seifert: Humboldt University Berlin, Berlin Intellectuals 1800-1830 ([http://tei.ibi.hu-berlin.de/berliner-intellektuelle/])
* Peter Stadler: ([[http://www.weber-gesamtausgabe.de/de/A009001]]) University of Paderborn, Carl Maria von Weber Collected Works
* Magdalena Turska: University of Oxford, DiXiT ([https://oxford.academia.edu/MagdalenaTurska])
* Laura Weakly: University of Nebraska-Lincoln ([http://unlcms.unl.edu/cas/center-for-digital-research-in-the-humanities/about/staff/weakly]), William F. Cody Archive ([http://www.codyarchive.org]), Interdisciplinary Life and Letters of John G. Neihardt ([http://neihardt.unl.edu])

===Discussion of <correspDesc>===
The SIG meeting took place right after the presentation of the proposed new <correspDesc> element by Sabine, Marcel and Peter. It started – actually before a short introduction by Peter and a brief insight in ongoing projects by the attendees – with Andrew’s question about the general procedure to include new elements in the TEI. Elena pointed out the importance of doing first things first: The new proposal should focus on the most important parts of <correspDesc>, other elements could be implemented afterwards. In general it was very useful to inform the council quite early or to invite members of the council to participate in the development of new elements since on the one hand their experience is helpful and on the other hand the council gets first-hand information.
We also discussed minor topics as the encoding of envelopes and address lines and the different views on these questions (Elena: envelopes sometimes get re-used and therefore have a “life themselves”, Magdalena: in the 16th century there were no envelopes at all so the usage of <div> is appropriate, Elena and Peter: one needs to clearly distinguish between the metadata (e.g. dates) derived from the envelopes and the text on the envelope itself).
Andy expressed his hope that minor issues concerning the encoding of correspondence could be implemented more quickly. After all one could see that there is a strong international demand for the implementation of the proposed <correspDesc> element.
Laura provided an example from the Neihardt collection for testing with the current correspDesc proposal.

===Organisational matters===
Please add editions to our wiki ([http://wiki.tei-c.org/index.php/SIG:Correspondence#Correspondence_Projects])!
The TEI small grant initiative is still active – maybe a workshop for the development of a best practice model for correspondence would be helpful.

SIG:Correspondence

2014-11-10T12:21:42Z

Illetschko Marcel: /* Evanston, Oct 22, 2014 */

== News ==

* Task Force Paper "Towards a Correspondence Module in the TEI", held at the TEI conference in Evanston: [http://tei.northwestern.edu/files/2014/10/Seifert-Illetschko-Stadler-2f2zhn3.pdf Abstract], [https://prezi.com/e70bkx9iqiib/towards-a-correspondence-module-in-the-tei/ Prezi], [https://docs.google.com/document/d/16DTp789wkrhPXH_79zexSy8wHWZId7W-RZkO4e1BAGM/edit?usp=sharing Talk] --[[User:Pstadler|pstadler]] 14:52, 7 November 2014 (CET)
* SIG MEETING at TEI conference in Evanston, Oct 22, Wednesday --[[User:Pstadler|pstadler]] 14:52, 7 November 2014 (CET)
* New page for the [[SIG:Correspondence/task-force-correspDesc|correspDesc task force]] --[[User:Pstadler|pstadler]] 10:22, 11 November 2013 (EST)

== Introduction ==
The TEI Special Interest Group on Correspondence seeks to bring together scholars interested in creating digital scholarly editions of correspondence. The goal of the SIG will be to discuss and develop sample tagsets (including suggesting additions/modifications to the TEI Guidelines) for varying forms of correspondence as well as to create tutorials and best practice models.

Because the initiative for this SIG emerged from editorial work with 19th century letters, the organizers of this SIG have focused on these types of materials. However, we want this SIG to be more encompassing, embracing varying types of historical and literary correspondence including epistles, telegrams, postcards, etc., and perhaps other types of documents that share features with physical written correspondence like diaries, diary entries, letters to the editor, e-mail, blogs, etc.

The common feature of these sorts of text is a generally formalized physical appearance (e.g., an envelope for letters) and structure of content (i.e. address field, special formulas for opener and closer). [http://www.tei-c.org/Activities/Projects/da03.xml DALF] was one of the best documented projects in this area developing specific DTDs for those needs in P4: this may be a starting point for further work in P5.

Initial topics for the SIG Correspondence may include:
* the handling of the envelope and postal addresses
* the formal description of correspondence as a written dialogue between an author and an addressee
* correspondence-specific bibliographical data within the metadata section

== Activities ==

The SIG runs a mailing list, which you can join by visiting http://listserv.brown.edu/tei-corresp-sig.html .

=== Topics currently under discussion ===
* The content of a special '''correspDesc''' element (see [[SIG:Correspondence/ODD_work]])
* Discussion of different P5-customizations for correspondence (see [[SIG:Correspondence/EncodingComparisons]])
--> For this, see the work of the [[SIG:Correspondence/task-force-correspDesc|correspDesc task force]] for current developments.
* The content model of '''postscript''': look at the [[Collection of Postscript-Examples]] and the contributions to the [[ps-discussion]].
* How to deal with '''enclosures''' or '''attachements''' to a letter
* The content model of opener/closer and their connection with salute, signed, dateline, etc.
* diary entries
* definition of <signed> does not correspond with its actual use in the P5 guidelines
* address now in but not in <div>: maybe not a good idea
* notification of addresses (different in different parts of the world). Could this be handled more adequately than just with datelines?
* [[SIG:Correspondence/pre-printed_text|pre-printed text]] (e.g. letterhead, postcard captions)

=== Meetings ===

==== Evanston, Oct 22, 2014 ====

Exhaustive minutes at [[http://wiki.tei-c.org/index.php/SIG:Correspondence/minutes-evanston]]

==== TEI Tweet Chat, Oct 9, 2014 ====

The first TEI Tweet Chat on [https://twitter.com/ Twitter] ever was hosted by the social media coordinator, Paul O’Shea, and the SIG Correspondence for one hour (from 16 GMT+2 to 17 GMT+2) ([https://twitter.com/TEIconsortium/status/519047322098204672 twitter announcement]). It was meant as an attempt to include the public online community, apart from the people on the TEI mailing lists.

Topics discussed/mentioned include:
* recent work of the SIG on the new <ct:correspDesc> element and when it will be part of the official TEI Guidelines, names of the proposed new elements, e.g. placeSender vs. senderPlace, placeAddressee vs. Addressee, etc.
* some digital editions of correspondence/projects were mentioned, e.g. [http://www.weber-gesamtausgabe.de/de/Index Carl Maria von Weber-Collected Works], [http://dh.tcd.ie/letters1916/ Letters of 1916], [http://dh.ucc.ie/boole George Boole Collection software transcription desk], [http://tei.ibi.hu-berlin.de/berliner-intellektuelle/?en Letters and Texts. Intellectual Berlin around 1800]
* list of projects on this very wikipage for people to add their own projects
* the new webservice [http://correspsearch.bbaw.de/index.xql CorrespSearch] (making metadata of currently 3 different correspondence projects searchable), BEACON and CorrespSearch
* [http://tei.northwestern.edu/ TEI Conference 2014 in Chicago]
* [http://dhd2015.uni-graz.at/ Dhd Conference 2015] in Graz, Austria
* letter transcription as an undergrad class project, teaching XML and TEI for undergrads, MAs and PhDs
* choice of XML editors, [http://www.oxygenxml.com/ oXygen XML editor], eXist built-in exIDE editor, straight up text editor vs. interface that hides the XML
* Is a tweet a letter? Where are the boundaries of correspondence? one-to-one communication and many-to-many correspondence, meaning and intentionality, trees nobody heard falling that may have intentions

There is a [https://docs.google.com/document/d/1i7CcnoGJVDWxKj4uTExzUrTRXOaQkeCgtt6mbR37FLE chat report], a [https://t.co/jUl8cMJcxJ Twitter archive] and a [http://t.co/mB2GQ1STkS TAGS Explorer Visualisation].

==== Rome, Oct 3, 2013 ====

Exhaustive minutes at [[SIG:Correspondence/minutes-rome]]

==== College Station, Nov 9, 2012 ====

09-12:30PM at Rudder Tower 302

'''Agenda''':

# Report on last year's activities
# [[SIG:Correspondence/RequestForModule|Request for a correspondence module and a wrapper element for correspondence meta data]]
# AOB

'''Minutes'''

Short summary/Outcome: [[SIG:Correspondence/ODD_work|A second draft for a correspondence ODD]]

Details: [[Minutes College Station]]

==== Wuerzburg, Oct 15, 2011 ====

Agenda of the meeting during the Wuerzburg MM (on Oct 15, 2011 from 9am to 10:30am in room 1.003):
* 1. New members / projects / demands
* 2. Short survey of the development of the SIG and the topics discussed
* 3. Views of the group about proposing a <correspDesc> (or similar) element or not
* 4. Future activities of the SIG: P5-Customizations for Correspondence ("Dalfy" et al.) / Special Guidelines (TEI by example) / Proposals / Next Steps
* 5. Roadmap for 2012
* 6. Website and Wiki

===== Minutes / Results / Goals =====

For more detailed minutes see [[SIGcorresp Minutes 20111015|Minutes Wuerzburg]], the main results of the discussions and the goals for the near future are summed up here:

* Preliminary goal: initiate a comparison between several customized or non-customized TEI versions for correspondence (to be published on the WiKi)
* Middle-term goal: propose "official" customization(s) for correspondence
* Middle-term goal: ask people to make some or their examples available and find out in which way they used TEI for correspondence
* Middle-term goal: develop best practice models
* Long-term goal: develop a compressed proposal for handling correspondence within TEI

==== Zadar, Nov 13, 2010 ====

Participation: around 5 people

1. Peter gave a report on last year's activities
* Task force ‘Dalfy’ was established after the Ann Arbor Meeting: Markus Flatscher, Bert Van Raemdonck, Peter Stadler
* Goal: Mapping of DALF (P4) to TEI P5 as a basis for further work on a correspondence customization
* But: Momentum got lost …
* Further: Some discussion on TEI-L about "signed vs. salute"

2. A brief look on open questions
* Correspondence meta data: correspDesc?
* The content model of postscript (cf. the Collection of Postscript-Examples and the contributions to the ps-discussion.)
* The content model of opener/closer and their connection with salute, signed, dateline, byline etc.

3. Attempt to create a roadmap for 2011
* Peter suggested a second attempt for a grant to achieve the mapping of DALF to P5
* Discussion about possible fundings for such an attempt
* review of the last failed TEI grant proposal: it was criticized by the present panel members that no preliminary work was (visibly) carried out
* Susan suggested to first initiate a survey on the correspondence list

4. AOB
* nothing

==== Ann Arbor, Nov 14, 2009 ====

Business and working meeting during the annual members meeting.
'''Participants''': Syd Bauman (SB), Markus Flatscher (MF), Elena Pierazzo (EP), Malte Rehbein (MR), Paul Schaffner (PSc), Peter Stadler (PSt), Bert Van Raemdonck (BV)

The business meeting was attended by MF, PSc, PSt and BV and - since the number of participants allowed it - was an informal talk about the different projects, the last meeting at London and the "correspDesc" PS had proposed there as well as the question whether editing correspondence from printed (secondary) material needs to treated differently than correspondence from manuscript source material. Work on the roadmap was postponed to the working meeting.

The working meeting was attended by all above mentioned participants who agreed on the need for a customization of some of the P5 elements (and element classes) for encoding correspondence. Question is of course: how?
* P5 has introduced some elements that were inspired by what had been done earlier in DALF (P4), but not all P4 customizations in DALF are actually rendered in P5 (and vice versa). Hence, a comparison of both should be a good starting point to eventually come to a new ODD for encoding correspondence, and maybe even for introducing an actual module for future TEI Guidelines.
* MF, PSt and BV agree on doing such a mapping together. Since BV is like the only DALF original left, he will coordinate this: he will split the work up, and will be contacting MF and PSt for further arrangements. [UPDATE: Edward Vanhoutte and Ron Van den Branden agreed to work on this with BV face to face and then get back to MF and PSt afterwards. --[[User:Pstadler|pstadler]] 07:04, 27 November 2009 (EST)]
* Before X-mas, there should be a conference call to catch up on how the mapping proceeds. PSt will contact Dan O'Donnell for funding.
* Bugs and absurdities in P5 regarding correspondence should be posted on Sourceforge. Elena Pierazzo will be the liaison between the SIG and the TEI Council. She will help SIG members to report our findings through Sourceforge or otherwise.
* The mapping should result in a new ODD. SB is willing to help us create it. The new ODD should somehow be more or less DALF-like. Hence, the working title of the ODD is 'Dalfy'. Dalfy will be an oddified version of DALF where obviously identical concepts will already be mapped to their P5 equivalents (therefore Dalfy != DALF).
* After the mapping is done, useful elements (or concepts, structures) that are neither in DALF or in P5 yet, should be listed. Members of the SIG are welcome to suggest their own 'favourite missing elements'.
* With Dalfy as starting point we can than try to rearrange and modify it to come to a new Correspondence ODD (no code name yet!) that should resolve all problems and satisfy all needs...
* Issues that came up during the meetings concern <address> (and multiple addresses within one letter) (SB and EP), <signed> (everyone), endorsements as well as correspondence by committee (PSc)
* Besides the work on Dalfy PSt shall finish his work on oddifying his <correspDesc>.
'''Roadmap/Milestones''':
* Before Christmas: Teleconference about the mapping (MF, PSt, BV)
* Febr. 10, 2010: Mapping done
* July, 2010: Next SIG meeting at Digital Humanities conference (London) on new ODD

[Minutes PSt and BV]

==== London, Nov 8, 2008 ====

The first section (14-15:30) saw short presentations of current projects by:
* Tim McLoughlin: James Barry's letters
* Hilde Bøe: eMunch project (assisted by Ellen Nessheim Wiger with the Henrik Ibsen correspondence)
* Peter Boot: correspondence of Vincent van Gogh
* David Sewell: correspondence projects published via ROTUNDA
* Deborah K. Wright: correspondence of Matthew Prior
* Peter Stadler: correspondence of Carl Maria von Weber

The second section (16-16:45) had to be shortened due to organisational necessities but saw general discussion about
* the content model of postscript which is rather restricted and does not allow for an i.e. '''head''' element. Everyone was encouraged to send examples via the list. [Let me add that the same holds true for '''address''' --[[User:Pstadler|pstadler]]]
* the need and the possible content for an '''correspDesc''' element within '''sourceDesc'''. I will try to create an odd file with the necessary additions to the schema as a starting point for further expertise. --[[User:Pstadler|pstadler]].
* correspondence as an event. Lou pointed this out as similar topics were discussed in the ontologies SIG.

== Correspondence Projects ==

Please add your projects alphabetically with link and (if possible) a short description!

=== Ongoing Projects ===

* [http://gams.uni-graz.at/fedora/get/container:rollett/bdef:Container/get The Letters of Alexander Rollett]. A project of the Center for Information Modeling in the Humanities (ZIM) at the University of Graz.
* Alfred Escher Correspondence. A project of the Alfred Escher Foundation, Zurich [http://www.alfred-escher.ch (Alfred Escher-Stiftung)]. Edition of the correspondence of Alfred Escher, influential 19th century Swiss politician and entrepreneur (e.g. Credit Suisse, Gotthard railway), comprising several thousand letters. At first, an edition of selected letters to and from Escher will be published in book form, including rich annotations. The first volume of the series is already available. Later on, the correspondence of Alfred Escher will be made available online. The correspondence covers topics as diverse as politics, economics, education, railways, banks, insurance. [http://www.briefedition.alfred-escher.ch/ Alfred Escher-Briefedition]
* Digital Archive of Letters in Flanders authors and composers from the 19th & 20th century, [http://www.kantl.be/ctb/project/dalf/ DALF]
*''Complete Letters of Willa Cather'', a new digital scholarly edition of the American author's complete correspondence, scheduled for initial publication in January 2018 on the [http://cather.unl.edu Willa Cather Archive]
* ''Emily Dickinson's Correspondences'' (public version not yet online), to be published under the [http://rotunda.upress.virginia.edu Rotunda] imprint by University of Virginia Press. An edition of selected correspondence to and from American poet Emily Dickinson, with MS facsimiles and rich metadata capturing physical details of the manuscripts.
* Gundolf-Elli. Correspondence between Friedrich Gundolf and Elisabeth Salomon (George-Kreis). Project at the German Literature Archive. There is no website, yet. For more information use the mailing list.
* eMunch. Edvard Munch's written material: Complete letters, diaries and writings, [http://www.emunch.no/eng/index.htm] (Updated and expanded 15.06.2009)
* Schleiermacher, Friedrich - Edition of the correspondence at Berlin-Brandenburg Academy of Sciences and Humanities ([http://www.bbaw.de/ BBAW]). At the moment the new work environment (with TEI) is in development.
* Weber, C.M.v.: Complete letters, diaries, writings and compositions, [http://www.weber-gesamtausgabe.de/ Carl-Maria-von-Weber-Gesamtausgabe] (at the moment german only)
* Digital edition [http://141.20.126.175/berliner-intellektuelle/?language=de 'Letters and texts. The intellectual Berlin around 1800'.] Realized by the project 'Berlin Intellectuals 1800-1830' at Humboldt University Berlin. Publication of letters and work manuscripts of Berlin-based writers and scholars from the late 18th and early 19th century. Manuscript facsimiles, transcriptions with annotation, XML files made available. Web presence launched in April 2012 with a first set of texts. Will be progressively enriched during the upcoming years.
* [http://elec.enc.sorbonne.fr/dubourg/ Correspondance of the chancellor Antoine Du Bourg]. A project of the École nationale des chartes. Certainly one of the richest administrative and political correspondence for the France of the Renaissance, it evokes all matters a chancellor has to manage: royal finances, monitoring the printed production, economic politics, .... The whole corpus contains around 1200 letters; for the moment, one hundred has been published online, the edition is still regularly increased. The edition is part of a bigger project of digital editions of modern correspondences (15th-18th century): the aim is to build a model and interface which could be usable and shared to every non literary correspondences for early modern history.
* [http://dantiscus.al.uw.edu.pl Texts & Correspondence of Ioannes Dantiscus]. Launched in 2010 and building upon material recorded since 1989 at the University of Warsaw Ioannes Dantiscus’ correspondence forms Central-Eastern Europe’s largest collection of letters (over 6,000 letters, mostly Latin and German) related to the Polish royal court and its partners in Renaissance Europe.

=== Completed Projects ===
* [http://rotunda.upress.virginia.edu/dmde The Dolley Madison Digital Edition], part of the University of Virginia Press's [http://rotunda.upress.virginia.edu/ Rotunda] series. This is an ongoing publication, but the first two "volumes" are online. Currently the underlying data is tagged using the [http://adh.sc.edu/ Model Editions Partnership] variant of TEI (P4), but we are also exporting and transforming the documents to TEI P5 for interoperability with other material. (Contact: [mailto:dsewell@virginia.edu David Sewell])
* [http://www.vnsbrieven.org/VNS/?lang=en Van Nu en Straks: Brieven / Letters], Online edition of the correspondence concerning the literary journal 'Van Nu en Straks' (1419 letters). The annotated letters contain references to ca 2500 persons, 500 places, 1000 titles of books, 650 journal articles and 350 poems. A network of 3600 hyperlinks facilitates intuitive and associative consulting. Project at the [http://www.ctb.kantl.be Centre for Scholarly Editing and Document Studies] / Royal Academy of Dutch Language and Literature (KANTL-CTB, Ghent-Belgium) and Ghent University (Belgium). This project is part of the broader [http://www.kantl.be/ctb/project/dalf/ DALF-project].
* [http://www.vangoghletters.org/vg/ Vincent van Gogh, The letters]. A full edition of all the extant correspondence of Vincent van Gogh (900 letters). The edition includes full transcriptions (in Dutch and French), translation into English, facsimiles, extensive annotations and about 2000 illustrations.

[[Category:SIG|Correspondence]]

SIG:Correspondence/task-force-correspDesc

2014-09-05T09:59:55Z

Illetschko Marcel: /* Literature and previous work */

User talk:Illetschko Marcel

2014-09-05T09:59:12Z

Illetschko Marcel: /* accidentally created page? */

'''Welcome to ''TEIWiki''!'''
We hope you will contribute much and well.
You will probably want to read the [[Help:Contents|help pages]].
Again, welcome and have fun! [[User:DavidSewell|DavidSewell]] 15:25, 3 April 2014 (CEST)

== accidentally created page? ==

Hello, did you accidentally create a paged called "[[Here]]" but later continue your work at [[SIG:Correspondence/task-force-correspDesc/summary_of_the_recent_discussion]]? If so, as an admin user on this wiki, I can delete the "[[Here]]" page. ([[User:Kshawkin|Kshawkin]] 02:18, 3 September 2014 (CEST))

Yes, please delete it! Thanks - it was my first time...

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

2014-09-02T14:57:33Z

Illetschko Marcel: /* suggestion: needs more structure */

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

== <ct:corresDesc> ==

=== 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.

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

2014-09-02T14:56:39Z

Illetschko Marcel: /* questions */

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

== <ct:corresDesc> ==

=== 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.

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

2014-09-02T14:55:57Z

Illetschko Marcel: /* questions */

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

== <ct:corresDesc> ==

=== 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.

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

2014-09-02T14:55:40Z

Illetschko Marcel: /* */

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

== <ct:corresDesc> ==

=== 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.

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

2014-09-02T14:52:34Z

Illetschko Marcel: /* suggestion: needs more structure */

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

== <ct:corresDesc> ==

=== 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.

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

2014-09-02T14:51:38Z

Illetschko Marcel: /* Suggestion: needs more structure */

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

== <ct:corresDesc> ==

=== 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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

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

2014-09-02T14:51:16Z

Illetschko Marcel: /* D) */

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

== <ct:corresDesc> ==

=== 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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

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

2014-09-02T14:50:06Z

Illetschko Marcel: /* pros & cons */

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

== <ct:corresDesc> ==

=== 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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

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

2014-09-02T14:49:33Z

Illetschko Marcel: /* C) , //, , … */

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

== <ct:corresDesc> ==

=== 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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

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

2014-09-02T14:48:50Z

Illetschko Marcel: /* vs. */

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

== <ct:corresDesc> ==

=== 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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

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

2014-09-02T14:48:24Z

Illetschko Marcel: /* B) vs. */

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

== <ct:corresDesc> ==

=== 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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

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

2014-09-02T14:47:57Z

Illetschko Marcel: /* questions */

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

== <ct:corresDesc> ==

=== 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!).

==== B) <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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

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

2014-09-02T14:47:33Z

Illetschko Marcel: /* pros & cons */

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

== <ct:corresDesc> ==

=== 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!).

==== B) <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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

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

2014-09-02T14:47:12Z

Illetschko Marcel: /* */

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

== <ct:corresDesc> ==

=== 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!).

==== B) <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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

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

2014-09-02T14:46:28Z

Illetschko Marcel: /* A) */

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

==== <ct:corresDesc> ====

'''''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!).

==== B) <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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

SIG:Correspondence/task-force-correspDesc

2014-09-02T14:46:04Z

Illetschko Marcel: /* Recent discussion */

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

2014-09-02T14:45:25Z

Illetschko Marcel: /* A) */

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

==== A) <ct:corresDesc> ====

'''''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!).

==== B) <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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

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

2014-09-02T14:44:40Z

Illetschko Marcel: /* A) */

back to --> [[SIG:Correspondence/task-force-correspDesc]]

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

==== A) <ct:corresDesc> ====

'''''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!).

==== B) <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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

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

2014-09-02T14:43:10Z

Illetschko Marcel: /* A) */

back to --> [[SIG:Correspondence/task-force-correspDesc]]

==== A) <ct:corresDesc> ====

'''''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!).

==== B) <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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

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

2014-09-02T14:40:17Z

Illetschko Marcel: Created page with "==== A) <ct:corresDesc> ==== '''''pros & cons''''' There seems to be a general agreement on the necessity of such a container element. - James C.: “<ct:correspDesc> – This ..."

==== A) <ct:corresDesc> ====

'''''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!).

==== B) <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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

SIG:Correspondence/task-force-correspDesc

2014-09-02T14:40:04Z

Illetschko Marcel: /* Recent discussion */

<- back to [[SIG:Correspondence]]

= Task force "correspDesc" =

* '''Members''': Marcel Illetschko, Sabine Seifert, Peter Stadler
* "'''Pusher'''": Mariana Gomes

We will try to make our work as transparent and open as possible so others can chime in and contribute at every stage. Please feel free to make use of all the various comment/edit/share/fork functions or to contact us directly.

== Goal ==

Create a formal proposal for a <correspDesc> (or whatever name) element for approval by the TEI council as a new element of the TEI standard. This work shall be based on the "second draft for a correspondence module and a wrapper element for correspondence meta data" as it was started during the 2012 SIG meeting.

== Background ==

There have been several P4 projects with a dedicated correspondence schema (DALF probably being the renowned). While several correspondence tags (<postscript> etc.) are available from the TEI P5 standard, there is no specific way of dealing with correspondence meta data (e.g. sender, addressee) in the current TEI header. Since that's an impediment on the interoperability and interchange of these texts and since there are good practice models working with a <correspDesc>, the SIG Correspondence started to draft such a proposal during its 2012 meeting and now set up a task force for elaborating this draft.

== Repositories ==

https://github.com/TEI-Correspondence-SIG/correspDesc
This will be the main place for bringing together the proposal.

== Recent discussion ==

The SIG's proposal already caused a lot of traffic at the mailing list. See the [[SIG:Correspondence/task-force-correspDesc/summary of the recent discussion]] here - sorted by elements and furnished with the task force's view on the topics.

==== A) <ct:corresDesc> ====

'''''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!).

==== B) <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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

== Meetings ==

=== Meeting June 17-18, 2014 ===
Two days of intense work on the proposal, mainly reworking and adding of prose description with encoding examples in the chapter "Implementation of the correspondence description":
* differentiation between sender and author
* differentiation between the intended and the actual (place of) addressee
* repeating of direct child elements of <correspDesc>
* use of <transmission> in contrast to the TEI element <channel>
* use of <context> with varying evaluations of the position within a correspondence
* text classification, classification schemes (and the lack thereof) and materiality aspects.

Adding of examples to formal specification of various elements.

Preparing proposal for handing in as feature request soon. All updates available at GitHub, with additional HTML page for easy reading.

=== Conf Call June 12, 2014 ===
The main part of this conf call was held with Stefan Dumont (BBAW) who set up the web service "correspSearch" that analyzes beacon files based on the task force's <correspDesc> format from several digital correspondence editions and thus providing the possibility for searching through meta data of these editions.

Discussion of information needed from participating digital editions/projects: responsible person (preferably with e-mail address, in <titleStmt>); name of the beacon file (in <titleStmt>); latest update (in <revisionDesc>); information on licensing (with URL etc., <publicationStmt>); bibliographic reference (<sourceDesc>, <bibl>).

There is also the question of how to handle duplicates, i.e. one letter in more than one participating digital edition and thus resulting in two entries. Especially in these cases, a correspSearch ID for each entry is desirable (referencing to them with @ref).

<correspClass> is not yet part of the web service but could be implemented.

The web service "correspSearch" will be developed further and soon be publicly available online in a beta version, with corresponding API.

=== Conf Call May 28, 2014 ===

It's been our fastest conf call ever! We reported on last weeks activities (not much, but some additions to the [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub repo]) and agreed on a f2f meeting on June 17/18 in Berlin. Next conf call is scheduled for June 12, 10 AM.

=== Conf Call May 20, 2014 ===

==== Reports on two conferences: ====
# Berlin: [https://www.literatur.hu-berlin.de/aktuelles_idl/konferenzen_tagungen_vortraege/ontologien/programm "Datenmodellierung in digitalen Briefeditionen und ihre interpretatorische Leistung. Ontologien, Textgenetik und Visualisierungsstrategien"]
Peter presented on "interoperability of letter collections" and touched on the work of the task force. A lot of people are planning (dreaming) of connecting letter collections.
# Vienna: [http://www.ogl.at/programm/aktuelles-programm/ Editorenkolloquium]
"The old world" – a strong bias against digital editions and only few letter projects presented at the conference. Nevertheless Marcel waved the correspDesc flag during his talk.

==== correspSearch ====
Stefan Dumont from the BBAW created a web service for querying correspDesc data. This web service will be presented as an open beta at the end of June. During his work on correspSearch he encountered several bugs and missing features in the CIF standard that need to be addressed now. (see next point)

==== proposed schema changes ====
* rename addressee to receiver? We decided not to change that right now but we will wait for the natives to chime in.
* CIF: @when-iso instead of @when: For the web service there is a strong need for standardized date formats. --> Yes, will implement
* CIF: clearly defined meta data with information about origin, person in charge, last change date etc. --> Yes, will implement
* CIF: shall @notBefore be required to have a counterpart @notAfter? --> No, rejected

==== Roadmap ====
* Next conf call on May 28, 10 AM
* f2f meeting on June 17/18 (date needs to be finalized)
* feature request due before next Council f2f, June 30
* correspSearch will go public at the end of June

=== Conf Call March 17, 2014 ===
Peter gave a short summary of the workshop “Digitising experiences of migration” (Mellon Centre for Migration Studies, Omagh, Northern Ireland, March 14-15) – and we discussed the difficulties with lacking authority-file-data for our Correspondence Interchange Format (CIF). Marcel (located at the Austrian National Library) will have a look at Europeana’s interchange format to find out whether it could be combined with the task force’s CIF; Peter will get in contact with the BBAW in order to create some sort of web service, which will facilitate for data interchange.
Roadmap: June 2014 TEI-Council in Oxford – proposal should be ready for feature request – October 2014: TEI-Meeting (SIG meeting and/or <correspDesc>-workshop)

=== Conf Call Feb. 18, 2014 ===
We discussed the <correspType> element, decided to change its name to <correspClass> (according to <textClass>). Then we dealt with the preparation of the presentation in Berlin, Feb. 26, 2014 (workshop: “Briefeditionen um 1800 – Schnittstellen finden und vernetzen”). To-dos: enhancing second draft ODD, enhancing text of proposal (theoretical considerations, preceeding work). Inform the communtiy via mailing list to get some feedback.

=== Presentation Feb. 02, 2014 ===

Short presentation of the element <correspDesc> (as developed so far) at workshop on editions of correspondence around 1800 at Berlin-Brandenburg Academy of Sciences in Berlin. The slides of the presentation (in German) are available [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/2014%2002%2026%20presentation.pdf?raw=true here] and at [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub].

Next conf call will be on March 17, 2014.

=== Conf Call Jan. 30, 2014 ===

Discussing new changes in schema (<correspDesc> now repeatable, <note> and @ref in <correspDesc> possible, probably new name for <ct:correspType> needed, etc.). Latest version of the proposal can be found on [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub]. Proposal fits well for encoding e-mails. Looking at real example of encoding a letter with our schema, discussing detailed structure and flat structure (CIF).

=== Meeting Jan. 13-14, 2014 ===

Meeting of task force in Berlin. We pushed forward the work on an ODD file for the correspondence module with the new element <correspDesc> (and several child elements). The result can be found at GitHub: [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/proposal.xml proposal.xml]. While the formal specification can already be considered alpha (i.e. you can build a schema and try it out), we are still behind enhancing the documentation with information on background, theoretical considerations, notes on implementation, etc.

Next conf call will be on Jan. 30 (09:30 CET), 2014.

=== Conf Call Jan. 8, 2014 ===

This conf call mainly dealt with the preparation of the face-to-face meeting in Berlin on Jan. 13-14.
To-do-list for this meeting: reading of Mariana's e-mail and files, and of literature mentioned during conf calls (editio, Emert, etc.).

General to-do-list: enhancing second draft ODD, enhancing text of proposal, have a look at Genetic Editions proposal.

We decided to put together a bibliography of literature on editing letters that will help writing our proposal.

All minutes from TEI conferences in TEI now online [http://www.tei-c.org/Activities/SIG/Correspondence/index.xml here].

=== Conf Call Dec. 18, 2013 ===

We closely dealt with the question, what information we want to encode within the new <correspDesc> element and what elements will be needed. Child elements of/information given within <correspDesc> will be: <sender>, <addressee>, <placeSender>, <placeAddressee>, <dateSender>, <dateAddressee>, Korrespondenzstelle, type of correspondence, bearer and method of message, information whether there is an envelope or not (description of envelope in <msDsc> and transcription in <body>).

What will not be encoded within <correspDesc> because it is not letter-specific: <incipit>, printed things like form fields or letterheads, <stamp> and postage stamps - all this information is encoded within <msDesc>.

There will be a short presentation of the work of the SIG Correspondence and especially the <correspDesc> task force at the meeting on technical interfaces in German digital editions of letters around 1800 at the Berlin-Brandenburg Academy of Sciences in Berlin on February 26th.

Next conf call will be on Jan. 8, 10AM.

=== Conf Call Nov. 26, 2013 ===

Second meeting of the task force. Main topic was bringing together correspondence specific metadata (that should be encoded within a new <correspDesc> - or otherwise called - element but not necessarily):
sender, addressee, place of sender, date of sending, place of addressee, date of receiving, type of correspondence (letter, postcard, etc.), incipit, envelope, context (previous/next letter), postmark, stamp, perhaps transmitter of the message and method of delivery.

We had a closer look at the DALF Preliminary P5 Proposal and the <dalf:letDesc> element as well as the <correspDesc> element used by [http://www.weber-gesamtausgabe.de Weber-Gesamtausgabe].
We dealt more closely with the problems of how and where to encode envelopes, the type of message, postmarks, etc. Seals are not specific for letters but for other manuscripts as well. Therefore, changing their encoding (in <sealDesc>) is not necessary.

Next steps: Peter starts reworking/extending the '[[SIG:Correspondence/ODD_work|second draft]]', Marcel turns the minutes of the SIG Correspondence meetings into TEI, and starts writing goal and background information, DALF and WEGA, development of this proposal, etc. Sabine starts putting together information on the letter specific metadata and their description, place, examples, etc. as well as building up a structure for our proposal.

Next conf call will be on Dec. 18, 10AM. At the face-to-face 'boot camp' on January 13-14 in Berlin, we will work on the customization ODD file.

=== Conf Call Nov. 6, 2013 ===

First meeting of the task force. We summed up the SIG meeting at Rome and made sure that we all shared (more or less) the same ideas about the goal of the task force. Had a look at the "[[SIG:Correspondence/ODD_work|second draft]]" from last year which we decided to take as a starting point for future work.

Furthermore we decided on GitHub as a central repository for carrying out the work on our proposal and envisioned a face2face meeting at the beginning of next year as sort of a "boot camp" (scheduled for Jan. 13/14 in Berlin).

Next conf call shall be on Nov. 26, 12PM were we will look more closely at DALF and try to narrow down the "correspondence specific meta data".

== Literature and previous work ==

* [http://ctb.kantl.be/project/dalf/P5/DALF_P5-p0.1.zip DALF Preliminary P5 Proposal]
* [[SIG:Correspondence/RequestForModule|Request for a correspondence module and a wrapper element for correspondence meta data]]
* Winfried Woesler: ''Richtlinienvorschläge für Briefkommentare'', in: Wissenschaftliche Briefeditionen und ihre Probleme. Editionswissenschaftliches Symposium, Berlin 1998, p. 87–96

SIG:Correspondence/task-force-correspDesc

2014-09-02T14:35:24Z

Illetschko Marcel: /* Recent discussion */

<- back to [[SIG:Correspondence]]

= Task force "correspDesc" =

* '''Members''': Marcel Illetschko, Sabine Seifert, Peter Stadler
* "'''Pusher'''": Mariana Gomes

We will try to make our work as transparent and open as possible so others can chime in and contribute at every stage. Please feel free to make use of all the various comment/edit/share/fork functions or to contact us directly.

== Goal ==

Create a formal proposal for a <correspDesc> (or whatever name) element for approval by the TEI council as a new element of the TEI standard. This work shall be based on the "second draft for a correspondence module and a wrapper element for correspondence meta data" as it was started during the 2012 SIG meeting.

== Background ==

There have been several P4 projects with a dedicated correspondence schema (DALF probably being the renowned). While several correspondence tags (<postscript> etc.) are available from the TEI P5 standard, there is no specific way of dealing with correspondence meta data (e.g. sender, addressee) in the current TEI header. Since that's an impediment on the interoperability and interchange of these texts and since there are good practice models working with a <correspDesc>, the SIG Correspondence started to draft such a proposal during its 2012 meeting and now set up a task force for elaborating this draft.

== Repositories ==

https://github.com/TEI-Correspondence-SIG/correspDesc
This will be the main place for bringing together the proposal.

== Recent discussion ==

The SIG's proposal already caused a lot of traffic at the mailing list. See a [[summary of the recent discussion]] here - sorted by elements and furnished with the task force's view on the topics.

==== A) <ct:corresDesc> ====

'''''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!).

==== B) <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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

== Meetings ==

=== Meeting June 17-18, 2014 ===
Two days of intense work on the proposal, mainly reworking and adding of prose description with encoding examples in the chapter "Implementation of the correspondence description":
* differentiation between sender and author
* differentiation between the intended and the actual (place of) addressee
* repeating of direct child elements of <correspDesc>
* use of <transmission> in contrast to the TEI element <channel>
* use of <context> with varying evaluations of the position within a correspondence
* text classification, classification schemes (and the lack thereof) and materiality aspects.

Adding of examples to formal specification of various elements.

Preparing proposal for handing in as feature request soon. All updates available at GitHub, with additional HTML page for easy reading.

=== Conf Call June 12, 2014 ===
The main part of this conf call was held with Stefan Dumont (BBAW) who set up the web service "correspSearch" that analyzes beacon files based on the task force's <correspDesc> format from several digital correspondence editions and thus providing the possibility for searching through meta data of these editions.

Discussion of information needed from participating digital editions/projects: responsible person (preferably with e-mail address, in <titleStmt>); name of the beacon file (in <titleStmt>); latest update (in <revisionDesc>); information on licensing (with URL etc., <publicationStmt>); bibliographic reference (<sourceDesc>, <bibl>).

There is also the question of how to handle duplicates, i.e. one letter in more than one participating digital edition and thus resulting in two entries. Especially in these cases, a correspSearch ID for each entry is desirable (referencing to them with @ref).

<correspClass> is not yet part of the web service but could be implemented.

The web service "correspSearch" will be developed further and soon be publicly available online in a beta version, with corresponding API.

=== Conf Call May 28, 2014 ===

It's been our fastest conf call ever! We reported on last weeks activities (not much, but some additions to the [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub repo]) and agreed on a f2f meeting on June 17/18 in Berlin. Next conf call is scheduled for June 12, 10 AM.

=== Conf Call May 20, 2014 ===

==== Reports on two conferences: ====
# Berlin: [https://www.literatur.hu-berlin.de/aktuelles_idl/konferenzen_tagungen_vortraege/ontologien/programm "Datenmodellierung in digitalen Briefeditionen und ihre interpretatorische Leistung. Ontologien, Textgenetik und Visualisierungsstrategien"]
Peter presented on "interoperability of letter collections" and touched on the work of the task force. A lot of people are planning (dreaming) of connecting letter collections.
# Vienna: [http://www.ogl.at/programm/aktuelles-programm/ Editorenkolloquium]
"The old world" – a strong bias against digital editions and only few letter projects presented at the conference. Nevertheless Marcel waved the correspDesc flag during his talk.

==== correspSearch ====
Stefan Dumont from the BBAW created a web service for querying correspDesc data. This web service will be presented as an open beta at the end of June. During his work on correspSearch he encountered several bugs and missing features in the CIF standard that need to be addressed now. (see next point)

==== proposed schema changes ====
* rename addressee to receiver? We decided not to change that right now but we will wait for the natives to chime in.
* CIF: @when-iso instead of @when: For the web service there is a strong need for standardized date formats. --> Yes, will implement
* CIF: clearly defined meta data with information about origin, person in charge, last change date etc. --> Yes, will implement
* CIF: shall @notBefore be required to have a counterpart @notAfter? --> No, rejected

==== Roadmap ====
* Next conf call on May 28, 10 AM
* f2f meeting on June 17/18 (date needs to be finalized)
* feature request due before next Council f2f, June 30
* correspSearch will go public at the end of June

=== Conf Call March 17, 2014 ===
Peter gave a short summary of the workshop “Digitising experiences of migration” (Mellon Centre for Migration Studies, Omagh, Northern Ireland, March 14-15) – and we discussed the difficulties with lacking authority-file-data for our Correspondence Interchange Format (CIF). Marcel (located at the Austrian National Library) will have a look at Europeana’s interchange format to find out whether it could be combined with the task force’s CIF; Peter will get in contact with the BBAW in order to create some sort of web service, which will facilitate for data interchange.
Roadmap: June 2014 TEI-Council in Oxford – proposal should be ready for feature request – October 2014: TEI-Meeting (SIG meeting and/or <correspDesc>-workshop)

=== Conf Call Feb. 18, 2014 ===
We discussed the <correspType> element, decided to change its name to <correspClass> (according to <textClass>). Then we dealt with the preparation of the presentation in Berlin, Feb. 26, 2014 (workshop: “Briefeditionen um 1800 – Schnittstellen finden und vernetzen”). To-dos: enhancing second draft ODD, enhancing text of proposal (theoretical considerations, preceeding work). Inform the communtiy via mailing list to get some feedback.

=== Presentation Feb. 02, 2014 ===

Short presentation of the element <correspDesc> (as developed so far) at workshop on editions of correspondence around 1800 at Berlin-Brandenburg Academy of Sciences in Berlin. The slides of the presentation (in German) are available [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/2014%2002%2026%20presentation.pdf?raw=true here] and at [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub].

Next conf call will be on March 17, 2014.

=== Conf Call Jan. 30, 2014 ===

Discussing new changes in schema (<correspDesc> now repeatable, <note> and @ref in <correspDesc> possible, probably new name for <ct:correspType> needed, etc.). Latest version of the proposal can be found on [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub]. Proposal fits well for encoding e-mails. Looking at real example of encoding a letter with our schema, discussing detailed structure and flat structure (CIF).

=== Meeting Jan. 13-14, 2014 ===

Meeting of task force in Berlin. We pushed forward the work on an ODD file for the correspondence module with the new element <correspDesc> (and several child elements). The result can be found at GitHub: [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/proposal.xml proposal.xml]. While the formal specification can already be considered alpha (i.e. you can build a schema and try it out), we are still behind enhancing the documentation with information on background, theoretical considerations, notes on implementation, etc.

Next conf call will be on Jan. 30 (09:30 CET), 2014.

=== Conf Call Jan. 8, 2014 ===

This conf call mainly dealt with the preparation of the face-to-face meeting in Berlin on Jan. 13-14.
To-do-list for this meeting: reading of Mariana's e-mail and files, and of literature mentioned during conf calls (editio, Emert, etc.).

General to-do-list: enhancing second draft ODD, enhancing text of proposal, have a look at Genetic Editions proposal.

We decided to put together a bibliography of literature on editing letters that will help writing our proposal.

All minutes from TEI conferences in TEI now online [http://www.tei-c.org/Activities/SIG/Correspondence/index.xml here].

=== Conf Call Dec. 18, 2013 ===

We closely dealt with the question, what information we want to encode within the new <correspDesc> element and what elements will be needed. Child elements of/information given within <correspDesc> will be: <sender>, <addressee>, <placeSender>, <placeAddressee>, <dateSender>, <dateAddressee>, Korrespondenzstelle, type of correspondence, bearer and method of message, information whether there is an envelope or not (description of envelope in <msDsc> and transcription in <body>).

What will not be encoded within <correspDesc> because it is not letter-specific: <incipit>, printed things like form fields or letterheads, <stamp> and postage stamps - all this information is encoded within <msDesc>.

There will be a short presentation of the work of the SIG Correspondence and especially the <correspDesc> task force at the meeting on technical interfaces in German digital editions of letters around 1800 at the Berlin-Brandenburg Academy of Sciences in Berlin on February 26th.

Next conf call will be on Jan. 8, 10AM.

=== Conf Call Nov. 26, 2013 ===

Second meeting of the task force. Main topic was bringing together correspondence specific metadata (that should be encoded within a new <correspDesc> - or otherwise called - element but not necessarily):
sender, addressee, place of sender, date of sending, place of addressee, date of receiving, type of correspondence (letter, postcard, etc.), incipit, envelope, context (previous/next letter), postmark, stamp, perhaps transmitter of the message and method of delivery.

We had a closer look at the DALF Preliminary P5 Proposal and the <dalf:letDesc> element as well as the <correspDesc> element used by [http://www.weber-gesamtausgabe.de Weber-Gesamtausgabe].
We dealt more closely with the problems of how and where to encode envelopes, the type of message, postmarks, etc. Seals are not specific for letters but for other manuscripts as well. Therefore, changing their encoding (in <sealDesc>) is not necessary.

Next steps: Peter starts reworking/extending the '[[SIG:Correspondence/ODD_work|second draft]]', Marcel turns the minutes of the SIG Correspondence meetings into TEI, and starts writing goal and background information, DALF and WEGA, development of this proposal, etc. Sabine starts putting together information on the letter specific metadata and their description, place, examples, etc. as well as building up a structure for our proposal.

Next conf call will be on Dec. 18, 10AM. At the face-to-face 'boot camp' on January 13-14 in Berlin, we will work on the customization ODD file.

=== Conf Call Nov. 6, 2013 ===

First meeting of the task force. We summed up the SIG meeting at Rome and made sure that we all shared (more or less) the same ideas about the goal of the task force. Had a look at the "[[SIG:Correspondence/ODD_work|second draft]]" from last year which we decided to take as a starting point for future work.

Furthermore we decided on GitHub as a central repository for carrying out the work on our proposal and envisioned a face2face meeting at the beginning of next year as sort of a "boot camp" (scheduled for Jan. 13/14 in Berlin).

Next conf call shall be on Nov. 26, 12PM were we will look more closely at DALF and try to narrow down the "correspondence specific meta data".

== Literature and previous work ==

* [http://ctb.kantl.be/project/dalf/P5/DALF_P5-p0.1.zip DALF Preliminary P5 Proposal]
* [[SIG:Correspondence/RequestForModule|Request for a correspondence module and a wrapper element for correspondence meta data]]
* Winfried Woesler: ''Richtlinienvorschläge für Briefkommentare'', in: Wissenschaftliche Briefeditionen und ihre Probleme. Editionswissenschaftliches Symposium, Berlin 1998, p. 87–96

SIG:Correspondence/task-force-correspDesc

2014-09-02T14:33:05Z

Illetschko Marcel: /* Recent discussion */

<- back to [[SIG:Correspondence]]

= Task force "correspDesc" =

* '''Members''': Marcel Illetschko, Sabine Seifert, Peter Stadler
* "'''Pusher'''": Mariana Gomes

We will try to make our work as transparent and open as possible so others can chime in and contribute at every stage. Please feel free to make use of all the various comment/edit/share/fork functions or to contact us directly.

== Goal ==

Create a formal proposal for a <correspDesc> (or whatever name) element for approval by the TEI council as a new element of the TEI standard. This work shall be based on the "second draft for a correspondence module and a wrapper element for correspondence meta data" as it was started during the 2012 SIG meeting.

== Background ==

There have been several P4 projects with a dedicated correspondence schema (DALF probably being the renowned). While several correspondence tags (<postscript> etc.) are available from the TEI P5 standard, there is no specific way of dealing with correspondence meta data (e.g. sender, addressee) in the current TEI header. Since that's an impediment on the interoperability and interchange of these texts and since there are good practice models working with a <correspDesc>, the SIG Correspondence started to draft such a proposal during its 2012 meeting and now set up a task force for elaborating this draft.

== Repositories ==

https://github.com/TEI-Correspondence-SIG/correspDesc
This will be the main place for bringing together the proposal.

== Recent discussion ==

The SIG's proposal already caused a lot of traffic at the mailing list. See a collection of all the contributions and ideas [[here]] - sorted by elements and furnished with the task force's view on the topics.

==== A) <ct:corresDesc> ====

'''''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!).

==== B) <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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

== Meetings ==

=== Meeting June 17-18, 2014 ===
Two days of intense work on the proposal, mainly reworking and adding of prose description with encoding examples in the chapter "Implementation of the correspondence description":
* differentiation between sender and author
* differentiation between the intended and the actual (place of) addressee
* repeating of direct child elements of <correspDesc>
* use of <transmission> in contrast to the TEI element <channel>
* use of <context> with varying evaluations of the position within a correspondence
* text classification, classification schemes (and the lack thereof) and materiality aspects.

Adding of examples to formal specification of various elements.

Preparing proposal for handing in as feature request soon. All updates available at GitHub, with additional HTML page for easy reading.

=== Conf Call June 12, 2014 ===
The main part of this conf call was held with Stefan Dumont (BBAW) who set up the web service "correspSearch" that analyzes beacon files based on the task force's <correspDesc> format from several digital correspondence editions and thus providing the possibility for searching through meta data of these editions.

Discussion of information needed from participating digital editions/projects: responsible person (preferably with e-mail address, in <titleStmt>); name of the beacon file (in <titleStmt>); latest update (in <revisionDesc>); information on licensing (with URL etc., <publicationStmt>); bibliographic reference (<sourceDesc>, <bibl>).

There is also the question of how to handle duplicates, i.e. one letter in more than one participating digital edition and thus resulting in two entries. Especially in these cases, a correspSearch ID for each entry is desirable (referencing to them with @ref).

<correspClass> is not yet part of the web service but could be implemented.

The web service "correspSearch" will be developed further and soon be publicly available online in a beta version, with corresponding API.

=== Conf Call May 28, 2014 ===

It's been our fastest conf call ever! We reported on last weeks activities (not much, but some additions to the [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub repo]) and agreed on a f2f meeting on June 17/18 in Berlin. Next conf call is scheduled for June 12, 10 AM.

=== Conf Call May 20, 2014 ===

==== Reports on two conferences: ====
# Berlin: [https://www.literatur.hu-berlin.de/aktuelles_idl/konferenzen_tagungen_vortraege/ontologien/programm "Datenmodellierung in digitalen Briefeditionen und ihre interpretatorische Leistung. Ontologien, Textgenetik und Visualisierungsstrategien"]
Peter presented on "interoperability of letter collections" and touched on the work of the task force. A lot of people are planning (dreaming) of connecting letter collections.
# Vienna: [http://www.ogl.at/programm/aktuelles-programm/ Editorenkolloquium]
"The old world" – a strong bias against digital editions and only few letter projects presented at the conference. Nevertheless Marcel waved the correspDesc flag during his talk.

==== correspSearch ====
Stefan Dumont from the BBAW created a web service for querying correspDesc data. This web service will be presented as an open beta at the end of June. During his work on correspSearch he encountered several bugs and missing features in the CIF standard that need to be addressed now. (see next point)

==== proposed schema changes ====
* rename addressee to receiver? We decided not to change that right now but we will wait for the natives to chime in.
* CIF: @when-iso instead of @when: For the web service there is a strong need for standardized date formats. --> Yes, will implement
* CIF: clearly defined meta data with information about origin, person in charge, last change date etc. --> Yes, will implement
* CIF: shall @notBefore be required to have a counterpart @notAfter? --> No, rejected

==== Roadmap ====
* Next conf call on May 28, 10 AM
* f2f meeting on June 17/18 (date needs to be finalized)
* feature request due before next Council f2f, June 30
* correspSearch will go public at the end of June

=== Conf Call March 17, 2014 ===
Peter gave a short summary of the workshop “Digitising experiences of migration” (Mellon Centre for Migration Studies, Omagh, Northern Ireland, March 14-15) – and we discussed the difficulties with lacking authority-file-data for our Correspondence Interchange Format (CIF). Marcel (located at the Austrian National Library) will have a look at Europeana’s interchange format to find out whether it could be combined with the task force’s CIF; Peter will get in contact with the BBAW in order to create some sort of web service, which will facilitate for data interchange.
Roadmap: June 2014 TEI-Council in Oxford – proposal should be ready for feature request – October 2014: TEI-Meeting (SIG meeting and/or <correspDesc>-workshop)

=== Conf Call Feb. 18, 2014 ===
We discussed the <correspType> element, decided to change its name to <correspClass> (according to <textClass>). Then we dealt with the preparation of the presentation in Berlin, Feb. 26, 2014 (workshop: “Briefeditionen um 1800 – Schnittstellen finden und vernetzen”). To-dos: enhancing second draft ODD, enhancing text of proposal (theoretical considerations, preceeding work). Inform the communtiy via mailing list to get some feedback.

=== Presentation Feb. 02, 2014 ===

Short presentation of the element <correspDesc> (as developed so far) at workshop on editions of correspondence around 1800 at Berlin-Brandenburg Academy of Sciences in Berlin. The slides of the presentation (in German) are available [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/2014%2002%2026%20presentation.pdf?raw=true here] and at [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub].

Next conf call will be on March 17, 2014.

=== Conf Call Jan. 30, 2014 ===

Discussing new changes in schema (<correspDesc> now repeatable, <note> and @ref in <correspDesc> possible, probably new name for <ct:correspType> needed, etc.). Latest version of the proposal can be found on [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub]. Proposal fits well for encoding e-mails. Looking at real example of encoding a letter with our schema, discussing detailed structure and flat structure (CIF).

=== Meeting Jan. 13-14, 2014 ===

Meeting of task force in Berlin. We pushed forward the work on an ODD file for the correspondence module with the new element <correspDesc> (and several child elements). The result can be found at GitHub: [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/proposal.xml proposal.xml]. While the formal specification can already be considered alpha (i.e. you can build a schema and try it out), we are still behind enhancing the documentation with information on background, theoretical considerations, notes on implementation, etc.

Next conf call will be on Jan. 30 (09:30 CET), 2014.

=== Conf Call Jan. 8, 2014 ===

This conf call mainly dealt with the preparation of the face-to-face meeting in Berlin on Jan. 13-14.
To-do-list for this meeting: reading of Mariana's e-mail and files, and of literature mentioned during conf calls (editio, Emert, etc.).

General to-do-list: enhancing second draft ODD, enhancing text of proposal, have a look at Genetic Editions proposal.

We decided to put together a bibliography of literature on editing letters that will help writing our proposal.

All minutes from TEI conferences in TEI now online [http://www.tei-c.org/Activities/SIG/Correspondence/index.xml here].

=== Conf Call Dec. 18, 2013 ===

We closely dealt with the question, what information we want to encode within the new <correspDesc> element and what elements will be needed. Child elements of/information given within <correspDesc> will be: <sender>, <addressee>, <placeSender>, <placeAddressee>, <dateSender>, <dateAddressee>, Korrespondenzstelle, type of correspondence, bearer and method of message, information whether there is an envelope or not (description of envelope in <msDsc> and transcription in <body>).

What will not be encoded within <correspDesc> because it is not letter-specific: <incipit>, printed things like form fields or letterheads, <stamp> and postage stamps - all this information is encoded within <msDesc>.

There will be a short presentation of the work of the SIG Correspondence and especially the <correspDesc> task force at the meeting on technical interfaces in German digital editions of letters around 1800 at the Berlin-Brandenburg Academy of Sciences in Berlin on February 26th.

Next conf call will be on Jan. 8, 10AM.

=== Conf Call Nov. 26, 2013 ===

Second meeting of the task force. Main topic was bringing together correspondence specific metadata (that should be encoded within a new <correspDesc> - or otherwise called - element but not necessarily):
sender, addressee, place of sender, date of sending, place of addressee, date of receiving, type of correspondence (letter, postcard, etc.), incipit, envelope, context (previous/next letter), postmark, stamp, perhaps transmitter of the message and method of delivery.

We had a closer look at the DALF Preliminary P5 Proposal and the <dalf:letDesc> element as well as the <correspDesc> element used by [http://www.weber-gesamtausgabe.de Weber-Gesamtausgabe].
We dealt more closely with the problems of how and where to encode envelopes, the type of message, postmarks, etc. Seals are not specific for letters but for other manuscripts as well. Therefore, changing their encoding (in <sealDesc>) is not necessary.

Next steps: Peter starts reworking/extending the '[[SIG:Correspondence/ODD_work|second draft]]', Marcel turns the minutes of the SIG Correspondence meetings into TEI, and starts writing goal and background information, DALF and WEGA, development of this proposal, etc. Sabine starts putting together information on the letter specific metadata and their description, place, examples, etc. as well as building up a structure for our proposal.

Next conf call will be on Dec. 18, 10AM. At the face-to-face 'boot camp' on January 13-14 in Berlin, we will work on the customization ODD file.

=== Conf Call Nov. 6, 2013 ===

First meeting of the task force. We summed up the SIG meeting at Rome and made sure that we all shared (more or less) the same ideas about the goal of the task force. Had a look at the "[[SIG:Correspondence/ODD_work|second draft]]" from last year which we decided to take as a starting point for future work.

Furthermore we decided on GitHub as a central repository for carrying out the work on our proposal and envisioned a face2face meeting at the beginning of next year as sort of a "boot camp" (scheduled for Jan. 13/14 in Berlin).

Next conf call shall be on Nov. 26, 12PM were we will look more closely at DALF and try to narrow down the "correspondence specific meta data".

== Literature and previous work ==

* [http://ctb.kantl.be/project/dalf/P5/DALF_P5-p0.1.zip DALF Preliminary P5 Proposal]
* [[SIG:Correspondence/RequestForModule|Request for a correspondence module and a wrapper element for correspondence meta data]]
* Winfried Woesler: ''Richtlinienvorschläge für Briefkommentare'', in: Wissenschaftliche Briefeditionen und ihre Probleme. Editionswissenschaftliches Symposium, Berlin 1998, p. 87–96

SIG:Correspondence/task-force-correspDesc

2014-09-02T14:32:16Z

Illetschko Marcel: /* Recent discussion */

<- back to [[SIG:Correspondence]]

= Task force "correspDesc" =

* '''Members''': Marcel Illetschko, Sabine Seifert, Peter Stadler
* "'''Pusher'''": Mariana Gomes

We will try to make our work as transparent and open as possible so others can chime in and contribute at every stage. Please feel free to make use of all the various comment/edit/share/fork functions or to contact us directly.

== Goal ==

Create a formal proposal for a <correspDesc> (or whatever name) element for approval by the TEI council as a new element of the TEI standard. This work shall be based on the "second draft for a correspondence module and a wrapper element for correspondence meta data" as it was started during the 2012 SIG meeting.

== Background ==

There have been several P4 projects with a dedicated correspondence schema (DALF probably being the renowned). While several correspondence tags (<postscript> etc.) are available from the TEI P5 standard, there is no specific way of dealing with correspondence meta data (e.g. sender, addressee) in the current TEI header. Since that's an impediment on the interoperability and interchange of these texts and since there are good practice models working with a <correspDesc>, the SIG Correspondence started to draft such a proposal during its 2012 meeting and now set up a task force for elaborating this draft.

== Repositories ==

https://github.com/TEI-Correspondence-SIG/correspDesc
This will be the main place for bringing together the proposal.

== Recent discussion ==

The SIG's proposal already caused a lot of traffic at the mailing list. See a collection of all the contributions and ideas [[http://wiki.tei-c.org/index.php/SIG:Correspondence/task-force-correspDesc#RecentDiscussion]] - sorted by elements and furnished with the task force's view on the topics.

==== A) <ct:corresDesc> ====

'''''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!).

==== B) <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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

== Meetings ==

=== Meeting June 17-18, 2014 ===
Two days of intense work on the proposal, mainly reworking and adding of prose description with encoding examples in the chapter "Implementation of the correspondence description":
* differentiation between sender and author
* differentiation between the intended and the actual (place of) addressee
* repeating of direct child elements of <correspDesc>
* use of <transmission> in contrast to the TEI element <channel>
* use of <context> with varying evaluations of the position within a correspondence
* text classification, classification schemes (and the lack thereof) and materiality aspects.

Adding of examples to formal specification of various elements.

Preparing proposal for handing in as feature request soon. All updates available at GitHub, with additional HTML page for easy reading.

=== Conf Call June 12, 2014 ===
The main part of this conf call was held with Stefan Dumont (BBAW) who set up the web service "correspSearch" that analyzes beacon files based on the task force's <correspDesc> format from several digital correspondence editions and thus providing the possibility for searching through meta data of these editions.

Discussion of information needed from participating digital editions/projects: responsible person (preferably with e-mail address, in <titleStmt>); name of the beacon file (in <titleStmt>); latest update (in <revisionDesc>); information on licensing (with URL etc., <publicationStmt>); bibliographic reference (<sourceDesc>, <bibl>).

There is also the question of how to handle duplicates, i.e. one letter in more than one participating digital edition and thus resulting in two entries. Especially in these cases, a correspSearch ID for each entry is desirable (referencing to them with @ref).

<correspClass> is not yet part of the web service but could be implemented.

The web service "correspSearch" will be developed further and soon be publicly available online in a beta version, with corresponding API.

=== Conf Call May 28, 2014 ===

It's been our fastest conf call ever! We reported on last weeks activities (not much, but some additions to the [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub repo]) and agreed on a f2f meeting on June 17/18 in Berlin. Next conf call is scheduled for June 12, 10 AM.

=== Conf Call May 20, 2014 ===

==== Reports on two conferences: ====
# Berlin: [https://www.literatur.hu-berlin.de/aktuelles_idl/konferenzen_tagungen_vortraege/ontologien/programm "Datenmodellierung in digitalen Briefeditionen und ihre interpretatorische Leistung. Ontologien, Textgenetik und Visualisierungsstrategien"]
Peter presented on "interoperability of letter collections" and touched on the work of the task force. A lot of people are planning (dreaming) of connecting letter collections.
# Vienna: [http://www.ogl.at/programm/aktuelles-programm/ Editorenkolloquium]
"The old world" – a strong bias against digital editions and only few letter projects presented at the conference. Nevertheless Marcel waved the correspDesc flag during his talk.

==== correspSearch ====
Stefan Dumont from the BBAW created a web service for querying correspDesc data. This web service will be presented as an open beta at the end of June. During his work on correspSearch he encountered several bugs and missing features in the CIF standard that need to be addressed now. (see next point)

==== proposed schema changes ====
* rename addressee to receiver? We decided not to change that right now but we will wait for the natives to chime in.
* CIF: @when-iso instead of @when: For the web service there is a strong need for standardized date formats. --> Yes, will implement
* CIF: clearly defined meta data with information about origin, person in charge, last change date etc. --> Yes, will implement
* CIF: shall @notBefore be required to have a counterpart @notAfter? --> No, rejected

==== Roadmap ====
* Next conf call on May 28, 10 AM
* f2f meeting on June 17/18 (date needs to be finalized)
* feature request due before next Council f2f, June 30
* correspSearch will go public at the end of June

=== Conf Call March 17, 2014 ===
Peter gave a short summary of the workshop “Digitising experiences of migration” (Mellon Centre for Migration Studies, Omagh, Northern Ireland, March 14-15) – and we discussed the difficulties with lacking authority-file-data for our Correspondence Interchange Format (CIF). Marcel (located at the Austrian National Library) will have a look at Europeana’s interchange format to find out whether it could be combined with the task force’s CIF; Peter will get in contact with the BBAW in order to create some sort of web service, which will facilitate for data interchange.
Roadmap: June 2014 TEI-Council in Oxford – proposal should be ready for feature request – October 2014: TEI-Meeting (SIG meeting and/or <correspDesc>-workshop)

=== Conf Call Feb. 18, 2014 ===
We discussed the <correspType> element, decided to change its name to <correspClass> (according to <textClass>). Then we dealt with the preparation of the presentation in Berlin, Feb. 26, 2014 (workshop: “Briefeditionen um 1800 – Schnittstellen finden und vernetzen”). To-dos: enhancing second draft ODD, enhancing text of proposal (theoretical considerations, preceeding work). Inform the communtiy via mailing list to get some feedback.

=== Presentation Feb. 02, 2014 ===

Short presentation of the element <correspDesc> (as developed so far) at workshop on editions of correspondence around 1800 at Berlin-Brandenburg Academy of Sciences in Berlin. The slides of the presentation (in German) are available [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/2014%2002%2026%20presentation.pdf?raw=true here] and at [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub].

Next conf call will be on March 17, 2014.

=== Conf Call Jan. 30, 2014 ===

Discussing new changes in schema (<correspDesc> now repeatable, <note> and @ref in <correspDesc> possible, probably new name for <ct:correspType> needed, etc.). Latest version of the proposal can be found on [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub]. Proposal fits well for encoding e-mails. Looking at real example of encoding a letter with our schema, discussing detailed structure and flat structure (CIF).

=== Meeting Jan. 13-14, 2014 ===

Meeting of task force in Berlin. We pushed forward the work on an ODD file for the correspondence module with the new element <correspDesc> (and several child elements). The result can be found at GitHub: [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/proposal.xml proposal.xml]. While the formal specification can already be considered alpha (i.e. you can build a schema and try it out), we are still behind enhancing the documentation with information on background, theoretical considerations, notes on implementation, etc.

Next conf call will be on Jan. 30 (09:30 CET), 2014.

=== Conf Call Jan. 8, 2014 ===

This conf call mainly dealt with the preparation of the face-to-face meeting in Berlin on Jan. 13-14.
To-do-list for this meeting: reading of Mariana's e-mail and files, and of literature mentioned during conf calls (editio, Emert, etc.).

General to-do-list: enhancing second draft ODD, enhancing text of proposal, have a look at Genetic Editions proposal.

We decided to put together a bibliography of literature on editing letters that will help writing our proposal.

All minutes from TEI conferences in TEI now online [http://www.tei-c.org/Activities/SIG/Correspondence/index.xml here].

=== Conf Call Dec. 18, 2013 ===

We closely dealt with the question, what information we want to encode within the new <correspDesc> element and what elements will be needed. Child elements of/information given within <correspDesc> will be: <sender>, <addressee>, <placeSender>, <placeAddressee>, <dateSender>, <dateAddressee>, Korrespondenzstelle, type of correspondence, bearer and method of message, information whether there is an envelope or not (description of envelope in <msDsc> and transcription in <body>).

What will not be encoded within <correspDesc> because it is not letter-specific: <incipit>, printed things like form fields or letterheads, <stamp> and postage stamps - all this information is encoded within <msDesc>.

There will be a short presentation of the work of the SIG Correspondence and especially the <correspDesc> task force at the meeting on technical interfaces in German digital editions of letters around 1800 at the Berlin-Brandenburg Academy of Sciences in Berlin on February 26th.

Next conf call will be on Jan. 8, 10AM.

=== Conf Call Nov. 26, 2013 ===

Second meeting of the task force. Main topic was bringing together correspondence specific metadata (that should be encoded within a new <correspDesc> - or otherwise called - element but not necessarily):
sender, addressee, place of sender, date of sending, place of addressee, date of receiving, type of correspondence (letter, postcard, etc.), incipit, envelope, context (previous/next letter), postmark, stamp, perhaps transmitter of the message and method of delivery.

We had a closer look at the DALF Preliminary P5 Proposal and the <dalf:letDesc> element as well as the <correspDesc> element used by [http://www.weber-gesamtausgabe.de Weber-Gesamtausgabe].
We dealt more closely with the problems of how and where to encode envelopes, the type of message, postmarks, etc. Seals are not specific for letters but for other manuscripts as well. Therefore, changing their encoding (in <sealDesc>) is not necessary.

Next steps: Peter starts reworking/extending the '[[SIG:Correspondence/ODD_work|second draft]]', Marcel turns the minutes of the SIG Correspondence meetings into TEI, and starts writing goal and background information, DALF and WEGA, development of this proposal, etc. Sabine starts putting together information on the letter specific metadata and their description, place, examples, etc. as well as building up a structure for our proposal.

Next conf call will be on Dec. 18, 10AM. At the face-to-face 'boot camp' on January 13-14 in Berlin, we will work on the customization ODD file.

=== Conf Call Nov. 6, 2013 ===

First meeting of the task force. We summed up the SIG meeting at Rome and made sure that we all shared (more or less) the same ideas about the goal of the task force. Had a look at the "[[SIG:Correspondence/ODD_work|second draft]]" from last year which we decided to take as a starting point for future work.

Furthermore we decided on GitHub as a central repository for carrying out the work on our proposal and envisioned a face2face meeting at the beginning of next year as sort of a "boot camp" (scheduled for Jan. 13/14 in Berlin).

Next conf call shall be on Nov. 26, 12PM were we will look more closely at DALF and try to narrow down the "correspondence specific meta data".

== Literature and previous work ==

* [http://ctb.kantl.be/project/dalf/P5/DALF_P5-p0.1.zip DALF Preliminary P5 Proposal]
* [[SIG:Correspondence/RequestForModule|Request for a correspondence module and a wrapper element for correspondence meta data]]
* Winfried Woesler: ''Richtlinienvorschläge für Briefkommentare'', in: Wissenschaftliche Briefeditionen und ihre Probleme. Editionswissenschaftliches Symposium, Berlin 1998, p. 87–96

SIG:Correspondence/task-force-correspDesc

2014-09-02T14:28:41Z

Illetschko Marcel: /* Repositories */

<- back to [[SIG:Correspondence]]

= Task force "correspDesc" =

* '''Members''': Marcel Illetschko, Sabine Seifert, Peter Stadler
* "'''Pusher'''": Mariana Gomes

We will try to make our work as transparent and open as possible so others can chime in and contribute at every stage. Please feel free to make use of all the various comment/edit/share/fork functions or to contact us directly.

== Goal ==

Create a formal proposal for a <correspDesc> (or whatever name) element for approval by the TEI council as a new element of the TEI standard. This work shall be based on the "second draft for a correspondence module and a wrapper element for correspondence meta data" as it was started during the 2012 SIG meeting.

== Background ==

There have been several P4 projects with a dedicated correspondence schema (DALF probably being the renowned). While several correspondence tags (<postscript> etc.) are available from the TEI P5 standard, there is no specific way of dealing with correspondence meta data (e.g. sender, addressee) in the current TEI header. Since that's an impediment on the interoperability and interchange of these texts and since there are good practice models working with a <correspDesc>, the SIG Correspondence started to draft such a proposal during its 2012 meeting and now set up a task force for elaborating this draft.

== Repositories ==

https://github.com/TEI-Correspondence-SIG/correspDesc
This will be the main place for bringing together the proposal.

== Recent discussion ==

The SIG's proposal already caused a lot of traffic at the mailing list. See a collection of all the contributions and ideas [[here]] - sorted by elements and furnished with the task force's view on the topics.

==== A) <ct:corresDesc> ====

'''''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!).

==== B) <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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

== Meetings ==

=== Meeting June 17-18, 2014 ===
Two days of intense work on the proposal, mainly reworking and adding of prose description with encoding examples in the chapter "Implementation of the correspondence description":
* differentiation between sender and author
* differentiation between the intended and the actual (place of) addressee
* repeating of direct child elements of <correspDesc>
* use of <transmission> in contrast to the TEI element <channel>
* use of <context> with varying evaluations of the position within a correspondence
* text classification, classification schemes (and the lack thereof) and materiality aspects.

Adding of examples to formal specification of various elements.

Preparing proposal for handing in as feature request soon. All updates available at GitHub, with additional HTML page for easy reading.

=== Conf Call June 12, 2014 ===
The main part of this conf call was held with Stefan Dumont (BBAW) who set up the web service "correspSearch" that analyzes beacon files based on the task force's <correspDesc> format from several digital correspondence editions and thus providing the possibility for searching through meta data of these editions.

Discussion of information needed from participating digital editions/projects: responsible person (preferably with e-mail address, in <titleStmt>); name of the beacon file (in <titleStmt>); latest update (in <revisionDesc>); information on licensing (with URL etc., <publicationStmt>); bibliographic reference (<sourceDesc>, <bibl>).

There is also the question of how to handle duplicates, i.e. one letter in more than one participating digital edition and thus resulting in two entries. Especially in these cases, a correspSearch ID for each entry is desirable (referencing to them with @ref).

<correspClass> is not yet part of the web service but could be implemented.

The web service "correspSearch" will be developed further and soon be publicly available online in a beta version, with corresponding API.

=== Conf Call May 28, 2014 ===

It's been our fastest conf call ever! We reported on last weeks activities (not much, but some additions to the [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub repo]) and agreed on a f2f meeting on June 17/18 in Berlin. Next conf call is scheduled for June 12, 10 AM.

=== Conf Call May 20, 2014 ===

==== Reports on two conferences: ====
# Berlin: [https://www.literatur.hu-berlin.de/aktuelles_idl/konferenzen_tagungen_vortraege/ontologien/programm "Datenmodellierung in digitalen Briefeditionen und ihre interpretatorische Leistung. Ontologien, Textgenetik und Visualisierungsstrategien"]
Peter presented on "interoperability of letter collections" and touched on the work of the task force. A lot of people are planning (dreaming) of connecting letter collections.
# Vienna: [http://www.ogl.at/programm/aktuelles-programm/ Editorenkolloquium]
"The old world" – a strong bias against digital editions and only few letter projects presented at the conference. Nevertheless Marcel waved the correspDesc flag during his talk.

==== correspSearch ====
Stefan Dumont from the BBAW created a web service for querying correspDesc data. This web service will be presented as an open beta at the end of June. During his work on correspSearch he encountered several bugs and missing features in the CIF standard that need to be addressed now. (see next point)

==== proposed schema changes ====
* rename addressee to receiver? We decided not to change that right now but we will wait for the natives to chime in.
* CIF: @when-iso instead of @when: For the web service there is a strong need for standardized date formats. --> Yes, will implement
* CIF: clearly defined meta data with information about origin, person in charge, last change date etc. --> Yes, will implement
* CIF: shall @notBefore be required to have a counterpart @notAfter? --> No, rejected

==== Roadmap ====
* Next conf call on May 28, 10 AM
* f2f meeting on June 17/18 (date needs to be finalized)
* feature request due before next Council f2f, June 30
* correspSearch will go public at the end of June

=== Conf Call March 17, 2014 ===
Peter gave a short summary of the workshop “Digitising experiences of migration” (Mellon Centre for Migration Studies, Omagh, Northern Ireland, March 14-15) – and we discussed the difficulties with lacking authority-file-data for our Correspondence Interchange Format (CIF). Marcel (located at the Austrian National Library) will have a look at Europeana’s interchange format to find out whether it could be combined with the task force’s CIF; Peter will get in contact with the BBAW in order to create some sort of web service, which will facilitate for data interchange.
Roadmap: June 2014 TEI-Council in Oxford – proposal should be ready for feature request – October 2014: TEI-Meeting (SIG meeting and/or <correspDesc>-workshop)

=== Conf Call Feb. 18, 2014 ===
We discussed the <correspType> element, decided to change its name to <correspClass> (according to <textClass>). Then we dealt with the preparation of the presentation in Berlin, Feb. 26, 2014 (workshop: “Briefeditionen um 1800 – Schnittstellen finden und vernetzen”). To-dos: enhancing second draft ODD, enhancing text of proposal (theoretical considerations, preceeding work). Inform the communtiy via mailing list to get some feedback.

=== Presentation Feb. 02, 2014 ===

Short presentation of the element <correspDesc> (as developed so far) at workshop on editions of correspondence around 1800 at Berlin-Brandenburg Academy of Sciences in Berlin. The slides of the presentation (in German) are available [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/2014%2002%2026%20presentation.pdf?raw=true here] and at [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub].

Next conf call will be on March 17, 2014.

=== Conf Call Jan. 30, 2014 ===

Discussing new changes in schema (<correspDesc> now repeatable, <note> and @ref in <correspDesc> possible, probably new name for <ct:correspType> needed, etc.). Latest version of the proposal can be found on [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub]. Proposal fits well for encoding e-mails. Looking at real example of encoding a letter with our schema, discussing detailed structure and flat structure (CIF).

=== Meeting Jan. 13-14, 2014 ===

Meeting of task force in Berlin. We pushed forward the work on an ODD file for the correspondence module with the new element <correspDesc> (and several child elements). The result can be found at GitHub: [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/proposal.xml proposal.xml]. While the formal specification can already be considered alpha (i.e. you can build a schema and try it out), we are still behind enhancing the documentation with information on background, theoretical considerations, notes on implementation, etc.

Next conf call will be on Jan. 30 (09:30 CET), 2014.

=== Conf Call Jan. 8, 2014 ===

This conf call mainly dealt with the preparation of the face-to-face meeting in Berlin on Jan. 13-14.
To-do-list for this meeting: reading of Mariana's e-mail and files, and of literature mentioned during conf calls (editio, Emert, etc.).

General to-do-list: enhancing second draft ODD, enhancing text of proposal, have a look at Genetic Editions proposal.

We decided to put together a bibliography of literature on editing letters that will help writing our proposal.

All minutes from TEI conferences in TEI now online [http://www.tei-c.org/Activities/SIG/Correspondence/index.xml here].

=== Conf Call Dec. 18, 2013 ===

We closely dealt with the question, what information we want to encode within the new <correspDesc> element and what elements will be needed. Child elements of/information given within <correspDesc> will be: <sender>, <addressee>, <placeSender>, <placeAddressee>, <dateSender>, <dateAddressee>, Korrespondenzstelle, type of correspondence, bearer and method of message, information whether there is an envelope or not (description of envelope in <msDsc> and transcription in <body>).

What will not be encoded within <correspDesc> because it is not letter-specific: <incipit>, printed things like form fields or letterheads, <stamp> and postage stamps - all this information is encoded within <msDesc>.

There will be a short presentation of the work of the SIG Correspondence and especially the <correspDesc> task force at the meeting on technical interfaces in German digital editions of letters around 1800 at the Berlin-Brandenburg Academy of Sciences in Berlin on February 26th.

Next conf call will be on Jan. 8, 10AM.

=== Conf Call Nov. 26, 2013 ===

Second meeting of the task force. Main topic was bringing together correspondence specific metadata (that should be encoded within a new <correspDesc> - or otherwise called - element but not necessarily):
sender, addressee, place of sender, date of sending, place of addressee, date of receiving, type of correspondence (letter, postcard, etc.), incipit, envelope, context (previous/next letter), postmark, stamp, perhaps transmitter of the message and method of delivery.

We had a closer look at the DALF Preliminary P5 Proposal and the <dalf:letDesc> element as well as the <correspDesc> element used by [http://www.weber-gesamtausgabe.de Weber-Gesamtausgabe].
We dealt more closely with the problems of how and where to encode envelopes, the type of message, postmarks, etc. Seals are not specific for letters but for other manuscripts as well. Therefore, changing their encoding (in <sealDesc>) is not necessary.

Next steps: Peter starts reworking/extending the '[[SIG:Correspondence/ODD_work|second draft]]', Marcel turns the minutes of the SIG Correspondence meetings into TEI, and starts writing goal and background information, DALF and WEGA, development of this proposal, etc. Sabine starts putting together information on the letter specific metadata and their description, place, examples, etc. as well as building up a structure for our proposal.

Next conf call will be on Dec. 18, 10AM. At the face-to-face 'boot camp' on January 13-14 in Berlin, we will work on the customization ODD file.

=== Conf Call Nov. 6, 2013 ===

First meeting of the task force. We summed up the SIG meeting at Rome and made sure that we all shared (more or less) the same ideas about the goal of the task force. Had a look at the "[[SIG:Correspondence/ODD_work|second draft]]" from last year which we decided to take as a starting point for future work.

Furthermore we decided on GitHub as a central repository for carrying out the work on our proposal and envisioned a face2face meeting at the beginning of next year as sort of a "boot camp" (scheduled for Jan. 13/14 in Berlin).

Next conf call shall be on Nov. 26, 12PM were we will look more closely at DALF and try to narrow down the "correspondence specific meta data".

== Literature and previous work ==

* [http://ctb.kantl.be/project/dalf/P5/DALF_P5-p0.1.zip DALF Preliminary P5 Proposal]
* [[SIG:Correspondence/RequestForModule|Request for a correspondence module and a wrapper element for correspondence meta data]]
* Winfried Woesler: ''Richtlinienvorschläge für Briefkommentare'', in: Wissenschaftliche Briefeditionen und ihre Probleme. Editionswissenschaftliches Symposium, Berlin 1998, p. 87–96

SIG:Correspondence/task-force-correspDesc

2014-09-02T14:28:28Z

Illetschko Marcel: /* Task force "correspDesc" */

<- back to [[SIG:Correspondence]]

= Task force "correspDesc" =

* '''Members''': Marcel Illetschko, Sabine Seifert, Peter Stadler
* "'''Pusher'''": Mariana Gomes

We will try to make our work as transparent and open as possible so others can chime in and contribute at every stage. Please feel free to make use of all the various comment/edit/share/fork functions or to contact us directly.

== Goal ==

Create a formal proposal for a <correspDesc> (or whatever name) element for approval by the TEI council as a new element of the TEI standard. This work shall be based on the "second draft for a correspondence module and a wrapper element for correspondence meta data" as it was started during the 2012 SIG meeting.

== Background ==

There have been several P4 projects with a dedicated correspondence schema (DALF probably being the renowned). While several correspondence tags (<postscript> etc.) are available from the TEI P5 standard, there is no specific way of dealing with correspondence meta data (e.g. sender, addressee) in the current TEI header. Since that's an impediment on the interoperability and interchange of these texts and since there are good practice models working with a <correspDesc>, the SIG Correspondence started to draft such a proposal during its 2012 meeting and now set up a task force for elaborating this draft.

== Repositories ==

https://github.com/TEI-Correspondence-SIG/correspDesc
This will be the main place for bringing together the proposal.

== Recent discussion ==

The SIG's proposal already caused a lot of traffic at the mailing list. See a collection of all the contributions and ideas [[here]] - sorted by elements and furnished with the task force's view on the topics.

==== A) <ct:corresDesc> ====

'''''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!).

==== B) <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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

== Meetings ==

=== Meeting June 17-18, 2014 ===
Two days of intense work on the proposal, mainly reworking and adding of prose description with encoding examples in the chapter "Implementation of the correspondence description":
* differentiation between sender and author
* differentiation between the intended and the actual (place of) addressee
* repeating of direct child elements of <correspDesc>
* use of <transmission> in contrast to the TEI element <channel>
* use of <context> with varying evaluations of the position within a correspondence
* text classification, classification schemes (and the lack thereof) and materiality aspects.

Adding of examples to formal specification of various elements.

Preparing proposal for handing in as feature request soon. All updates available at GitHub, with additional HTML page for easy reading.

=== Conf Call June 12, 2014 ===
The main part of this conf call was held with Stefan Dumont (BBAW) who set up the web service "correspSearch" that analyzes beacon files based on the task force's <correspDesc> format from several digital correspondence editions and thus providing the possibility for searching through meta data of these editions.

Discussion of information needed from participating digital editions/projects: responsible person (preferably with e-mail address, in <titleStmt>); name of the beacon file (in <titleStmt>); latest update (in <revisionDesc>); information on licensing (with URL etc., <publicationStmt>); bibliographic reference (<sourceDesc>, <bibl>).

There is also the question of how to handle duplicates, i.e. one letter in more than one participating digital edition and thus resulting in two entries. Especially in these cases, a correspSearch ID for each entry is desirable (referencing to them with @ref).

<correspClass> is not yet part of the web service but could be implemented.

The web service "correspSearch" will be developed further and soon be publicly available online in a beta version, with corresponding API.

=== Conf Call May 28, 2014 ===

It's been our fastest conf call ever! We reported on last weeks activities (not much, but some additions to the [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub repo]) and agreed on a f2f meeting on June 17/18 in Berlin. Next conf call is scheduled for June 12, 10 AM.

=== Conf Call May 20, 2014 ===

==== Reports on two conferences: ====
# Berlin: [https://www.literatur.hu-berlin.de/aktuelles_idl/konferenzen_tagungen_vortraege/ontologien/programm "Datenmodellierung in digitalen Briefeditionen und ihre interpretatorische Leistung. Ontologien, Textgenetik und Visualisierungsstrategien"]
Peter presented on "interoperability of letter collections" and touched on the work of the task force. A lot of people are planning (dreaming) of connecting letter collections.
# Vienna: [http://www.ogl.at/programm/aktuelles-programm/ Editorenkolloquium]
"The old world" – a strong bias against digital editions and only few letter projects presented at the conference. Nevertheless Marcel waved the correspDesc flag during his talk.

==== correspSearch ====
Stefan Dumont from the BBAW created a web service for querying correspDesc data. This web service will be presented as an open beta at the end of June. During his work on correspSearch he encountered several bugs and missing features in the CIF standard that need to be addressed now. (see next point)

==== proposed schema changes ====
* rename addressee to receiver? We decided not to change that right now but we will wait for the natives to chime in.
* CIF: @when-iso instead of @when: For the web service there is a strong need for standardized date formats. --> Yes, will implement
* CIF: clearly defined meta data with information about origin, person in charge, last change date etc. --> Yes, will implement
* CIF: shall @notBefore be required to have a counterpart @notAfter? --> No, rejected

==== Roadmap ====
* Next conf call on May 28, 10 AM
* f2f meeting on June 17/18 (date needs to be finalized)
* feature request due before next Council f2f, June 30
* correspSearch will go public at the end of June

=== Conf Call March 17, 2014 ===
Peter gave a short summary of the workshop “Digitising experiences of migration” (Mellon Centre for Migration Studies, Omagh, Northern Ireland, March 14-15) – and we discussed the difficulties with lacking authority-file-data for our Correspondence Interchange Format (CIF). Marcel (located at the Austrian National Library) will have a look at Europeana’s interchange format to find out whether it could be combined with the task force’s CIF; Peter will get in contact with the BBAW in order to create some sort of web service, which will facilitate for data interchange.
Roadmap: June 2014 TEI-Council in Oxford – proposal should be ready for feature request – October 2014: TEI-Meeting (SIG meeting and/or <correspDesc>-workshop)

=== Conf Call Feb. 18, 2014 ===
We discussed the <correspType> element, decided to change its name to <correspClass> (according to <textClass>). Then we dealt with the preparation of the presentation in Berlin, Feb. 26, 2014 (workshop: “Briefeditionen um 1800 – Schnittstellen finden und vernetzen”). To-dos: enhancing second draft ODD, enhancing text of proposal (theoretical considerations, preceeding work). Inform the communtiy via mailing list to get some feedback.

=== Presentation Feb. 02, 2014 ===

Short presentation of the element <correspDesc> (as developed so far) at workshop on editions of correspondence around 1800 at Berlin-Brandenburg Academy of Sciences in Berlin. The slides of the presentation (in German) are available [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/2014%2002%2026%20presentation.pdf?raw=true here] and at [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub].

Next conf call will be on March 17, 2014.

=== Conf Call Jan. 30, 2014 ===

Discussing new changes in schema (<correspDesc> now repeatable, <note> and @ref in <correspDesc> possible, probably new name for <ct:correspType> needed, etc.). Latest version of the proposal can be found on [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub]. Proposal fits well for encoding e-mails. Looking at real example of encoding a letter with our schema, discussing detailed structure and flat structure (CIF).

=== Meeting Jan. 13-14, 2014 ===

Meeting of task force in Berlin. We pushed forward the work on an ODD file for the correspondence module with the new element <correspDesc> (and several child elements). The result can be found at GitHub: [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/proposal.xml proposal.xml]. While the formal specification can already be considered alpha (i.e. you can build a schema and try it out), we are still behind enhancing the documentation with information on background, theoretical considerations, notes on implementation, etc.

Next conf call will be on Jan. 30 (09:30 CET), 2014.

=== Conf Call Jan. 8, 2014 ===

This conf call mainly dealt with the preparation of the face-to-face meeting in Berlin on Jan. 13-14.
To-do-list for this meeting: reading of Mariana's e-mail and files, and of literature mentioned during conf calls (editio, Emert, etc.).

General to-do-list: enhancing second draft ODD, enhancing text of proposal, have a look at Genetic Editions proposal.

We decided to put together a bibliography of literature on editing letters that will help writing our proposal.

All minutes from TEI conferences in TEI now online [http://www.tei-c.org/Activities/SIG/Correspondence/index.xml here].

=== Conf Call Dec. 18, 2013 ===

We closely dealt with the question, what information we want to encode within the new <correspDesc> element and what elements will be needed. Child elements of/information given within <correspDesc> will be: <sender>, <addressee>, <placeSender>, <placeAddressee>, <dateSender>, <dateAddressee>, Korrespondenzstelle, type of correspondence, bearer and method of message, information whether there is an envelope or not (description of envelope in <msDsc> and transcription in <body>).

What will not be encoded within <correspDesc> because it is not letter-specific: <incipit>, printed things like form fields or letterheads, <stamp> and postage stamps - all this information is encoded within <msDesc>.

There will be a short presentation of the work of the SIG Correspondence and especially the <correspDesc> task force at the meeting on technical interfaces in German digital editions of letters around 1800 at the Berlin-Brandenburg Academy of Sciences in Berlin on February 26th.

Next conf call will be on Jan. 8, 10AM.

=== Conf Call Nov. 26, 2013 ===

Second meeting of the task force. Main topic was bringing together correspondence specific metadata (that should be encoded within a new <correspDesc> - or otherwise called - element but not necessarily):
sender, addressee, place of sender, date of sending, place of addressee, date of receiving, type of correspondence (letter, postcard, etc.), incipit, envelope, context (previous/next letter), postmark, stamp, perhaps transmitter of the message and method of delivery.

We had a closer look at the DALF Preliminary P5 Proposal and the <dalf:letDesc> element as well as the <correspDesc> element used by [http://www.weber-gesamtausgabe.de Weber-Gesamtausgabe].
We dealt more closely with the problems of how and where to encode envelopes, the type of message, postmarks, etc. Seals are not specific for letters but for other manuscripts as well. Therefore, changing their encoding (in <sealDesc>) is not necessary.

Next steps: Peter starts reworking/extending the '[[SIG:Correspondence/ODD_work|second draft]]', Marcel turns the minutes of the SIG Correspondence meetings into TEI, and starts writing goal and background information, DALF and WEGA, development of this proposal, etc. Sabine starts putting together information on the letter specific metadata and their description, place, examples, etc. as well as building up a structure for our proposal.

Next conf call will be on Dec. 18, 10AM. At the face-to-face 'boot camp' on January 13-14 in Berlin, we will work on the customization ODD file.

=== Conf Call Nov. 6, 2013 ===

First meeting of the task force. We summed up the SIG meeting at Rome and made sure that we all shared (more or less) the same ideas about the goal of the task force. Had a look at the "[[SIG:Correspondence/ODD_work|second draft]]" from last year which we decided to take as a starting point for future work.

Furthermore we decided on GitHub as a central repository for carrying out the work on our proposal and envisioned a face2face meeting at the beginning of next year as sort of a "boot camp" (scheduled for Jan. 13/14 in Berlin).

Next conf call shall be on Nov. 26, 12PM were we will look more closely at DALF and try to narrow down the "correspondence specific meta data".

== Literature and previous work ==

* [http://ctb.kantl.be/project/dalf/P5/DALF_P5-p0.1.zip DALF Preliminary P5 Proposal]
* [[SIG:Correspondence/RequestForModule|Request for a correspondence module and a wrapper element for correspondence meta data]]
* Winfried Woesler: ''Richtlinienvorschläge für Briefkommentare'', in: Wissenschaftliche Briefeditionen und ihre Probleme. Editionswissenschaftliches Symposium, Berlin 1998, p. 87–96

SIG:Correspondence/task-force-correspDesc

2014-09-02T14:25:17Z

Illetschko Marcel: /* Recent discussion */

<- back to [[SIG:Correspondence]]

= Task force "correspDesc" =

* '''Members''': Marcel Illetschko, Sabine Seifert, Peter Stadler
* "'''Pusher'''": Mariana Gomes

We will try to make our work as transparent and open as possible so others can chime in and contribute at every stage. Please feel free to make use of all the various comment/edit/share/fork functions or to contact us directly.

== Goal ==

Create a formal proposal for a <correspDesc> (or whatever name) element for approval by the TEI council as a new element of the TEI standard. This work shall be based on the "second draft for a correspondence module and a wrapper element for correspondence meta data" as it was started during the 2012 SIG meeting.

== Background ==

There have been several P4 projects with a dedicated correspondence schema (DALF probably being the renowned). While several correspondence tags (<postscript> etc.) are available from the TEI P5 standard, there is no specific way of dealing with correspondence meta data (e.g. sender, addressee) in the current TEI header. Since that's an impediment on the interoperability and interchange of these texts and since there are good practice models working with a <correspDesc>, the SIG Correspondence started to draft such a proposal during its 2012 meeting and now set up a task force for elaborating this draft.

== Repositories ==

https://github.com/TEI-Correspondence-SIG/correspDesc
This will be the main place for bringing together the proposal.

== Recent discussion ==

The SIG's proposal already caused a lot of traffic at the mailing list. See a collection of all the contributions and ideas here - sorted by elements and furnished with the task force's view on the topics.

==== A) <ct:corresDesc> ====

'''''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!).

==== B) <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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

== Meetings ==

=== Meeting June 17-18, 2014 ===
Two days of intense work on the proposal, mainly reworking and adding of prose description with encoding examples in the chapter "Implementation of the correspondence description":
* differentiation between sender and author
* differentiation between the intended and the actual (place of) addressee
* repeating of direct child elements of <correspDesc>
* use of <transmission> in contrast to the TEI element <channel>
* use of <context> with varying evaluations of the position within a correspondence
* text classification, classification schemes (and the lack thereof) and materiality aspects.

Adding of examples to formal specification of various elements.

Preparing proposal for handing in as feature request soon. All updates available at GitHub, with additional HTML page for easy reading.

=== Conf Call June 12, 2014 ===
The main part of this conf call was held with Stefan Dumont (BBAW) who set up the web service "correspSearch" that analyzes beacon files based on the task force's <correspDesc> format from several digital correspondence editions and thus providing the possibility for searching through meta data of these editions.

Discussion of information needed from participating digital editions/projects: responsible person (preferably with e-mail address, in <titleStmt>); name of the beacon file (in <titleStmt>); latest update (in <revisionDesc>); information on licensing (with URL etc., <publicationStmt>); bibliographic reference (<sourceDesc>, <bibl>).

There is also the question of how to handle duplicates, i.e. one letter in more than one participating digital edition and thus resulting in two entries. Especially in these cases, a correspSearch ID for each entry is desirable (referencing to them with @ref).

<correspClass> is not yet part of the web service but could be implemented.

The web service "correspSearch" will be developed further and soon be publicly available online in a beta version, with corresponding API.

=== Conf Call May 28, 2014 ===

It's been our fastest conf call ever! We reported on last weeks activities (not much, but some additions to the [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub repo]) and agreed on a f2f meeting on June 17/18 in Berlin. Next conf call is scheduled for June 12, 10 AM.

=== Conf Call May 20, 2014 ===

==== Reports on two conferences: ====
# Berlin: [https://www.literatur.hu-berlin.de/aktuelles_idl/konferenzen_tagungen_vortraege/ontologien/programm "Datenmodellierung in digitalen Briefeditionen und ihre interpretatorische Leistung. Ontologien, Textgenetik und Visualisierungsstrategien"]
Peter presented on "interoperability of letter collections" and touched on the work of the task force. A lot of people are planning (dreaming) of connecting letter collections.
# Vienna: [http://www.ogl.at/programm/aktuelles-programm/ Editorenkolloquium]
"The old world" – a strong bias against digital editions and only few letter projects presented at the conference. Nevertheless Marcel waved the correspDesc flag during his talk.

==== correspSearch ====
Stefan Dumont from the BBAW created a web service for querying correspDesc data. This web service will be presented as an open beta at the end of June. During his work on correspSearch he encountered several bugs and missing features in the CIF standard that need to be addressed now. (see next point)

==== proposed schema changes ====
* rename addressee to receiver? We decided not to change that right now but we will wait for the natives to chime in.
* CIF: @when-iso instead of @when: For the web service there is a strong need for standardized date formats. --> Yes, will implement
* CIF: clearly defined meta data with information about origin, person in charge, last change date etc. --> Yes, will implement
* CIF: shall @notBefore be required to have a counterpart @notAfter? --> No, rejected

==== Roadmap ====
* Next conf call on May 28, 10 AM
* f2f meeting on June 17/18 (date needs to be finalized)
* feature request due before next Council f2f, June 30
* correspSearch will go public at the end of June

=== Conf Call March 17, 2014 ===
Peter gave a short summary of the workshop “Digitising experiences of migration” (Mellon Centre for Migration Studies, Omagh, Northern Ireland, March 14-15) – and we discussed the difficulties with lacking authority-file-data for our Correspondence Interchange Format (CIF). Marcel (located at the Austrian National Library) will have a look at Europeana’s interchange format to find out whether it could be combined with the task force’s CIF; Peter will get in contact with the BBAW in order to create some sort of web service, which will facilitate for data interchange.
Roadmap: June 2014 TEI-Council in Oxford – proposal should be ready for feature request – October 2014: TEI-Meeting (SIG meeting and/or <correspDesc>-workshop)

=== Conf Call Feb. 18, 2014 ===
We discussed the <correspType> element, decided to change its name to <correspClass> (according to <textClass>). Then we dealt with the preparation of the presentation in Berlin, Feb. 26, 2014 (workshop: “Briefeditionen um 1800 – Schnittstellen finden und vernetzen”). To-dos: enhancing second draft ODD, enhancing text of proposal (theoretical considerations, preceeding work). Inform the communtiy via mailing list to get some feedback.

=== Presentation Feb. 02, 2014 ===

Short presentation of the element <correspDesc> (as developed so far) at workshop on editions of correspondence around 1800 at Berlin-Brandenburg Academy of Sciences in Berlin. The slides of the presentation (in German) are available [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/2014%2002%2026%20presentation.pdf?raw=true here] and at [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub].

Next conf call will be on March 17, 2014.

=== Conf Call Jan. 30, 2014 ===

Discussing new changes in schema (<correspDesc> now repeatable, <note> and @ref in <correspDesc> possible, probably new name for <ct:correspType> needed, etc.). Latest version of the proposal can be found on [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub]. Proposal fits well for encoding e-mails. Looking at real example of encoding a letter with our schema, discussing detailed structure and flat structure (CIF).

=== Meeting Jan. 13-14, 2014 ===

Meeting of task force in Berlin. We pushed forward the work on an ODD file for the correspondence module with the new element <correspDesc> (and several child elements). The result can be found at GitHub: [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/proposal.xml proposal.xml]. While the formal specification can already be considered alpha (i.e. you can build a schema and try it out), we are still behind enhancing the documentation with information on background, theoretical considerations, notes on implementation, etc.

Next conf call will be on Jan. 30 (09:30 CET), 2014.

=== Conf Call Jan. 8, 2014 ===

This conf call mainly dealt with the preparation of the face-to-face meeting in Berlin on Jan. 13-14.
To-do-list for this meeting: reading of Mariana's e-mail and files, and of literature mentioned during conf calls (editio, Emert, etc.).

General to-do-list: enhancing second draft ODD, enhancing text of proposal, have a look at Genetic Editions proposal.

We decided to put together a bibliography of literature on editing letters that will help writing our proposal.

All minutes from TEI conferences in TEI now online [http://www.tei-c.org/Activities/SIG/Correspondence/index.xml here].

=== Conf Call Dec. 18, 2013 ===

We closely dealt with the question, what information we want to encode within the new <correspDesc> element and what elements will be needed. Child elements of/information given within <correspDesc> will be: <sender>, <addressee>, <placeSender>, <placeAddressee>, <dateSender>, <dateAddressee>, Korrespondenzstelle, type of correspondence, bearer and method of message, information whether there is an envelope or not (description of envelope in <msDsc> and transcription in <body>).

What will not be encoded within <correspDesc> because it is not letter-specific: <incipit>, printed things like form fields or letterheads, <stamp> and postage stamps - all this information is encoded within <msDesc>.

There will be a short presentation of the work of the SIG Correspondence and especially the <correspDesc> task force at the meeting on technical interfaces in German digital editions of letters around 1800 at the Berlin-Brandenburg Academy of Sciences in Berlin on February 26th.

Next conf call will be on Jan. 8, 10AM.

=== Conf Call Nov. 26, 2013 ===

Second meeting of the task force. Main topic was bringing together correspondence specific metadata (that should be encoded within a new <correspDesc> - or otherwise called - element but not necessarily):
sender, addressee, place of sender, date of sending, place of addressee, date of receiving, type of correspondence (letter, postcard, etc.), incipit, envelope, context (previous/next letter), postmark, stamp, perhaps transmitter of the message and method of delivery.

We had a closer look at the DALF Preliminary P5 Proposal and the <dalf:letDesc> element as well as the <correspDesc> element used by [http://www.weber-gesamtausgabe.de Weber-Gesamtausgabe].
We dealt more closely with the problems of how and where to encode envelopes, the type of message, postmarks, etc. Seals are not specific for letters but for other manuscripts as well. Therefore, changing their encoding (in <sealDesc>) is not necessary.

Next steps: Peter starts reworking/extending the '[[SIG:Correspondence/ODD_work|second draft]]', Marcel turns the minutes of the SIG Correspondence meetings into TEI, and starts writing goal and background information, DALF and WEGA, development of this proposal, etc. Sabine starts putting together information on the letter specific metadata and their description, place, examples, etc. as well as building up a structure for our proposal.

Next conf call will be on Dec. 18, 10AM. At the face-to-face 'boot camp' on January 13-14 in Berlin, we will work on the customization ODD file.

=== Conf Call Nov. 6, 2013 ===

First meeting of the task force. We summed up the SIG meeting at Rome and made sure that we all shared (more or less) the same ideas about the goal of the task force. Had a look at the "[[SIG:Correspondence/ODD_work|second draft]]" from last year which we decided to take as a starting point for future work.

Furthermore we decided on GitHub as a central repository for carrying out the work on our proposal and envisioned a face2face meeting at the beginning of next year as sort of a "boot camp" (scheduled for Jan. 13/14 in Berlin).

Next conf call shall be on Nov. 26, 12PM were we will look more closely at DALF and try to narrow down the "correspondence specific meta data".

== Literature and previous work ==

* [http://ctb.kantl.be/project/dalf/P5/DALF_P5-p0.1.zip DALF Preliminary P5 Proposal]
* [[SIG:Correspondence/RequestForModule|Request for a correspondence module and a wrapper element for correspondence meta data]]
* Winfried Woesler: ''Richtlinienvorschläge für Briefkommentare'', in: Wissenschaftliche Briefeditionen und ihre Probleme. Editionswissenschaftliches Symposium, Berlin 1998, p. 87–96

SIG:Correspondence/task-force-correspDesc

2014-09-02T14:24:05Z

Illetschko Marcel: /* Recent discussions */

<- back to [[SIG:Correspondence]]

= Task force "correspDesc" =

* '''Members''': Marcel Illetschko, Sabine Seifert, Peter Stadler
* "'''Pusher'''": Mariana Gomes

We will try to make our work as transparent and open as possible so others can chime in and contribute at every stage. Please feel free to make use of all the various comment/edit/share/fork functions or to contact us directly.

== Goal ==

Create a formal proposal for a <correspDesc> (or whatever name) element for approval by the TEI council as a new element of the TEI standard. This work shall be based on the "second draft for a correspondence module and a wrapper element for correspondence meta data" as it was started during the 2012 SIG meeting.

== Background ==

There have been several P4 projects with a dedicated correspondence schema (DALF probably being the renowned). While several correspondence tags (<postscript> etc.) are available from the TEI P5 standard, there is no specific way of dealing with correspondence meta data (e.g. sender, addressee) in the current TEI header. Since that's an impediment on the interoperability and interchange of these texts and since there are good practice models working with a <correspDesc>, the SIG Correspondence started to draft such a proposal during its 2012 meeting and now set up a task force for elaborating this draft.

== Repositories ==

https://github.com/TEI-Correspondence-SIG/correspDesc
This will be the main place for bringing together the proposal.

== Recent discussion ==

The SIG's proposal already caused a lot of traffic at the mailing list. See a list of all the contributions and ideas here - sorted by elements and furnished with the task force's view on the topics.

==== A) <ct:corresDesc> ====

'''''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!).

==== B) <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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

== Meetings ==

=== Meeting June 17-18, 2014 ===
Two days of intense work on the proposal, mainly reworking and adding of prose description with encoding examples in the chapter "Implementation of the correspondence description":
* differentiation between sender and author
* differentiation between the intended and the actual (place of) addressee
* repeating of direct child elements of <correspDesc>
* use of <transmission> in contrast to the TEI element <channel>
* use of <context> with varying evaluations of the position within a correspondence
* text classification, classification schemes (and the lack thereof) and materiality aspects.

Adding of examples to formal specification of various elements.

Preparing proposal for handing in as feature request soon. All updates available at GitHub, with additional HTML page for easy reading.

=== Conf Call June 12, 2014 ===
The main part of this conf call was held with Stefan Dumont (BBAW) who set up the web service "correspSearch" that analyzes beacon files based on the task force's <correspDesc> format from several digital correspondence editions and thus providing the possibility for searching through meta data of these editions.

Discussion of information needed from participating digital editions/projects: responsible person (preferably with e-mail address, in <titleStmt>); name of the beacon file (in <titleStmt>); latest update (in <revisionDesc>); information on licensing (with URL etc., <publicationStmt>); bibliographic reference (<sourceDesc>, <bibl>).

There is also the question of how to handle duplicates, i.e. one letter in more than one participating digital edition and thus resulting in two entries. Especially in these cases, a correspSearch ID for each entry is desirable (referencing to them with @ref).

<correspClass> is not yet part of the web service but could be implemented.

The web service "correspSearch" will be developed further and soon be publicly available online in a beta version, with corresponding API.

=== Conf Call May 28, 2014 ===

It's been our fastest conf call ever! We reported on last weeks activities (not much, but some additions to the [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub repo]) and agreed on a f2f meeting on June 17/18 in Berlin. Next conf call is scheduled for June 12, 10 AM.

=== Conf Call May 20, 2014 ===

==== Reports on two conferences: ====
# Berlin: [https://www.literatur.hu-berlin.de/aktuelles_idl/konferenzen_tagungen_vortraege/ontologien/programm "Datenmodellierung in digitalen Briefeditionen und ihre interpretatorische Leistung. Ontologien, Textgenetik und Visualisierungsstrategien"]
Peter presented on "interoperability of letter collections" and touched on the work of the task force. A lot of people are planning (dreaming) of connecting letter collections.
# Vienna: [http://www.ogl.at/programm/aktuelles-programm/ Editorenkolloquium]
"The old world" – a strong bias against digital editions and only few letter projects presented at the conference. Nevertheless Marcel waved the correspDesc flag during his talk.

==== correspSearch ====
Stefan Dumont from the BBAW created a web service for querying correspDesc data. This web service will be presented as an open beta at the end of June. During his work on correspSearch he encountered several bugs and missing features in the CIF standard that need to be addressed now. (see next point)

==== proposed schema changes ====
* rename addressee to receiver? We decided not to change that right now but we will wait for the natives to chime in.
* CIF: @when-iso instead of @when: For the web service there is a strong need for standardized date formats. --> Yes, will implement
* CIF: clearly defined meta data with information about origin, person in charge, last change date etc. --> Yes, will implement
* CIF: shall @notBefore be required to have a counterpart @notAfter? --> No, rejected

==== Roadmap ====
* Next conf call on May 28, 10 AM
* f2f meeting on June 17/18 (date needs to be finalized)
* feature request due before next Council f2f, June 30
* correspSearch will go public at the end of June

=== Conf Call March 17, 2014 ===
Peter gave a short summary of the workshop “Digitising experiences of migration” (Mellon Centre for Migration Studies, Omagh, Northern Ireland, March 14-15) – and we discussed the difficulties with lacking authority-file-data for our Correspondence Interchange Format (CIF). Marcel (located at the Austrian National Library) will have a look at Europeana’s interchange format to find out whether it could be combined with the task force’s CIF; Peter will get in contact with the BBAW in order to create some sort of web service, which will facilitate for data interchange.
Roadmap: June 2014 TEI-Council in Oxford – proposal should be ready for feature request – October 2014: TEI-Meeting (SIG meeting and/or <correspDesc>-workshop)

=== Conf Call Feb. 18, 2014 ===
We discussed the <correspType> element, decided to change its name to <correspClass> (according to <textClass>). Then we dealt with the preparation of the presentation in Berlin, Feb. 26, 2014 (workshop: “Briefeditionen um 1800 – Schnittstellen finden und vernetzen”). To-dos: enhancing second draft ODD, enhancing text of proposal (theoretical considerations, preceeding work). Inform the communtiy via mailing list to get some feedback.

=== Presentation Feb. 02, 2014 ===

Short presentation of the element <correspDesc> (as developed so far) at workshop on editions of correspondence around 1800 at Berlin-Brandenburg Academy of Sciences in Berlin. The slides of the presentation (in German) are available [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/2014%2002%2026%20presentation.pdf?raw=true here] and at [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub].

Next conf call will be on March 17, 2014.

=== Conf Call Jan. 30, 2014 ===

Discussing new changes in schema (<correspDesc> now repeatable, <note> and @ref in <correspDesc> possible, probably new name for <ct:correspType> needed, etc.). Latest version of the proposal can be found on [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub]. Proposal fits well for encoding e-mails. Looking at real example of encoding a letter with our schema, discussing detailed structure and flat structure (CIF).

=== Meeting Jan. 13-14, 2014 ===

Meeting of task force in Berlin. We pushed forward the work on an ODD file for the correspondence module with the new element <correspDesc> (and several child elements). The result can be found at GitHub: [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/proposal.xml proposal.xml]. While the formal specification can already be considered alpha (i.e. you can build a schema and try it out), we are still behind enhancing the documentation with information on background, theoretical considerations, notes on implementation, etc.

Next conf call will be on Jan. 30 (09:30 CET), 2014.

=== Conf Call Jan. 8, 2014 ===

This conf call mainly dealt with the preparation of the face-to-face meeting in Berlin on Jan. 13-14.
To-do-list for this meeting: reading of Mariana's e-mail and files, and of literature mentioned during conf calls (editio, Emert, etc.).

General to-do-list: enhancing second draft ODD, enhancing text of proposal, have a look at Genetic Editions proposal.

We decided to put together a bibliography of literature on editing letters that will help writing our proposal.

All minutes from TEI conferences in TEI now online [http://www.tei-c.org/Activities/SIG/Correspondence/index.xml here].

=== Conf Call Dec. 18, 2013 ===

We closely dealt with the question, what information we want to encode within the new <correspDesc> element and what elements will be needed. Child elements of/information given within <correspDesc> will be: <sender>, <addressee>, <placeSender>, <placeAddressee>, <dateSender>, <dateAddressee>, Korrespondenzstelle, type of correspondence, bearer and method of message, information whether there is an envelope or not (description of envelope in <msDsc> and transcription in <body>).

What will not be encoded within <correspDesc> because it is not letter-specific: <incipit>, printed things like form fields or letterheads, <stamp> and postage stamps - all this information is encoded within <msDesc>.

There will be a short presentation of the work of the SIG Correspondence and especially the <correspDesc> task force at the meeting on technical interfaces in German digital editions of letters around 1800 at the Berlin-Brandenburg Academy of Sciences in Berlin on February 26th.

Next conf call will be on Jan. 8, 10AM.

=== Conf Call Nov. 26, 2013 ===

Second meeting of the task force. Main topic was bringing together correspondence specific metadata (that should be encoded within a new <correspDesc> - or otherwise called - element but not necessarily):
sender, addressee, place of sender, date of sending, place of addressee, date of receiving, type of correspondence (letter, postcard, etc.), incipit, envelope, context (previous/next letter), postmark, stamp, perhaps transmitter of the message and method of delivery.

We had a closer look at the DALF Preliminary P5 Proposal and the <dalf:letDesc> element as well as the <correspDesc> element used by [http://www.weber-gesamtausgabe.de Weber-Gesamtausgabe].
We dealt more closely with the problems of how and where to encode envelopes, the type of message, postmarks, etc. Seals are not specific for letters but for other manuscripts as well. Therefore, changing their encoding (in <sealDesc>) is not necessary.

Next steps: Peter starts reworking/extending the '[[SIG:Correspondence/ODD_work|second draft]]', Marcel turns the minutes of the SIG Correspondence meetings into TEI, and starts writing goal and background information, DALF and WEGA, development of this proposal, etc. Sabine starts putting together information on the letter specific metadata and their description, place, examples, etc. as well as building up a structure for our proposal.

Next conf call will be on Dec. 18, 10AM. At the face-to-face 'boot camp' on January 13-14 in Berlin, we will work on the customization ODD file.

=== Conf Call Nov. 6, 2013 ===

First meeting of the task force. We summed up the SIG meeting at Rome and made sure that we all shared (more or less) the same ideas about the goal of the task force. Had a look at the "[[SIG:Correspondence/ODD_work|second draft]]" from last year which we decided to take as a starting point for future work.

Furthermore we decided on GitHub as a central repository for carrying out the work on our proposal and envisioned a face2face meeting at the beginning of next year as sort of a "boot camp" (scheduled for Jan. 13/14 in Berlin).

Next conf call shall be on Nov. 26, 12PM were we will look more closely at DALF and try to narrow down the "correspondence specific meta data".

== Literature and previous work ==

* [http://ctb.kantl.be/project/dalf/P5/DALF_P5-p0.1.zip DALF Preliminary P5 Proposal]
* [[SIG:Correspondence/RequestForModule|Request for a correspondence module and a wrapper element for correspondence meta data]]
* Winfried Woesler: ''Richtlinienvorschläge für Briefkommentare'', in: Wissenschaftliche Briefeditionen und ihre Probleme. Editionswissenschaftliches Symposium, Berlin 1998, p. 87–96

SIG:Correspondence/task-force-correspDesc

2014-09-02T13:54:07Z

Illetschko Marcel: /* Task force "correspDesc" */

<- back to [[SIG:Correspondence]]

= Task force "correspDesc" =

* '''Members''': Marcel Illetschko, Sabine Seifert, Peter Stadler
* "'''Pusher'''": Mariana Gomes

We will try to make our work as transparent and open as possible so others can chime in and contribute at every stage. Please feel free to make use of all the various comment/edit/share/fork functions or to contact us directly.

== Goal ==

Create a formal proposal for a <correspDesc> (or whatever name) element for approval by the TEI council as a new element of the TEI standard. This work shall be based on the "second draft for a correspondence module and a wrapper element for correspondence meta data" as it was started during the 2012 SIG meeting.

== Background ==

There have been several P4 projects with a dedicated correspondence schema (DALF probably being the renowned). While several correspondence tags (<postscript> etc.) are available from the TEI P5 standard, there is no specific way of dealing with correspondence meta data (e.g. sender, addressee) in the current TEI header. Since that's an impediment on the interoperability and interchange of these texts and since there are good practice models working with a <correspDesc>, the SIG Correspondence started to draft such a proposal during its 2012 meeting and now set up a task force for elaborating this draft.

== Repositories ==

https://github.com/TEI-Correspondence-SIG/correspDesc
This will be the main place for bringing together the proposal.

== Recent discussions ==

==== A) <ct:corresDesc> ====

'''''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!).

==== B) <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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

== Meetings ==

=== Meeting June 17-18, 2014 ===
Two days of intense work on the proposal, mainly reworking and adding of prose description with encoding examples in the chapter "Implementation of the correspondence description":
* differentiation between sender and author
* differentiation between the intended and the actual (place of) addressee
* repeating of direct child elements of <correspDesc>
* use of <transmission> in contrast to the TEI element <channel>
* use of <context> with varying evaluations of the position within a correspondence
* text classification, classification schemes (and the lack thereof) and materiality aspects.

Adding of examples to formal specification of various elements.

Preparing proposal for handing in as feature request soon. All updates available at GitHub, with additional HTML page for easy reading.

=== Conf Call June 12, 2014 ===
The main part of this conf call was held with Stefan Dumont (BBAW) who set up the web service "correspSearch" that analyzes beacon files based on the task force's <correspDesc> format from several digital correspondence editions and thus providing the possibility for searching through meta data of these editions.

Discussion of information needed from participating digital editions/projects: responsible person (preferably with e-mail address, in <titleStmt>); name of the beacon file (in <titleStmt>); latest update (in <revisionDesc>); information on licensing (with URL etc., <publicationStmt>); bibliographic reference (<sourceDesc>, <bibl>).

There is also the question of how to handle duplicates, i.e. one letter in more than one participating digital edition and thus resulting in two entries. Especially in these cases, a correspSearch ID for each entry is desirable (referencing to them with @ref).

<correspClass> is not yet part of the web service but could be implemented.

The web service "correspSearch" will be developed further and soon be publicly available online in a beta version, with corresponding API.

=== Conf Call May 28, 2014 ===

It's been our fastest conf call ever! We reported on last weeks activities (not much, but some additions to the [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub repo]) and agreed on a f2f meeting on June 17/18 in Berlin. Next conf call is scheduled for June 12, 10 AM.

=== Conf Call May 20, 2014 ===

==== Reports on two conferences: ====
# Berlin: [https://www.literatur.hu-berlin.de/aktuelles_idl/konferenzen_tagungen_vortraege/ontologien/programm "Datenmodellierung in digitalen Briefeditionen und ihre interpretatorische Leistung. Ontologien, Textgenetik und Visualisierungsstrategien"]
Peter presented on "interoperability of letter collections" and touched on the work of the task force. A lot of people are planning (dreaming) of connecting letter collections.
# Vienna: [http://www.ogl.at/programm/aktuelles-programm/ Editorenkolloquium]
"The old world" – a strong bias against digital editions and only few letter projects presented at the conference. Nevertheless Marcel waved the correspDesc flag during his talk.

==== correspSearch ====
Stefan Dumont from the BBAW created a web service for querying correspDesc data. This web service will be presented as an open beta at the end of June. During his work on correspSearch he encountered several bugs and missing features in the CIF standard that need to be addressed now. (see next point)

==== proposed schema changes ====
* rename addressee to receiver? We decided not to change that right now but we will wait for the natives to chime in.
* CIF: @when-iso instead of @when: For the web service there is a strong need for standardized date formats. --> Yes, will implement
* CIF: clearly defined meta data with information about origin, person in charge, last change date etc. --> Yes, will implement
* CIF: shall @notBefore be required to have a counterpart @notAfter? --> No, rejected

==== Roadmap ====
* Next conf call on May 28, 10 AM
* f2f meeting on June 17/18 (date needs to be finalized)
* feature request due before next Council f2f, June 30
* correspSearch will go public at the end of June

=== Conf Call March 17, 2014 ===
Peter gave a short summary of the workshop “Digitising experiences of migration” (Mellon Centre for Migration Studies, Omagh, Northern Ireland, March 14-15) – and we discussed the difficulties with lacking authority-file-data for our Correspondence Interchange Format (CIF). Marcel (located at the Austrian National Library) will have a look at Europeana’s interchange format to find out whether it could be combined with the task force’s CIF; Peter will get in contact with the BBAW in order to create some sort of web service, which will facilitate for data interchange.
Roadmap: June 2014 TEI-Council in Oxford – proposal should be ready for feature request – October 2014: TEI-Meeting (SIG meeting and/or <correspDesc>-workshop)

=== Conf Call Feb. 18, 2014 ===
We discussed the <correspType> element, decided to change its name to <correspClass> (according to <textClass>). Then we dealt with the preparation of the presentation in Berlin, Feb. 26, 2014 (workshop: “Briefeditionen um 1800 – Schnittstellen finden und vernetzen”). To-dos: enhancing second draft ODD, enhancing text of proposal (theoretical considerations, preceeding work). Inform the communtiy via mailing list to get some feedback.

=== Presentation Feb. 02, 2014 ===

Short presentation of the element <correspDesc> (as developed so far) at workshop on editions of correspondence around 1800 at Berlin-Brandenburg Academy of Sciences in Berlin. The slides of the presentation (in German) are available [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/2014%2002%2026%20presentation.pdf?raw=true here] and at [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub].

Next conf call will be on March 17, 2014.

=== Conf Call Jan. 30, 2014 ===

Discussing new changes in schema (<correspDesc> now repeatable, <note> and @ref in <correspDesc> possible, probably new name for <ct:correspType> needed, etc.). Latest version of the proposal can be found on [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub]. Proposal fits well for encoding e-mails. Looking at real example of encoding a letter with our schema, discussing detailed structure and flat structure (CIF).

=== Meeting Jan. 13-14, 2014 ===

Meeting of task force in Berlin. We pushed forward the work on an ODD file for the correspondence module with the new element <correspDesc> (and several child elements). The result can be found at GitHub: [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/proposal.xml proposal.xml]. While the formal specification can already be considered alpha (i.e. you can build a schema and try it out), we are still behind enhancing the documentation with information on background, theoretical considerations, notes on implementation, etc.

Next conf call will be on Jan. 30 (09:30 CET), 2014.

=== Conf Call Jan. 8, 2014 ===

This conf call mainly dealt with the preparation of the face-to-face meeting in Berlin on Jan. 13-14.
To-do-list for this meeting: reading of Mariana's e-mail and files, and of literature mentioned during conf calls (editio, Emert, etc.).

General to-do-list: enhancing second draft ODD, enhancing text of proposal, have a look at Genetic Editions proposal.

We decided to put together a bibliography of literature on editing letters that will help writing our proposal.

All minutes from TEI conferences in TEI now online [http://www.tei-c.org/Activities/SIG/Correspondence/index.xml here].

=== Conf Call Dec. 18, 2013 ===

We closely dealt with the question, what information we want to encode within the new <correspDesc> element and what elements will be needed. Child elements of/information given within <correspDesc> will be: <sender>, <addressee>, <placeSender>, <placeAddressee>, <dateSender>, <dateAddressee>, Korrespondenzstelle, type of correspondence, bearer and method of message, information whether there is an envelope or not (description of envelope in <msDsc> and transcription in <body>).

What will not be encoded within <correspDesc> because it is not letter-specific: <incipit>, printed things like form fields or letterheads, <stamp> and postage stamps - all this information is encoded within <msDesc>.

There will be a short presentation of the work of the SIG Correspondence and especially the <correspDesc> task force at the meeting on technical interfaces in German digital editions of letters around 1800 at the Berlin-Brandenburg Academy of Sciences in Berlin on February 26th.

Next conf call will be on Jan. 8, 10AM.

=== Conf Call Nov. 26, 2013 ===

Second meeting of the task force. Main topic was bringing together correspondence specific metadata (that should be encoded within a new <correspDesc> - or otherwise called - element but not necessarily):
sender, addressee, place of sender, date of sending, place of addressee, date of receiving, type of correspondence (letter, postcard, etc.), incipit, envelope, context (previous/next letter), postmark, stamp, perhaps transmitter of the message and method of delivery.

We had a closer look at the DALF Preliminary P5 Proposal and the <dalf:letDesc> element as well as the <correspDesc> element used by [http://www.weber-gesamtausgabe.de Weber-Gesamtausgabe].
We dealt more closely with the problems of how and where to encode envelopes, the type of message, postmarks, etc. Seals are not specific for letters but for other manuscripts as well. Therefore, changing their encoding (in <sealDesc>) is not necessary.

Next steps: Peter starts reworking/extending the '[[SIG:Correspondence/ODD_work|second draft]]', Marcel turns the minutes of the SIG Correspondence meetings into TEI, and starts writing goal and background information, DALF and WEGA, development of this proposal, etc. Sabine starts putting together information on the letter specific metadata and their description, place, examples, etc. as well as building up a structure for our proposal.

Next conf call will be on Dec. 18, 10AM. At the face-to-face 'boot camp' on January 13-14 in Berlin, we will work on the customization ODD file.

=== Conf Call Nov. 6, 2013 ===

First meeting of the task force. We summed up the SIG meeting at Rome and made sure that we all shared (more or less) the same ideas about the goal of the task force. Had a look at the "[[SIG:Correspondence/ODD_work|second draft]]" from last year which we decided to take as a starting point for future work.

Furthermore we decided on GitHub as a central repository for carrying out the work on our proposal and envisioned a face2face meeting at the beginning of next year as sort of a "boot camp" (scheduled for Jan. 13/14 in Berlin).

Next conf call shall be on Nov. 26, 12PM were we will look more closely at DALF and try to narrow down the "correspondence specific meta data".

== Literature and previous work ==

* [http://ctb.kantl.be/project/dalf/P5/DALF_P5-p0.1.zip DALF Preliminary P5 Proposal]
* [[SIG:Correspondence/RequestForModule|Request for a correspondence module and a wrapper element for correspondence meta data]]
* Winfried Woesler: ''Richtlinienvorschläge für Briefkommentare'', in: Wissenschaftliche Briefeditionen und ihre Probleme. Editionswissenschaftliches Symposium, Berlin 1998, p. 87–96

SIG:Correspondence/task-force-correspDesc

2014-09-02T12:25:57Z

Illetschko Marcel: /* D) */

<- back to [[SIG:Correspondence]]

= Task force "correspDesc" =

* '''Members''': Marcel Illetschko, Sabine Seifert, Peter Stadler
* "'''Pusher'''": Mariana Gomes

We will try to make our work as transparent and open as possible so others can chime in and contribute at every stage. Please feel free to make use of all the various comment/edit/share/fork functions or to contact us directly.

== Goal ==

Create a formal proposal for a <correspDesc> (or whatever name) element for approval by the TEI council as a new element of the TEI standard. This work shall be based on the "second draft for a correspondence module and a wrapper element for correspondence meta data" as it was started during the 2012 SIG meeting.

== Background ==

There have been several P4 projects with a dedicated correspondence schema (DALF probably being the renowned). While several correspondence tags (<postscript> etc.) are available from the TEI P5 standard, there is no specific way of dealing with correspondence meta data (e.g. sender, addressee) in the current TEI header. Since that's an impediment on the interoperability and interchange of these texts and since there are good practice models working with a <correspDesc>, the SIG Correspondence started to draft such a proposal during its 2012 meeting and now set up a task force for elaborating this draft.

== Repositories ==

https://github.com/TEI-Correspondence-SIG/correspDesc
This will be the main place for bringing together the proposal.

== Recent discussions ==

==== A) <ct:corresDesc> ====

'''''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!).

==== B) <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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

== Meetings ==

=== Meeting June 17-18, 2014 ===
Two days of intense work on the proposal, mainly reworking and adding of prose description with encoding examples in the chapter "Implementation of the correspondence description":
* differentiation between sender and author
* differentiation between the intended and the actual (place of) addressee
* repeating of direct child elements of <correspDesc>
* use of <transmission> in contrast to the TEI element <channel>
* use of <context> with varying evaluations of the position within a correspondence
* text classification, classification schemes (and the lack thereof) and materiality aspects.

Adding of examples to formal specification of various elements.

Preparing proposal for handing in as feature request soon. All updates available at GitHub, with additional HTML page for easy reading.

=== Conf Call June 12, 2014 ===
The main part of this conf call was held with Stefan Dumont (BBAW) who set up the web service "correspSearch" that analyzes beacon files based on the task force's <correspDesc> format from several digital correspondence editions and thus providing the possibility for searching through meta data of these editions.

Discussion of information needed from participating digital editions/projects: responsible person (preferably with e-mail address, in <titleStmt>); name of the beacon file (in <titleStmt>); latest update (in <revisionDesc>); information on licensing (with URL etc., <publicationStmt>); bibliographic reference (<sourceDesc>, <bibl>).

There is also the question of how to handle duplicates, i.e. one letter in more than one participating digital edition and thus resulting in two entries. Especially in these cases, a correspSearch ID for each entry is desirable (referencing to them with @ref).

<correspClass> is not yet part of the web service but could be implemented.

The web service "correspSearch" will be developed further and soon be publicly available online in a beta version, with corresponding API.

=== Conf Call May 28, 2014 ===

It's been our fastest conf call ever! We reported on last weeks activities (not much, but some additions to the [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub repo]) and agreed on a f2f meeting on June 17/18 in Berlin. Next conf call is scheduled for June 12, 10 AM.

=== Conf Call May 20, 2014 ===

==== Reports on two conferences: ====
# Berlin: [https://www.literatur.hu-berlin.de/aktuelles_idl/konferenzen_tagungen_vortraege/ontologien/programm "Datenmodellierung in digitalen Briefeditionen und ihre interpretatorische Leistung. Ontologien, Textgenetik und Visualisierungsstrategien"]
Peter presented on "interoperability of letter collections" and touched on the work of the task force. A lot of people are planning (dreaming) of connecting letter collections.
# Vienna: [http://www.ogl.at/programm/aktuelles-programm/ Editorenkolloquium]
"The old world" – a strong bias against digital editions and only few letter projects presented at the conference. Nevertheless Marcel waved the correspDesc flag during his talk.

==== correspSearch ====
Stefan Dumont from the BBAW created a web service for querying correspDesc data. This web service will be presented as an open beta at the end of June. During his work on correspSearch he encountered several bugs and missing features in the CIF standard that need to be addressed now. (see next point)

==== proposed schema changes ====
* rename addressee to receiver? We decided not to change that right now but we will wait for the natives to chime in.
* CIF: @when-iso instead of @when: For the web service there is a strong need for standardized date formats. --> Yes, will implement
* CIF: clearly defined meta data with information about origin, person in charge, last change date etc. --> Yes, will implement
* CIF: shall @notBefore be required to have a counterpart @notAfter? --> No, rejected

==== Roadmap ====
* Next conf call on May 28, 10 AM
* f2f meeting on June 17/18 (date needs to be finalized)
* feature request due before next Council f2f, June 30
* correspSearch will go public at the end of June

=== Conf Call March 17, 2014 ===
Peter gave a short summary of the workshop “Digitising experiences of migration” (Mellon Centre for Migration Studies, Omagh, Northern Ireland, March 14-15) – and we discussed the difficulties with lacking authority-file-data for our Correspondence Interchange Format (CIF). Marcel (located at the Austrian National Library) will have a look at Europeana’s interchange format to find out whether it could be combined with the task force’s CIF; Peter will get in contact with the BBAW in order to create some sort of web service, which will facilitate for data interchange.
Roadmap: June 2014 TEI-Council in Oxford – proposal should be ready for feature request – October 2014: TEI-Meeting (SIG meeting and/or <correspDesc>-workshop)

=== Conf Call Feb. 18, 2014 ===
We discussed the <correspType> element, decided to change its name to <correspClass> (according to <textClass>). Then we dealt with the preparation of the presentation in Berlin, Feb. 26, 2014 (workshop: “Briefeditionen um 1800 – Schnittstellen finden und vernetzen”). To-dos: enhancing second draft ODD, enhancing text of proposal (theoretical considerations, preceeding work). Inform the communtiy via mailing list to get some feedback.

=== Presentation Feb. 02, 2014 ===

Short presentation of the element <correspDesc> (as developed so far) at workshop on editions of correspondence around 1800 at Berlin-Brandenburg Academy of Sciences in Berlin. The slides of the presentation (in German) are available [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/2014%2002%2026%20presentation.pdf?raw=true here] and at [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub].

Next conf call will be on March 17, 2014.

=== Conf Call Jan. 30, 2014 ===

Discussing new changes in schema (<correspDesc> now repeatable, <note> and @ref in <correspDesc> possible, probably new name for <ct:correspType> needed, etc.). Latest version of the proposal can be found on [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub]. Proposal fits well for encoding e-mails. Looking at real example of encoding a letter with our schema, discussing detailed structure and flat structure (CIF).

=== Meeting Jan. 13-14, 2014 ===

Meeting of task force in Berlin. We pushed forward the work on an ODD file for the correspondence module with the new element <correspDesc> (and several child elements). The result can be found at GitHub: [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/proposal.xml proposal.xml]. While the formal specification can already be considered alpha (i.e. you can build a schema and try it out), we are still behind enhancing the documentation with information on background, theoretical considerations, notes on implementation, etc.

Next conf call will be on Jan. 30 (09:30 CET), 2014.

=== Conf Call Jan. 8, 2014 ===

This conf call mainly dealt with the preparation of the face-to-face meeting in Berlin on Jan. 13-14.
To-do-list for this meeting: reading of Mariana's e-mail and files, and of literature mentioned during conf calls (editio, Emert, etc.).

General to-do-list: enhancing second draft ODD, enhancing text of proposal, have a look at Genetic Editions proposal.

We decided to put together a bibliography of literature on editing letters that will help writing our proposal.

All minutes from TEI conferences in TEI now online [http://www.tei-c.org/Activities/SIG/Correspondence/index.xml here].

=== Conf Call Dec. 18, 2013 ===

We closely dealt with the question, what information we want to encode within the new <correspDesc> element and what elements will be needed. Child elements of/information given within <correspDesc> will be: <sender>, <addressee>, <placeSender>, <placeAddressee>, <dateSender>, <dateAddressee>, Korrespondenzstelle, type of correspondence, bearer and method of message, information whether there is an envelope or not (description of envelope in <msDsc> and transcription in <body>).

What will not be encoded within <correspDesc> because it is not letter-specific: <incipit>, printed things like form fields or letterheads, <stamp> and postage stamps - all this information is encoded within <msDesc>.

There will be a short presentation of the work of the SIG Correspondence and especially the <correspDesc> task force at the meeting on technical interfaces in German digital editions of letters around 1800 at the Berlin-Brandenburg Academy of Sciences in Berlin on February 26th.

Next conf call will be on Jan. 8, 10AM.

=== Conf Call Nov. 26, 2013 ===

Second meeting of the task force. Main topic was bringing together correspondence specific metadata (that should be encoded within a new <correspDesc> - or otherwise called - element but not necessarily):
sender, addressee, place of sender, date of sending, place of addressee, date of receiving, type of correspondence (letter, postcard, etc.), incipit, envelope, context (previous/next letter), postmark, stamp, perhaps transmitter of the message and method of delivery.

We had a closer look at the DALF Preliminary P5 Proposal and the <dalf:letDesc> element as well as the <correspDesc> element used by [http://www.weber-gesamtausgabe.de Weber-Gesamtausgabe].
We dealt more closely with the problems of how and where to encode envelopes, the type of message, postmarks, etc. Seals are not specific for letters but for other manuscripts as well. Therefore, changing their encoding (in <sealDesc>) is not necessary.

Next steps: Peter starts reworking/extending the '[[SIG:Correspondence/ODD_work|second draft]]', Marcel turns the minutes of the SIG Correspondence meetings into TEI, and starts writing goal and background information, DALF and WEGA, development of this proposal, etc. Sabine starts putting together information on the letter specific metadata and their description, place, examples, etc. as well as building up a structure for our proposal.

Next conf call will be on Dec. 18, 10AM. At the face-to-face 'boot camp' on January 13-14 in Berlin, we will work on the customization ODD file.

=== Conf Call Nov. 6, 2013 ===

First meeting of the task force. We summed up the SIG meeting at Rome and made sure that we all shared (more or less) the same ideas about the goal of the task force. Had a look at the "[[SIG:Correspondence/ODD_work|second draft]]" from last year which we decided to take as a starting point for future work.

Furthermore we decided on GitHub as a central repository for carrying out the work on our proposal and envisioned a face2face meeting at the beginning of next year as sort of a "boot camp" (scheduled for Jan. 13/14 in Berlin).

Next conf call shall be on Nov. 26, 12PM were we will look more closely at DALF and try to narrow down the "correspondence specific meta data".

== Literature and previous work ==

* [http://ctb.kantl.be/project/dalf/P5/DALF_P5-p0.1.zip DALF Preliminary P5 Proposal]
* [[SIG:Correspondence/RequestForModule|Request for a correspondence module and a wrapper element for correspondence meta data]]
* Winfried Woesler: ''Richtlinienvorschläge für Briefkommentare'', in: Wissenschaftliche Briefeditionen und ihre Probleme. Editionswissenschaftliches Symposium, Berlin 1998, p. 87–96

== Meetings ==

=== Meeting June 17-18, 2014 ===
Two days of intense work on the proposal, mainly reworking and adding of prose description with encoding examples in the chapter "Implementation of the correspondence description":
* differentiation between sender and author
* differentiation between the intended and the actual (place of) addressee
* repeating of direct child elements of <correspDesc>
* use of <transmission> in contrast to the TEI element <channel>
* use of <context> with varying evaluations of the position within a correspondence
* text classification, classification schemes (and the lack thereof) and materiality aspects.

Adding of examples to formal specification of various elements.

Preparing proposal for handing in as feature request soon. All updates available at GitHub, with additional HTML page for easy reading.

=== Conf Call June 12, 2014 ===
The main part of this conf call was held with Stefan Dumont (BBAW) who set up the web service "correspSearch" that analyzes beacon files based on the task force's <correspDesc> format from several digital correspondence editions and thus providing the possibility for searching through meta data of these editions.

Discussion of information needed from participating digital editions/projects: responsible person (preferably with e-mail address, in <titleStmt>); name of the beacon file (in <titleStmt>); latest update (in <revisionDesc>); information on licensing (with URL etc., <publicationStmt>); bibliographic reference (<sourceDesc>, <bibl>).

There is also the question of how to handle duplicates, i.e. one letter in more than one participating digital edition and thus resulting in two entries. Especially in these cases, a correspSearch ID for each entry is desirable (referencing to them with @ref).

<correspClass> is not yet part of the web service but could be implemented.

The web service "correspSearch" will be developed further and soon be publicly available online in a beta version, with corresponding API.

=== Conf Call May 28, 2014 ===

It's been our fastest conf call ever! We reported on last weeks activities (not much, but some additions to the [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub repo]) and agreed on a f2f meeting on June 17/18 in Berlin. Next conf call is scheduled for June 12, 10 AM.

=== Conf Call May 20, 2014 ===

==== Reports on two conferences: ====
# Berlin: [https://www.literatur.hu-berlin.de/aktuelles_idl/konferenzen_tagungen_vortraege/ontologien/programm "Datenmodellierung in digitalen Briefeditionen und ihre interpretatorische Leistung. Ontologien, Textgenetik und Visualisierungsstrategien"]
Peter presented on "interoperability of letter collections" and touched on the work of the task force. A lot of people are planning (dreaming) of connecting letter collections.
# Vienna: [http://www.ogl.at/programm/aktuelles-programm/ Editorenkolloquium]
"The old world" – a strong bias against digital editions and only few letter projects presented at the conference. Nevertheless Marcel waved the correspDesc flag during his talk.

==== correspSearch ====
Stefan Dumont from the BBAW created a web service for querying correspDesc data. This web service will be presented as an open beta at the end of June. During his work on correspSearch he encountered several bugs and missing features in the CIF standard that need to be addressed now. (see next point)

==== proposed schema changes ====
* rename addressee to receiver? We decided not to change that right now but we will wait for the natives to chime in.
* CIF: @when-iso instead of @when: For the web service there is a strong need for standardized date formats. --> Yes, will implement
* CIF: clearly defined meta data with information about origin, person in charge, last change date etc. --> Yes, will implement
* CIF: shall @notBefore be required to have a counterpart @notAfter? --> No, rejected

==== Roadmap ====
* Next conf call on May 28, 10 AM
* f2f meeting on June 17/18 (date needs to be finalized)
* feature request due before next Council f2f, June 30
* correspSearch will go public at the end of June

=== Conf Call March 17, 2014 ===
Peter gave a short summary of the workshop “Digitising experiences of migration” (Mellon Centre for Migration Studies, Omagh, Northern Ireland, March 14-15) – and we discussed the difficulties with lacking authority-file-data for our Correspondence Interchange Format (CIF). Marcel (located at the Austrian National Library) will have a look at Europeana’s interchange format to find out whether it could be combined with the task force’s CIF; Peter will get in contact with the BBAW in order to create some sort of web service, which will facilitate for data interchange.
Roadmap: June 2014 TEI-Council in Oxford – proposal should be ready for feature request – October 2014: TEI-Meeting (SIG meeting and/or <correspDesc>-workshop)

=== Conf Call Feb. 18, 2014 ===
We discussed the <correspType> element, decided to change its name to <correspClass> (according to <textClass>). Then we dealt with the preparation of the presentation in Berlin, Feb. 26, 2014 (workshop: “Briefeditionen um 1800 – Schnittstellen finden und vernetzen”). To-dos: enhancing second draft ODD, enhancing text of proposal (theoretical considerations, preceeding work). Inform the communtiy via mailing list to get some feedback.

=== Presentation Feb. 02, 2014 ===

Short presentation of the element <correspDesc> (as developed so far) at workshop on editions of correspondence around 1800 at Berlin-Brandenburg Academy of Sciences in Berlin. The slides of the presentation (in German) are available [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/2014%2002%2026%20presentation.pdf?raw=true here] and at [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub].

Next conf call will be on March 17, 2014.

=== Conf Call Jan. 30, 2014 ===

Discussing new changes in schema (<correspDesc> now repeatable, <note> and @ref in <correspDesc> possible, probably new name for <ct:correspType> needed, etc.). Latest version of the proposal can be found on [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub]. Proposal fits well for encoding e-mails. Looking at real example of encoding a letter with our schema, discussing detailed structure and flat structure (CIF).

=== Meeting Jan. 13-14, 2014 ===

Meeting of task force in Berlin. We pushed forward the work on an ODD file for the correspondence module with the new element <correspDesc> (and several child elements). The result can be found at GitHub: [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/proposal.xml proposal.xml]. While the formal specification can already be considered alpha (i.e. you can build a schema and try it out), we are still behind enhancing the documentation with information on background, theoretical considerations, notes on implementation, etc.

Next conf call will be on Jan. 30 (09:30 CET), 2014.

=== Conf Call Jan. 8, 2014 ===

This conf call mainly dealt with the preparation of the face-to-face meeting in Berlin on Jan. 13-14.
To-do-list for this meeting: reading of Mariana's e-mail and files, and of literature mentioned during conf calls (editio, Emert, etc.).

General to-do-list: enhancing second draft ODD, enhancing text of proposal, have a look at Genetic Editions proposal.

We decided to put together a bibliography of literature on editing letters that will help writing our proposal.

All minutes from TEI conferences in TEI now online [http://www.tei-c.org/Activities/SIG/Correspondence/index.xml here].

=== Conf Call Dec. 18, 2013 ===

We closely dealt with the question, what information we want to encode within the new <correspDesc> element and what elements will be needed. Child elements of/information given within <correspDesc> will be: <sender>, <addressee>, <placeSender>, <placeAddressee>, <dateSender>, <dateAddressee>, Korrespondenzstelle, type of correspondence, bearer and method of message, information whether there is an envelope or not (description of envelope in <msDsc> and transcription in <body>).

What will not be encoded within <correspDesc> because it is not letter-specific: <incipit>, printed things like form fields or letterheads, <stamp> and postage stamps - all this information is encoded within <msDesc>.

There will be a short presentation of the work of the SIG Correspondence and especially the <correspDesc> task force at the meeting on technical interfaces in German digital editions of letters around 1800 at the Berlin-Brandenburg Academy of Sciences in Berlin on February 26th.

Next conf call will be on Jan. 8, 10AM.

=== Conf Call Nov. 26, 2013 ===

Second meeting of the task force. Main topic was bringing together correspondence specific metadata (that should be encoded within a new <correspDesc> - or otherwise called - element but not necessarily):
sender, addressee, place of sender, date of sending, place of addressee, date of receiving, type of correspondence (letter, postcard, etc.), incipit, envelope, context (previous/next letter), postmark, stamp, perhaps transmitter of the message and method of delivery.

We had a closer look at the DALF Preliminary P5 Proposal and the <dalf:letDesc> element as well as the <correspDesc> element used by [http://www.weber-gesamtausgabe.de Weber-Gesamtausgabe].
We dealt more closely with the problems of how and where to encode envelopes, the type of message, postmarks, etc. Seals are not specific for letters but for other manuscripts as well. Therefore, changing their encoding (in <sealDesc>) is not necessary.

Next steps: Peter starts reworking/extending the '[[SIG:Correspondence/ODD_work|second draft]]', Marcel turns the minutes of the SIG Correspondence meetings into TEI, and starts writing goal and background information, DALF and WEGA, development of this proposal, etc. Sabine starts putting together information on the letter specific metadata and their description, place, examples, etc. as well as building up a structure for our proposal.

Next conf call will be on Dec. 18, 10AM. At the face-to-face 'boot camp' on January 13-14 in Berlin, we will work on the customization ODD file.

=== Conf Call Nov. 6, 2013 ===

First meeting of the task force. We summed up the SIG meeting at Rome and made sure that we all shared (more or less) the same ideas about the goal of the task force. Had a look at the "[[SIG:Correspondence/ODD_work|second draft]]" from last year which we decided to take as a starting point for future work.

Furthermore we decided on GitHub as a central repository for carrying out the work on our proposal and envisioned a face2face meeting at the beginning of next year as sort of a "boot camp" (scheduled for Jan. 13/14 in Berlin).

Next conf call shall be on Nov. 26, 12PM were we will look more closely at DALF and try to narrow down the "correspondence specific meta data".

== Literature and previous work ==

* [http://ctb.kantl.be/project/dalf/P5/DALF_P5-p0.1.zip DALF Preliminary P5 Proposal]
* [[SIG:Correspondence/RequestForModule|Request for a correspondence module and a wrapper element for correspondence meta data]]
* Winfried Woesler: ''Richtlinienvorschläge für Briefkommentare'', in: Wissenschaftliche Briefeditionen und ihre Probleme. Editionswissenschaftliches Symposium, Berlin 1998, p. 87–96

SIG:Correspondence/task-force-correspDesc

2014-09-02T12:25:45Z

Illetschko Marcel: /* C) , //, , … */

<- back to [[SIG:Correspondence]]

= Task force "correspDesc" =

* '''Members''': Marcel Illetschko, Sabine Seifert, Peter Stadler
* "'''Pusher'''": Mariana Gomes

We will try to make our work as transparent and open as possible so others can chime in and contribute at every stage. Please feel free to make use of all the various comment/edit/share/fork functions or to contact us directly.

== Goal ==

Create a formal proposal for a <correspDesc> (or whatever name) element for approval by the TEI council as a new element of the TEI standard. This work shall be based on the "second draft for a correspondence module and a wrapper element for correspondence meta data" as it was started during the 2012 SIG meeting.

== Background ==

There have been several P4 projects with a dedicated correspondence schema (DALF probably being the renowned). While several correspondence tags (<postscript> etc.) are available from the TEI P5 standard, there is no specific way of dealing with correspondence meta data (e.g. sender, addressee) in the current TEI header. Since that's an impediment on the interoperability and interchange of these texts and since there are good practice models working with a <correspDesc>, the SIG Correspondence started to draft such a proposal during its 2012 meeting and now set up a task force for elaborating this draft.

== Repositories ==

https://github.com/TEI-Correspondence-SIG/correspDesc
This will be the main place for bringing together the proposal.

== Recent discussions ==

==== A) <ct:corresDesc> ====

'''''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!).

==== B) <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.

==== C) <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

== Meetings ==

=== Meeting June 17-18, 2014 ===
Two days of intense work on the proposal, mainly reworking and adding of prose description with encoding examples in the chapter "Implementation of the correspondence description":
* differentiation between sender and author
* differentiation between the intended and the actual (place of) addressee
* repeating of direct child elements of <correspDesc>
* use of <transmission> in contrast to the TEI element <channel>
* use of <context> with varying evaluations of the position within a correspondence
* text classification, classification schemes (and the lack thereof) and materiality aspects.

Adding of examples to formal specification of various elements.

Preparing proposal for handing in as feature request soon. All updates available at GitHub, with additional HTML page for easy reading.

=== Conf Call June 12, 2014 ===
The main part of this conf call was held with Stefan Dumont (BBAW) who set up the web service "correspSearch" that analyzes beacon files based on the task force's <correspDesc> format from several digital correspondence editions and thus providing the possibility for searching through meta data of these editions.

Discussion of information needed from participating digital editions/projects: responsible person (preferably with e-mail address, in <titleStmt>); name of the beacon file (in <titleStmt>); latest update (in <revisionDesc>); information on licensing (with URL etc., <publicationStmt>); bibliographic reference (<sourceDesc>, <bibl>).

There is also the question of how to handle duplicates, i.e. one letter in more than one participating digital edition and thus resulting in two entries. Especially in these cases, a correspSearch ID for each entry is desirable (referencing to them with @ref).

<correspClass> is not yet part of the web service but could be implemented.

The web service "correspSearch" will be developed further and soon be publicly available online in a beta version, with corresponding API.

=== Conf Call May 28, 2014 ===

It's been our fastest conf call ever! We reported on last weeks activities (not much, but some additions to the [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub repo]) and agreed on a f2f meeting on June 17/18 in Berlin. Next conf call is scheduled for June 12, 10 AM.

=== Conf Call May 20, 2014 ===

==== Reports on two conferences: ====
# Berlin: [https://www.literatur.hu-berlin.de/aktuelles_idl/konferenzen_tagungen_vortraege/ontologien/programm "Datenmodellierung in digitalen Briefeditionen und ihre interpretatorische Leistung. Ontologien, Textgenetik und Visualisierungsstrategien"]
Peter presented on "interoperability of letter collections" and touched on the work of the task force. A lot of people are planning (dreaming) of connecting letter collections.
# Vienna: [http://www.ogl.at/programm/aktuelles-programm/ Editorenkolloquium]
"The old world" – a strong bias against digital editions and only few letter projects presented at the conference. Nevertheless Marcel waved the correspDesc flag during his talk.

==== correspSearch ====
Stefan Dumont from the BBAW created a web service for querying correspDesc data. This web service will be presented as an open beta at the end of June. During his work on correspSearch he encountered several bugs and missing features in the CIF standard that need to be addressed now. (see next point)

==== proposed schema changes ====
* rename addressee to receiver? We decided not to change that right now but we will wait for the natives to chime in.
* CIF: @when-iso instead of @when: For the web service there is a strong need for standardized date formats. --> Yes, will implement
* CIF: clearly defined meta data with information about origin, person in charge, last change date etc. --> Yes, will implement
* CIF: shall @notBefore be required to have a counterpart @notAfter? --> No, rejected

==== Roadmap ====
* Next conf call on May 28, 10 AM
* f2f meeting on June 17/18 (date needs to be finalized)
* feature request due before next Council f2f, June 30
* correspSearch will go public at the end of June

=== Conf Call March 17, 2014 ===
Peter gave a short summary of the workshop “Digitising experiences of migration” (Mellon Centre for Migration Studies, Omagh, Northern Ireland, March 14-15) – and we discussed the difficulties with lacking authority-file-data for our Correspondence Interchange Format (CIF). Marcel (located at the Austrian National Library) will have a look at Europeana’s interchange format to find out whether it could be combined with the task force’s CIF; Peter will get in contact with the BBAW in order to create some sort of web service, which will facilitate for data interchange.
Roadmap: June 2014 TEI-Council in Oxford – proposal should be ready for feature request – October 2014: TEI-Meeting (SIG meeting and/or <correspDesc>-workshop)

=== Conf Call Feb. 18, 2014 ===
We discussed the <correspType> element, decided to change its name to <correspClass> (according to <textClass>). Then we dealt with the preparation of the presentation in Berlin, Feb. 26, 2014 (workshop: “Briefeditionen um 1800 – Schnittstellen finden und vernetzen”). To-dos: enhancing second draft ODD, enhancing text of proposal (theoretical considerations, preceeding work). Inform the communtiy via mailing list to get some feedback.

=== Presentation Feb. 02, 2014 ===

Short presentation of the element <correspDesc> (as developed so far) at workshop on editions of correspondence around 1800 at Berlin-Brandenburg Academy of Sciences in Berlin. The slides of the presentation (in German) are available [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/2014%2002%2026%20presentation.pdf?raw=true here] and at [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub].

Next conf call will be on March 17, 2014.

=== Conf Call Jan. 30, 2014 ===

Discussing new changes in schema (<correspDesc> now repeatable, <note> and @ref in <correspDesc> possible, probably new name for <ct:correspType> needed, etc.). Latest version of the proposal can be found on [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub]. Proposal fits well for encoding e-mails. Looking at real example of encoding a letter with our schema, discussing detailed structure and flat structure (CIF).

=== Meeting Jan. 13-14, 2014 ===

Meeting of task force in Berlin. We pushed forward the work on an ODD file for the correspondence module with the new element <correspDesc> (and several child elements). The result can be found at GitHub: [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/proposal.xml proposal.xml]. While the formal specification can already be considered alpha (i.e. you can build a schema and try it out), we are still behind enhancing the documentation with information on background, theoretical considerations, notes on implementation, etc.

Next conf call will be on Jan. 30 (09:30 CET), 2014.

=== Conf Call Jan. 8, 2014 ===

This conf call mainly dealt with the preparation of the face-to-face meeting in Berlin on Jan. 13-14.
To-do-list for this meeting: reading of Mariana's e-mail and files, and of literature mentioned during conf calls (editio, Emert, etc.).

General to-do-list: enhancing second draft ODD, enhancing text of proposal, have a look at Genetic Editions proposal.

We decided to put together a bibliography of literature on editing letters that will help writing our proposal.

All minutes from TEI conferences in TEI now online [http://www.tei-c.org/Activities/SIG/Correspondence/index.xml here].

=== Conf Call Dec. 18, 2013 ===

We closely dealt with the question, what information we want to encode within the new <correspDesc> element and what elements will be needed. Child elements of/information given within <correspDesc> will be: <sender>, <addressee>, <placeSender>, <placeAddressee>, <dateSender>, <dateAddressee>, Korrespondenzstelle, type of correspondence, bearer and method of message, information whether there is an envelope or not (description of envelope in <msDsc> and transcription in <body>).

What will not be encoded within <correspDesc> because it is not letter-specific: <incipit>, printed things like form fields or letterheads, <stamp> and postage stamps - all this information is encoded within <msDesc>.

There will be a short presentation of the work of the SIG Correspondence and especially the <correspDesc> task force at the meeting on technical interfaces in German digital editions of letters around 1800 at the Berlin-Brandenburg Academy of Sciences in Berlin on February 26th.

Next conf call will be on Jan. 8, 10AM.

=== Conf Call Nov. 26, 2013 ===

Second meeting of the task force. Main topic was bringing together correspondence specific metadata (that should be encoded within a new <correspDesc> - or otherwise called - element but not necessarily):
sender, addressee, place of sender, date of sending, place of addressee, date of receiving, type of correspondence (letter, postcard, etc.), incipit, envelope, context (previous/next letter), postmark, stamp, perhaps transmitter of the message and method of delivery.

We had a closer look at the DALF Preliminary P5 Proposal and the <dalf:letDesc> element as well as the <correspDesc> element used by [http://www.weber-gesamtausgabe.de Weber-Gesamtausgabe].
We dealt more closely with the problems of how and where to encode envelopes, the type of message, postmarks, etc. Seals are not specific for letters but for other manuscripts as well. Therefore, changing their encoding (in <sealDesc>) is not necessary.

Next steps: Peter starts reworking/extending the '[[SIG:Correspondence/ODD_work|second draft]]', Marcel turns the minutes of the SIG Correspondence meetings into TEI, and starts writing goal and background information, DALF and WEGA, development of this proposal, etc. Sabine starts putting together information on the letter specific metadata and their description, place, examples, etc. as well as building up a structure for our proposal.

Next conf call will be on Dec. 18, 10AM. At the face-to-face 'boot camp' on January 13-14 in Berlin, we will work on the customization ODD file.

=== Conf Call Nov. 6, 2013 ===

First meeting of the task force. We summed up the SIG meeting at Rome and made sure that we all shared (more or less) the same ideas about the goal of the task force. Had a look at the "[[SIG:Correspondence/ODD_work|second draft]]" from last year which we decided to take as a starting point for future work.

Furthermore we decided on GitHub as a central repository for carrying out the work on our proposal and envisioned a face2face meeting at the beginning of next year as sort of a "boot camp" (scheduled for Jan. 13/14 in Berlin).

Next conf call shall be on Nov. 26, 12PM were we will look more closely at DALF and try to narrow down the "correspondence specific meta data".

== Literature and previous work ==

* [http://ctb.kantl.be/project/dalf/P5/DALF_P5-p0.1.zip DALF Preliminary P5 Proposal]
* [[SIG:Correspondence/RequestForModule|Request for a correspondence module and a wrapper element for correspondence meta data]]
* Winfried Woesler: ''Richtlinienvorschläge für Briefkommentare'', in: Wissenschaftliche Briefeditionen und ihre Probleme. Editionswissenschaftliches Symposium, Berlin 1998, p. 87–96

== Meetings ==

=== Meeting June 17-18, 2014 ===
Two days of intense work on the proposal, mainly reworking and adding of prose description with encoding examples in the chapter "Implementation of the correspondence description":
* differentiation between sender and author
* differentiation between the intended and the actual (place of) addressee
* repeating of direct child elements of <correspDesc>
* use of <transmission> in contrast to the TEI element <channel>
* use of <context> with varying evaluations of the position within a correspondence
* text classification, classification schemes (and the lack thereof) and materiality aspects.

Adding of examples to formal specification of various elements.

Preparing proposal for handing in as feature request soon. All updates available at GitHub, with additional HTML page for easy reading.

=== Conf Call June 12, 2014 ===
The main part of this conf call was held with Stefan Dumont (BBAW) who set up the web service "correspSearch" that analyzes beacon files based on the task force's <correspDesc> format from several digital correspondence editions and thus providing the possibility for searching through meta data of these editions.

Discussion of information needed from participating digital editions/projects: responsible person (preferably with e-mail address, in <titleStmt>); name of the beacon file (in <titleStmt>); latest update (in <revisionDesc>); information on licensing (with URL etc., <publicationStmt>); bibliographic reference (<sourceDesc>, <bibl>).

There is also the question of how to handle duplicates, i.e. one letter in more than one participating digital edition and thus resulting in two entries. Especially in these cases, a correspSearch ID for each entry is desirable (referencing to them with @ref).

<correspClass> is not yet part of the web service but could be implemented.

The web service "correspSearch" will be developed further and soon be publicly available online in a beta version, with corresponding API.

=== Conf Call May 28, 2014 ===

It's been our fastest conf call ever! We reported on last weeks activities (not much, but some additions to the [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub repo]) and agreed on a f2f meeting on June 17/18 in Berlin. Next conf call is scheduled for June 12, 10 AM.

=== Conf Call May 20, 2014 ===

==== Reports on two conferences: ====
# Berlin: [https://www.literatur.hu-berlin.de/aktuelles_idl/konferenzen_tagungen_vortraege/ontologien/programm "Datenmodellierung in digitalen Briefeditionen und ihre interpretatorische Leistung. Ontologien, Textgenetik und Visualisierungsstrategien"]
Peter presented on "interoperability of letter collections" and touched on the work of the task force. A lot of people are planning (dreaming) of connecting letter collections.
# Vienna: [http://www.ogl.at/programm/aktuelles-programm/ Editorenkolloquium]
"The old world" – a strong bias against digital editions and only few letter projects presented at the conference. Nevertheless Marcel waved the correspDesc flag during his talk.

==== correspSearch ====
Stefan Dumont from the BBAW created a web service for querying correspDesc data. This web service will be presented as an open beta at the end of June. During his work on correspSearch he encountered several bugs and missing features in the CIF standard that need to be addressed now. (see next point)

==== proposed schema changes ====
* rename addressee to receiver? We decided not to change that right now but we will wait for the natives to chime in.
* CIF: @when-iso instead of @when: For the web service there is a strong need for standardized date formats. --> Yes, will implement
* CIF: clearly defined meta data with information about origin, person in charge, last change date etc. --> Yes, will implement
* CIF: shall @notBefore be required to have a counterpart @notAfter? --> No, rejected

==== Roadmap ====
* Next conf call on May 28, 10 AM
* f2f meeting on June 17/18 (date needs to be finalized)
* feature request due before next Council f2f, June 30
* correspSearch will go public at the end of June

=== Conf Call March 17, 2014 ===
Peter gave a short summary of the workshop “Digitising experiences of migration” (Mellon Centre for Migration Studies, Omagh, Northern Ireland, March 14-15) – and we discussed the difficulties with lacking authority-file-data for our Correspondence Interchange Format (CIF). Marcel (located at the Austrian National Library) will have a look at Europeana’s interchange format to find out whether it could be combined with the task force’s CIF; Peter will get in contact with the BBAW in order to create some sort of web service, which will facilitate for data interchange.
Roadmap: June 2014 TEI-Council in Oxford – proposal should be ready for feature request – October 2014: TEI-Meeting (SIG meeting and/or <correspDesc>-workshop)

=== Conf Call Feb. 18, 2014 ===
We discussed the <correspType> element, decided to change its name to <correspClass> (according to <textClass>). Then we dealt with the preparation of the presentation in Berlin, Feb. 26, 2014 (workshop: “Briefeditionen um 1800 – Schnittstellen finden und vernetzen”). To-dos: enhancing second draft ODD, enhancing text of proposal (theoretical considerations, preceeding work). Inform the communtiy via mailing list to get some feedback.

=== Presentation Feb. 02, 2014 ===

Short presentation of the element <correspDesc> (as developed so far) at workshop on editions of correspondence around 1800 at Berlin-Brandenburg Academy of Sciences in Berlin. The slides of the presentation (in German) are available [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/2014%2002%2026%20presentation.pdf?raw=true here] and at [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub].

Next conf call will be on March 17, 2014.

=== Conf Call Jan. 30, 2014 ===

Discussing new changes in schema (<correspDesc> now repeatable, <note> and @ref in <correspDesc> possible, probably new name for <ct:correspType> needed, etc.). Latest version of the proposal can be found on [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub]. Proposal fits well for encoding e-mails. Looking at real example of encoding a letter with our schema, discussing detailed structure and flat structure (CIF).

=== Meeting Jan. 13-14, 2014 ===

Meeting of task force in Berlin. We pushed forward the work on an ODD file for the correspondence module with the new element <correspDesc> (and several child elements). The result can be found at GitHub: [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/proposal.xml proposal.xml]. While the formal specification can already be considered alpha (i.e. you can build a schema and try it out), we are still behind enhancing the documentation with information on background, theoretical considerations, notes on implementation, etc.

Next conf call will be on Jan. 30 (09:30 CET), 2014.

=== Conf Call Jan. 8, 2014 ===

This conf call mainly dealt with the preparation of the face-to-face meeting in Berlin on Jan. 13-14.
To-do-list for this meeting: reading of Mariana's e-mail and files, and of literature mentioned during conf calls (editio, Emert, etc.).

General to-do-list: enhancing second draft ODD, enhancing text of proposal, have a look at Genetic Editions proposal.

We decided to put together a bibliography of literature on editing letters that will help writing our proposal.

All minutes from TEI conferences in TEI now online [http://www.tei-c.org/Activities/SIG/Correspondence/index.xml here].

=== Conf Call Dec. 18, 2013 ===

We closely dealt with the question, what information we want to encode within the new <correspDesc> element and what elements will be needed. Child elements of/information given within <correspDesc> will be: <sender>, <addressee>, <placeSender>, <placeAddressee>, <dateSender>, <dateAddressee>, Korrespondenzstelle, type of correspondence, bearer and method of message, information whether there is an envelope or not (description of envelope in <msDsc> and transcription in <body>).

What will not be encoded within <correspDesc> because it is not letter-specific: <incipit>, printed things like form fields or letterheads, <stamp> and postage stamps - all this information is encoded within <msDesc>.

There will be a short presentation of the work of the SIG Correspondence and especially the <correspDesc> task force at the meeting on technical interfaces in German digital editions of letters around 1800 at the Berlin-Brandenburg Academy of Sciences in Berlin on February 26th.

Next conf call will be on Jan. 8, 10AM.

=== Conf Call Nov. 26, 2013 ===

Second meeting of the task force. Main topic was bringing together correspondence specific metadata (that should be encoded within a new <correspDesc> - or otherwise called - element but not necessarily):
sender, addressee, place of sender, date of sending, place of addressee, date of receiving, type of correspondence (letter, postcard, etc.), incipit, envelope, context (previous/next letter), postmark, stamp, perhaps transmitter of the message and method of delivery.

We had a closer look at the DALF Preliminary P5 Proposal and the <dalf:letDesc> element as well as the <correspDesc> element used by [http://www.weber-gesamtausgabe.de Weber-Gesamtausgabe].
We dealt more closely with the problems of how and where to encode envelopes, the type of message, postmarks, etc. Seals are not specific for letters but for other manuscripts as well. Therefore, changing their encoding (in <sealDesc>) is not necessary.

Next steps: Peter starts reworking/extending the '[[SIG:Correspondence/ODD_work|second draft]]', Marcel turns the minutes of the SIG Correspondence meetings into TEI, and starts writing goal and background information, DALF and WEGA, development of this proposal, etc. Sabine starts putting together information on the letter specific metadata and their description, place, examples, etc. as well as building up a structure for our proposal.

Next conf call will be on Dec. 18, 10AM. At the face-to-face 'boot camp' on January 13-14 in Berlin, we will work on the customization ODD file.

=== Conf Call Nov. 6, 2013 ===

First meeting of the task force. We summed up the SIG meeting at Rome and made sure that we all shared (more or less) the same ideas about the goal of the task force. Had a look at the "[[SIG:Correspondence/ODD_work|second draft]]" from last year which we decided to take as a starting point for future work.

Furthermore we decided on GitHub as a central repository for carrying out the work on our proposal and envisioned a face2face meeting at the beginning of next year as sort of a "boot camp" (scheduled for Jan. 13/14 in Berlin).

Next conf call shall be on Nov. 26, 12PM were we will look more closely at DALF and try to narrow down the "correspondence specific meta data".

== Literature and previous work ==

* [http://ctb.kantl.be/project/dalf/P5/DALF_P5-p0.1.zip DALF Preliminary P5 Proposal]
* [[SIG:Correspondence/RequestForModule|Request for a correspondence module and a wrapper element for correspondence meta data]]
* Winfried Woesler: ''Richtlinienvorschläge für Briefkommentare'', in: Wissenschaftliche Briefeditionen und ihre Probleme. Editionswissenschaftliches Symposium, Berlin 1998, p. 87–96

SIG:Correspondence/task-force-correspDesc

2014-09-02T12:25:16Z

Illetschko Marcel: /* B) vs. */

<- back to [[SIG:Correspondence]]

= Task force "correspDesc" =

* '''Members''': Marcel Illetschko, Sabine Seifert, Peter Stadler
* "'''Pusher'''": Mariana Gomes

We will try to make our work as transparent and open as possible so others can chime in and contribute at every stage. Please feel free to make use of all the various comment/edit/share/fork functions or to contact us directly.

== Goal ==

Create a formal proposal for a <correspDesc> (or whatever name) element for approval by the TEI council as a new element of the TEI standard. This work shall be based on the "second draft for a correspondence module and a wrapper element for correspondence meta data" as it was started during the 2012 SIG meeting.

== Background ==

There have been several P4 projects with a dedicated correspondence schema (DALF probably being the renowned). While several correspondence tags (<postscript> etc.) are available from the TEI P5 standard, there is no specific way of dealing with correspondence meta data (e.g. sender, addressee) in the current TEI header. Since that's an impediment on the interoperability and interchange of these texts and since there are good practice models working with a <correspDesc>, the SIG Correspondence started to draft such a proposal during its 2012 meeting and now set up a task force for elaborating this draft.

== Repositories ==

https://github.com/TEI-Correspondence-SIG/correspDesc
This will be the main place for bringing together the proposal.

== Recent discussions ==

==== A) <ct:corresDesc> ====

'''''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!).

==== B) <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.

==== C) <sender>, <adressee>/<recipient>/<receiver>, <dateSender>, <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.“

==== D) <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.”

==== E) <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>.

==== F) <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."

==== G) 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.“

==== H) 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.

== Meetings ==

=== Meeting June 17-18, 2014 ===
Two days of intense work on the proposal, mainly reworking and adding of prose description with encoding examples in the chapter "Implementation of the correspondence description":
* differentiation between sender and author
* differentiation between the intended and the actual (place of) addressee
* repeating of direct child elements of <correspDesc>
* use of <transmission> in contrast to the TEI element <channel>
* use of <context> with varying evaluations of the position within a correspondence
* text classification, classification schemes (and the lack thereof) and materiality aspects.

Adding of examples to formal specification of various elements.

Preparing proposal for handing in as feature request soon. All updates available at GitHub, with additional HTML page for easy reading.

=== Conf Call June 12, 2014 ===
The main part of this conf call was held with Stefan Dumont (BBAW) who set up the web service "correspSearch" that analyzes beacon files based on the task force's <correspDesc> format from several digital correspondence editions and thus providing the possibility for searching through meta data of these editions.

Discussion of information needed from participating digital editions/projects: responsible person (preferably with e-mail address, in <titleStmt>); name of the beacon file (in <titleStmt>); latest update (in <revisionDesc>); information on licensing (with URL etc., <publicationStmt>); bibliographic reference (<sourceDesc>, <bibl>).

There is also the question of how to handle duplicates, i.e. one letter in more than one participating digital edition and thus resulting in two entries. Especially in these cases, a correspSearch ID for each entry is desirable (referencing to them with @ref).

<correspClass> is not yet part of the web service but could be implemented.

The web service "correspSearch" will be developed further and soon be publicly available online in a beta version, with corresponding API.

=== Conf Call May 28, 2014 ===

It's been our fastest conf call ever! We reported on last weeks activities (not much, but some additions to the [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub repo]) and agreed on a f2f meeting on June 17/18 in Berlin. Next conf call is scheduled for June 12, 10 AM.

=== Conf Call May 20, 2014 ===

==== Reports on two conferences: ====
# Berlin: [https://www.literatur.hu-berlin.de/aktuelles_idl/konferenzen_tagungen_vortraege/ontologien/programm "Datenmodellierung in digitalen Briefeditionen und ihre interpretatorische Leistung. Ontologien, Textgenetik und Visualisierungsstrategien"]
Peter presented on "interoperability of letter collections" and touched on the work of the task force. A lot of people are planning (dreaming) of connecting letter collections.
# Vienna: [http://www.ogl.at/programm/aktuelles-programm/ Editorenkolloquium]
"The old world" – a strong bias against digital editions and only few letter projects presented at the conference. Nevertheless Marcel waved the correspDesc flag during his talk.

==== correspSearch ====
Stefan Dumont from the BBAW created a web service for querying correspDesc data. This web service will be presented as an open beta at the end of June. During his work on correspSearch he encountered several bugs and missing features in the CIF standard that need to be addressed now. (see next point)

==== proposed schema changes ====
* rename addressee to receiver? We decided not to change that right now but we will wait for the natives to chime in.
* CIF: @when-iso instead of @when: For the web service there is a strong need for standardized date formats. --> Yes, will implement
* CIF: clearly defined meta data with information about origin, person in charge, last change date etc. --> Yes, will implement
* CIF: shall @notBefore be required to have a counterpart @notAfter? --> No, rejected

==== Roadmap ====
* Next conf call on May 28, 10 AM
* f2f meeting on June 17/18 (date needs to be finalized)
* feature request due before next Council f2f, June 30
* correspSearch will go public at the end of June

=== Conf Call March 17, 2014 ===
Peter gave a short summary of the workshop “Digitising experiences of migration” (Mellon Centre for Migration Studies, Omagh, Northern Ireland, March 14-15) – and we discussed the difficulties with lacking authority-file-data for our Correspondence Interchange Format (CIF). Marcel (located at the Austrian National Library) will have a look at Europeana’s interchange format to find out whether it could be combined with the task force’s CIF; Peter will get in contact with the BBAW in order to create some sort of web service, which will facilitate for data interchange.
Roadmap: June 2014 TEI-Council in Oxford – proposal should be ready for feature request – October 2014: TEI-Meeting (SIG meeting and/or <correspDesc>-workshop)

=== Conf Call Feb. 18, 2014 ===
We discussed the <correspType> element, decided to change its name to <correspClass> (according to <textClass>). Then we dealt with the preparation of the presentation in Berlin, Feb. 26, 2014 (workshop: “Briefeditionen um 1800 – Schnittstellen finden und vernetzen”). To-dos: enhancing second draft ODD, enhancing text of proposal (theoretical considerations, preceeding work). Inform the communtiy via mailing list to get some feedback.

=== Presentation Feb. 02, 2014 ===

Short presentation of the element <correspDesc> (as developed so far) at workshop on editions of correspondence around 1800 at Berlin-Brandenburg Academy of Sciences in Berlin. The slides of the presentation (in German) are available [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/2014%2002%2026%20presentation.pdf?raw=true here] and at [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub].

Next conf call will be on March 17, 2014.

=== Conf Call Jan. 30, 2014 ===

Discussing new changes in schema (<correspDesc> now repeatable, <note> and @ref in <correspDesc> possible, probably new name for <ct:correspType> needed, etc.). Latest version of the proposal can be found on [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub]. Proposal fits well for encoding e-mails. Looking at real example of encoding a letter with our schema, discussing detailed structure and flat structure (CIF).

=== Meeting Jan. 13-14, 2014 ===

Meeting of task force in Berlin. We pushed forward the work on an ODD file for the correspondence module with the new element <correspDesc> (and several child elements). The result can be found at GitHub: [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/proposal.xml proposal.xml]. While the formal specification can already be considered alpha (i.e. you can build a schema and try it out), we are still behind enhancing the documentation with information on background, theoretical considerations, notes on implementation, etc.

Next conf call will be on Jan. 30 (09:30 CET), 2014.

=== Conf Call Jan. 8, 2014 ===

This conf call mainly dealt with the preparation of the face-to-face meeting in Berlin on Jan. 13-14.
To-do-list for this meeting: reading of Mariana's e-mail and files, and of literature mentioned during conf calls (editio, Emert, etc.).

General to-do-list: enhancing second draft ODD, enhancing text of proposal, have a look at Genetic Editions proposal.

We decided to put together a bibliography of literature on editing letters that will help writing our proposal.

All minutes from TEI conferences in TEI now online [http://www.tei-c.org/Activities/SIG/Correspondence/index.xml here].

=== Conf Call Dec. 18, 2013 ===

We closely dealt with the question, what information we want to encode within the new <correspDesc> element and what elements will be needed. Child elements of/information given within <correspDesc> will be: <sender>, <addressee>, <placeSender>, <placeAddressee>, <dateSender>, <dateAddressee>, Korrespondenzstelle, type of correspondence, bearer and method of message, information whether there is an envelope or not (description of envelope in <msDsc> and transcription in <body>).

What will not be encoded within <correspDesc> because it is not letter-specific: <incipit>, printed things like form fields or letterheads, <stamp> and postage stamps - all this information is encoded within <msDesc>.

There will be a short presentation of the work of the SIG Correspondence and especially the <correspDesc> task force at the meeting on technical interfaces in German digital editions of letters around 1800 at the Berlin-Brandenburg Academy of Sciences in Berlin on February 26th.

Next conf call will be on Jan. 8, 10AM.

=== Conf Call Nov. 26, 2013 ===

Second meeting of the task force. Main topic was bringing together correspondence specific metadata (that should be encoded within a new <correspDesc> - or otherwise called - element but not necessarily):
sender, addressee, place of sender, date of sending, place of addressee, date of receiving, type of correspondence (letter, postcard, etc.), incipit, envelope, context (previous/next letter), postmark, stamp, perhaps transmitter of the message and method of delivery.

We had a closer look at the DALF Preliminary P5 Proposal and the <dalf:letDesc> element as well as the <correspDesc> element used by [http://www.weber-gesamtausgabe.de Weber-Gesamtausgabe].
We dealt more closely with the problems of how and where to encode envelopes, the type of message, postmarks, etc. Seals are not specific for letters but for other manuscripts as well. Therefore, changing their encoding (in <sealDesc>) is not necessary.

Next steps: Peter starts reworking/extending the '[[SIG:Correspondence/ODD_work|second draft]]', Marcel turns the minutes of the SIG Correspondence meetings into TEI, and starts writing goal and background information, DALF and WEGA, development of this proposal, etc. Sabine starts putting together information on the letter specific metadata and their description, place, examples, etc. as well as building up a structure for our proposal.

Next conf call will be on Dec. 18, 10AM. At the face-to-face 'boot camp' on January 13-14 in Berlin, we will work on the customization ODD file.

=== Conf Call Nov. 6, 2013 ===

First meeting of the task force. We summed up the SIG meeting at Rome and made sure that we all shared (more or less) the same ideas about the goal of the task force. Had a look at the "[[SIG:Correspondence/ODD_work|second draft]]" from last year which we decided to take as a starting point for future work.

Furthermore we decided on GitHub as a central repository for carrying out the work on our proposal and envisioned a face2face meeting at the beginning of next year as sort of a "boot camp" (scheduled for Jan. 13/14 in Berlin).

Next conf call shall be on Nov. 26, 12PM were we will look more closely at DALF and try to narrow down the "correspondence specific meta data".

== Literature and previous work ==

* [http://ctb.kantl.be/project/dalf/P5/DALF_P5-p0.1.zip DALF Preliminary P5 Proposal]
* [[SIG:Correspondence/RequestForModule|Request for a correspondence module and a wrapper element for correspondence meta data]]
* Winfried Woesler: ''Richtlinienvorschläge für Briefkommentare'', in: Wissenschaftliche Briefeditionen und ihre Probleme. Editionswissenschaftliches Symposium, Berlin 1998, p. 87–96

== Meetings ==

=== Meeting June 17-18, 2014 ===
Two days of intense work on the proposal, mainly reworking and adding of prose description with encoding examples in the chapter "Implementation of the correspondence description":
* differentiation between sender and author
* differentiation between the intended and the actual (place of) addressee
* repeating of direct child elements of <correspDesc>
* use of <transmission> in contrast to the TEI element <channel>
* use of <context> with varying evaluations of the position within a correspondence
* text classification, classification schemes (and the lack thereof) and materiality aspects.

Adding of examples to formal specification of various elements.

Preparing proposal for handing in as feature request soon. All updates available at GitHub, with additional HTML page for easy reading.

=== Conf Call June 12, 2014 ===
The main part of this conf call was held with Stefan Dumont (BBAW) who set up the web service "correspSearch" that analyzes beacon files based on the task force's <correspDesc> format from several digital correspondence editions and thus providing the possibility for searching through meta data of these editions.

Discussion of information needed from participating digital editions/projects: responsible person (preferably with e-mail address, in <titleStmt>); name of the beacon file (in <titleStmt>); latest update (in <revisionDesc>); information on licensing (with URL etc., <publicationStmt>); bibliographic reference (<sourceDesc>, <bibl>).

There is also the question of how to handle duplicates, i.e. one letter in more than one participating digital edition and thus resulting in two entries. Especially in these cases, a correspSearch ID for each entry is desirable (referencing to them with @ref).

<correspClass> is not yet part of the web service but could be implemented.

The web service "correspSearch" will be developed further and soon be publicly available online in a beta version, with corresponding API.

=== Conf Call May 28, 2014 ===

It's been our fastest conf call ever! We reported on last weeks activities (not much, but some additions to the [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub repo]) and agreed on a f2f meeting on June 17/18 in Berlin. Next conf call is scheduled for June 12, 10 AM.

=== Conf Call May 20, 2014 ===

==== Reports on two conferences: ====
# Berlin: [https://www.literatur.hu-berlin.de/aktuelles_idl/konferenzen_tagungen_vortraege/ontologien/programm "Datenmodellierung in digitalen Briefeditionen und ihre interpretatorische Leistung. Ontologien, Textgenetik und Visualisierungsstrategien"]
Peter presented on "interoperability of letter collections" and touched on the work of the task force. A lot of people are planning (dreaming) of connecting letter collections.
# Vienna: [http://www.ogl.at/programm/aktuelles-programm/ Editorenkolloquium]
"The old world" – a strong bias against digital editions and only few letter projects presented at the conference. Nevertheless Marcel waved the correspDesc flag during his talk.

==== correspSearch ====
Stefan Dumont from the BBAW created a web service for querying correspDesc data. This web service will be presented as an open beta at the end of June. During his work on correspSearch he encountered several bugs and missing features in the CIF standard that need to be addressed now. (see next point)

==== proposed schema changes ====
* rename addressee to receiver? We decided not to change that right now but we will wait for the natives to chime in.
* CIF: @when-iso instead of @when: For the web service there is a strong need for standardized date formats. --> Yes, will implement
* CIF: clearly defined meta data with information about origin, person in charge, last change date etc. --> Yes, will implement
* CIF: shall @notBefore be required to have a counterpart @notAfter? --> No, rejected

==== Roadmap ====
* Next conf call on May 28, 10 AM
* f2f meeting on June 17/18 (date needs to be finalized)
* feature request due before next Council f2f, June 30
* correspSearch will go public at the end of June

=== Conf Call March 17, 2014 ===
Peter gave a short summary of the workshop “Digitising experiences of migration” (Mellon Centre for Migration Studies, Omagh, Northern Ireland, March 14-15) – and we discussed the difficulties with lacking authority-file-data for our Correspondence Interchange Format (CIF). Marcel (located at the Austrian National Library) will have a look at Europeana’s interchange format to find out whether it could be combined with the task force’s CIF; Peter will get in contact with the BBAW in order to create some sort of web service, which will facilitate for data interchange.
Roadmap: June 2014 TEI-Council in Oxford – proposal should be ready for feature request – October 2014: TEI-Meeting (SIG meeting and/or <correspDesc>-workshop)

=== Conf Call Feb. 18, 2014 ===
We discussed the <correspType> element, decided to change its name to <correspClass> (according to <textClass>). Then we dealt with the preparation of the presentation in Berlin, Feb. 26, 2014 (workshop: “Briefeditionen um 1800 – Schnittstellen finden und vernetzen”). To-dos: enhancing second draft ODD, enhancing text of proposal (theoretical considerations, preceeding work). Inform the communtiy via mailing list to get some feedback.

=== Presentation Feb. 02, 2014 ===

Short presentation of the element <correspDesc> (as developed so far) at workshop on editions of correspondence around 1800 at Berlin-Brandenburg Academy of Sciences in Berlin. The slides of the presentation (in German) are available [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/2014%2002%2026%20presentation.pdf?raw=true here] and at [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub].

Next conf call will be on March 17, 2014.

=== Conf Call Jan. 30, 2014 ===

Discussing new changes in schema (<correspDesc> now repeatable, <note> and @ref in <correspDesc> possible, probably new name for <ct:correspType> needed, etc.). Latest version of the proposal can be found on [https://github.com/TEI-Correspondence-SIG/correspDesc GitHub]. Proposal fits well for encoding e-mails. Looking at real example of encoding a letter with our schema, discussing detailed structure and flat structure (CIF).

=== Meeting Jan. 13-14, 2014 ===

Meeting of task force in Berlin. We pushed forward the work on an ODD file for the correspondence module with the new element <correspDesc> (and several child elements). The result can be found at GitHub: [https://github.com/TEI-Correspondence-SIG/correspDesc/blob/master/proposal.xml proposal.xml]. While the formal specification can already be considered alpha (i.e. you can build a schema and try it out), we are still behind enhancing the documentation with information on background, theoretical considerations, notes on implementation, etc.

Next conf call will be on Jan. 30 (09:30 CET), 2014.

=== Conf Call Jan. 8, 2014 ===

This conf call mainly dealt with the preparation of the face-to-face meeting in Berlin on Jan. 13-14.
To-do-list for this meeting: reading of Mariana's e-mail and files, and of literature mentioned during conf calls (editio, Emert, etc.).

General to-do-list: enhancing second draft ODD, enhancing text of proposal, have a look at Genetic Editions proposal.

We decided to put together a bibliography of literature on editing letters that will help writing our proposal.

All minutes from TEI conferences in TEI now online [http://www.tei-c.org/Activities/SIG/Correspondence/index.xml here].

=== Conf Call Dec. 18, 2013 ===

We closely dealt with the question, what information we want to encode within the new <correspDesc> element and what elements will be needed. Child elements of/information given within <correspDesc> will be: <sender>, <addressee>, <placeSender>, <placeAddressee>, <dateSender>, <dateAddressee>, Korrespondenzstelle, type of correspondence, bearer and method of message, information whether there is an envelope or not (description of envelope in <msDsc> and transcription in <body>).

What will not be encoded within <correspDesc> because it is not letter-specific: <incipit>, printed things like form fields or letterheads, <stamp> and postage stamps - all this information is encoded within <msDesc>.

There will be a short presentation of the work of the SIG Correspondence and especially the <correspDesc> task force at the meeting on technical interfaces in German digital editions of letters around 1800 at the Berlin-Brandenburg Academy of Sciences in Berlin on February 26th.

Next conf call will be on Jan. 8, 10AM.

=== Conf Call Nov. 26, 2013 ===

Second meeting of the task force. Main topic was bringing together correspondence specific metadata (that should be encoded within a new <correspDesc> - or otherwise called - element but not necessarily):
sender, addressee, place of sender, date of sending, place of addressee, date of receiving, type of correspondence (letter, postcard, etc.), incipit, envelope, context (previous/next letter), postmark, stamp, perhaps transmitter of the message and method of delivery.

We had a closer look at the DALF Preliminary P5 Proposal and the <dalf:letDesc> element as well as the <correspDesc> element used by [http://www.weber-gesamtausgabe.de Weber-Gesamtausgabe].
We dealt more closely with the problems of how and where to encode envelopes, the type of message, postmarks, etc. Seals are not specific for letters but for other manuscripts as well. Therefore, changing their encoding (in <sealDesc>) is not necessary.

Next steps: Peter starts reworking/extending the '[[SIG:Correspondence/ODD_work|second draft]]', Marcel turns the minutes of the SIG Correspondence meetings into TEI, and starts writing goal and background information, DALF and WEGA, development of this proposal, etc. Sabine starts putting together information on the letter specific metadata and their description, place, examples, etc. as well as building up a structure for our proposal.

Next conf call will be on Dec. 18, 10AM. At the face-to-face 'boot camp' on January 13-14 in Berlin, we will work on the customization ODD file.

=== Conf Call Nov. 6, 2013 ===

First meeting of the task force. We summed up the SIG meeting at Rome and made sure that we all shared (more or less) the same ideas about the goal of the task force. Had a look at the "[[SIG:Correspondence/ODD_work|second draft]]" from last year which we decided to take as a starting point for future work.

Furthermore we decided on GitHub as a central repository for carrying out the work on our proposal and envisioned a face2face meeting at the beginning of next year as sort of a "boot camp" (scheduled for Jan. 13/14 in Berlin).

Next conf call shall be on Nov. 26, 12PM were we will look more closely at DALF and try to narrow down the "correspondence specific meta data".

== Literature and previous work ==

* [http://ctb.kantl.be/project/dalf/P5/DALF_P5-p0.1.zip DALF Preliminary P5 Proposal]
* [[SIG:Correspondence/RequestForModule|Request for a correspondence module and a wrapper element for correspondence meta data]]
* Winfried Woesler: ''Richtlinienvorschläge für Briefkommentare'', in: Wissenschaftliche Briefeditionen und ihre Probleme. Editionswissenschaftliches Symposium, Berlin 1998, p. 87–96