[MEI-L] Annotations visible on the music and arbitrary segmentation

Roland, Perry D. (pdr4h) pdr4h at eservices.virginia.edu
Sat Mar 4 16:27:02 CET 2017

Hi everyone,

Let's not dive too deeply into where/how things are displayed before making sure the semantics of <dir> and <annot> are clear.

<dir> is, indeed, intended to capture performance directions that aren't already dealt with by more specific elements.  Phrases like "con sordino", "sul ponticello", and "Rock out!" are good examples.  They affect performance but don't fit the definition of articulations or tempo indications.  They're also not words (sung or spoken) intended to be performed.

Although for obvious reasons it can't have the same name, <annot> is analogous to TEI's <note> element, which is defined (in a circular way) as "a note or annotation".  Delving a little more deeply into the TEI Guidelines one finds

"A note is any additional comment found in a text, marked in some way as being out of the main textual stream. All notes should be

marked using the same tag, note, whether they appear as block notes in the main text area, at the foot of the page, at the end of the

chapter or volume, in the margin, or in some other place.

Notes may be in a different hand or typeface, may be authorial or editorial, and may have been added later. Attributes may be used

to specify these and other characteristics of notes, as detailed below.

A note is usually attached to a specific point or span within a text, which we term here its point of attachment. In conventional printed

text, the point of attachment is represented by some siglum such as a star or cross, or a superscript digit."

This narrows the definition somewhat, but it's still fairly broad.  Functionally, a note/annot can contain anything the "text" (in the generic sense) may, the only difference being that the note is somehow "out of the main textual stream".  In other words, it's a text inside the main text.  Sometimes this is referred to as "floating text".  Because an annotation can be either *authorial* or *editorial*, I do not agree that <annot> indications shouldn't appear in the score.  In fact, if they don't appear in the score, they're not annotations according to the definition above.  However, I can see the need to mark some notes as visible/invisible or to define the intended audience, for example "public" and "private".

With regard to *where* to display it, <annot> can be linked to starting and ending times via @tstamp and @tstamp2 (most useful in the CMN repertoire) or @startid and @endid (in any repertoire).  So, even though it permits a broader range of content than <dir> -- plain text,  text components (like fig, list, and p), phrase-level elements, and editorial and transcriptional elements -- it can behave exactly the same as <dir> with regard to its position relative to musical events.

Given that the content of <annot> *does not* include any of the non-textual entities that are allowed in <staff> or <layer>, such as <note>, <chord>, <slur>, <dynam>, etc., it can't be used to encode any of these things added by a later scribe (composer, editor, etc.) *without egregious tag abuse*.  Therefore, Bernstein's "annotations" of a Mahler score don't fit the MEI definition of <annotation>.  These must be addressed in the musical text; that is, at the measure level (in CMN), staff level (in Mensural notation), or syllable level (in Neume notation).  Since Bernstein's additions were made on an already-printed edition, they should be marked with the <add> element.  It is these additions, not <annot> per se, whose positioning must be given more thought.  With the addition of @place (newly available on <add> in MEI development) one can now indicate where the added material is to be placed, for example, in the margins or directly in the musical text.  When necessary, @place can also record whether the addition is superimposed over other material.  Given an addition with @place containing "superimposed", rendering software must position it according to information provided by the individual slur, dynam, etc., but *without regard* for other material.  Making @place available on <annot> will provide the same behavior for it.



> -----Original Message-----

> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Byrd,

> Donald A.

> Sent: Friday, March 03, 2017 7:37 PM

> To: Music Encoding Initiative

> Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation


> For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, Perry and I, plus

> other members of the mensural IG -- have been discussing the need for

> annotations with arbitrary text that are displayed on the music. Unfortunately,

> the discussion so far has been scattered among several places, including the

> mensural IG mailing list and Verovio GitHub issues #248 ("Directives in

> mensural notation aren't drawn"), 388 ("@n for <harm>"), and especially 389

> ("implement <annot> display"). You can read #389 at


>    https://github.com/rism-ch/verovio/issues/389


> and similarly for the other Verovio issues. Anyway, I'll try to summarize the

> issues here.


> We've talked about using one of two existing tags for these annotations,

> namely <dir> and <annot>. It seems clear that <dir> is not what we want

> because it's specifically intended for performance directions. As for <annot>s,

> of course they are currently only for annotating the encoding, not the music,

> and they're not displayed in the SVG. We could add a @visible attribute to

> <annot>, but the problem then is _where_ on the music should they appear?

> But it seems to me this is only a serious problem if you expect the notation

> engine to position everything automatically, and that's something that I think

> is completely unrealistic for complex music regardless of annotation. I suggest

> visible <annot>s should have a crudely-calculated default position, and it'd be

> up to the user to specify a different position if they want.


> Giuliano has raised a related concern. He wrote yesterday that


> "[N]ot only something like <dir> for arbitrary non-lyric text is needed, but also

> some arbitrary segmentation, to encapsulate portions of music and/or

> lyric/non-lyric text where things happen (such as, lyric text loosely connected

> with a portion of music, or passages where the mensuration is uncertain...).


> "If I understand correctly, most of the problem with <dir>  originates from the

> missing <measure> level in the hierarchy (at least this creates problems with

> Verovio), so I was wondering whether the introduction of a tag <segment> at

> that level could be useful. The latter, contrary to <measure> would be totally

> optional, and contrary to <measure> or <section> would be used without any

> structural meaning.


> "This is the point where we felt the need that the discussion escalates on MEI-

> L.  Non-structural segmentation is something that TEI introduced lately in their

> schema (they call it <seg> when the portion of text is shorter than a paragraph,

> and <ab> when an 'anonymous block' of text is found that escapes from the

> paragraph structure). In my experience this is one of the most useful features

> when dealing with complex documents, and in past projects I used it also to

> provide annotations. I wonder whether there are any reasons for not having a

> <seg>-like tag available at any level."


> Giuliano's ideas make sense to me, but I don't feel very well qualified to

> evaluate them.


> I'm looking forward to hearing people's thoughts on all of this!


> --Don



> ---

> Donald Byrd

> Woodrow Wilson Indiana Teaching Fellow

> Adjunct Associate Professor of Informatics Visiting Scientist, Research

> Technologies Indiana University Bloomington








> _______________________________________________

> mei-l mailing list

> mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>

> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20170304/0aafc66c/attachment.html>

More information about the mei-l mailing list