[MEI-L] Encoding of personal names
Benjamin Wolff Bohl
bohl at edirom.de
Thu Feb 7 09:36:39 CET 2013
Hi Kristina and List:eners!
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.
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.
Thus I can understand Perry's idea and might even support to
> 1. return to the list provided by TEI -- author, editor, funder,
> meeting, principal (as in principal investigator), sponsor, and respStmt,
>
> 2. but drop meeting and principal, and
>
> 3. add arranger, composer, librettist, and lyricist.
>
> 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.
Though making a decision here always weans to draw a line. But where to
draw the line?
Arranger could still be dropped as his activity might be secondary or
even tertiary use of the work.
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.
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!
**Thus I would propose of having such an element to compensate this!**
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.
> titleStmt>
> <title>My Music, Op. 1</title>
> <respStmt>
>
> <resp>Composer</resp>
>
> <persName>Composer de Jure</persName>
>
> <resp>Lyricist</resp>
>
> <persName>Johann Collaborator Bach</persName>
>
> <resp>Arranger</resp>
>
> <persName>Arranger Man</persName>
> <resp>Encoders</resp>
> <persName>[encoder 1]</persName>
> <persName>[encoder 2]</persName>
> </respStmt>
> </titleStmt>
>
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:
<respStmt>
<resp>Composer</resp>
<persName>Composer de Jure</persName>
</respStmt>
<respStmt>
<resp>Lyricist</resp>
<persName>Johann Collaborator Bach</persName>
</respStmt>
<respStmt>
<resp>Arranger</resp>
<persName>Arranger Man</persName>
</respStmt>
<respStmt>
<resp>Encoders</resp>
<persName>[encoder 1]</persName>
<persName>[encoder 2]</persName>
</respStmt>
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:
1) Why to supply <resp> if I can provide @role and @authURI on <persName>?
<respStmt>
<persName role="cmp" authUri="...MARC...">Composer de Jure</persName>
<persName role="lyr" authUri="...MARC...">Johann Collaborator
Bach</persName>
...
</respStmt>
2) How to supply the laguage-specific role description that Eleanor
pointed out in the discussion?
Is <resp> the right place?
<respStmt>
<resp>Komponist</resp>
<persName>Composer de Jure</persName>
</respStmt>
Apparently not, as it only may have attributes to relate the included
string to a controlled vocabulary.
maybe:
<respStmt label="Komponist">
...
</...>
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 ).
The again this would miss someting like @xml:lang which could allowed on
<resp> if used for a label.
Then if detailed description is not of primary interest, one could come
up with a flat hierarchy:
<respStmt>
<persName role="cmp" authUri="...MARC...">Composer de Jure</persName>
<persName role="lyr" authUri="...MARC...">Johann Collaborator
Bach</persName>
...
</respStmt>
or:
<respStmt>
<resp xml:lang="de_DE">Komponist</resp>
<persName>Composer de Jure</persName>
</respStmt>
That's it for now. Sorry for getting lengthy and raising even more
questions.
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 ;-)
In expectation of a nice discussion,
Benjamin
Am 05.02.2013 18:23, schrieb Roland, Perry (pdr4h):
>
> Hello everyone,
>
> 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
>
> 1. return to the list provided by TEI -- author, editor, funder,
> meeting, principal (as in principal investigator), sponsor, and respStmt,
>
> 2. but drop meeting and principal, and
>
> 3. add arranger, composer, librettist, and lyricist.
>
> As in TEI, any roles not specifically provided for by this list, such
> as conductor, encoder, and so on, belong in <respStmt>, for example --
>
> <titleStmt>
> <title>My Music, Op. 1</title>
> <composer>Composer de Jure</composer>
>
> <lyricist>Johann Collaborator Bach</lyricist>
>
> <arranger>Arranger Extraordinaire</arranger>
> <respStmt>
> <resp>Encoders</resp>
> <persName>[encoder 1]</persName>
> <persName>[encoder 2]</persName>
> </respStmt>
> </titleStmt>
>
> 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.
>
> MARC relator code list
> (http://www.loc.gov/marc/relators/relaterm.html) 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.)
>
> 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:
>
> <titleStmt>
> <title>My Music, Op. 1</title>
> <respStmt>
>
> <resp>Composer</resp>
>
> <persName>Composer de Jure</persName>
>
> <resp>Lyricist</resp>
>
> <persName>Johann Collaborator Bach</persName>
>
> <resp>Arranger</resp>
>
> <persName>Arranger Man</persName>
> <resp>Encoders</resp>
> <persName>[encoder 1]</persName>
> <persName>[encoder 2]</persName>
> </respStmt>
> </titleStmt>
>
> 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.
>
> 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>.
>
> Best wishes,
>
> --
>
> p.
>
>
> __________________________
> Perry Roland
> Music Library
>
> University of Virginia
> P. O. Box 400175
> Charlottesville, VA 22904
> 434-982-2702 (w)
> pdr4h (at) virginia (dot) edu
> ------------------------------------------------------------------------
> *From:* mei-l-bounces at lists.uni-paderborn.de
> [mei-l-bounces at lists.uni-paderborn.de] on behalf of Eleanor
> Selfridge-Field [esfield at stanford.edu]
> *Sent:* Monday, February 04, 2013 4:39 PM
> *To:* 'Music Encoding Initiative'
> *Subject:* Re: [MEI-L] Encoding of personal names
>
> 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.
>
> 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.
>
> 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.
>
> Best regards,
>
> Eleanor
>
> Eleanor Selfridge-Field
> Consulting Professor, Music (and, by courtesy, Symbolic Systems)
> Braun Music Center #129
> Stanford University
> Stanford, CA 94305-3076, USA
> http://www.stanford.edu/~esfield/ <http://www.stanford.edu/%7Eesfield/>
>
> *From:*mei-l-bounces at lists.uni-paderborn.de
> [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of *Kristina
> Richts
> *Sent:* Monday, February 04, 2013 9:55 AM
> *To:* mei-l at lists.uni-paderborn.de
> *Subject:* [MEI-L] Encoding of personal names
>
> 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
>
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20130207/b29c5771/attachment.html>
More information about the mei-l
mailing list