[MEI-L] FRBR in MEI
Axel Teich Geertinger
atge at kb.dk
Mon Nov 19 15:11:23 CET 2012
Hi Craig
That's an interesting case. First, an attempt at modeling it the "strict" FRBR way, using expressions for performances (including the studio or live performances resulting in recordings). In that case, <eventList>s will not be used to describe performances. Assuming that the "translation" expression-to-expression relationship, which FRBR uses to describe a transcription of music, also is the one to use the other way (from score to performance), I get something like the following in <workDesc>:
<work>
<titleStmt>
<title>Variations Op. 27</title>
<respStmt>
<name role="composer">Anton Webern</name>
</respStmt>
</titleStmt>
<expressionList>
<expression xml:id="expression_1">
<titleStmt>
<title>Variations Op. 27 (score)</title>
</titleStmt>
<relationList>
<relation rel="hasEmbodiment" target="source_1"/>
<relation rel="hasTranslation" target="expression_2"/>
</relationList>
</expression>
<expression xml:id="expression_2">
<titleStmt>
<title>1961 Recording</title>
<respStmt>
<name role="instrumentalist">Webster Aitken</name>
</respStmt>
</titleStmt>
<relationList>
<relation rel="isTranslationOf" target="expression_1"/>
<relation rel="hasTranslation" target="expression_3"/>
<relation rel="hasEmbodiment" target="source_2"/>
</relationList>
</expression>
<expression xml:id="expression_3" analog="frbr:manifestation">
<titleStmt>
<title>Craig's performance score of the 1961 recording</title>
</titleStmt>
<relationList>
<relation rel="isTranslationOf" target="expression_2"/>
<relation rel="hasEmbodiment" target="source_3"/>
</relationList>
</expression>
<expression xml:id="expression_4">
<titleStmt>
<title>Some live performance</title>
<respStmt>
<name role="instrumentalist">Webster Aitken</name>
</respStmt>
</titleStmt>
<relationList>
<relation rel="isTranslationOf" target="source_1"/>
</relationList>
</expression>
</expressionList>
</work>
And in <sourceDesc>:
<source xml:id="source_1" analog="frbr:manifestation">
<titleStmt>
<title>UE Score</title>
</titleStmt>
<pubStmt>
<respStmt>
<corpName role="publisher">Universal Edition</corpName>
</respStmt>
<date isodate="1937">1937</date>
</pubStmt>
<relationList>
<relation rel="isEmbodimentOf" target="expression_1"/>
</relationList>
</source>
<source xml:id="source_2" analog="frbr:manifestation">
<titleStmt>
<title>Aitken Recording DEL 25407</title>
</titleStmt>
<pubStmt>
<respStmt>
<corpName role="publisher">Delos</corpName>
</respStmt>
<date>1978</date>
</pubStmt>
<relationList>
<relation rel="isEmbodimentOf" target="expression_2"/>
</relationList>
</source>
<source xml:id="source_3" analog="frbr:manifestation">
<titleStmt>
<title>Craig's online performance score of the 1961 recording</title>
</titleStmt>
<pubStmt>
<availability>
<acqSource><ptr target="http://mazurka.org.uk/webern/notation/Aitken1961"/></acqSource>
</availability>
</pubStmt>
<relationList>
<relation rel="isEmbodimentOf" target="expression_3"/>
</relationList>
</source>
That's certainly a possible approach. I see a few problems, though. Most important, you will get a lot of expressions and an even larger number of <relation>s to explain their interrelations. This may be perfectly valid, but quite complex to process, as I see it. Also, allowing only a very small amount of variation within an expression (such as Johannes suggests, and indeed the FRBR report too) tends to produce 1:1-relationships between expression and manifestation, which is not very useful. For instance, manuscripts will obviously differ from a printed edition more than, say, "two states of the same edition" (FRBR), so following this logic strictly, we would need to define a separate expression for a manuscript draft, another one for a fair copy, yet another for the printed first edition etc. My problem is that this would leave no room for defining different versions of the work - or: to do so, I would have to define expressions (all as siblings!), some of which describe a completely abstract entity (like "the version for nose flute & harpsichord"), and some of which describe not-so-abstract entities like the expression that is embodied only by one manuscript or one specific performance. I suspect FRBR would regard these versions as actually being separate *works*, but I think it should really be the project editor's decision where to draw that line. Traditionally, in most thematic catalogues different versions of a work are listed as variant representations of the same work.
I find the distinction between the four FRBR group 1 entities really useful only if we maintain the distinction between completely abtract entities (work and expression), and non-abstract (manifestation [=source] and item). This may not be exactly how FRBR intends it, but otherwise I'd say there an entity missing between work and expression, grouping the more or less physical realizations of the work into clusters of closely related expressions (for instance, the written representations, the recordings, and the performances of the version for nose flute).
Of course, we could introduce an additional "version" element. But that would leave us with five levels of description with even less clear distinction between them. I think the more productive approach for us would be to decide that we limit expressions (defined by FRBR as "the specific intellectual or artistic form that a work takes each time it is "realized" ") to describing versions, and accommodating the different mediations, which expressions may otherwise represent, as children of these expressions, like we do when using <eventList> for performances. Also bearing in mind that the MEI is *not* a general music cataloguing language, but primarily relates to music notation, I find it completely acceptable that MEI metadata are notation-centric, treating other media such as recordings and performances more as peripheral phenomena. We may consider, though, if in that case we should avoid the element name <expression> and call it <version> instead.
Interpreting expression as version, I would suggest something more like the following. In the Webern Op. 27 case, there is only one expression, serving as the container for all. It could be used to describe the sequence of movements, which is shared by all these representations, too (in a <componentGrp> element; not included here). You will notice the encoding is more concise, actually without loss of information. The FRBR relations, however, are now used at different levels than by original FRBR. In <workDesc>:
<work>
<titleStmt>
<title>Variations Op. 27</title>
<respStmt>
<name role="composer">Anton Webern</name>
</respStmt>
</titleStmt>
<expressionList>
<expression xml:id="expression_1">
<titleStmt>
<title>Variations Op. 27</title>
</titleStmt>
<history>
<eventList type="performances">
<event>
<title>Some live performance</title>
<name role="instrumentalist">Webster Aitken</name>
</event>
</eventList>
</history>
<relationList>
<relation rel="hasEmbodiment" target="source_1"/>
<relation rel="hasEmbodiment" target="source_2"/>
<relation rel="hasEmbodiment" target="source_3"/>
</relationList>
</expression>
</expressionList>
</work>
In <sourceDESC>:
<source xml:id="source_1" analog="frbr:manifestation">
<titleStmt>
<title>UE Score</title>
</titleStmt>
<pubStmt>
<respStmt>
<corpName role="publisher">Universal Edition</corpName>
</respStmt>
<date isodate="1937">1937</date>
</pubStmt>
<relationList>
<relation rel="isEmbodimentOf" target="expression_1"/>
<relation rel="hasTranslation" target="source_2"/>
</relationList>
</source>
<source xml:id="source_2" analog="frbr:manifestation">
<titleStmt>
<title>Aitken Recording DEL 25407</title>
</titleStmt>
<pubStmt>
<respStmt>
<corpName role="publisher">Delos</corpName>
</respStmt>
<date>1978</date>
</pubStmt>
<relationList>
<relation rel="isEmbodimentOf" target="expression_1"/>
<relation rel="isTranslationOf" target="source_1"/>
<relation rel="hasTranslation" target="source_3"/>
</relationList>
</source>
<source xml:id="source_3" analog="frbr:manifestation">
<titleStmt>
<title>Craig's performance score of the 1961 recording</title>
</titleStmt>
<pubStmt>
<availability>
<acqSource><ptr target="http://mazurka.org.uk/webern/notation/Aitken1961"/></acqSource>
</availability>
</pubStmt>
<relationList>
<relation rel="isEmbodimentOf" target="expression_1"/>
<relation rel="isTranslationOf" target="source_2"/>
</relationList>
</source>
Following this path even further, recordings could be treated in about the same way as performances, as <bibl>s for instance - but this of course depends on the importance of the recording for the encoding of the music (if any) in the MEI document in question:
<workDesc>
<work>
<titleStmt>
<title>Variations Op. 27</title>
<respStmt>
<name role="composer">Anton Webern</name>
</respStmt>
</titleStmt>
<expressionList>
<expression xml:id="expression_1">
<titleStmt>
<title>Variations Op. 27</title>
</titleStmt>
<history>
<eventList type="performances">
<event>
<title>Some live performance</title>
<name role="instrumentalist">Webster Aitken</name>
</event>
</eventList>
</history>
<biblList>
<bibl>
<!-- there seems to no more precise MARC genre term than "sound"(?) -->
<genre authority="marcgt" authURI="http://www.loc.gov/standards/valuelist/marcgt.html">sound</genre>
<title>Aitken Recording DEL 25407</title>
<name role="instrumentalist">Webster Aitken</name>
<imprint>
<publisher>Delos</publisher>
<date>1978</date>
</imprint>
</bibl>
</biblList>
<relationList>
<relation rel="hasEmbodiment" target="source_1"/>
<relation rel="hasEmbodiment" target="source_2"/>
<relation rel="hasTranslation" target="expression_2"/>
</relationList>
</expression>
</expressionList>
</work>
It doesn't have to be either/or, of course. As Perry has pointed out, it may be done either way, depending on the individual projects. If the use of FRBR is optional anyway (for instance, by putting <expression> and the like in an optional module), I guess it would be acceptable doing it this way too. Opinions?
Cheers,
Axel
Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Craig Sapp
Sendt: 16. november 2012 20:46
Til: Music Encoding Initiative
Emne: Re: [MEI-L] FRBR in MEI
Hi All,
On Tue, Nov 13, 2012 at 2:33 AM, Axel Teich Geertinger <atge at kb.dk<mailto:atge at kb.dk>> wrote:
We encode performances using <eventList> elements within expression/history, i.e. as (grand-)children of <expression>, which really makes sense to me.
This year I extracted note/event level timings for all commercially available recordings of Webern's (not Weber's) Op. 27 piano variations. "Performance" scores of the piece can be viewed online:
http://mazurka.org.uk/webern/notation
The notation engine is SCORE, with the output converted into SVG images (one per system) (Thanks to Thomas Weber for his SCORE EPS to SVG converter: https://github.com/th-we/seps2svg). The horizontal axis in the notation represents time, and the grayscale of the noteheads represents loudness (light=soft, dark=loud). Timings/dynamics are for all notes occurring simultaneously in the score (i.e., "chords", and which I usually call "events"), not individual notes. For your amusement, here is the performance data:
http://mazurka.org.uk/webern/dynamics/mvmt1/webern-op27-1-Aitken1961.dyn
used to generate this score (mvmt 1):
http://mazurka.org.uk/webern/notation/Aitken1961
and here is the SCORE data used to generate the score (first system of first movement):
http://mazurka.org.uk/webern/notation/Aitken1961/webern-op27-1-Aitken1961-sys01.pmx
(first in the data are lots of little lines for the tick marks above and below the system, then the lists of notes which I am coloring in SVG rather than SCORE)
How would this sort of data be encoded in MEI along with the printed score (luckily all performers are using the same edition of the music, and I ignore wrong notes)? Could multiple <eventList>s be stored with the score for different performances? And how might all this relate to FRBR? Another wonder: how would the "performance" scores be represented in MEI (or just leave the "manifestation" to the renderer?). In other words, these "scores" have pitch information (but no accidentals to preserve clarity), no score rhythms but with performance rhythm indicated by spatial layout on the system.
Thanks to an American, the works of Webern will go into the public domain at the end of 2015, so something interesting might be done with this data and the printed score in a few years without the need for permissions.
-=+Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20121119/7cac4abb/attachment.html>
More information about the mei-l
mailing list