From Margrethe.Bue at nb.no  Tue Oct 15 10:48:02 2019
From: Margrethe.Bue at nb.no (Margrethe Bue)
Date: Tue, 15 Oct 2019 08:48:02 +0000
Subject: [mei-catalog-ig] Report from the MEI metadata IG meeting Oct 2019
Message-ID: <6b943c9622474e15ab182ab7450674ec@nb.no>


Dear all,

Our group convened Oct 3.-4. in Copenhagen. The discussions were partly a continuation of the discussions in Vienna, and partly new issues based on the participants experiences and needs. Participants were Axel Teich Geertinger, Sophia Dörner, Irmlind Cappelle, Guido Viverit, Klaus Rettinghaus, Margrethe Bue.   We had three project presentations: Hoftheater Detmold (Irmlind), Tartini Work Catalogue (Guido), MEI Guidelines Ch. 3 (Klaus). A lot of issues were presented and discussed, and here are the main points:


FRBR, LRM:


·         FRBR and LRM: a proposal was made to "upgrade" the conceptual model behind MEI to LRM for compatibility reasons. Discussion about the agent (LRM) entity and overall idea to take a course to go more general with the person entities.

·         LRM <agent> is a schema problem, not a guideline problem. LRM-R11 defines modified relationship that can't be expressed that way in MEI because inscription doesn't allow a <persName> as child element.

·         table maybe better form for the relationships declared in FRBR.



MerMEId:


·         Incipits: currently incipits are not searchable within MerMEId, but the need is there. MEI is not very well suited for internal search. Incipits are encoded with MEI and PNG. For searching, other formats like Plaine and Easie might be better suited. Klaus Rettinghaus is working on a conversion from MEI to P&E and possibly an implementation in MerMEId would be possible.

·         confusion with collection of works and collection of sources and how to encode the relationships within MerMEId: in MerMEId there is no place to put a source independent of the work, this kind of description isn't modelled in MerMEId. A solution could be to use a <componentlist>. This can be done with MerMEId but the problem is still where to put it and how to link to it. One could use the attribute editor (target of the source), as it is a way to overcome some of the limitations in MerMEId, but MerMEId won't know what to do with it and it wouldn't show in the html conversion.

·         As the DCM is closing from 2020, there is no work on developing or updating MerMEId right now. There are dialogues with other institutions to see if someone can offer a hosting server for external projects using MermEId. Also someone, in addition to MEI, have to take responsibility for the continued work on MerMEId.



Guidelines:


·         New Metadata section chapter 3.3.3 key meter tempo add warning/recommendation: if MEI.all is used Key meter tempo data should be evaluated as to whether this information is sensible to put on the work level or better to put it on the expression level.

·         move last paragraph before 3.3.5 below the heading Work History and don't start two paragraphs with "the following"

·         <language> chapter 3.3.6 should be reconsidered and be more specific about why you should use <language> and why use it on the work level. Recommend to rather put it on the expression level when MEI.frbr is active. Overall it should be clarified what language is used where and why (to indicate what is the "original" language). If @xml:lang always refers to ISO standards there is no need to declare a <language> as in the example of the guidelines. Example should be reworked.

·         the example for <contentItem> is not so good since the label element relies heavily on the structure of the content items (in the example).  Detmold is using the label as attribute, but it's very good and the numbers in the label element are not sufficient within this context.

·         bibliographic evidence 3.3.10 could use an example as to how <biblList> may appear in the work context.

·         Classification 3.3.12 doesn't include the description of the taxonomy which seems to be a problem. Another problem is that there isn't an example where it is explained where the pointer in the example is going to and how to declare the class that is pointed to. Classification should be revised completely, at least adding a reference to section of <classDecl> and the examples.

·         pointer problem is also apparent in 3.4.1.1, ref <classDecl>.

·         height and width in 3.4.1.2 should be equal to the same in dimension - a schema problem.

·         in <classDecl> maybe the @auth.uri and @auth attributes should be declared at the <taxonomy> element and the <category> element could be "dropped".

·         authority files 3.7 is empty.  Kristina Richts and Kristin Herold wrote something for a workshop/summer school, maybe we can reuse that?

·         you should use the any-start schema for the creation of independent headers in the respective section.



Schema:


·         Counting issue, still discussed: if you have multiple instruments you should encode the instrument as many times as you have it and differentiate by the "n" attribute. If you have an exact number of players you may use count, if you don't you shouldn't use count alternating instruments may be encoded with "flute and piccolo" or similar. We should be much more specific about the count attribute and provide an example for the "n".

·         the <dedicatee> element is quite sensless: it isn't allowed where it would make sense, like <item> or <manifestation>. Instead it is part of model.textPhraseLike.limited, which allows it in all those non-sense places like <date>, <dynam>, and <tempo>. The SIG proposes to drop it and use @role="dedicatee" whenever and wherever it is needed.

Thanks a lot to Sophia Dörner for excellent notes! (Any mistakes are on my account...)



The group will meet again at the MEC2020 in Boston, and then in the autumn 2020. We are also considering a meeting before Boston, we'll let you know what happens.

Take care,

Margrethe S. Bue




Med vennlig hilsen

Margrethe S. Bue

Nasjonalbiblioteket
Seksjon for musikk
Telefon: +47 23 27 63 15
Mobil:     +47 419 22 419

http://www.nb.no

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20191015/55d2e5f4/attachment.html>