[tei-council] correspdesc musings

[Peter Stadler]

Am 21.08.2014 um 17:52 schrieb Lou Burnard <lou.burnard at RETIRED.OX.AC.UK>:

> On 21/08/14 16:45, Martin Holmes wrote:
>> On 14-08-21 08:37 AM, Lou Burnard wrote:
>>> I thought we'd agreed that the Council would continue to discuss this
>>> proposal on the Council list?
>> The problem is that we're trying to interact with members of the SIG who
>> are not on the Council list. I don't see how we can conduct this on the
>> Council list if we want their input.
> 
> The council list is just as accessible to them as the SIG list is to 
> (non-sig-subscribed) Council members, surely?
Yes, true. Nevertheless there are currently 105(!) subscribers to the TEI-CORRESP-SIG list and I hope someone will find the reply button.
Having emails pushed to those 105 people increases this possibility rather wanting them to pull from the Council list. 

>> Something interesting is emerging, I think, from the recent discussion:
>> the SIG group seem (to me) to perceive the proposed corresp stuff as a
>> little island of specialized elements and attributes which is not really
>> intended to be part of the larger TEI infrastructure.
Hmm, how is a TEI module (that’s what we are proposing) not part of the larger TEI infrastructure?

> That's not my reading of the discussion at all. They want specialised 
> elements which *can* fit into the TEI framework, just like everyone else.
Yes, we propose specialised elements for the encoding of one act of correspondence (mediated communication)

>>  That would
>> certainly mean that it could be clean, tight and simple -- dedicated
>> elements for a few specific purposes such as <sender> and <addressee>.
>> My instinct is to look for ways to generalize these requirements so that
>> any new elements or attributes we create might be useful in other
>> contexts, but that necessarily involves undermining that simple clarity
>> (I would replace <sender> and <recipient> with a generic <participant
>> role="something">, which could be useful elsewhere, but Peter (for
>> instance) is opposed to this.
I really don’t care about the tag names. But yes, my idea is to have a very (semantically clear and) constrained set of header elements for the description of correspondence. <participant role="something“> would be an intermediate to <name role="something“>, am I right? And I wonder if there was a concrete use case for that intermediate?
I hope I do not sound to harsh — I do not try to oppose something but try to explain our proposal (the guiding concepts). So, if some concepts can be abstracted from our proposal, that’s great but I can’t see that at the moment.

> We have an element <particDesc> of course which tends to make me prefer 
> the notion of a generic participant element like you. However, I think 
> you are somewhat misrepresenting Peter's argument too : his notion of 
> "sender" and "recipient" seems to be tied closely to the notion of 
> "transmission", so it's not the participant, but what the participant 
> does which he wants to encode.
Yes, thank you.

> 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.
Well, I’d say it depends on your editorial principles ;-)
If you were interested in the factual place, you’d encode that.
If you were interested in the narrative place, you’d encode that.
If you were interested in both, you’d encode two placeSender with different @type


I wonder whether it would be nice (well, it would be nice!) if some Council members would be interested in a conf call with the correspDesc task force? We already had a chat with Syd but it might be good to have some sort of a breakout group to discuss these things orally? What do you think? Any volunteers? End of next week could be a feasible date?!

Best
Peter


-------------- 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/20140822/e0c3cd7c/attachment.bin