Missing documentation: Additional for handList/hand

[gucl-mu]

The identification of scribes, scribe hands and scribe profiles is a central point in the evaluation of manuscripts. All scribes identified in a manuscript can therefore be deposited in <handList> as <hand> in combination with the writing material chosen by the respective scribe.

<handList>
    <hand medium="black ink">Arnold Schönberg</hand>
    <hand medium="pencil">Alban Berg</hand>
</handList>

By means of @resp, @corresp and @auth.uri, the scribes as well as the editors responsible for their identification can be linked. In many cases scribes are unknown, so it is recommended to consider a system that can be used to distinguish between different unknown scribes. For example, @class can be used to indicate different qualities such as annotations, revisions, lyrics or corrections.
To record shift of hands within the manuscript, you can use <handShift> and <handNote> (see 11.2.4.3 Substitutions, Restorations, and Handshifts) and link to the respective <hand> in the MEIHeader via @hand.

[gucl-mu]

#18

[riedde]

Thanks for you proposal. I like it and have just two small comments:

I would give <hand> an @xml:id in the example, because you talk about linking in the last sentence.

By means of @resp, @corresp and @auth.uri, the scribes as well as the editors responsible for their identification can be linked. In many cases scribes are unknown, so it is recommended to consider a system that can be used to distinguish between different unknown scribes. For example, @Class can be used to indicate different qualities such as annotations, revisions, lyrics or corrections.

Would it be helpful to give a short example here? This could also be a best practice (suggestion) so an example could clarify the use of @resp and @auth.uri.

[ahankinson]

It's likely you don't want to encode personal names directly within the <hand> element itself. That's what the <persName> element is for.

TEI has quite robust support for this. If the IG wants to re-model <hand>, I would suggest adopting the TEI model and methods instead of creating a new one.

[ahankinson]

See also, for examples:

<handDesc> in the Fihrist MSS catalogue: https://github.com/fihristorg/fihrist-mss/search?q=handDesc

<handDesc> in the Bodleian Medieval MSS catalogue: https://github.com/bodleian/medieval-mss/search?p=1&q=handDesc

[riedde]

@ahankinson I think this is not an issue about remodelling but about exploring the element and introducing a description to the guidelines.

[ahankinson]

I think the TEI examples can help with this. For example, I don't think <hand> is meant to identify the person who wrote it; rather it is to describe the 'hand' itself. In this case, the example in the first comment is not correct; perhaps it should be more like:

<handList>
    <hand medium="black ink">Principal text in neat manuscript by <persName>Arnold Schönberg</persName>, written in black ink.</hand>
    <hand medium="pencil">Additional marginal annotations in pencil by <persName>Alban Berg</persName></hand>
</handList>

[gucl-mu]

Thank you for your input. So that something is not lost in translation: You suggest the following:

<hand medium="black ink">
       <persName>Arnold Schönberg</persName
</hand>

To be honest, that seems unnecessarily complicated to me. Why should another layer be needed for this information? Then you could also omit <hand> and just use <persName>. The only difference is then @medium.
But maybe my understanding of <handList> is not correct, I thought it was a list with the name of the scribe and the writing medium he/she used. In such a list, even in a scholary edition, I would not expect a description of individual hands or the reason why an editor assigned this or that entry to a particular scribe. That would come in another place, wouldn't it? That's where my question (here #18) came from, whether to mix this content.
ad <handDesc>: I'm not sure I understand your suggestion. Isn't <handList> the MEI equivalent of <handDesc> in TEI, isn't it? For me it is different whether I list or describe a thing. But both are necessary here and I would rather separate this information?

[ahankinson]

I would definitely check out the usage and description of the TEI hand elements that I posted above. The TEI guidelines, and the examples, were written by experts in manuscript description so I would defer to them to what they mean when they say 'hand'.

(You'll also notice that they wrap any person mentioned in their hand description in <persName> elements.)

[ahankinson]

As I see it:

• MEI <handList> ~= TEI <handDesc>
• MEI <hand> ~= TEI <handNote>

Then you could also omit <hand> and just use <persName>

Correct. If you want to describe a person, use <persName>. You can reference this person elsewhere, but <hand> is not a specialized way of describing a person; it specifically describes the hand in which the document is written. If you can assign a personal name to it, fine, but it's generally a way of identifying the "style" in which the document is written, including any deviations from what might be expected, e.g.,

• "Anglicana hands except for art. 4, similar but apparently different in each booklet."
• "Art. 1 in an informal early gothic bookhand of French appearance. The rest is in English bookhands, except for additions on blank spaces, in anglicana hands of c.1300."

[doerners]

I think that this discussion clarified that there is some confusion or difference in interpretation regarding these elements. This might stem from a difference in practice between musicology and codicology and maybe partly because of the different naming conventions in TEI and MEI. Thus it seems as it would be worth while to have a greater discussion within the IG and subsequently the wider MEI community about our understanding of these elements and the needs for musicological descriptions in projects that deal with manuscript sources. If from a musicological perspective the identification or demarcation of different scribes is of more pressing importance rather than the description of the handwriting style than it might be worth considering how these or other elements could cater to those needs and what might need to be change.

However, the best place for having/documenting the discussion would probably be #18 rather than here.