[MEI-L] Antw: Re: Question for users of the <annot> element (Erkrankung)
Jürgen Diet
diet at bsb-muenchen.de
Mon Jan 12 06:10:43 CET 2026
Sehr geehrte Damen und Herren,
ich bin erkrankt und kann Ihre Mail nicht bearbeiten. BItte wenden Sie sich an meinen Vertreter Bernhard Lutz (bernhard.lutz at bsb-muenchen.de).
Beste Grüße,
Jürgen Diet
>>> David Lewis <david.lewis at oerc.ox.ac.uk> 9.1.26 16:07 >>>
Dear all,
[Please accept my apologies for using the full list for this. If you’re not interested in annotations or pull requests, please look away now.]
Following on from discussions within the community on this list and at conferences, I’ve just raised a very small pull request to update the guidelines for the <annot> element and to add @func.
It’s at the URL below, and I’d welcome any feedback:
https://github.com/music-encoding/music-encoding/pull/1743
Best wishes,
David
> On 6 May 2025, at 18:06, David Lewis <david.lewis at oerc.ox.ac.uk> wrote:
>
> 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
More information about the mei-l
mailing list