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

[Ichiro Fujinaga, Prof.]

Thank you, Perry and Andrew for working on this.

Before making any major changes, I have made a start for the MEI Neumes Module Draft, Version 0.2.2: 
https://docs.google.com/document/d/1iJ4S3epL0-IfOsOVm547Fg-VO_bORUbtRCW775nPQ1A/edit

The only difference from 0.21 (which should’ve been numbered 0.2.1), so far, is the values for @intm, where, to be consistent, “sh” was changed to “su” and “sl” was changed to “sd”.

The link to MEI Neumes Module Draft, Version 0.21 is here:
https://docs.google.com/document/d/14EVIGmBPdEtw7vXOPK8Uas7MG6WK6mxy_gQGSMpZH9A/edit

In the next few days and weeks, I’d like to start adding the changes suggested by Perry and Andrew; while encouraging discussions on this list.

Ichiro


> On Oct 16, 2017, at 2:51 PM, Roland, Perry (pdr4h) <pdr4h at virginia.edu> wrote:
> 
> 
> As Andrew has reported, he and I had some discussion about neumes in C'ville recently.  I'd like to provide an overview of our plan using a brief, nonsense example --
> 
> <syllable>
>  <neume type="pes">
>    <ncGrp xml:id="n01">
>      <nc xml:id="n02" con="g" angled="true" curved="a" diagonalright="d" episema="true"
>        extended="true" flat="true" jagged="true" liquescent="true" long="true" oriscus="c"
>        quilisma="2" sigletters="true" wavy="true"/>
>      <nc xml:id="n03" con="l" pname="g" oct="4"/>
>      <ncGrp/>
>    </ncGrp>
>    <nc xml:id="n04"/>
>  </neume>
>  <connect startid="#n02" endid="#n03" con="g"/>
>  <connect startid="#n03" endid="#n04" con="l"/>
>  <ncGrp/>
> </syllable>
> 
> 1. a <syllable> may contain <neume> or <connect> elements.  BTW, the name "connect" is a placeholder, it's not carved in stone.  <neumeCon>, <ncCon>, etc. are possibilities, but just don't have the right "oomph".  Suggestions gratefully accepted.  Names that are less generic and more historically appropriate would be great.
> 
> 2. a <neume> may contain <nc> (neume component) or <ncGrp> (neume component group) elements.  The <neume> element carries visual information and <nc> carries both visual and pitch data.
> 
> 3. <ncGrp> provides a way to assign a name and attributes to a collection of neume components.  It doesn't appear to be necessary at the moment, but adding it seems like a good future-proofing move.
> 
> 4.  @con is provided on <nc> to encode the connection between the component bearing the attribute and *the next component*.  This is a reversal of the prior approach.  For processing purposes, it's better to know that the current element is connected to the next, rather than the other way around.  In CMN, we mark ties the same way; that is, the first note of a tie carries the @tie attribute.
> 
> 5. In addition to @con, <connect> is provided for those situations where connections may "cut across" <neume>, <ncGrp>, or <nc> hierarchies.  It's analogous to the <tie> element in CMN in that it provides a point of attachment for attributes that describe the connection in more detail than can be accomplished using @con.
> 
> 6. <nc> can have a large number of attributes.  The number is not important, but the separation of attributes into those that provide semantic information and those that provide visual information is very important.  That's what provides the ability to "switch off" attributes that the encoder may not care about.  I realize this separation is difficult to achieve, but I'd encourage the group to look for similarities across the various styles of notation as indicators of semantics.  Also, semantics usually stick close to "is-a" or "has-a" relationships.  If a neume "is a" or "has a" something, then that something is likely to be of semantic value.  Attributes like this tend to have Boolean values or values from a closed list.  The presence of (or the lack of) such an attribute can be semantic too.  For instance, if a component is / has an episema, then that's semantic info, irrespective of what the episema looks like or what the performance implications of the episema are.  In the example above, @sigletters marks the presence of significative letters without saying what those letters are, where they are, what color they are, etc.
> 
> 7. Speaking of visual characteristics, we created an att.paleography class containing the visual attributes of <nc>, which can also be applied to <neume> and <ncGrp> if the group decides that's necessary.  This attribute class is just a suggested starting point.  If necessary, it can be further divided into stylistic groups of attributes.  But this work can't be done (or at least it's significantly more difficult) without first agreeing on the semantic attributes.
> 
> 8. It's important not to rely too greatly on attributes to encode interpretation.  We already have ways of handling that, using <app> or <choice>, for instance.  For classification, we provide @type and @class for ad hoc and formal ontologies, respectively.  In the proposed ODD, @type on <neume> and <ncGrp> uses a semi-open list of the more-or-less standard names of neumes for those who want this feature.  This approach can be extended to <nc> if necessary.
> 
> I've attached the ODD.  Please let me know if you have questions.
> 
> --
> p.
> 
> <latest_DEV_neumes.odd>_______________________________________________
> mei-neumes-ig mailing list
> mei-neumes-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig