[MEI-L] form & function

[Johannes Kepper]

Hi Perry,

musicclass sounds not to bad for these things, but I haven't expected  
this kind of information in there. TEI's msDesc seems to be a good  
alternative (regarding the name), although I dislike the different  
approach for prints and manuscripts. Of course, prints and mss need  
different descriptions, but I think we should leave it to the user to  
break the format…

What do you think about renaming musicclass, giving it a more sounding  
name (at least for my ears)? Raffaele, how big are the differences  
between mei:musicclass and tei:msdesc? Do you think we can get a  
compatible solution?


--
johannes


Am 06.03.2009 um 18:09 schrieb 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
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l