[tei-council] correspDesc proposal: some feedback.

[James Cummings]

Since we are all tasked with providing feedback on the 
correspDesc proposals
http://www.tei-c.org/Activities/Council/Meetings/tcm60.xml#Correspondence
by 1 august.

Here are my brief thoughts, some of which we discussed at the 
face to face meeting.

I would separate discussion of correspDesc for detailed data 
capture and have a later customisation of this for an interchange 
format.  I think the interchange format is a good idea, but 
doesn't need to muddy the water for initial proposals to change 
the TEI. (A question is whether this interchange format should 
also be documented in the guidelines or not. I'm undecided about 
that.)

As discussed at the face to face, a number of the proposed 
elements are very similar to existing TEI elements. I do feel 
Council should resist the addition of new elements where not 
necessary to stop overall bloat of the TEI. This does not mean we 
shouldn't add new elements, but just that the case for them needs 
to be clearly made, especially when existing elements might be 
used, or modified to include new uses.

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">
<ct:correspClass> = <keywords>  (using inside <ct:correspDesc> 
gives heirarchy to know it is relating to correspondence.)

<ct:correspDesc> – This generally makes sense as an enclosing 
element. Having option for model.pLike+ makes sense and is in 
keeping with general TE structured vs unstructured descriptions.

<ct:transmission> – seems generally reasonable to me but I worry 
isn't sophisicated enough. 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 in 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  –  so this might benefit from more structure.

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

Those are the thoughts that occurred to me while rereading the 
proposal in github.

-James

-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford