[MEI-L] Encoding of personal names
Roland, Perry (pdr4h)
pdr4h at eservices.virginia.edu
Fri Feb 8 14:40:42 CET 2013
Sorry for the short answers, but I'm only one guy trying to field questions from what sometimes seems like an army of questioners. I'm supposed to be working on MusicXML <-> MEI transforms and several other things too.
> 3) <respStmt> should definitely be allowed in <bibl>
added to /branches/MEI_dev/customizations/mei2013.xml
> 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:
My example was a literal copy of the data in a MARC record. If you prefer not to put the dates inside <persName>, then don't! And don't worry so much about a problem that hasn't happened yet. How do you think I got all these gray hairs? :-)
> 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.
Revision of <respStmt> is not on the table. I'm fine with following TEI's lead on this one.
> 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).
Also added in mei2013.xml.
--
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 Benjamin Wolff Bohl [bohl at edirom.de]
Sent: Friday, February 08, 2013 3:46 AM
To: Music Encoding Initiative
Subject: 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
More information about the mei-l
mailing list