[MEI-L] Notation type
Roland, Perry (pdr4h)
pdr4h at eservices.virginia.edu
Tue Sep 20 19:26:54 CEST 2011
Andrew,
It's true that there's no controlled vocabulary for notation types, but uncontrolled terms are permitted within <classification> so I don't see how <notationDesc> (where I presume the value of notationFamily/@name is uncontrolled) is a huge improvement over <classification>, especially since the kind of data element -> metadata linking that you suggest is already available via the decls attribute (which is available on 26 elements, among them music, section, staff, and layer).
<classification> does occur in the header, but it doesn't apply to the whole file. It applies to its <source>, <relatedItem>, or <work> parent. (N.B. Once upon a time, it existed within <fileDesc> as well and we could put it back there if classification of the file itself is necessary.)
The advantage of the <notationDesc> approach is that perhaps it can provide a natural language description of the notation as opposed to <classification> which is more of a thesaurus/ontology. Still, I'm concerned that <notationDesc> provides a second place to put a specific kind (classification?) of classification information, leading users to question when/how to use it as opposed to <classification>.
Also, is this a change you'd like to see in the next release or can we postpone this discussion 'til later?
--
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 Andrew Hankinson, Mr [andrew.hankinson at mail.mcgill.ca]
Sent: Tuesday, September 20, 2011 11:17 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] Notation type
Thanks, Perry.
I looked at classification, but as you rightly point out there is no controlled vocabulary for notation types. I'm not interested in trying to create a controlled vocabulary for notation types, since that really does seem like a way to get nowhere, fast. <classification /> is also global (being in the header), and affects the whole file. If I were encoding both mensural and CMN in the same file (e.g., the tradition of including the original notation as an incipit in a modern edition), then simply noting what modules were used or capturing some sort of information in <classification /> would not be specific enough. The only indication that I was in mensural notation would have to be drawn from the use of mensural durations on the notes (breve, semibreve, etc.) or other elements specific to this notation. To do this automatically would require the computer to try and infer what was going on, and we all know how good a machine's inferences are…
I'm not too sure that there's an equivalent problem in the text world. Various parallels could be drawn to language, script style or hand, all of which are in TEI in some form or another. I think that perhaps the most direct parallel (although still imperfect) would be language, and I would be shocked to find out that TEI doesn't allow you to capture which language was being used at any given point in the document.
Perhaps the term "notation family" would be more appropriate. For neumed notation there are different sub-types (sangallan, aquitanian, hufnagel, etc.) that would all fall under the "neume" family. Likewise in mensural there is "white" and "black" notation.
My suggestion would be to add a <notationDesc /> section and allow pointers to it from <section />, <score />, or <music />, e.g.,
============
<notationDesc>
<notationFamily xml:id="foo" name="mensural" />
<notationFamily xml:id="bar" name="cmn" />
</notationDesc>
...
<music notationfamily="bar">
...
<section notationfamily="foo">
...
</section>
...
</music>
============
<notationFamily /> could then have child elements to describe characteristics of the notation itself (for neumes, the specific sub-type, heighted/unheighted, etc.)
-Andrew
On 2011-09-20, at 9:12 AM, Roland, Perry (pdr4h) wrote:
> Hi Andrew,
>
> Your assessment is correct -- there's currently no dedicated way of recording the kind of notation or modules in use.
>
> I've always thought this was a classification issue; that is, that one could use <classification> to hold an indication of the file's qualities not otherwise carried in the markup, including the notational type. This isn't all that much different from saying this file is a motet or a symphony using <classification>. What's required, of course, is agreement on standard labels for the various kinds of notation. But there are lots of different types and sub-types of notation, and I fear that trying to reach agreement on their names and content will lead nowhere very quickly.
>
> Perhaps we can avoid this problem by documenting which modules were used in this particular instance. This is relatively easy to add, say, in the MEI header. But how far do we go? For instance, what if I've modified the mensural module, removing some existing elements and adding some new ones? Can/should I still claim that I'm using the mensural module or even that the markup is "mensural notation" since I've changed the definition of "mensural"? Must I document my ODD customization in the MEI header? Isn't this redundant if the customized ODD itself is provided? In fact, isn't any documentation of the syntax of the schema in the document instance redundant?
>
> You see, when we start down this path, it gets rocky pretty quickly. So, I chose to avoid it with the generic <classification> approach, but if reasonable arguments can be made for adding a more specific method, then I'm not opposed.
>
> By the way, I don't think there's anything like this in TEI, so I wonder what the reasons were for not including something like this there. Can anyone enlighten me?
>
> Regards,
>
> --
> 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 Andrew Hankinson, Mr [andrew.hankinson at mail.mcgill.ca]
> Sent: Tuesday, September 20, 2011 1:05 AM
> To: Music Encoding Initiative
> Subject: [MEI-L] Notation type
>
> Hi all,
>
> I've been looking through the documentation and I cannot seem to find a method (element or attribute) for specifying the type of notation being encoded.
>
> We have modules for mensural, tablature, neumes, etc., but once the schema is constructed from these modules there seems to be no way of specifying the type of notation used. It seems that the type of notation can only be derived implicitly by looking at the elements and attributes present in the encoding.
>
> There is the "@type" attribute on some possible candidate elements (<score />, for example), but that seems like it's meant to be generic and can be used for just about anything.
>
> This seems like it should be possible, but I can't find it. Have I missed something?
>
> Thanks,
> -Andrew
> _______________________________________________
> 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