[MEI-L] form & function

Roland, Perry (pdr4h) pdr4h at eservices.virginia.edu
Fri Mar 6 19:57:53 CET 2009 

All,

I think it would be very bad indeed to put TEI's msdesc element into MEI at this time.  I don't see a reason to replicate msdesc in MEI mainly because it's too complex.  I think I've provided most of the same description capabilities in MEI in a simpler fashion; that is, via the sub-elements of physdesc.

The name "musicclass" is an adaptation of "textclass" from TEI P4.  And I'm not opposed to renaming it as long as the new name isn't "msdesc"!  :)  That would cause a different kind of confusion.  However, I don't have a different name on the tip of my tongue right now.

--
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: Friday, March 06, 2009 1:30 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] form & function

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


_______________________________________________
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