<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Helvetica, Arial, sans-serif">Hello,<br>
<br>
well, I think, this discussion for itself shows the different
needs of encoding responsibilities and even one thing more: We
can't find a solution for all these needs.<br>
So, I vote to keep things as general as possible. Johannes is
right that we don't have to draw the line. This is better than
drawing it just "somewhere".<br>
I can understand Perry's approach to provide <creator> and
<contributor> as replacements for <author>. Regarding
the FRBR stuff I have worked myself through different cataloguing
rules (international as well as national) these days and you can
find the separation into these two big groups of responsibilities
almost everywhere. It is the question if we want to jump up or
just leave it. All in all, the "syntactic sugar" </font><font
face="Helvetica, Arial, sans-serif"><font face="Helvetica, Arial,
sans-serif">(to speak in your language <span
class="moz-smiley-s3"><span> ;-) </span></span>) </font>won't
help to make the decision, if someone is "author" or "creator" or
whatever, easier. Regarding this, it would be fine to maintain
single <persName>, <corpName> etc. elements within the
statement of responsibility. The 200 MARC relator terms should
provide enough specification (as long as they are used). So, I
would support to remove <arranger>, <author>,
<composer>, <librettist> and <lyricist>.<br>
<br>
By the way: Thanks for the hint, that there is no "encoder" term
in the MARC term list for relators ;-) I totally forgot about
that, but remember now, this was the reason, why we chose
"creator" (instead of "encoder") first... <br>
The "markup editor" term is fine. Or "transcriber" (as it is an
electronic transcription)?<br>
<br>
Best,<br>
Kristina<br>
<br>
</font><br>
<br>
<div class="moz-cite-prefix">Am 07.02.2013 12:05, schrieb Benjamin
Wolff Bohl:<br>
</div>
<blockquote cite="mid:51138A70.9070402@edirom.de" type="cite">Only a
quick follow up question and response (see inline)
<br>
<br>
Am 07.02.2013 10:44, schrieb Johannes Kepper:
<br>
<blockquote type="cite">Hi all,
<br>
<br>
I would really like to get around this can of worms, but I can't
resist any longer ;-)
<br>
<br>
All these elements are syntactic sugar – author, editor, funder,
sponsor, arranger, composer, librettist and lyricist. Benjamin's
posting showcases that it is not absolutely clear why we have
exactly this selection of sugar drops. I for myself feel equally
inconvenient with it, as does Kristina (if I got her right in a
recent discussion in Detmold). It seems like drawing a line is
easy, but agreeing on and justifying that line is less easy.
Therefore, my question is whether we really need to draw that
line. MEI existed without that syntactic sugar for quite some
time, and I don't remember major complains about this as a
missing feature. Wouldn't it be much better to delegate that to
individual projects, which could add their own flavor of sugar,
and document what they did in their own ODD? (Yes, we need
better resources for explaining how to actually do that…).
<br>
</blockquote>
<br>
If I understand this right, you propose not to have these
syntactic sugar elements in the schema but to stick to
<respStmt> with <resp> and either <persName> or
<corpName> and suggest to add sugar by referencing
corresponding authority codes.
<br>
As mentioned before there might be cases where no corresponding
authority code exists (as with encoder in MARC). The I could
either find a different autority or just not supply the authority
@s.
<br>
<br>
Fine with me - does make processing easier!
<br>
Any other opinions on that?
<br>
<br>
Now to the next point of discussion:
<br>
<blockquote type="cite">
<br>
Regarding the mixed use of <resp> and <name>, please
note the current guidelines, which read on page 25 (chapter
2.1.1: Title Statement):
<br>
<br>
"While <resp> accommodates capturing the wide variety of
text that may occur in responsibility statements, use of the
@role attribute provides the possibility of recording a
controlled value independently of the textual content of
<resp>. The use of @role is required for improved data
processability and interchange."
<br>
<br>
Basically, <resp> is used to transcribe the wording in a
source, whereas @role on the name itself is better suited (and
therefore recommended) for processing the data. On the following
page, there is also a reference to the MARC list Benjamin
mentioned:
<br>
<br>
"Values from the MARC relator code list
(<a class="moz-txt-link-freetext" href="http://www.loc.gov/marc/relators/relacode.html">http://www.loc.gov/marc/relators/relacode.html</a>) or term list
(<a class="moz-txt-link-freetext" href="http://www.loc.gov/marc/relators/relaterm.html">http://www.loc.gov/marc/relators/relaterm.html</a>) are recommended
for @role, where applicable."
<br>
<br>
Of course, this does not solve the starting question, but it
illustrates that it may occasionally help to read the friendly
manual ;-)
<br>
Best,
<br>
Johannes
<br>
</blockquote>
<br>
I completely understand what the guidelines state here but
regarding the schema design for <resp> implies that it is
meant differently:
<br>
When transcribing the wording of the source in <resp> what
use do @authority and @authURI have as I cannot supply this info
with the authorities code for that certain type of responsibility,
ergo something similar to @role in <persName> would be
required, maybe @dbkey or comparable could fill this gap?
<br>
<br>
cheers,
<br>
benni
<br>
<br>
<blockquote type="cite">
<br>
<br>
<br>
<br>
Am 07.02.2013 um 09:36 schrieb Benjamin Wolff Bohl:
<br>
<br>
<blockquote type="cite">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">1. return to the list provided by TEI
-- author, editor, funder, meeting, principal (as in
principal investigator), sponsor, and respStmt,
<br>
2. but drop meeting and principal, and
<br>
3. add arranger, composer, librettist, and lyricist.
<br>
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.
<br>
</blockquote>
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">titleStmt>
<br>
<title>My Music, Op. 1</title>
<br>
<respStmt>
<br>
<resp>Composer</resp>
<br>
<persName>Composer de Jure</persName>
<br>
<resp>Lyricist</resp>
<br>
<persName>Johann Collaborator
Bach</persName>
<br>
<resp>Arranger</resp>
<br>
<persName>Arranger Man</persName>
<br>
<resp>Encoders</resp>
<br>
<persName>[encoder 1]</persName>
<br>
<persName>[encoder 2]</persName>
<br>
</respStmt>
<br>
</titleStmt>
<br>
</blockquote>
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>
<br>
<resp>Composer</resp>
<br>
<persName>Composer de Jure</persName>
<br>
</respStmt>
<br>
<respStmt>
<br>
<resp>Lyricist</resp>
<br>
<persName>Johann Collaborator Bach</persName>
<br>
</respStmt>
<br>
<respStmt>
<br>
<resp>Arranger</resp>
<br>
<persName>Arranger Man</persName>
<br>
</respStmt>
<br>
<respStmt>
<br>
<resp>Encoders</resp>
<br>
<persName>[encoder 1]</persName>
<br>
<persName>[encoder 2]</persName>
<br>
</respStmt>
<br>
<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>
<br>
<persName role="cmp" authUri="...MARC...">Composer
de Jure</persName>
<br>
<persName role="lyr" authUri="...MARC...">Johann
Collaborator Bach</persName>
<br>
...
<br>
</respStmt>
<br>
<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>
<br>
<resp>Komponist</resp>
<br>
<persName>Composer de Jure</persName>
<br>
</respStmt>
<br>
<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>
<br>
<persName role="cmp" authUri="...MARC...">Composer
de Jure</persName>
<br>
<persName role="lyr" authUri="...MARC...">Johann
Collaborator Bach</persName>
<br>
...
<br>
</respStmt>
<br>
<br>
or:
<br>
<br>
<respStmt>
<br>
<resp xml:lang="de_DE">Komponist</resp>
<br>
<persName>Composer de Jure</persName>
<br>
</respStmt>
<br>
<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>
<blockquote type="cite">Hello everyone,
<br>
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
<br>
1. return to the list provided by TEI -- author, editor,
funder, meeting, principal (as in principal investigator),
sponsor, and respStmt,
<br>
2. but drop meeting and principal, and
<br>
3. add arranger, composer, librettist, and lyricist.
<br>
As in TEI, any roles not specifically provided for by this
list, such as conductor, encoder, and so on, belong in
<respStmt>, for example --
<br>
<titleStmt>
<br>
<title>My Music, Op. 1</title>
<br>
<composer>Composer de Jure</composer>
<br>
<lyricist>Johann Collaborator Bach</lyricist>
<br>
<arranger>Arranger Extraordinaire</arranger>
<br>
<respStmt>
<br>
<resp>Encoders</resp>
<br>
<persName>[encoder 1]</persName>
<br>
<persName>[encoder 2]</persName>
<br>
</respStmt>
<br>
</titleStmt>
<br>
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.
<br>
MARC relator code list
(<a class="moz-txt-link-freetext" 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.)
<br>
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:
<br>
<titleStmt>
<br>
<title>My Music, Op. 1</title>
<br>
<respStmt>
<br>
<resp>Composer</resp>
<br>
<persName>Composer de Jure</persName>
<br>
<resp>Lyricist</resp>
<br>
<persName>Johann Collaborator
Bach</persName>
<br>
<resp>Arranger</resp>
<br>
<persName>Arranger Man</persName>
<br>
<resp>Encoders</resp>
<br>
<persName>[encoder 1]</persName>
<br>
<persName>[encoder 2]</persName>
<br>
</respStmt>
<br>
</titleStmt>
<br>
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.
<br>
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>.
<br>
Best wishes,
<br>
--
<br>
p.
<br>
<br>
__________________________
<br>
Perry Roland
<br>
Music Library
<br>
University of Virginia
<br>
P. O. Box 400175
<br>
Charlottesville, VA 22904
<br>
434-982-2702 (w)
<br>
pdr4h (at) virginia (dot) edu
<br>
From: <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>
Sent: Monday, February 04, 2013 4:39 PM
<br>
To: 'Music Encoding Initiative'
<br>
Subject: Re: [MEI-L] Encoding of personal names
<br>
<br>
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.
<br>
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.
<br>
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.
<br>
Best regards,
<br>
Eleanor
<br>
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 class="moz-txt-link-freetext" href="http://www.stanford.edu/~esfield/">http://www.stanford.edu/~esfield/</a>
<br>
From: <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>] On Behalf Of
Kristina Richts
<br>
Sent: Monday, February 04, 2013 9:55 AM
<br>
To: <a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
<br>
Subject: [MEI-L] Encoding of personal names
<br>
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>
<br>
</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>
<br>
<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
intellectual creation 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>
<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>
<br>
<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>
Any comments on this?
<br>
<br>
Best,
<br>
Kristina
<br>
<br>
<br>
_______________________________________________
<br>
mei-l mailing list
<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
<br>
<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>
<br>
</blockquote>
_______________________________________________
<br>
mei-l mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
<br>
<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>
<br>
</blockquote>
<br>
_______________________________________________
<br>
mei-l mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
<br>
<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>
<br>
</blockquote>
<br>
<br>
_______________________________________________
<br>
mei-l mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
<br>
<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>
<br>
</blockquote>
<br>
</body>
</html>