[MEI-L] Encoding of personal names

[Roland, Perry (pdr4h)]

Greetings, MEI-ers!  (Or are we all collectively "MEI-onaisse"?)

A bit o' history first:

The addition of these so-called "syntactic sugar" elements to <titleStmt> came about as a result of revision of the <bibl> element.  In <bibl> they're not sugary, but meaty.  :-)  In other words, they provide for marking the component parts of bibliographic citations.  Using <respStmt> exclusively in bibliographic citations would require re-ordering the citation's components, which is not acceptable if you're trying to capture the original citation.

But making them available in <bibl> raises the question of allowing them in <titleStmt>.  Following TEI's lead, I chose to allow them.  There's nothing technically wrong with choosing not to use them in fileDesc/titleStmt, although in keeping with the traditional method of bibliographic description discussed below, I recommend their use.  They're not just sugar; they permit (encourage, even) traditional bibliographic description.

While there's no way to enforce it (and I don't think we want to), Benni's preference for explicit grouping of <resp> and name-like elements --

<titleStmt>
  <title>My Composition</title>
  <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>
</titleStmt>

is allowed.  In fact, this is the only way to achieve grouping of <resp> and one or more names. In addition, as I said before, this method "leans toward" cataloging schemes, such as MODS, that don't privilege one role (say, composer) over another (like encoder).

However, the more traditional way to encode this example is --

<titleStmt>
  <title>My Composition</title>
  <composer>
    <persName>Composer de Jure</persName>
  </composer>
  <lyricist>
    <persName>Johann Collaborator Bach</persName>
  </lyricist>
  <arranger>
    <persName>Arranger Man</persName>
  </arranger>
  <respStmt>
    <resp>Encoders</resp>
    <persName>[encoder 1]</persName>
    <persName>[encoder 2]</persName>
  </respStmt>
</titleStmt>

This creates an explicit mapping between certain common roles and names, but relegates others to a secondary position (within respStmt).

>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!**

For better or worse, the traditional method of describing edited (and by extension encoded) publications is to keep the original creator as the creator of the new publication and add descriptions for contributing authors.  For example,

      Principles of orchestration, with musical examples drawn from his own works [by] Nikolay Rimsky-Korsakov. Edited by 
      Maximilian Steinberg. English translation by Edward Agate.

While an encoder "creates" the encoding, just as Steinberg was presumably the "creator" of a notebook full of revisions, he/she is not the creator of the work.  One could argue that this approach is "old-fashioned", but it's the one most people have come to expect.

If the encoder has "primary and extensive influence", then I would argue that makes him an "editor", not merely an "encoder".  So, I would capture this as --

<titleStmt>
  <title>My Composition</title>
  <composer>
    <persName>Composer de Jure</persName>
  </composer>
  <lyricist>
    <persName>Johann Collaborator Bach</persName>
  </lyricist>
  <arranger>
    <persName>Arranger Man</persName>
  </arranger>
  <editor>Kristina Richts and Maja Hartwig</editor>
</titleStmt>

or, in order to capture the all-important "edited by" string, --

<titleStmt>
  <title>My Composition</title>
  <composer>
    <persName>Composer de Jure</persName>
  </composer>
  <lyricist>
    <persName>Johann Collaborator Bach</persName>
  </lyricist>
  <arranger>
    <persName>Arranger Man</persName>
  </arranger>
  <respStmt>
    <resp>Edited by </resp>
    <persName>Kristina Richts</persName>
    <persName>Maja Hartwig</persName>
  </respStmt>
</titleStmt>

Though I think it would cause other problems that I won't discuss now (and therefore I don't recommend it), one could even go as far as --

<titleStmt>
  <title>My Composition</title>
  <respStmt>
    <resp>Edited by </resp>
    <persName>Kristina Richts</persName>
    <persName>Maja Hartwig</persName>
  </respStmt>
</titleStmt>

leaving the description of the work to <workDesc>.


> 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>

While strictly legal according to the schema, <respStmt> is nonsensical without <resp>.  It's legal because it's impossible to control both order and number of the child <resp> and name-like elements.  To accommodate the widest range of order and number, all the children of <respStmt> have to be allowed to occur zero or more times, but that doesn't mean that <resp> can ever be left out.  A schematron rule should probably be added to require at least one <resp>.  This makes @role on respStmt/persName unnecessary.

@authURI is intended to capture a reference to an authorized value *for the content of the element*, in this case "Composer de Jure", not the value of @role.  If it's necessary to capture a reference to the source of the value of @role, use <resp> instead --

<respStmt>
  <resp authURI="http://www.loc.gov/marc/relators/relaterm.html">Composer</resp>
  <persName authURI="http://d-nb.info/gnd" authority="GND">Composer de Jure</persName>
</respStmt>

Currently, there's no way to put an un-authorized value in <resp> and then point to an authority for what the value "ought to be".  The following isn't kosher because "Komponist" doesn't exist in the MARC relator list --

<respStmt>
  <resp authURI="http://www.loc.gov/marc/relators/relaterm.html">Komponist</resp>
  <persName authURI="http://d-nb.info/gnd" authority="GND">Composer de Jure</persName>
</respStmt>

> 2) How to supply the laguage-specific role description that Eleanor pointed out in the discussion?
> Is <resp> the right place?

I'm not sure I understand what you're getting at here.  But, I agree that xml:lang should be added to <resp>.  And to <respStmt> so that one could write --

<respStmt xml:lang="de">
  <resp>Komponist</resp>
  <persName>Martin Luther</persName>
</respStmt>
<respStmt xml:lang="la">
  <resp>Composerus</resp> <!-- Or whatever the word for composer is in Latin -->
  <persName>Martinus Lutheraneuns</persName>  <!-- God forgive me! -->
</respStmt>

and choose the desired language later.

While I'm all for MEI doing something different when it's necessary, I also think it's important to employ those things (in this case, traditional bibliographic description principals and the markup of such things in TEI) which have a long history of usefulness.

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