[MEI-L] Encoding of personal names

[Roland, Perry (pdr4h)]

> Ah, here are the worms, freshly served from the foothills of the blue ridge mountains ;-)

It's what we specialize in.  ;-)  But it's not our entire Diet.  Bah, dum, dum!

> Perry, honestly, I remember myriads of discussions about this, and you still have this 
> tendency of relapsing. 

Is this a subtle way of saying I'm old?  :-)  In any case, what you call "relapsing", I call "reconsideration" or "refinement".  But to paraphrase Ronald Reagan, I won't hold your youth and inexperience against you.  ;-)

>First, what I miss in your post is an example of these elements in the context of <bibl>.
> You mention this is the meatful part, but only telling us about the food makes us 
> hungry, not well-fed (and convinced).

The message was long enough already.  I didn't see a need to launch into another round of the <bibl> discussions we endured not so long ago.  But if you insist, ...

In text, a bibliographic entity might be described using the bibliographic components allowed in inline text (as in the 1st paragraph) or with more detail using the <bibl> element --

<div>
  <p>My favorite composition is <title>Symphony No. 7</title> by <persName>Ludwig van Beethoven</persName>.</p>
  <p>But it's more formally described as 
    <bibl>
      <composer><persName>Beethoven, Ludwig van, <date>1770-1827</date></persName></composer>.
      <title type="uniform">Symphonies, no. 7, op. 92, A major</title>
      <title><title xml:lang="de">Symphonie Nr. 7 in A-dur</title> = <title xml:lang="en">Symphony no. 7 in A major</title>: <identifier>op. 92</identifier></title>.
      <!-- <respStmt>
        <resp>Urtext herausgegeben von</resp>
        <persName>Jonathan Del Mar</persName>
      </respStmt> -->. 
      <imprint>
        <pubPlace>Kassel ; New York</pubPlace>
        <publisher>Bärenreiter</publisher>
        <date>c2001</date>
      </imprint>.
    </bibl>
  </p>
</div>

[Unfortunately, this example doesn't allow <respStmt>, but it should.  It's just an oversight in the ODD revision.]

With only slight modification, mostly by eliminating separating punctuation, this publication can be described as the source of an MEI encoding using --

<source>
  <titleStmt>
    <title type="uniform">Symphonies, no. 7, op. 92, A major</title>
    <title><title xml:lang="de">Symphonie Nr. 7 in A-dur</title> = <title xml:lang="en">Symphony no. 7 in A major</title>: <identifier>op. 92</identifier></title>
    <composer><persName>Beethoven, Ludwig van, <date>1770-1827</date></persName></composer>
   <respStmt>
     <resp>Urtext herausgegeben von</resp>
     <persName>Jonathan Del Mar</persName>
   </respStmt>
 </titleStmt>
 <pubStmt>
   <pubPlace>Kassel ; New York</pubPlace>
   <publisher>Bärenreiter</publisher>
   <date>c2001</date>
 </pubStmt>
</source>

and the MEI encoding itself can be described by --

<titleStmt>
  <title type="uniform">Symphonies, no. 7, op. 92, A major</title>
  <title><title xml:lang="de">Symphonie Nr. 7 in A-dur</title> = <title xml:lang="en">Symphony
      no. 7 in A major</title>: <identifier>op. 92</identifier></title>
  <composer><persName>Beethoven, Ludwig van, <date>1770-1827</date></persName></composer>
  <respStmt>
    <resp>Encoded by </resp> 
    <persName>Maja Hartwig</persName>
    <persName>Kristina Richts</persName>
  </respStmt>
</titleStmt>
<pubStmt>
  <!-- Our usual publication statement here, although I'd use <publisher> 
  with <address> moved inside it.  -->
</pubStmt>

or, if composer and encoder are thought to be of equal importance --

 <titleStmt>
  <title type="uniform">Symphonies, no. 7, op. 92, A major</title>
  <title><title xml:lang="de">Symphonie Nr. 7 in A-dur</title> = <title xml:lang="en">Symphony
  no. 7 in A major</title>: <identifier>op. 92</identifier></title>
  <respStmt>
    <resp>Composed by</resp>
    <persName>Beethoven, Ludwig van, <date>1770-1827</date></persName>
    <resp>Encoded by </resp> 
    <persName>Maja Hartwig</persName>
    <persName>Kristina Richts</persName>
  </respStmt>
</titleStmt>

The point is that a bibliographic entity can be described in different places within MEI -- in the text proper, in fileDesc, sourceDesc, workDesc, etc.  The more we can harmonize the markup used in these places, the better.  But, we must also disallow anything that would cause confusion and require (when possible) markup that would clarify the description without creating a rigid scheme.

The <resp> element should be required in the example above for two reasons: 1) it makes the use of <respStmt> here compliant with use in the previous examples, and 2) it can hold the attributes @authURI, @authority, and @code to explicate the meaning of the phrases "Composed by" and "Encoded by".  The alternative of using @role on <persName> for this purpose forces the use of attributes to describe the values of other attributes, something to be zealously defended against.

With the addition of @code on <resp>, the preceding example could be enhanced --

<resp  authURI="http://www.loc.gov/marc/relators/relaterm.html" code="cmp">Composed by</resp>
<persName>Beethoven, Ludwig van, <date>1770-1827</date></persName>

> It's not that I don't see the usefulness of these elements, it's just that I don't see a 
> clear line where to stop when adding these elements. I also totally agree that <resp> is
> useful (for transcribing sources), although I see no difference about this in <respStmt>
> and <bibl>. I think the distinction we made (after passing the long and wormy
> road of discussion…) is pretty useful: <resp> for the texty part of a description, @code
> on names for processing. Requiring <resp> may be useful for certain <respStmt>, 
> like inside a <sourceDesc>, but what do you plan to transcribe in the
> fileDesc/titleStmt/respStmt? This about an electronic resource, and it is by definition
> the file your operating in. You're about to transcribe yourself here, starting into 
> recursion mode. I think <resp> in fileDesc may be useful if you want to add additional
> text, but technically, there is no benefit compared to <persName role="editor"> or the 
> like.

I had the same reservations earlier, but I now believe the line can be drawn between those who have, as Benni said, a "primary role" in the creation of the entity and those with a secondary one.  It's clear that creation of intellectual content is primary. For this role, TEI allows only <author>, which will not suit musical purposes.  I believe we need the ones I enumerated before:  <composer>, <librettist>, and <lyricist>.  <editor> and <arranger> are special cases as sometimes (as in the case of anthologies) there's no one else to assign credit to, so they take the primary role.  Where the creator of the item is known, however, the tradition is to assign the primary role to that person, with editors, encoders, arrangers, and the like taking a secondary one.  This is also entangled with the issue of deciding when a bibliographic entity is different enough to become a new "work".  MEI can't resolve that issue, only provide markup for allowing someone to make his/her choice clear.

> The benefit of <resp role="cmp">Komponist</resp> comes into play when you
> add @xml:lang to this. But the current Guidelines recommend to use <resp>komponiert
> von</resp>, not the proper noun.

> As I said, I see a benefit in <composer> etc., but I would really like to restrict these 
> elements as much as possible. 
>
> There is some risk down that road – I see MEI having to deal with the same 
> philosophical questions TEI has stumbled over, namely the discussion about the 
> distinction between persNames and persons. Don't you see a chance for s to stay 
> ignorant about this? Only because they have jumped out of the window, do we really 
> have to follow? Also, what does MODS allow that isn't possible with the current set? 
> Yes, it uses a slightly different model, but it actually contains the same information.
>
>If you really feel a need for those elements, I would like to draw the shortest possible 
> line, allowing only the most convincing elements. But who should identify them?

As far as I am concerned, consider the list of new elements limited to list given above.

I don't think this discussion has anything to do with personal names versus persons.  I think we can avoid that topic for now.  But I don't endorse self-imposed ignorance of any kind.  :-)

The allusion to MODS was not to say that it provides any new data points, only that an MEI encoding that did not use the role-like elements (composer, etc.) but used <respStmt> exclusively, would be closer to the MODS model and would therefore be easier to transform into, or derive from, MODS.

By the same token, using the role-like elements as described above would be closer to the approach taken by MARC.  I'm just trying to convey that MEI should not take a side in this battle, but allow users to choose a side for themselves.


--
p.