[MEI-L] Question for users of the <annot> element

[Axel Teich Geertinger]

Hi David and Kevin

A bit delayed, but hopefully not too late: 
Thanks for bringing this up. The guidelines are indeed somewhat vague about the use of <annot>, but perhaps they need to be. 

I am aware that <annot> can serve many purposes, so I just want to outline how I and projects I have been involved in have been using it. Generally, we have used <annot> as part of the editorial markup: Either inside other editorial markup such as <supplied> or <app><lem> to qualify the reasons for editorial intervention, or on its own inside encoded entities as an editorial/critical comment. 

In a context where editorial markup is visualised as text critical notes in pop-up boxes in the score, we have sometimes used the @type attribute to indicate whether the annotation should, for instance, _replace_ the commentary's general lemma/reading structure entirely, or (default) should be _added_ after the displayed content of <lem> or <rdg> (depending on where the annotation is), or replace either <lem> or <rdg>. I regard that as a very project-specific approach, though. 

@motivation may be useful, but I would be unsure which one to use in the above cases – we are annotating as part of the editing process (@motivation="editing"?) to comment ("commenting"?) on or explain or qualify (?) the intervention. And perhaps we could use @func for that instead? I tend to think that intended use and purpose of the annotation is more useful for a reader/software than the encoder's motivation for adding it.

The value @func="score" seems a little counter-intuitive to me. How is score a function? Does it mean that the annotation is intended to be shown only in the context of the score (as opposed to the parts)? If so, perhaps a new attribute @context would be easier to understand?

Just some quick thoughts :-)

Best,
Axel

-----Original Message-----
From: mei-l <mei-l-bounces at lists.uni-paderborn.de> On Behalf Of David Lewis
Sent: Tuesday, May 6, 2025 7:07 PM
To: mei-l at lists.uni-paderborn.de
Subject: [MEI-L] Question for users of the <annot> element

Hi all,

As some of you may have noticed, Verovio has recently gained the ability to display annotations that refer to parts of a score (i.e. not the header information or commentary about the encoding itself).

In the process of adding this, we had a small discussion about how to characterise different uses of <annot> in MEI so that software can interpret them clearly. Since the guidelines are at times a little unspecific (or confusing), we’re interested in hearing from people who are _already using_ <annot> in their encodings.

As a preliminary step, we have used a particular @type value on <annot> (<annot type="score">) to specify the sorts of annotation that we actually want to display, but this is a temporary measure. @type is not intended to carry important semantics in this way, but we can use it without changing the current schema.

Before we propose a longer term solution, we’d like to check for unintended consequences. If you've used <annot> before or are using it now, we'd like to hear how the following options  would affect your work or your encodings.

 1. Introduce a @motivation attribute (informed by web annotation and TEI) with a fixed set of values – assessing, bookmarking, classifying, commenting, describing, editing, highlighting, identifying, linking, moderating, questioning, replying, tagging. New motivations would have to be created as part of external authorities linked using motivation.auth / motivation.url

   It has been suggested that we would distinguish annotations to display from others by the presence or absence of @motivation, or by the specific values of @motivation

 2. Use @func or some other relatively lightweight approach to distinguish (e.g. <annot func="score">

 3. Use a new, additional element for the things we need to distinguish (TEI uses <annotation> and <note>, which MEI can't for obvious reasons)

These options are not exclusive – we can have @motivation, @func _and_ different elements. Any one of them has the potential to help clarify things, but it could also complicate existing uses or make unclear what is currently clear.

We look forward to benefiting from the combined experience of the community.

Thanks for your input

David Lewis & Kevin Page
AHRC Annote Project
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l