<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Axel,<br>
thanks for this huge insight into the FRBR-customization. Having
considered some recording metadata in the Freischütz project I'll
try to add my thought's on this topic.<br>
Sorry for adding late to this discussion, I had prepared this mail
this morning in the train, then forgot to send it from work...<br>
See my comments inline<br>
<br>
Am 13.11.2012 13:21, schrieb Axel Teich Geertinger:<br>
</div>
<blockquote
cite="mid:0B6F63F59F405E4C902DFE2C2329D0D1514EF677@EXCHANGE-01.kb.dk"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<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]-->
<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.</p>
</div>
</blockquote>
First, I don't think, that a recording and a performance are really
two different things, but correct me if I'm missing something. The
way to both of them is the same, only the recording might result in
further manifestations.<br>
Let's say you have a copy of a specific recording of a work.
Interpreting your record as a expression of the work is fine.
Interpeting the recording session as expression of the work can be
rather problematic.<br>
The record you own is a manifestation of the recording
(expression/?) which on the other hand will be the
trans-medialization of specific performance material, having been
worked with and modified by conductor and musicians in order to
resemble the performance (manifestation) which again is based on a
certain printed edition of the work (expression) possibly taking
into account diffrences from other sources.<br>
Would one say that this makes the record inferior and nested deep
inside the work-expression-manifestation of the written sources or
rather a sibling expression-manifestation tree of the same work with
strong relations to each other?<br>
I think it's the very right thing you did in moving the performance
list to <expression>.<br>
<br>
Some further complications might arise from the following two
thougts:<br>
(a)The record you may moreover be (an this is quite popular in
recent years, especially with 'classical' msuic) the re-release of
an older record (i.e. another manifestation of the same recording)
but modified in order to fit the new medium, remastered and
digitized and potentially even remixed (Vinyls have certain physical
implications on the nature of the sound, whilst CDs or digital audio
has different ones).<br>
(b) The record doesn't com alone, it has a booklet, which could be
referenced from <extent>? This booklet will incorporate texts
by different persons and again if re-released might incorporate the
old booklet and add additional material.<br>
<br>
See you later,<br>
Benjamin<br>
<o:p></o:p>
<blockquote
cite="mid:0B6F63F59F405E4C902DFE2C2329D0D1514EF677@EXCHANGE-01.kb.dk"
type="cite">
<div class="WordSection1">
<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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
mei-l mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
<a class="moz-txt-link-freetext" href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a>
</pre>
</blockquote>
<br>
</body>
</html>