[MEI-L] Encoding of personal names
Benjamin Wolff Bohl
bohl at edirom.de
Fri Feb 8 11:48:26 CET 2013
Hi Axel,
thanks for joining the discussion!
Am 08.02.2013 11:06, schrieb Axel Teich Geertinger:
> Hi all,
>
> I guess I was just hoping somehow to stay out of this... sorry :-)
>
> I think (possibly contradicting something I might have said earlier) that the only "clear" line we can draw – if that is what we want – would be to avoid special elements for specific roles (<creator>, <composer> etc.) all together. I somehow like the idea of treating all persName-like elements the same, using @role to specify the role. That gives us maximum flexibility and expandability, and we could process all those elements the same way. I cannot see anything we can do with <composer> that cannot do with @role="cmp", except that in some cases we may have to choose <corpName> instead of <persName>, if the role is not associated with a single person.
>
> I agree with Benni that putting dates into persNames looks... peculiar. Rather than trying to nest a description of a person into the person's name, I would try to link the name to some authority resource for disambiguation and further information.
Linking to an authority resource sounds like a very good idea, for example:
<persName authority="GND" authURI="http://d-nb.info/gnd/"
dbkey="118629662">Carl Maria von Weber</persName>
Nevertheless my spelling of the name is not the same as in the GND
resource. Should it be?
>
> I see another conceptual problem concerning @authority or @authURI as used in Perry's example:
> <resp authURI="http://www.loc.gov/marc/relators/relaterm.html" code="cmp">Composed by</resp>
>
> Just from the syntax, I would expect @authURI to refer to the content of the element, but here in fact it refers to @code. How do we avoid that ambiguity? Or: how can attributes explicitly refer to another attribute rather than to the element? If I understand it right, we can have
> <resp authURI="http://www.loc.gov/marc/relators/relaterm.html">cmp</resp>
> or
> <resp authURI="http://www.loc.gov/marc/relators/relaterm.html">composer</resp>
> but not
> <resp authURI="http://www.loc.gov/marc/relators/relaterm.html" code="cmp">Komponiert von</resp>
> – or am I mistaking?
I understand it the same way you do.
>
> Exactly for this reason we have chosen not to use the authority/authURI attributes on persNames or responsibilities, even though we do stick to the MARC relators list. The consequence, however, is that we cannot be sure (at least in principle) to resolve @role using MARC (e.g., translating "cmp" to "composer" in the output), so we actually use the written-out roles from the MARC list:
>
> <persName role="composer">Beethoven</persName>
>
> That is also the reason why we do not add @authURI=" http://www.loc.gov/marc/bibliographic/bd048.html" to
> <instrVoice code="wa" count="2" solo="false">fl.</instrVoice>
>
> Any thoughts on how to solve this?
>
> /axel
In spelling out the role you avoid the problem only as long as you can
assign a definitive role. I just went through all the responsibilities I
had in one of my recording data sets and instantly ran into problems
when a team of persons were responsible and one would be the team
leader. This would require me to insert "Lead" into @role as well and
when it comes to composite terms I would have something like
@role="Recording engineer Lead" making it hard to separate the different
terms by other means than capital letters.
What I could think of is to treat the @code on <role> as in the above
example with the association of <persName> to an authority.
<resp code="rce led" authority="..." authURI="...">Aufnahmeleitung<!--
as spelled in the source--></resp>
It's qustionable whether the association of another attribute (@code)
with @authority and @authURI is/should be the same as with @dbkey or
whehter the MARC list or similar controlled vocabularies should be
denominated as "authority". One could actually allow @dbkey on <resp>
instead of @code, no?
cheers,
benni
> -----Oprindelig meddelelse-----
> Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Benjamin Wolff Bohl
> Sendt: 8. februar 2013 09:47
> Til: Music Encoding Initiative
> Emne: Re: [MEI-L] Encoding of personal names
>
> On a scond try of replying to this mail...
>
> 1) Thank you Perry for the code examples, these brought me back of not only thinking about the elements but also to consider the context in which they appear.
>
> 2) Of course in an ideal world, we would model a perfet way of coping with all this and get MOD and MARC and whichever scheme exist to conform with us ;-). But all these standards exist and are being used so not standing in the way of certain ones when trying to convert from or to MEI is very important. After all, we want MEI to spread.
>
> 3) <respStmt> should definitely be allowed in <bibl>
>
> 4) Although being yet another poblem, the person-vs-persName problem Johannes mentioned is at the brink of bothering us. Seein <date> as child of <persName> makes me feel uncomfortable. I'd prefer:
>
> <composer><persName>Beethoven, Ludwig
> van<persName><date>1770-1827</date></composer>
>
> The date is not part of the person's name, although it's additional info for identifying purposes etc.
> Then again, this is not possible within <respStmt> which should be an alternative for <composer>. Even if I was allowed to put <date> in <respStmt> I'd expect this date to be associated with the responsibility, not the person.
>
> <respStmt>
> <resp>composed by<resp>
> <persName>Beethoven, Ludwig van<persName>
> <date>1811-1812</date><!-- being the years in which LvB composed the 7th --> </respStmt>
>
> similar to <pubStmt>!
> But <composer> would not be able to hold this date of composition. Thus the benefit of explicitly marking a <composer> would deprive me of the possibilities to add additional data concerning the composition process.
> Now if I understand the needs of librarians right you would try to put in as much of the metadata as you can find on your item and if there's Beethoven's dates of birth and death you put them in the "author"
> (composer) field. But why? Are these dates part of the name for identifying purposes? Or is it the intention of "transcribing" all the metadata supplied by the "source" itself?
>
> 5) I think we should dissalow multiple <resp>s in the same <respStmt> or is there any other grouping mechanism for the children of <respStmt> other than xml-order? Making it more feasible to process.
>
> 6) Still an open question for me is the @code on <resp> which is not allowed in the current mei-all.rng in trunk (or at least not in my working copy). Neither could I find an issue on google code referring to it. Did I miss anything?
> It's definitely good to have such an attribute (as e.g. in <instrVoice>), but does this attribute by any means correlate with @authority and @authURI (which I had expected so far but Perry if I got him right discouraged such attribute-correlation).
>
>
> cheers,
> benni
>
> Am 07.02.2013 20:18, schrieb 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.
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
More information about the mei-l
mailing list