[mei-neumes-ig] MEI Neumes Module Draft, Version 0.2

Inga Behrendt inga.behrendt at uni-tuebingen.de
Sat Sep 23 02:58:43 CEST 2017


Dear Thomas, dear Elaine,

we talked today about your suggestions during our Cantus Ultimus-Workshop.
(1) And it ended up saying that we think that terms like "acuta",  
"gravis", "punctum" fit to SOME notations, but not to ALL. However, we  
are trying to find a MEI Neumes Module Schema that covers all  
different kinds of neume notations. For example, Elsa de Luca, our  
expert in Old Hispanic Neume Notation, said that she cannot use such  
names for her signs.
And we all agreed that - if we want to create a Module Schema that we  
can use for all nematic notations - than we need to be very careful in  
the choice of names. So, I think, everybody in the Cantus Ultimus  
group would underline Andrew´s words from his previous mail:

"I have been under the impression that building a system built on  
explicit naming of neumes as elements would not be a good idea, based  
on critiques I have heard on the existing neume module. The same neume  
can have many names (across styles or languages) and building a system  
on neume names makes it more difficult to accurately capture the  
longer non-standard (i.e., "compound") neumes. Thus the reason for  
building a system based on shape contour, rather than shape name."

(2) Andrew mentioned the other point to your questions ("I'm also of  
the opinion that the current proposal has a significant bias towards  
the visual component,"). We are in the moment describing the shape of  
the notation signs rather than giving names. And long discussions let  
us think in the end that is better not to include the meaning of the  
neume sign. We just describe the neume shapes. For example, an  
episema: if it means a longer duration or if it is a modal indication  
or if it shows a semitone within a descending line..., all of this we  
know from different works of colleagues, is not encoded. We KNOW of  
the different meanings. But in order to not determine already now the  
meaning we rather describe the shape.

Herzlich
Inga

Zitat von "Prof. Dr. Morent" <stefan.morent at uni-tuebingen.de>:

> I would agree with the idea to encode the logical concept behind  
> neume signs, considering the individual visual appearance as a  
> "font" used by scribes within various traditions over time and space  
> and within these traditions to express individual meaning.
>
> Even if "producta" sounds probably unfamiliar to most chant scholars  
> as to now it has the advantage to have a historical-theoretical  
> background compared to the (modern invention) "tractulus".
>
> I would however be cautious with terms like "longer", "duration" ...  
> perhaps something like "light"/"heavy", "more emphasized", "strong"  
> ... would be more appropriate?
>
> best Stefan
>
> ----- Nachricht von Elaine Stratton Hild  
> <elaine.stratton_hild at uni-wuerzburg.de> ---------
>      Datum: Thu, 21 Sep 2017 14:05:37 +0200
>        Von: Elaine Stratton Hild <elaine.stratton_hild at uni-wuerzburg.de>
> Antwort an: Neumes Interest Group of the Music Encoding Initiative  
> <mei-neumes-ig at lists.uni-paderborn.de>
>    Betreff: Re: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
>         An: mei-neumes-ig at lists.uni-paderborn.de
>
>> Thanks so much for your time, Andrew (and all!).  My answers are  
>> below, marked with *. 
>>
>>  All best wishes,
>>  Elaine
>>  
>>
>>       
>>    
>>    
>>   Dr. Elaine Stratton Hild
>>   Corpus monodicum: Die einstimmige Musik des lateinischen Mittelalters    
>>        Julius-Maximilians-Universität Würzburg
>> Institut für Musikforschung
>> Domerschulstraße 13
>> D-97070 Würzburg            
>>      
>>
>>>>> Andrew Hankinson <andrew.hankinson at mail.mcgill.ca> 09/20/17 9:24 PM >>>
>> Thank you, Elaine! This clarifies a few things.
>>
>> "Shape" is a term I borrowed from the process of data modelling to  
>> mean two objects which share the same properties and values, but  
>> which may be completely different instances of something. Two  
>> houses with one door and 10 windows could be said to have the same  
>> 'data shape', and it doesn't matter if one is a bungalow and one a  
>> skinny three-story Dutch house, and one is called a 'house' and  
>> another a 'huis'.
>>
>> In this case, it simply means that two things that have a pitch  
>> contour of "up-then-down," for example, must be instances of the  
>> same class of things regardless of any particular name or  
>> identifier attached to them. The thing is defined by its  
>> properties, and not by a name that is given to it.
>>    
>>   ***Thank you for the explanation!
>>
>> Perhaps you could clarify a few things about the functioning of  
>> your proposed elements. It seems that there are properties of these  
>> symbols that are non-exclusive, and that a single symbol can carry  
>> with it multiple dimensions of description.
>>
>> As an encoder, when would I choose to use a 'gravis' over a  
>> 'puncta' if they can both mean 'lower' pitch? 
>>    
>>   ***These terms refer to different signs, different visual forms  
>> on the page. A gravis looks different than a punctus. (Gravis looks  
>> like \ while punctus looks like a period . In O splendidissima, the  
>> first notational sign above the syllable "splen" is an acuta  
>> connected to a gravis; two punctus are visible above the syllable  
>> "di")  A musicologist encoding the notation can record the basic  
>> visual forms with the terms gravis, acuta, punctus, producta. The  
>> meanings of these signs will need to encoded separately, because  
>> the meanings depend, to some extent, on context of the surrounding  
>> signs (which a musicologist can interpret). A punctus can mean  
>> "lower than preceding pitch" or it could also be slightly more  
>> ambiguous--it could mean "same or lower than the preceding pitch." 
>>    
>>    I understand that only puncta can be 'same or lower' but it  
>> seems, on the face of it, that there might be some confusion about  
>> when to use each. It also seems like there are three signs  
>> available to encode the 'same' pitch, two for 'lower', and only one  
>> for 'higher.' 
>>    
>>   ***When choosing which basic sign to encode, the musicologist  
>> will follow the scribe's use of the signs. Yes, you're right,  
>> different signs were used to convey the same information about  
>> pitch content. Conveying information about pitch content was not  
>> the only (or even the most important) aspect of notation for many  
>> medieval scribes. They used different forms to show different  
>> aspects of performance, and that's why it's important for us to be  
>> able to encode both the graphic signs (the visual domain) as well  
>> as the meanings we can glean from the scribe's use of the signs  
>> (the logical domain).  Returning to O splendidissima, the "lower"  
>> pitches the scribe wrote with punctus were probably performed  
>> shorter, or "lighter" than the the "lower" pitch recorded with the  
>> gravis. A musicologist should be able to add as much of this  
>> nuanced performance information that she wants, depending on her  
>> understanding of the notation and her desire for detail.
>>    
>>    Will this cover the range of pitch movements necessary in the  
>> repertoires?
>>    
>>   ***We need the options of neutral (or unknown), same, lower, same  
>> or lower, higher, same or higher. In some cases, a scribe will  
>> modify a sign to give additional information concerning pitch  
>> content. For instance, a scribe sometimes wrote a gravis longer,  
>> visually--extending down further than usual. (The gravis over  
>> "splen" happens to be one example.) The information about melodic  
>> interval is still "lower than previous pitch", but the musicologist  
>> might want to record the additional visual information (extended)  
>> and also record the meaning she attributes to the scribe's  
>> modification ("lower than the previous pitch by a third or more").  
>>  (In the case of O splendidissima, because the scribe used a staff,  
>> we can record absolute pitch levels--the descent of "g" to "e".)
>>
>> Both 'puncta' and 'producta' also seem to have an impact on  
>> duration, which I think should be clearly separated from pitch. Is  
>> there any way to separate the duration implications out from them?  
>> If we remove duration from the meaning of the sign (and encode it  
>> in a separate attribute), are 'punctus' and 'productus' effectively  
>> the same thing? 
>>    
>>   ****We would still differentiate between punctus and producta to  
>> reflect the sign the scribe used (for our visual domain). Yes, I  
>> think we absolutely should record the duration implications  
>> separately, because some scribes used "producta" as the standard  
>> sign for "lower" and "same or lower" pitches, while other scribes  
>> used "punctus" as the standard and only used "producta" in special  
>> situations, to indicate lengthened duration. I think Thomas Weber  
>> was considering suggesting the @dur attribute  
>> (data.DURATION.neumes) with the values "longer" and "shorter". 
>>
>> Is there a sign for 'same or higher with longer duration'? Is that  
>> necessary?
>>    
>>   **No, there's no basic sign for that. To show a higher pitch with  
>> longer duration, a scribe would add an episema to the acuta, or add  
>> a significative letter "t" (tenere) next to the acuta. The proposal  
>> from Thomas Weber and me would allow a significative letter element  
>> and using the @dur attribute (longer and shorter duration) to  
>> record the meaning of the scribe's use of episema and significative  
>> letters.
>>
>> Is there a reason the 'neume' element has been replaced with 'ncg'  
>> in the supplied encoding?
>>    
>>   ***Yes! We are trying to make the Neumes Module revision  
>> comfortable for all musicologists. The term neume can mean  
>> different things, depending on the context in which it is used, and  
>> the musicologist. Neume component grouping is clearly a technical  
>> term, specific to the encoding, that will not cause confusion for  
>> chant scholars.
>>
>> Cheers!
>> -Andrew
>>
>>> On 20 Sep 2017, at 16:55, Elaine Stratton Hild  
>>> <elaine.stratton_hild at uni-wuerzburg.de> wrote:
>>>
>>> Dear All,
>>>
>>> Thank you for your work on this.
>>>
>>> I agree completely, Andrew, that the neume names should be able to  
>>> be included in the encoding, but the encoding should not depend on  
>>> them. A quick thought concerning your suggestion below… “neume  
>>> name” (rather than “neume type” would probably be more specific  
>>> and clearer to musicologists (like me!) using the module.
>>>
>>> Just to clarify… the proposal Thomas Weber and I have put forward  
>>> does not rely upon neume names. The designations we recommend  
>>> (“acuta” / “gravis” \ “punctus” . and “producta” _ ) are the  
>>> earliest historical designations for notational signs, and—most  
>>> importantly—they are not limited to one notational type. (Perhaps  
>>> this is along the lines of what you meant with "data shapes",  
>>> Andrew?)
>>>
>>> They designate basic shapes that themselves convey basic  
>>> information (acuta = one note with the same or higher pitch;  
>>> gravis = one note with lower pitch; punctus = one note with same  
>>> or lower pitch and normal duration; producta = one note with same  
>>> or lower pitch and longer duration).
>>>
>>> They are especially convenient for encoding because they can be  
>>> combined to create all the notational signs of all types medieval  
>>> notation.
>>>
>>> (Small historical detour... For the writer of the 10th century  
>>> treatise where these terms are first used for musical notation,  
>>> the signs formed binary oppositions to each other: “Acuta” and  
>>> “gravis” were drawn from the study of grammar, with the acuta  
>>> placed over vowels where the voice rose in pitch and the gravis  
>>> placed with syllables where the voice fell in pitch. “Punctus” and  
>>> “producta” are symbols drawn from verse analysis: short syllables  
>>> in Latin were marked with punctus; long syllables were marked with  
>>> producta.)
>>>
>>> We suggest using these designations (as basic "data shapes"),  
>>> rather than the tilt attribute, because the basic meaning conveyed  
>>> by an acuta (the logical domain) remains consistent across all  
>>> medieval notations, but the nuanced tilt of the sign (the visual  
>>> domain, whether it’s written “north” or “northeast”, for example)  
>>> varies with individual scribes.
>>>
>>> Many thanks and all best wishes,
>>> Elaine
>>>
>>>
>>>
>>>
>>>
>>>
>>> Dr. Elaine Stratton Hild
>>> Corpus monodicum: Die einstimmige Musik des lateinischen Mittelalters
>>> Julius-Maximilians-Universität Würzburg
>>> Institut für Musikforschung
>>> Domerschulstraße 13
>>> D-97070 Würzburg
>>>
>>>
>>>>>> Andrew Hankinson <andrew.hankinson at mail.mcgill.ca> 09/20/17 4:58 PM >>>
>>> Hi Thomas,
>>>
>>> Thanks for this, and spending time putting forward some concrete  
>>> suggestions.
>>>
>>> I'm also of the opinion that the current proposal has a  
>>> significant bias towards the visual component. I believe this has  
>>> emerged largely because the exact musical content of some  
>>> repertoires is unknown, making a system built on a "logical"  
>>> domain approach to musical description difficult to define. (that  
>>> is, when all you have a symbol that is angled, and you don't even  
>>> know what pitch it is, how do you describe it musically?) That  
>>> said, I think it's worthwhile to try and tug the existing proposal  
>>> in the direction of addressing and describing the musical content  
>>> directly.
>>>
>>> I have been under the impression that building a system built on  
>>> explicit naming of neumes as elements would not be a good idea,  
>>> based on critiques I have heard on the existing neume module. The  
>>> same neume can have many names (across styles or languages) and  
>>> building a system on neume names makes it more difficult to  
>>> accurately capture the longer non-standard (i.e., "compound")  
>>> neumes. Thus the reason for building a system based on shape  
>>> contour, rather than shape name.
>>>
>>> That isn't to say that names are not a valuable thing to encode,  
>>> but the idea is that these names would be included in a separate  
>>> taxonomy within the file (or even a separate controlled  
>>> vocabulary) that might be referenced within an encoding. I think  
>>> this will go further towards making a general encoding system for  
>>> all neumed repertoires, instead of narrowing it down to a  
>>> particular style.
>>>
>>> You might imagine something along the lines of:
>>>
>>> <neume type="#clivis">
>>> ...
>>> </neume>
>>>
>>> or
>>>
>>> <neume type="http://example.org/neumevocabulary#clivis">
>>> ...
>>> </neume>
>>>
>>> This would let you use your own controlled vocabulary to name  
>>> things for your own encoding, while maintaining a more general  
>>> 'data shape' for the musical structures, allowing them to be  
>>> compared across repertoires.
>>>
>>> -Andrew
>>>
>>>> On 20 Sep 2017, at 15:26, Thomas Weber  
>>>> <thomas.weber at notengrafik.com> wrote:
>>>>
>>>> Dear group,
>>>>
>>>>
>>>> Elaine and me looked at both the Hildegard example as well as the  
>>>> "standard" neumes table by Cardine and made an attempt at  
>>>> encoding the signs' properties with better separation of domains.  
>>>> We tried to add more logical domain information to the previously  
>>>> mostly graphical domain info.
>>>>
>>>> Our thesis was that the main distinguishing factor between  
>>>> different use cases of the Neumes module is in how much detail  
>>>> the notation should be described. Many projects right now use the  
>>>> Volpiano font to capture only the melodic contour and potentially  
>>>> connection information. For Corpus monodicum, we want to encode  
>>>> more properties of single staff-bound components, mainly whether  
>>>> a component is an oriscus, quilisma or strophicus. Our  
>>>> understanding is that the Old Hispanic project as well as the  
>>>> Optical Neumes Recognition project need even more detailed  
>>>> information to be encodable.
>>>>
>>>> We came to the conclusion that the problem we still need to solve  
>>>> is better separation of visual and logical domains. Our  
>>>> impression is that the visual domain is of primary importance for  
>>>> both of the named projects. That might be the reason why the  
>>>> current draft seems to mainly focus on the visual domain.
>>>>
>>>> We prepared the following table based on Cardine that outlines  
>>>> our suggested encoding.
>>>>
>>>> http://cm.notengrafik.com/2017-Graz-Cantus-Newtork/cardine-table/cardine_web.xml
>>>>
>>>> The most obvious addition are sub-elements describing each <nc>  
>>>> as one of the seven basic single pitch signs (four basic signs  
>>>> based on Anonymus Vaticanus: acuta, gravis, punctus, producta;  
>>>> three special signs: quilisma, oriscus, strophicus). We chose to  
>>>> make them elements so that each of those can get its specific set  
>>>> of attributes describing them in more detail, like "extended" for  
>>>> acuta/gravis (understood to indicate larger intervals) or "waves"  
>>>> for quilisma. The idea behind that was to make it clearer which  
>>>> attributes are usable in which contexts, but this could also be  
>>>> done by means of Schematron rules when using attributes instead  
>>>> of elements - which we did in our pre-Graz state of ideas:
>>>>
>>>> http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presentation.html#variations
>>>> http://cm.notengrafik.com/2017-Graz-Cantus-Network/presentation/presentation.html#code-sign
>>>>
>>>> We suggest to represent the "angled" property using the @con  
>>>> attribute, as "angularity" is a property of the connection.  
>>>> Depending on the sign, the logical meaning of this would be to  
>>>> lengthen the component before or after the angled connection.  
>>>> This logical domain info could be recorded using @dur on the  
>>>> proper <nc>.
>>>>
>>>> We picked up Ich's encoding of "O splendidissima" and made a  
>>>> modified version here:
>>>>
>>>> http://cm.notengrafik.com/2017-Graz-Cantus-Network/O_splindidissima.mei
>>>>
>>>> Here we also tried to illustrate how more detailed visual domain  
>>>> information could added, namely the suggested @tilt. As the tilt  
>>>> is in most cases a consistent scribal idiosyncrasy, this might  
>>>> however better be solved using the tables of signs that Stefan  
>>>> Morent reminded us of recently. There, these idiosyncrasies could  
>>>> be described once for an entire file, source or hand. Johannes  
>>>> (hi to Johannes in CC) suggested that these "standard" patterns  
>>>> of writing might be best put in <scoreDef> and to encode  
>>>> deviations where they occur. These tables could also be useful to  
>>>> document variation among tokens.
>>>>
>>>> We suggest to keep the table problem and how to link between the  
>>>> content and the tables (by semi-standardized names, by project  
>>>> specific naming/numbering schemes or by simple XML IDs, or maybe  
>>>> implicitly by characteristic sequence of single pitch signs) for  
>>>> later discussion, together with other topics like how to  
>>>> represent mi signs and rubrics.
>>>>
>>>> We wish you a fruitful workshop in Halifax, and we are looking  
>>>> forward to hearing about any outcome concerning the neumes module!
>>>> Thomas
>>>>
>>>>
>>>> Am 07.09.2017 um 14:57 schrieb Ichiro Fujinaga, Prof.:
>>>>> Here’s what I have for the draft of the proposal for the new MEI  
>>>>> Neumes Module schema.
>>>>> I’ve arbitrarily named it Version 0.2, so that we can refer back to it.
>>>>>
>>>>> For ease of discussion and efficiency, please discuss one issue  
>>>>> at a time in separate email threads, e.g., Re: @oriscus.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ichiro
>>>>>
>>>>> ==============================
>>>>> MEI Neumes Module Draft, Version 0.2
>>>>>
>>>>> A <neume> element consists of one or more <nc> element(s).
>>>>>
>>>>> A <nc> (neume component) is a single pitched event, although the  
>>>>> exact pitch may not be known.
>>>>>
>>>>> Attributes for <neume>:
>>>>> @intm (interval melodic; relative to the previous <neume>)  
>>>>> {u|d|s|n|sh|sl} (u = up/high, d = down/low, s = same, n =  
>>>>> neutral/unknown, sh = same or higher (but not lower), sl = same  
>>>>> or lower (but not higher))
>>>>> @significative letters
>>>>> @hispanicTick (type1, type2)
>>>>> @hook
>>>>>
>>>>> Attributes for <nc>:
>>>>> @pname
>>>>> @oct
>>>>> @intm (interval melodic; relative to the previous <neume>)  
>>>>> {u|d|s|n|sh|sl} (u = up, d = down, s = same, n =  
>>>>> neutral/unknown, sh = same or higher (but not lower), sl = same  
>>>>> or lower (but not higher))
>>>>> @wavy
>>>>> @significative letters
>>>>> @curved (anticlockwise, clockwise)
>>>>> @angular (plain, v-shaped, staircase) (was @angled)
>>>>> @liquescence
>>>>> @episema
>>>>> @extended
>>>>> @tilt {n|ne|e|se|s|sw|w|ne} (north, northeast, etc.)
>>>>> @quilisma (2, 3, or 4 curves)
>>>>> @oriscus (curved, flat, jagged)
>>>>> @con (gapped, looped) (connection to the previous <nc> within  
>>>>> the same <neume>)
>>>>>
>>>>> Removed from the previous version: @jagged, @flat, @long,  
>>>>> @diagonalright, and @hispanicLoop from the <neume> level.
>>>>>
>>>>> _______________________________________________
>>>>> mei-neumes-ig mailing list
>>>>>
>>>>> mei-neumes-ig at lists.uni-paderborn.de
>>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>>>>
>>>> --
>>>>
>>>> Notengrafik Berlin GmbH
>>>> HRB 15007
>>>>
>>>> UstID: DE 289234097
>>>> Geschäftsführer:
>>>> Thomas Weber und Werner J. Wolff
>>>>
>>>> fon: +49 30 220661685
>>>>
>>>> Leuschnerdamm 13
>>>> 10999 Berlin
>>>>
>>>> notengrafik.com
>>>>
>>>> _______________________________________________
>>>> mei-neumes-ig mailing list
>>>> mei-neumes-ig at lists.uni-paderborn.de
>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>>>
>>> _______________________________________________
>>> mei-neumes-ig mailing list
>>> mei-neumes-ig at lists.uni-paderborn.de
>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>>> _______________________________________________
>>> mei-neumes-ig mailing list
>>> mei-neumes-ig at lists.uni-paderborn.de
>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>>
>> _______________________________________________
>> mei-neumes-ig mailing list
>> mei-neumes-ig at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>
> ----- Ende der Nachricht von Elaine Stratton Hild  
> <elaine.stratton_hild at uni-wuerzburg.de> -----




More information about the mei-neumes-ig mailing list