[MEI-L] Encoding of personal names

Kristina Richts kristina.richts at gmx.de
Mon Feb 4 18:54:57 CET 2013


Dear all,

during the work on the MEI sample collection, questions appeared on how 
to encode the creators of each electronic file correctly.
In MEI2012 the normal path (or better said: the way, we first chose to 
encode it) was to encode several <persName>-elements within the 
statement of responsibilty. A differentiation between several involved 
persons only became apparent through additional @role-attributes, i.e.
<respStmt>
    <persName role="composer">Anton Webern</persName>
    <persName role="creator">John Doe</persName>
</respStmt>

In a second step we decided not to encode ourselves as "creators" of the 
file (although we are), but as "encoders" and to assign the composer of 
the encoded work as creator, i.e.

<respStmt>
    <persName role="creator">Anton Webern</persName>
    <persName role="encoder">John Doe</persName>
</respStmt>

The decision is based on the fact, that we encode the _intellectual 
creation_ of a composer's work. We tried to keep up the distinction 
between the composer and the encoder.

MEI2013 will offer some new elements to specify the role of persons, 
organizations etc. a bit more: <creator>, <contributor>, <editor>, 
<funder> and <sponsor>.
In this regard it is now the question how to encode this best:

<respStmt>
     <creator>
         <persName>Anton Webern</persName>
     </creator>
     <creator>
        <persName>John Doe</persName>
     </creator>
</respStmt>

or

<respStmt>
     <creator>
         <persName role="composer">Anton Webern</persName>
     </creator>
     <creator>
        <persName role="encoder">John Doe</persName>
     </creator>
</respStmt>
?

We first thought, it would be a good idea, to add a <composer> element 
to the list. But that alone would not be sufficient, as the creative 
aspect regarding musical works is difficult to manage. In this case, we 
would rather have to extend the list by adding some more elements like 
<arranger>, <lyricist>, etc. But this can soon become very unwieldy.

I have to admit that I don't prefer to encode detailed specifications 
only within child elements. However, if we choose to maintain the 'more 
detailed elements', I would at least like to see some mandatory child 
elements, such as <persName>, <name>, <corpName> etc., in there.

When thinking about all this, I came to the conclusion, that it might be 
enough to allow a <creator> and a <contributor> element (with some 
mandatory child elements). I am not even sure, if we should offer a 
separate <editor> element or if an editor should be considered as a 
contributor as well.
What is to be said against a specification of the role on the <creator> 
or <contributor> element? Wouldn't this make things easier to handle for 
the encoder, who might not know as much about the encoding of persNames 
with MEI?


Any comments on this?

Best,
Kristina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20130204/08657fc3/attachment.html>


More information about the mei-l mailing list