[mei-neumes-ig] Minutes of Meeting: Tübingen, 19 November

[Ichiro Fujinaga, Prof.]

Sounds like you had a very productive meeting!
Thank you, Andrew, for taking and posting the minutes.

As a member of the MEI Board, I’ll ask if you can set up a repository on the MEI GitHub.

Ichiro

> On Nov 20, 2016, at 2:31 PM, Andrew Hankinson <andrew.hankinson at mail.mcgill.ca> wrote:
> 
> Hello all,
> 
> Here are the minutes of the meeting we had yesterday in Tübingen. Attendees, please reply and comment if there are amendments to be made. 
> 
> Cheers,
> -Andrew
> 
> ------
> 
> MEI Neumes Interest Group Meeting : 19 November 2016, Tübingen, Germany
> 
> Present:
> - Andrew Hankinson (U. Oxford)
> - Kate Helsen (U. Western Ontario)
> - Elaine Hild (U. Würtemberg)
> - Stefan Morent (U. Tübingen)
> - Jason Stoessel (U. New England)
> - Thomas Weber (Notengrafik Berlin)
> - Werner Wolff (Notengrafik Berlin)
> 
> A meeting of some members of the MEI Neumes Interest Group took place at the University of Tübingen, after the "Digital Methods in Musicology Winterschool." The meeting started at 18:00.
> 
> Stefan opened the meeting with a reminder of the first meeting of the SIG at the Music Encoding Conference in Mainz in 2013. Andrew mentioned that the MEI Neumes SIG mailing list was now functioning, and encouraged the members present to sign up and use it as a discussion forum for the group, so that everyone could be 'in the loop.'
> 
> Andrew reviewed some of the recent discussions that had been taking place in various forums since the last meeting. Notably, he acknowledged the work of Emma Hornby's team at Bristol in developing their contour-based description of individual neumes, and that this was the basis of the current discussions in individual neume descriptions. It was agreed that this was a better way forward than the current requirement to 'name' individual neumes. Andrew mentioned that it would still be possible to assign a name to a neume, but that this would be handled through a reference to an item in a taxonomy, likely held in the MEI header of a given file.
> 
> Andrew discussed the structure of a neume element, and the necessary separation between a "pitch" and a "component". A component was described as an individual pitch-carrying element, although the exact pitch may not be known (e.g., Hartker). It was also acknowledged that one of the reasons for the existence of a component separate from a 'note' element was the need to describe the connections between the individual components. Jason clarified that adopting component would not have an impact on the data he already had with John Stinson's corpus. 
> 
> Jason asked whether 'component' was over-engineering for pitched repertoires, since the contour was implicitly carried on 'note' if a pitch name was present. Andrew presented two arguments: one, that it was over-engineering and that it might be sufficient to simply contain 'note' within 'neume', and two, that it would be better for software developers if we could expect a consistent structure within neume, and that component was necessary to capture relationship between two components. After some discussion it was agreed to require 'component' as a container for 'note', but that it could be minimally described.
> 
> Thomas asked if we could 'overload' the note element to describe the contour, but Andrew mentioned that having the separation between note and component was useful, since we want to describe the connection between the individual pitches, and that 'component' was a useful abstraction. Elaine mentioned that the word 'component' was not present in standard literature about neume structure. Andrew acknowledged this, and that it was not set in stone should a more suitable name be offered.
> 
> Werner raised a question of whether we were describing a 'pitch' or a 'pen stroke' within a neume. After some discussion we agreed that it was a pitch, since pen strokes would differ between notation styles. THis would mean cross-style comparison would be more difficult.
> 
> Kate presented the table that she and Inga had been working on, and described their plan for how individual neumes might be identified by unique combinations of individual components. The "@modification", "@connection", and "@liquesence" attributes were proposed for the 'component' element. Andrew clarified that the "relation to previous" and "relation to next" attributes with values of 'H', 'L', or 'N' were necessary to be carried on the 'neume' element.
> 
> Andrew moved the discussion to the question of textual representation, and acknowledged that the current method of organization in MEI Neumes (syllable-first) came from Stefan's work. Andrew presented two options: one, that we keep the syllable-first organization since it could be argued that a neume was a 'property' or 'sonification' of that syllable, and this organization represented that subordinate relationship in the XML structure. The second option was that we separate the neumes and text into 'streams', where syllables are related to individual neumes by the use of the MEI XML ID linking pattern. This would better represent the separation of the 'streams' (Stefan clarified this terminology): textual streams, and musical streams on the staff. Jason asked where the text stream would be stored, as this would have an impact on manual "one-pass" encoding. Andrew suggested that it may be stored separately, similar to the 'facsimile' and 'recording' streams already present, but no decisions were made about this.
> 
> We considered questions of contrafact and multiple text underlays. Thomas clarified that it would be possible to have a n-1 relationship (that is, the same neume could carry two texts).
> 
> A discussion of how to treat oriscus, quilisma, and strophici was held, and whether they would constitue their own 'neume' or that they would be properties of a single component. Kate showed how she and Inga handled this in their table, assigning an oriscus to a particular combination of component attributes, while Thomas and Elaine said that they used an attribute on the neume to describe it. It was agreed that further experimentation and sample encodings would help to clarify the best way to capture this information.
> 
> Andrew brought up the need to capture the notation style: "square", "aquitanian", "old hispanic", etc. It was agreed that there was little consensus on how these styles would be named, and that the possible values for these names were endless. Nevertheless, it was agreed that some information about this would be necessary to capture. Andrew suggested incorporating URIs as identifiers for notation styles, and it was generally agreed that this was a good idea, but that the possibility of capturing a human-readable name would still be convenient.
> 
> A discussion of how to treat rubrics was held. Thomas and Elaine presented a case for making a new element, 'rubric', that could be handled as part of the musical structure since it typically contains performance information (similar to textual performance instructions in CMN, i.e., 'andante'). Jason concurred that a dedicated element for capturing rubrics was an attractive idea. We decided to further explore this idea at a later date.
> 
> Andrew concluded the meeting with two comments: One, that a 'test set' for neume encodings should be established, with samples drawn from various repertoires in order to shake out the details of the encoding, and two, that as an 'official' interest group we were entitled to a repository on the MEI GitHub, and that he could set this up after checking with the board.
> 
> The meeting ended at 20:00.
> 
> ---- AH ----
> _______________________________________________
> mei-neumes-ig mailing list
> mei-neumes-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig
>