<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Kristina and List:eners!<br>
In the past few months I've been dealing with the idea of capuring
the metadata of published records in MEI and to start out I
decided for the harest part ;-) A recording was made publicized
and later re-issued on a differnet sound carrier, additional work
done by technicians and additional text parts completed this
re-issue.<br>
As you might imagine, I came across quite a lot of responsibility
statements and I find it very convnient to stitch to the MARC code
list for Relators.<br>
Thus I can understand Perry's idea and might even support to<br>
<br>
<blockquote type="cite">
<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>
</blockquote>
<br>
<blockquote type="cite">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.
</blockquote>
<br>
Though making a decision here always weans to draw a line. But
where to draw the line?<br>
Arranger could still be dropped as his activity might be secondary
or even tertiary use of the work.<br>
<br>
Then on the other hand when moving forward in the publication
process more and more persons fill different and nevertheless very
important roles. For example, when talking modern times an editor
has extensive influence on the gestalt of the publicized/published
work. And another very important role is that of the engraver (or
typesetter however to call the function in digital times). Now
going this road a bit we are very fast to come across someone
being the encoder, as depending on workflow and technologies used,
encoding and setting the music might overlap at some point.<br>
<br>
And for me this is an essential question that can be drawn from
Kristina's post. Oe could even discuss of putting the encoder as
<author> or <editor> in <fileDesc> as
<fileDesc> is not about the music but about the encoded data
(although opening another question with this...). And this is
where the encoder has primary and extensive influence. And, if I'm
not mistaken, there is no MARC code for this!<br>
**Thus I would propose of having such an element to compensate
this!**<br>
<br>
Another thing that has come to me - opening yet another bottle -
is the encoding that Perry's second example shows, as I came
across this in my metadata. <br>
<br>
<blockquote type="cite">
<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>
</blockquote>
<br>
Although straightforward the content of <respStmt> leaves me
with a shudder, as no explicit mapping of <resp> and
<persName> is to be observed. I would very much prefer to
see something like this:<br>
<br>
<respStmt>
<p> <resp>Composer</resp></p>
<p> <persName>Composer de Jure</persName></p>
<p>
</respStmt></p>
<p> <respStmt>
<br>
<resp>Lyricist</resp></p>
<p> <persName>Johann Collaborator Bach</persName></p>
<p>
</respStmt></p>
<p> <respStmt> <br>
</p>
<p> <resp>Arranger</resp></p>
<p> <persName>Arranger Man</persName><br>
</p>
<p>
</respStmt></p>
<p> <respStmt> <br>
</p>
<p>
<resp>Encoders</resp><br>
<persName>[encoder 1]</persName><br>
<persName>[encoder 2]</persName><br>
</respStmt></p>
<br>
Adding some MARC relator code either in @role on <persName>
or in <resp> with the corresponding @authURI would be
helpful since providing a mapping to a controlled vocabulary.
Although even here the setup could be discussed:<br>
<br>
1) Why to supply <resp> if I can provide @role and @authURI
on <persName>?<br>
<br>
<respStmt>
<p> <persName role="cmp" authUri="...MARC...">Composer de
Jure</persName><br>
</p>
<p> <persName role="lyr" authUri="...MARC...">Johann
Collaborator Bach</persName></p>
<p> ...<br>
</p>
<p>
</respStmt></p>
<br>
2) How to supply the laguage-specific role description that
Eleanor pointed out in the discussion?<br>
Is <resp> the right place?<br>
<br>
<respStmt>
<p> <resp>Komponist</resp></p>
<p> <persName>Composer de Jure</persName></p>
<p>
</respStmt></p>
<br>
Apparently not, as it only may have attributes to relate the
included string to a controlled vocabulary.<br>
maybe:<br>
<br>
<respStmt label="Komponist"><br>
...<br>
</...><br>
<br>
This would make necessary a <respStmt> for each role to be
supplied. Which even is a good idea to group multiple names (as
seen in preceeding examples by Kristina and Perry ).<br>
The again this would miss someting like @xml:lang which could
allowed on <resp> if used for a label.<br>
<br>
Then if detailed description is not of primary interest, one could
come up with a flat hierarchy:<br>
<br>
<respStmt>
<p> <persName role="cmp" authUri="...MARC...">Composer de
Jure</persName><br>
</p>
<p> <persName role="lyr" authUri="...MARC...">Johann
Collaborator Bach</persName></p>
<p> ...<br>
</p>
<p>
</respStmt><br>
</p>
<p><br>
or:<br>
</p>
<br>
<respStmt>
<p> <resp xml:lang="de_DE">Komponist</resp></p>
<p> <persName>Composer de Jure</persName></p>
<p>
</respStmt></p>
<br>
<br>
That's it for now. Sorry for getting lengthy and raising even more
questions.<br>
As I'm no metadata expert I see that at some points I might have
been too focused on transcription instead of metadata, please
excuse ;-)<br>
In expectation of a nice discussion,<br>
<br>
Benjamin<br>
<br>
<br>
Am 05.02.2013 18:23, schrieb Roland, Perry (pdr4h):<br>
</div>
<blockquote
cite="mid:BBCC497C40D85642B90E9F94FC30343D2D9ED861@GRANT.eservices.virginia.edu"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<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>
<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 moz-do-not-send="true"
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</font></p>
<font size="2">
</font>
<div><font size="2">
</font>
<div class="BodyFragment"><font size="2">
<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 size="2"
color="#000000" face="Tahoma"><b>From:</b>
<a class="moz-txt-link-abbreviated" href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a>
[<a class="moz-txt-link-abbreviated" href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a>] on behalf of
Eleanor Selfridge-Field [<a class="moz-txt-link-abbreviated" href="mailto:esfield@stanford.edu">esfield@stanford.edu</a>]<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 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 moz-do-not-send="true"
href="http://www.stanford.edu/%7Eesfield/"
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">
<a class="moz-txt-link-abbreviated" href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a>
[<a class="moz-txt-link-freetext" href="mailto:mei-l-bounces@lists.uni-paderborn.de">mailto:mei-l-bounces@lists.uni-paderborn.de</a>]
<b>On Behalf Of </b>Kristina Richts<br>
<b>Sent:</b> Monday, February 04, 2013 9:55 AM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
mei-l mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
<a class="moz-txt-link-freetext" href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a>
</pre>
</blockquote>
<br>
</body>
</html>