LISTSERV mailing list manager LISTSERV 16.5

Help for TEI-CORRESP-SIG Archives


TEI-CORRESP-SIG Archives

TEI-CORRESP-SIG Archives


TEI-CORRESP-SIG@LISTSERV.BROWN.EDU


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

TEI-CORRESP-SIG Home

TEI-CORRESP-SIG Home

TEI-CORRESP-SIG  November 2014

TEI-CORRESP-SIG November 2014

Subject:

Re: revised correspDesc proposal

From:

Peter Stadler <[log in to unmask]>

Reply-To:

Peter Stadler <[log in to unmask]>

Date:

Wed, 12 Nov 2014 20:35:48 +0100

Content-Type:

multipart/signed

Parts/Attachments:

Parts/Attachments

text/plain (106 lines) , signature.asc (106 lines)

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 <[log in to unmask]>:

> 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 <[log in to unmask]> 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
>> [log in to unmask]
> 


Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

January 2019
December 2018
November 2018
September 2018
August 2017
May 2017
February 2017
November 2016
September 2016
August 2016
January 2016
December 2015
November 2015
October 2015
September 2015
March 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
July 2013
June 2013
January 2013
December 2012
November 2012
August 2012
May 2012
April 2012
March 2012
February 2012
December 2011
November 2011
October 2011
July 2011
June 2011
May 2011
December 2010
November 2010
October 2010
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
August 2008
July 2008

ATOM RSS1 RSS2



LISTSERV.BROWN.EDU

CataList Email List Search Powered by the LISTSERV Email List Manager