<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Almindelig tekst Tegn";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Arial","sans-serif";
color:black;}
span.AlmindeligtekstTegn
{mso-style-name:"Almindelig tekst Tegn";
mso-style-priority:99;
mso-style-link:"Almindelig tekst";
font-family:"Arial","sans-serif";
color:black;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 121.0pt 1.0in 121.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoPlainText">Hi Johannes,<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Thanks for your comments. Good and relevant as always. I think I better leave it to the more technically skilled people to answer most of it, but I have just a few comments.
<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">> ><o:p></o:p></p>
<p class="MsoPlainText">> > 4) There is a problem possibly emerging from the notation-centric nature of<o:p></o:p></p>
<p class="MsoPlainText">> MEI, or perhaps it is really a FRBR problem; namely the handling of performances<o:p></o:p></p>
<p class="MsoPlainText">> and recordings. FRBR treats them both as expressions, i.e. as "siblings" to what I<o:p></o:p></p>
<p class="MsoPlainText">> (and MerMEId) would regard as different versions of the work. We encode<o:p></o:p></p>
<p class="MsoPlainText">> performances using <eventList> elements within expression/history, i.e. as (grand-<o:p></o:p></p>
<p class="MsoPlainText">> )children of <expression>, which really makes sense to me. A performance must<o:p></o:p></p>
<p class="MsoPlainText">> be of a certain version (form, instrumentation) of the work, so I strongly believe we<o:p></o:p></p>
<p class="MsoPlainText">> should keep it this way. It's just not how FRBR sees it. On the other hand, as far as<o:p></o:p></p>
<p class="MsoPlainText">> I can see there is nothing (except the practical an conceptual difficulties) that<o:p></o:p></p>
<p class="MsoPlainText">> prevents users from encoding e performance or a recording as an expression, so<o:p></o:p></p>
<p class="MsoPlainText">> FRBR compliance is probably possible also in this respect. I just wouldn't<o:p></o:p></p>
<p class="MsoPlainText">> recommend it, and I actually suspect FRBR having a problem there rather than<o:p></o:p></p>
<p class="MsoPlainText">> MEI.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> I haven't looked this up, but are you sure that performances and recordings are on<o:p></o:p></p>
<p class="MsoPlainText">> the same level? I would see performances as expressions, while recordings are<o:p></o:p></p>
<p class="MsoPlainText">> manifestations. Of course a performance follows a certain version of a work, like<o:p></o:p></p>
<p class="MsoPlainText">> the piano version (=expression). But, the musician moves that to a different<o:p></o:p></p>
<p class="MsoPlainText">> domain (graphical to audio), and he may or may not play the repeats, and he may<o:p></o:p></p>
<p class="MsoPlainText">> or may not follow the dynamic indications of the score. There certainly is a strong<o:p></o:p></p>
<p class="MsoPlainText">> relationship between both expressions, but they are distinct to me. I see your<o:p></o:p></p>
<p class="MsoPlainText">> reasons for putting everything into an eventList, and thus subsuming it under one<o:p></o:p></p>
<p class="MsoPlainText">> expression, but that might not always be the most appropriate model. Sometimes,<o:p></o:p></p>
<p class="MsoPlainText">> it might be better to use separate expressions for the piano version and it's<o:p></o:p></p>
<p class="MsoPlainText">> performances and connect them with one or more relations.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Sorry, my mistake. Now that I look it up I see you are right: performances are expressions, recordings are not. As I said, I haven’t really been looking into the recordings question yet. Here's an example from the FRBR report:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">w1 J. S. Bach's Six suites for unaccompanied cello <o:p></o:p></p>
<p class="MsoPlainText" style="text-indent:.5in">e1 performances by Janos Starker recorded partly in 1963 and completed in 1965
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-indent:.5in">m1 recordings released on 33 1/3 rpm sound discs in 1966 by Mercury<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:1.0in">m2 recordings re-released on compact disc in 1991 by Mercury
<o:p></o:p></p>
<p class="MsoPlainText" style="text-indent:.5in">e2 performances by Yo-Yo Ma recorded in 1983
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-indent:.5in">m1 recordings released on 33 1/3 rpm sound discs in 1983 by CBS Records
<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-indent:.5in">m2 recordings re-released on compact disc in 1992 by CBS Records<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">So, recordings are no problem, I guess. But that still leaves us with two very different ways of encoding performance data. FYI, we have recently moved performance <eventList>s from <work> to <expression>, so we do subsume them under
a particular expression already.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">> > 5) Finally, an issue related to the FRBR discussion, though not directly a<o:p></o:p></p>
<p class="MsoPlainText">> consequence of it: MEI 2012 allows multiple <work> elements within <workDesc>. I<o:p></o:p></p>
<p class="MsoPlainText">> can't think of any situation, however, in which it may be desirable to describe more<o:p></o:p></p>
<p class="MsoPlainText">> than one work in a single file. On the contrary, it could easily cause a lot of<o:p></o:p></p>
<p class="MsoPlainText">> confusion, so I would actually suggest allowing only one <work> element; in other<o:p></o:p></p>
<p class="MsoPlainText">> words: either skip <workDesc> and have 1 optional <work> in <meiHead>, or keep<o:p></o:p></p>
<p class="MsoPlainText">> <workDesc>, and change its content model to be the one used by <work> now.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Again, I think that this perspective is biased from your application, where it makes<o:p></o:p></p>
<p class="MsoPlainText">> perfect sense. Consider you're working on Wagner's Ring. You might want to say<o:p></o:p></p>
<p class="MsoPlainText">> something about all these works in just one file. All I want to say is that this is a<o:p></o:p></p>
<p class="MsoPlainText">> modeling question, which is clearly project-specific. It seems perfectly reasonable<o:p></o:p></p>
<p class="MsoPlainText">> to restrict merMEId to MEI instances with only one work, but I wouldn't restrict MEI<o:p></o:p></p>
<p class="MsoPlainText">> to one work per file. This may result in preprocessing files before operating on<o:p></o:p></p>
<p class="MsoPlainText">> them with merMEId, but we have similar situations for many other aspects for MEI,<o:p></o:p></p>
<p class="MsoPlainText">> so this isn't bad per se.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">In the Ring case, we are talking about the individual dramas as components of a larger work. This would probably be one of the situations where <componentGrp> would come in handy as a child of <work> (which the customization allows already).
I would be reluctant, however, to include them as four <work> elements directly under <workDesc>. To clarify what that would mean, it would be necessary to specify work-to-work relations. Furthermore, there wouldn’t be any place to put metadata concerning
*<b>all</b>* four works, since we would be at top level already. <o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Best, <o:p></o:p></p>
<p class="MsoPlainText">Axel<o:p></o:p></p>
</div>
</body>
</html>