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

Andrew Hankinson andrew.hankinson at mail.mcgill.ca
Wed Sep 20 16:58:17 CEST 2017


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



More information about the mei-neumes-ig mailing list