[MEI-L] Encoding of personal names

Eleanor Selfridge-Field esfield at stanford.edu
Mon Feb 4 22:39:18 CET 2013


Kristina poses interesting questions.  Instinctively I would go for
"composer", "encoder," etc and err on the side of being verbose and
explicit.  With electronic data, being able to track who encoded what
(with version number and date) can be very valuable.  

 

I find labels such as "creator" and "corporate name" very unwieldy,
particularly when working in a second language (in my case usually
Italian).  Italian bibliographical databases a full of these kinds of
terms, but there is something subtly cultural about the misunderstandings
they can create.  The various instantiations of a single work can have
many creators-a composer, an arranger, and editor, a translator of the
text, and in the case of recording a conductor, performer, performing
group, etc. Because they can all pertain to a single work, a general label
deprives the user of knowing what the role of each one was.  

 

A much messier area is dating.  A single work can have an almost endless
number of "year"s-of composition, publication, first performance, revision
<1..n>, arrangement, recording, text translation, etc.  There too being
more specific saves time for those searching.  

 

Best regards,

 

Eleanor

 

 

Eleanor Selfridge-Field
Consulting Professor, Music (and, by courtesy, Symbolic Systems)
Braun Music Center #129
Stanford University
Stanford, CA 94305-3076, USA
 <http://www.stanford.edu/~esfield/> http://www.stanford.edu/~esfield/ 

 

 

 

From: mei-l-bounces at lists.uni-paderborn.de
[mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Kristina Richts
Sent: Monday, February 04, 2013 9:55 AM
To: mei-l at lists.uni-paderborn.de
Subject: [MEI-L] Encoding of personal names

 

Dear all,

during the work on the MEI sample collection, questions appeared on how to
encode the creators of each electronic file correctly.
In MEI2012 the normal path (or better said: the way, we first chose to
encode it) was to encode several <persName>-elements within the statement
of responsibilty. A differentiation between several involved persons only
became apparent through additional @role-attributes, i.e. 
<respStmt>
   <persName role="composer">Anton Webern</persName>
   <persName role="creator">John Doe</persName> 
</respStmt>

In a second step we decided not to encode ourselves as "creators" of the
file (although we are), but as "encoders" and to assign the composer of
the encoded work as creator, i.e.

<respStmt>
   <persName role="creator">Anton Webern</persName>
   <persName role="encoder">John Doe</persName> 
</respStmt>

The decision is based on the fact, that we encode the intellectual
creation of a composer's work. We tried to keep up the distinction between
the composer and the encoder. 

MEI2013 will offer some new elements to specify the role of persons,
organizations etc. a bit more: <creator>, <contributor>, <editor>,
<funder> and <sponsor>. 
In this regard it is now the question how to encode this best:
 
<respStmt>
    <creator>   
        <persName>Anton Webern</persName>
    </creator>
    <creator>
       <persName>John Doe</persName> 
    </creator>
</respStmt>

or

<respStmt>
    <creator>   
        <persName role="composer">Anton Webern</persName>
    </creator>
    <creator>
       <persName role="encoder">John Doe</persName> 
    </creator>
</respStmt>
?

We first thought, it would be a good idea, to add a <composer> element to
the list. But that alone would not be sufficient, as the creative aspect
regarding musical works is difficult to manage. In this case, we would
rather have to extend the list by adding some more elements like
<arranger>, <lyricist>, etc. But this can soon become very unwieldy.

I have to admit that I don't prefer to encode detailed specifications only
within child elements. However, if we choose to maintain the 'more
detailed elements', I would at least like to see some mandatory child
elements, such as <persName>, <name>, <corpName> etc., in there. 

When thinking about all this, I came to the conclusion, that it might be
enough to allow a <creator> and a <contributor> element (with some
mandatory child elements). I am not even sure, if we should offer a
separate <editor> element or if an editor should be considered as a
contributor as well.
What is to be said against a specification of the role on the <creator> or
<contributor> element? Wouldn't this make things easier to handle for the
encoder, who might not know as much about the encoding of persNames with
MEI?

 
Any comments on this?

Best,
Kristina

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20130204/41a35af1/attachment.html>


More information about the mei-l mailing list