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

Wed Sep 20 17:20:15 CEST 2017

Thomas,

I haven't yet had the time to read your proposal, but I agree with Andrew that semantic meaning (rather than visual characteristics) should be the primary focus of any encoding.  As for naming, MEI 4.0.0 allows one to reference a locally- or externally-defined taxonomy/ontology/controlled vocabulary/classification scheme using the @class attribute, e.g., 

<div class="http://www.myTaxonomy.com/#class001">

The @type attribute can be used for ad hoc typing for extension or restriction; that is, where a formal taxonomy doesn't exist, e.g.,

<div type="foo">
<div type="bar">
<div type="bingo">

--
p.

> -----Original Message-----
> From: mei-neumes-ig [mailto:mei-neumes-ig-bounces at lists.uni-paderborn.de] On Behalf
> Of Andrew Hankinson
> Sent: Wednesday, September 20, 2017 10:58 AM
> To: Neumes Interest Group of the Music Encoding Initiative <mei-neumes-ig at lists.uni-
> paderborn.de>
> Cc: Johannes Kepper <kepper at edirom.de>
> Subject: Re: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2
> 
> 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/cardi
> > ne_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/presen
> > tation.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.me
> > i
> >
> > 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