[MEI-L] Encoding of personal names
Roland, Perry (pdr4h)
pdr4h at eservices.virginia.edu
Fri Feb 8 16:38:21 CET 2013
In fact, this calls into question all of the revisions of <bibl>, including <recipient> and <genre> as well as <imprint> and its children, <publisher>, <distributor>, and <pubPlace>.
--
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 Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu]
Sent: Friday, February 08, 2013 10:22 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] Encoding of personal names
Sorry for the thrashing about. But if <composer>, etc. go, so also do <creator>, <contributor>, and <recipient>. Sorry, but you're back to <name>, <persName> and <corpName> with @role.
--
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+pdr4h=virginia.edu at lists.uni-paderborn.de [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk]
Sent: Friday, February 08, 2013 10:13 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] Encoding of personal names
>Precisely! That's why I don't understand the tempest their addition has created. But since you all object so
>strongly, I will remove them.
[...]
>isn't possible in fileDesc and why it's not possible to capture creator-like information for musical works in <bibl> without abusing <author>.
Theoretically, I agree it's best not add these elements. From a pragmatic point of view... well, following the recent <bibl> discussion we had just implemented <creator> and <recipient> for letter references in MerMEId. So now I would have to remove them again. Anyway, I am not going to postpone (again) the opening of the MerMEId demo version we have scheduled for next week. Instead, we'll offer a transformation to whatever we will agree on when MEI2013 is released. It's hard to follow a target moving as fast as MEI :-)
Best,
Axel
__________________________
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 Johannes Kepper [kepper at edirom.de]
Sent: Friday, February 08, 2013 9:22 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] Encoding of personal names
Am 08.02.2013 um 15:03 schrieb "Roland, Perry (pdr4h)" <pdr4h at eservices.virginia.edu>:
> Thanks for the quotes from the Guidelines. But, remember, we wrote them, we can un-write them!
>
Yes, but we arrived there after some very intense discussions. This was probably not the best solution, but it was a solution that everyone could agree on. To paraphrase you, we managed to upset everyone to the same degree. If you start the discussion over and over again, you don't accept this balance.
> The Guidelines contradict me all the time. Or do I contradict them? Some days I feel like abiding by them, some days not so much. Don't think too literally. Don't let your quest for perfection stop you from creating something that's by and large pretty damn good.
>
>> This example illustrates the problem of attributes referring to each other.
>
> Ok, Like I said, sometimes this kind of thing can be avoided, sometimes it can't. Sue me.
>
>> These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values
>> for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for
>> other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're
>> quite safe _by following a convention as expressed in the Guidelines_.
>
> Ok, so don't sue me. Just go with it.
It's not about blaming someone. We all agree that this isn't simple, that there is no perfect solution, and that one has to be conscious about the model he uses. There is nothing wrong in discussing the benefits and drawbacks of certain models. I'm just reluctant to add yet another possibility getting confused.
>
>> So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is
>> the case, I would probably argue to follow TEI in the the land of <person>, <place> etc. The <persName>s would
>> then point to <person>s, which in turn may have multiple references to authorities (probably using <identifier> or
>> some such as child elements). There would be no direct linking from the individual names anymore.
>
> Axel's not using authorities at all and you're introducing the idea of multiple authorities. Again, I'd like to caution against inventing new problems to solve, claiming the old solutions don't solve the new problem. Of course they don't, they weren't designed to. New problems need new solutions. And TEI may point in a good direction or not. Right now, though, with the end of the grant looming large on the horizon, we don't have time to tackle new problems, especially not one this contentious.
>
But if I overlook the discussion correctly, it seems like you're the only one insisting on introducing <composer> and the like. If we'd leave that out and stick with the situation we had in 2.0.0, there is no issue. And to be honest, up to the level we discuss here, there is not much of a difference between <composer/> and <name role="composer"/>. I hardly see a war between different standards at this basic level…
I don't want to kill the discussion here, but if you have so many other obligations (and I know you have), do we really need to add this? Or wouldn't it be easier to remove it from the dev version? Is there someone else sufficiently attracted by the proposed elements to keep the discussion going?
Best,
jo
> --
> 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 Johannes Kepper [kepper at edirom.de]
> Sent: Friday, February 08, 2013 5:32 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] Encoding of personal names
>
> Am 08.02.2013 um 11:06 schrieb Axel Teich Geertinger <atge at kb.dk>:
>
>> 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.
>>
>> 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?
>
> Again, let's have a look at the friendly manual. We have an example on page 217, which reads
>
> <persName
> authURI="http://d-nb.info/gnd"
> authority="GND"
> dbkey="118584596"
> role="composer">Wolfgang Amadeus Mozart</persName>
>
> This example illustrates the problem of attributes referring to each other. Do @authURI and @authority provide additional information for @dbkey or @role? Luckily, the Guidelines give further explanation preceding the example. They read:
>
> "The Marc code list for relators offers a variety of controlled terms that may serve as values for this use of @role."
>
> This can be understood as a default specification of the values of @role. The Guidelines continue:
>
> "For names in the metadata header, the use of a controlled list, such as the Gemeinsame Normdatei (GND) or the Library of Congress Name Authorities, is recommended. The name and web-accessible location of the list may be recorded using the @authority and @authURI attributes, respectively. To record a value which serves as a primary key in an external database, the @dbkey attribute may be used."
>
> These attributes are explicitly intended to be combined. As long as the MARC list of relators gives us all required values for @role, and we don't have to opt for a different authority list here, @authority, @authURI, and @dbkey are free for other uses. As soon as the MARC list does not suffice, we are indeed running into problems, but up to that point, we're quite safe _by following a convention as expressed in the Guidelines_.
>
> So, the question is if we need to have multiple values from different controlled authorities for a single entry. If that is the case, I would probably argue to follow TEI in the the land of <person>, <place> etc. The <persName>s would then point to <person>s, which in turn may have multiple references to authorities (probably using <identifier> or some such as child elements). There would be no direct linking from the individual names anymore.
>
> Best,
> Johannes
>
>
>
>
>>
>> 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
>>
>> -----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
>
>
> _______________________________________________
> 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
_______________________________________________
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