From ichiro.fujinaga at mcgill.ca Mon Dec 18 00:26:03 2017 From: ichiro.fujinaga at mcgill.ca (Ichiro Fujinaga, Prof.) Date: Sun, 17 Dec 2017 23:26:03 +0000 Subject: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.21 In-Reply-To: References: <310B8AC5-3E74-4697-B141-7116F85D5BD3@mcgill.ca> <5C6A0ED4-C703-4BF6-B14E-E65879D4A4EC@mail.mcgill.ca> Message-ID: <3304D30D-5BF9-4745-B6E4-40E928EDDC1F@mcgill.ca> 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) 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 -- > > > > > extended="true" flat="true" jagged="true" liquescent="true" long="true" oriscus="c" > quilisma="2" sigletters="true" wavy="true"/> > > > > > > > > > > > 1. a may contain or elements. BTW, the name "connect" is a placeholder, it's not carved in stone. , , 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 may contain (neume component) or (neume component group) elements. The element carries visual information and carries both visual and pitch data. > > 3. 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 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, is provided for those situations where connections may "cut across" , , or hierarchies. It's analogous to the 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. 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 , which can also be applied to and 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 or , for instance. For classification, we provide @type and @class for ad hoc and formal ontologies, respectively. In the proposed ODD, @type on and 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 if necessary. > > I've attached the ODD. Please let me know if you have questions. > > -- > p. > > _______________________________________________ > mei-neumes-ig mailing list > mei-neumes-ig at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-neumes-ig From ichiro.fujinaga at mcgill.ca Fri Dec 22 19:36:33 2017 From: ichiro.fujinaga at mcgill.ca (Ichiro Fujinaga, Prof.) Date: Fri, 22 Dec 2017 18:36:33 +0000 Subject: [mei-neumes-ig] MEI Neumes Module Draft, Version 0.2.2: Significative letters Message-ID: <69A1838B-EA55-42B5-A72B-F300EAA4CDAD@mcgill.ca> Dear list, I would like to propose that “significative letters” be encoded as an element. It had been an attribute for both and . Making this an element would make it more flexible: It can specify the colour and the position. It can be applied to a specific or to a as a whole, for example (thank you, Andrew for this): a Or a The change is reflected here (MEI Neumes Module Draft, Version 0.2.2): https://docs.google.com/document/d/1iJ4S3epL0-IfOsOVm547Fg-VO_bORUbtRCW775nPQ1A Any feedback would be appreciated. Ichiro