Re: correspondence encoding problems: letter headings

Ron— Glad the TEI Header idea is useful! I like the <fw> element best so far as a solution for handling the letterhead inline, but I hope (for ease of handling a large project) that <supportDesc> or <layoutDesc> is deemed an optimal solution. I find myself increasingly thinking about how we deal with the evaluation of how much of a physical document and its supporting materials: Of course these things matter to record, but to follow them in “sequence” poses interesting semantic questions about writing and reading order, and whether we’re encoding primarily the physical details of a document or the communication it facilitates. Always a thorny (and interesting) question of course!

Elisa
-- 
Elisa Beshero-Bondar, PhD
Director, Center for the Digital Text | Associate Professor of English
University of Pittsburgh at Greensburg | Humanities Division
150 Finoli Drive
Greensburg, PA  15601  USA
E-mail: [email protected] <mailto:[email protected]>
Development site: http://newtfire.org <http://newtfire.org/>






> On Feb 23, 2017, at 9:03 AM, Ron Van den Branden <[email protected]> wrote:
> 
> Hi Elisa,
> 
> Thanks for your suggestion! I'm very much aware of the tension between transcription of logical units vs diplomatic "accidentals", this issue touches upon. We're still shaping the encoding guidelines for this project, and I'm not sure how desirable (and (resource-)wise) it will be to really transcribe the letterhead information in place for a couple of thousand letters. Still, if the project partners think it will be important to include them with the transcription, it would be comfortable to have a solution available.
> 
> I fully agree that abstracting this information into a meta-description in the header makes much sense, I guess <supportDesc> or <layoutDesc> would be suitable places.
> 
> Best,
> 
> Ron
> 
> On 23/02/2017 13:02, Elisa wrote:
>> Dear Ron (and Paul and Peter),
>> The letters I work on aren't on letterhead, but in my university life I am often having to prepare a formal letter to be sent on the stuff, which usually involves a little awareness of spacing on the page and some sense that the printing on letterhead contributes (semantically) to the authority of the communication. I can understand then why you might want to encode the printed letterhead "inline", and perhaps there is something more meaningful in your project than the official institutional ethos afforded by specially printed paper. But I think I would be drawn to including the letterhead information and description much the way we currently handle postmarks, wax seals, and watermarks in my (19th-c.) Digital Mitford project, and that is by tucking the details in the TEI header in the supportDesc, as information about the supporting material on which the document is printed that tells us about the paper and resources used (literally) to *support* the document. I think much would depend on how incidental or semantically important the letterhead content is in the project you're developing, and I just wanted to trot supportDesc out as an option to consider. 
>> 
>> I'm refraining from indicating exactly where in the supportDesc the rendering of letterhead contents might go because I've never coded letterhead before and I'd need to spend a lot of time meditating over the Guidelines to work it out, but my tendency would be to find a way to encode the letterhead such that it doesn't seem part of the semantic flow of the letter's contents. Treating it as a figure makes sense, but how literally does the encoding need to mimic the physical page layout? 
>> 
>> Cheers,
>> Elisa
>> 
>