SIG:Correspondence/task-force-correspDesc

From TEIWiki
Revision as of 16:32, 2 September 2014 by Illetschko Marcel (talk | contribs) (→‎Recent discussion)
Jump to navigation Jump to search

<- 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 [[1]] - 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 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:

  1. Berlin: "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.

  1. Vienna: 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 here and at 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 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: 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 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 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 '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 "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

Retrieved from "https://wiki.tei-c.org/index.php?title=SIG:Correspondence/task-force-correspDesc&oldid=13714"