[tei-council] correspdesc musings

Lou Burnard lou.burnard at retired.ox.ac.uk
Fri Aug 1 07:15:17 EDT 2014


I finally got round to reading the correspdesc proposal carefully last 
night. Here are my initial thoughts, which I hope are useful, even if 
they reiterate questions the SIG has already considered.

If both WEGA and DALF independently have found it necessary to invent an 
additional element,  trying to harmonize their proposals and add the 
results into mainstream TEI must be A Good Thing. So I agree with the 
general idea that we need something somewhere in the header to record 
metadata concerning the transmission of documents like letters, 
postcards, email, etc. The devil is in the detail.

Here are some randomly organized questions:

1. 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?)

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

3. 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?

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

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

6. The place a letter is actually sent from (as witnessed by the 
postmark, or other evidence) may be different from the place the 
sender/s say it is sent from. (We've all written postcards to send home, 
and forgotten to post them!). How would you handle that.

7. I dont think @type and @subtype are strong enough to handle the full 
complexity of information one might want to record under 
<ct:transmission> -- this whole area of the proposal needs more 
elaboration I think. It might also be useful in this context to look at 
the work of the CMC sig, as I think I mentioned before.

8. 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?

9. 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?

Oooh, I see James has got his reactions in already, so I will pause here 
and see if we agree on anything...











More information about the tei-council mailing list