[MEI-L] form & function

[Roland, Perry (pdr4h)]

Hi, everyone,

It was my intention that the musicclass element be used for this kind of "cataloging".  The <source> element allows <musicclass> as its last child.  For example,

          <musicclass>
            <keywords>
              <term n="form">score</term>
              <term n="function">sketch</term>
            </keywords>
          </musicclass>


Obviously, the <term> element contains a word or phrase describing the source.  The term can be "controlled", i.e., drawn from a particular thesaurus or ontology, or "uncontrolled".  In the example above, the terms "score" and "sketch" are uncontrolled, that is, they are my own invention.  I've labelled them with the n attribute so as to make a distinction between the two kinds of terms. This works well for those situations where only I need to make use of my descriptive terms.  Of course, this makes it more difficult for anyone else to search my corpus of encodings because my terms may be strange and inconsistently applied.

To improve this situation, there is another choice.  I can rely on standard thesauri by stating the source of the terms using <classcode> elements and by linking the terms to a particular <classcode> using the classcode attribute on <term>.  For example,
 
          <musicclass>
            <classcode id="cc1">Thesaurus of musical form terms</classcode>
            <classcode id="cc2">Thesaurus of musical function terms</classcode>
            <keywords>
              <term n="form" classcode="cc1">full score</term>
              <term n="function" classcode="cc2">sketch</term>
            </keywords>
          </musicclass>

In this case, the n attributes are probably unnecessary since "cc1" contains musical form terms and "cc2" contains musical function terms.

I think one should rely on standards wherever possible, but I can't offer much advice about which particular terms and classification codes to use.  Those choices have to be left to each encoder/project.  Obviously possibilities include Library of Congress subject headings, MARC leader and 008 field codes and the 047 (form of composition), 048 (instruments and voices), and 254 (musical presentation) fields, and the (apparently discontinued) Music Library Association music thesaurus project.

--
perry

________________
Perry Roland
Scholarly Resources
P.O. Box 400155
University of Virginia Library
Charlottesville, VA 22904-4155
434-982-2702 (w)
pdr4h at virginia.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: Thursday, March 05, 2009 6:35 PM
To: Music Encoding Initiative
Subject: [MEI-L] form & function

Hi all,

for the Edirom, we need to describe sources in a way that currently
seems to be unsupported by MEI (please correct me, Perry). We have no
encoded music to imply some of the information, so it needs to be
declared explicitly somewhere.

What we need is a distinction of the source's form: score, voices,
piano reduction… and also of it's function: sketch, fair copy,
presentation copy, working manuscript, performance material…

When thinking about prints, there might be the need for an explicit
labelling of first prints.



Regarding the form, a simple attribute @form on <source> might be
sufficient in most cases (what do you think about using <extent>
instead???).

For the function, we probably need an own element, probably as direct
child of <source> and sibling of <physdesc>. It might turn out that
the very same source serves a multiple or different functions in one
or more editions, and in that case we would need to specify the
context of the function with the help of an appropriate attribute.
This context thing is nothing we're currently worried about, but I see
some future problems in this field, and we should try to pick a
solution that's easily extensible later. Therefore I propose a
<function> within <source>.

Any comments?

johannes
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l