[tei-council] [TEI-CORRESP-SIG] revised correspDesc proposal
Peter Stadler
stadler at edirom.de
Wed Nov 12 14:35:48 EST 2014
I *hope* it’s just a matter of naming.
The current naming (confusion) resulted from two strands being merged here:
1. The making-generic of the formerly known <addressee> and <sender> as <participant> (as proposed by Martin)
2. Using TEI standard elements for names, places and dates and wrap those within a super element (as proposed by Syd)
So, what <participant> *means* to be is the left/right side of our sender-message-receiver model which are determined not only by agents, but also by places and dates.
Best
Peter
Am 12.11.2014 um 20:14 schrieb Lou Burnard <lou.burnard at RETIRED.OX.AC.UK>:
> I think that Andrew makes very good points here.
>
> When the term "participant" is used in other parts of the Guidelines (for example in particDesc) it is always with reference to a human participant or a group acting as one. But (unless I misunderstand it completely) the two children of <correspDesc> are intended to describe the "from" and the "to" of the act of communication, two abstractions each of which may correspond (ha ha) with one or more or no human agents at all. Certainly when I get a letter from an automated reply system or from the Inland Revenue, there's no human agent involved!
>
> It is only a matter of naming the elements, of course: the intended function and structure is clear and (I think) correct. But giving things the right name is by no means a simple task...
>
>
> On 12/11/14 18:53, Andrew Jewell wrote:
>> Dear all:
>>
>> Thanks to Peter and his group for moving forward with the proposal--I think it is shaping up nicely.
>>
>> I have one question, likely borne out of my ignorance of the conversations surrounding this proposal: is it logical to make place and date information children of <particpant>? That is, it seems like the element <participant> is about a human participant, and the children are really about the event of sending and receiving the correspondence (that is, a person doesn't have a date or a place, the action of sending a letter does). Perhaps this issue occurs to me only because of the definition of the word (rather than the element) "participant." However, I wonder if this model is evolving away from people as the core elements (ie, sender and addressee) and toward the events as the core elements. If so, one might imagine replacing <particpant type="sender"> and <participant type="receiver"> with something like this:
>>
>> <profileDesc>
>> <ct:correspDesc>
>> <ct:send>
>> <persName>Adelbert von Chamisso</persName>
>> <placeName>Vertus</placeName>
>> <date when="1807-01-29">29 January 1807</date>
>> </ct:send>
>> <ct:receive>
>> <persName>Louis de La Foye</persName>
>> <placeName>Caen</placeName>
>> </ct:receive>
>> </ct:correspDesc>
>> </profileDesc>
>>
>> I suppose someone will say these two elements do not properly contain all the available actions or events related to correspondence. OK, then also include <ct:action> with @type values that can meet specific needs.
>>
>> Just my thoughts,
>> Andy Jewell
>>
>> On Wed, Nov 12, 2014 at 11:50 AM, Peter Stadler <stadler at edirom.de> wrote:
>> Dear all,
>>
>> the next Council meeting is approaching and so we duly revised our proposal according to the latest comments.
>> We also (re)structured the GitHub repository a little bit, so you’ll find the latest
>>
>> * ODD file at
>> https://raw.githubusercontent.com/TEI-Correspondence-SIG/correspDesc/master/odd/proposal.xml
>> * RNG file at
>> https://raw.githubusercontent.com/TEI-Correspondence-SIG/correspDesc/master/schema/proposal.rng
>> * HTML documentation at
>> https://raw.githubusercontent.com/TEI-Correspondence-SIG/correspDesc/master/doc/proposal.html
>>
>> Changes include:
>> * moved correspDesc from sourceDesc to profileDesc
>> * merged sender & addressee into participant
>> * subsumed names, places and dates of sending/receiving under the new <participant>
>> * renamed context to correspContext (still not completely satisfying …)
>> * removed everything else, especially <transmission>. This is purely pragmatic while we are trying to focus on fewer issues now and add features subsequently.
>>
>> A (minimal) sample encoding may now look like:
>> <profileDesc>
>> <ct:correspDesc>
>> <ct:participant role="sender">
>> <persName>Adelbert von Chamisso</persName>
>> <placeName>Vertus</placeName>
>> <date when="1807-01-29">29 January 1807</date>
>> </ct:participant>
>> <ct:participant role="recipient">
>> <persName>Louis de La Foye</persName>
>> <placeName>Caen</placeName>
>> </ct:participant>
>> </ct:correspDesc>
>> </profileDesc>
>>
>> Open issues:
>> * Do we need a wrapper element for correspDesc (and/or should it be renamed) in analogy to settingDesc/setting? This came up during a conf call with some Council members. I’m still not convinced and there are various counter examples …
>> * When there are several senders, how to encode the date of sending? Our proposal considers every agent a participant on its own, so it’s not permitted to collect all names under one <participant>. But, do we need to encode the date (and place) on every <participant> then? That’d be very inconvenient.
>>
>> Any comments highly appreciated!
>>
>> Best
>> Peter
>>
>>
>>
>>
>> --
>> Andrew Jewell, Ph.D.
>> Associate Professor, University Libraries
>> co-editor, Scholarly Editing: The Annual of the Association for Documentary Editing (www.scholarlyediting.org)
>> Editor, Willa Cather Archive (http://cather.unl.edu)
>> 203 Love Library
>> University of Nebraska-Lincoln
>> Lincoln, NE 68588
>> 402.472.5266
>> ajewell2 at unl.edu
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20141112/1d7e85ac/attachment.bin
More information about the tei-council
mailing list