<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style>@font-face {
        font-family: Helvetica;
}
@font-face {
        font-family: Helvetica;
}
@font-face {
        font-family: Calibri;
}
@font-face {
        font-family: Tahoma;
}
@page WordSection1 {margin: 1.0in 1.0in 1.0in 1.0in; }
P.MsoNormal {
        MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"; COLOR: black; FONT-SIZE: 12pt
}
LI.MsoNormal {
        MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"; COLOR: black; FONT-SIZE: 12pt
}
DIV.MsoNormal {
        MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"; COLOR: black; FONT-SIZE: 12pt
}
A:link {
        COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
        COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
        COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
        COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
        FONT-FAMILY: "Calibri","sans-serif"; COLOR: #1f497d
}
.MsoChpDefault {
        FONT-SIZE: 10pt
}
</style><style id="owaParaStyle">P {
        MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
P {
        MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body lang="EN-US" bgcolor="white" vlink="purple" link="blue" fPStyle="1" ocsi="0">
<div style="FONT-FAMILY: Arial Unicode MS; DIRECTION: ltr; COLOR: #000000; FONT-SIZE: 12pt">
<p>Hello everyone,</p>
<p> </p>
<p>I can see now that my plan to provide <creator> and <contributor> as replacements for TEI's <author> element isn't defensible because it's causing more confusion than it alleviates.  So, I suggest that we
</p>
<p> </p>
<p>1. return to the list provided by TEI -- author, editor, funder, meeting, principal (as in principal investigator), sponsor, and respStmt,</p>
<p>2. but drop meeting and principal, and</p>
<p>3. add arranger, composer, librettist, and lyricist.</p>
<p> </p>
<p>As in TEI, any roles not specifically provided for by this list, such as conductor, encoder, and so on, belong in <respStmt>, for example --</p>
<p> </p>
<p><titleStmt><br>
  <title>My Music, Op. 1</title><br>
  <composer>Composer de Jure</composer></p>
<p>  <lyricist>Johann Collaborator Bach</lyricist></p>
<p>  <arranger>Arranger Extraordinaire</arranger><br>
  <respStmt><br>
    <resp>Encoders</resp><br>
    <persName>[encoder 1]</persName><br>
    <persName>[encoder 2]</persName><br>
  </respStmt><br>
</titleStmt></p>
<p> </p>
<p>In this scheme, <arranger>, <composer>, <librettist>, and <lyricist> for musical compositions are equivalent to <author> for textual material.  The <author> element *should not* be used for lyricists or librettists. 
</p>
<p> </p>
<p>MARC relator code list (<a href="http://www.loc.gov/marc/relators/relaterm.html">http://www.loc.gov/marc/relators/relaterm.html</a>) provides more than 200 codes/terms for roles, several of which apply to music and musical performances.  There's no way we
 can accommodate them all.  So, it makes sense to continue the TEI method of recording those responsible for the *intellectual content* of the work in special elements and relegating other roles to <respStmt>. (I think this actually stems from ISBD and AACR2,
 not TEI.)</p>
<p> </p>
<p>The addition of these elements *does not* mandate their use; that is, <respStmt> can be used for all responsibilities.  The following markup is a valid alternative to the example above:</p>
<p> </p>
<p><titleStmt><br>
  <title>My Music, Op. 1</title><br>
  <respStmt></p>
<p>    <resp>Composer</resp></p>
<p>    <persName>Composer de Jure</persName></p>
<p>    <resp>Lyricist</resp></p>
<p>    <persName>Johann Collaborator Bach</persName></p>
<p>    <resp>Arranger</resp></p>
<p>    <persName>Arranger Man</persName><br>
    <resp>Encoders</resp><br>
    <persName>[encoder 1]</persName><br>
    <persName>[encoder 2]</persName><br>
  </respStmt><br>
</titleStmt></p>
<p> </p>
<p>This form can be easier to produce mechanistically from other encoding schemes and is conformant with forms of cataloging that don't require a "main entry" approach, meaning that it would be easier to transform into one of those systems, such as MODS.</p>
<p> </p>
<p>Also, it's necessary to keep in mind that since <fileDesc> is a kind of bibliographic citation, elements used here are also available in (and must also fit within the purpose of) other elements, such as <bibl> and <work>.</p>
<p> </p>
<p>Best wishes,</p>
<p> </p>
<p>--</p>
<p>p.</p>
<p><font size="2"><br>
__________________________<br>
Perry Roland<br>
Music Library</p>
<div>
<div class="BodyFragment">
<div class="PlainText">University of Virginia</div>
<div class="PlainText">P. O. Box 400175</div>
<div class="PlainText">Charlottesville, VA 22904<br>
434-982-2702 (w)<br>
pdr4h (at) virginia (dot) edu</div>
</font></div>
</div>
<div style="FONT-FAMILY: Times New Roman; COLOR: #000000; FONT-SIZE: 16px">
<hr tabindex="-1">
<div style="DIRECTION: ltr" id="divRpF79605"><font color="#000000" size="2" face="Tahoma"><b>From:</b> mei-l-bounces@lists.uni-paderborn.de [mei-l-bounces@lists.uni-paderborn.de] on behalf of Eleanor Selfridge-Field [esfield@stanford.edu]<br>
<b>Sent:</b> Monday, February 04, 2013 4:39 PM<br>
<b>To:</b> 'Music Encoding Initiative'<br>
<b>Subject:</b> Re: [MEI-L] Encoding of personal names<br>
</font><br>
</div>
<div></div>
<div>
<div class="WordSection1">
<p class="MsoNormal"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">Kristina poses interesting questions.  Instinctively I would go for “composer”, “encoder,” etc and err on the side of being verbose and explicit.  With electronic
 data, being able to track who encoded what (with version number and date) can be very valuable. 
</span></p>
<p class="MsoNormal"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"></span> </p>
<p class="MsoNormal"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">I find labels such as “creator” and “corporate name” very unwieldy, particularly when working in a second language (in my case usually Italian).  Italian
 bibliographical databases a full of these kinds of terms, but there is something subtly cultural about the misunderstandings they can create.  The various instantiations of a single work can have many creators—a composer, an arranger, and editor, a translator
 of the text, and in the case of recording a conductor, performer, performing group, etc. Because they can all pertain to a single work, a general label deprives the user of knowing what the role of each one was. 
</span></p>
<p class="MsoNormal"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"></span> </p>
<p class="MsoNormal"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">A much messier area is dating.  A single work can have an almost endless number of “year”s—of composition, publication, first performance, revision <1..n>,
 arrangement, recording, text translation, etc.  There too being more specific saves time for those searching. 
</span></p>
<p class="MsoNormal"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"></span> </p>
<p class="MsoNormal"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">Best regards,</span></p>
<p class="MsoNormal"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"></span> </p>
<p class="MsoNormal"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">Eleanor</span></p>
<p class="MsoNormal"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"></span> </p>
<p class="MsoNormal"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"></span> </p>
<p class="MsoNormal"><span style="COLOR: #1f497d; FONT-SIZE: 10pt">Eleanor Selfridge-Field<br>
Consulting Professor, Music (and, by courtesy, Symbolic Systems)<br>
Braun Music Center #129<br>
Stanford University<br>
Stanford, CA 94305-3076, USA<br>
<a href="http://www.stanford.edu/~esfield/" target="_blank"><span style="COLOR: blue">http://www.stanford.edu/~esfield/</span></a></span><span style="COLOR: #1f497d">
</span></p>
<p class="MsoNormal"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"></span> </p>
<p class="MsoNormal"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"></span> </p>
<p class="MsoNormal"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"></span> </p>
<div>
<div style="BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<p class="MsoNormal"><b><span style="FONT-FAMILY: 'Tahoma','sans-serif'; COLOR: windowtext; FONT-SIZE: 10pt">From:</span></b><span style="FONT-FAMILY: 'Tahoma','sans-serif'; COLOR: windowtext; FONT-SIZE: 10pt"> mei-l-bounces@lists.uni-paderborn.de [mailto:mei-l-bounces@lists.uni-paderborn.de]
<b>On Behalf Of </b>Kristina Richts<br>
<b>Sent:</b> Monday, February 04, 2013 9:55 AM<br>
<b>To:</b> mei-l@lists.uni-paderborn.de<br>
<b>Subject:</b> [MEI-L] Encoding of personal names</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span style="FONT-FAMILY: 'Helvetica','sans-serif'">Dear all,<br>
<br>
during the work on the MEI sample collection, questions appeared on how to encode the creators of each electronic file correctly.<br>
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. <br>
<respStmt><br>
   <persName role="composer">Anton Webern</persName><br>
   <persName role="creator">John Doe</persName> </span><br>
<span style="FONT-FAMILY: 'Helvetica','sans-serif'"></respStmt><br>
<br>
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.<br>
</span><br>
<span style="FONT-FAMILY: 'Helvetica','sans-serif'"><respStmt><br>
   <persName role="creator">Anton Webern</persName><br>
   <persName role="encoder">John Doe</persName> <br>
</respStmt><br>
<br>
The decision is based on the fact, that we encode the <u>intellectual creation</u> of a composer's work. We tried to keep up the distinction between the composer and the encoder.
<br>
<br>
MEI2013 will offer some new elements to specify the role of persons, organizations etc. a bit more: <creator>, <contributor>, <editor>, <funder> and <sponsor>.
<br>
In this regard it is now the question how to encode this best:<br>
 </span><br>
<span style="FONT-FAMILY: 'Helvetica','sans-serif'"><respStmt><br>
    <creator>   <br>
        <persName>Anton Webern</persName><br>
    </creator><br>
    <creator><br>
       <persName>John Doe</persName> <br>
    </creator><br>
</respStmt><br>
<br>
or<br>
</span><br>
<span style="FONT-FAMILY: 'Helvetica','sans-serif'"><respStmt><br>
    <creator>   <br>
        <persName role="composer">Anton Webern</persName><br>
    </creator><br>
    <creator><br>
       <persName role="encoder">John Doe</persName> <br>
    </creator><br>
</respStmt><br>
?<br>
<br>
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.<br>
<br>
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. <br>
<br>
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.<br>
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?<br>
<br>
 <br>
Any comments on this?<br>
<br>
Best,<br>
Kristina</span></p>
</div>
</div>
</div>
</div>
</body>
</html>