[MEI-L] FRBR in MEI: performances vs. recordings

[Byrd, Donald A.]

One more thing about the relationship between performances and 
recordings that might clarify why FRBR considers the former an 
expression and the latter a manifestation. The difference between the 
two can go way beyond merely re-releasing a recording in digital form 
that was originally on vinyl. That's  especially true outside of the 
classical music world. For example, I believe the Grateful Dead were 
famous for not discouraging people from making their own recordings of 
their concerts, and I think there are some of their performances for 
which dozens, maybe hundreds, of recordings exist -- all done from 
different locations with different equipment, and probably many of them 
containing just parts of the concert! And some early jazz sessions were 
recorded with two microphones in different positions, which were 
originally thought of just as two slightly different mono recordings, 
but making possible after-the-fact stereo.

--Don


>>>> ---- SNIP ----
>>>> Fra: mei-l-bounces at lists.uni-paderborn.de
>>>> [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Benjamin
>>>> Wolff Bohl
>>>> Sendt: 14. november 2012 19:59
>>>> Til: Music Encoding Initiative
>>>> Emne: Re: [MEI-L] FRBR in MEI
>>>>
>>>> Hi Axel,
>>>> 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.
>>>> Sorry for adding late to this discussion, I had prepared this mail
>>>> this morning in the train, then forgot to send it from work...
>>>> See my comments inline
>>>>
>>>> Am 13.11.2012 13:21, schrieb Axel Teich Geertinger:
>>>> Hi Johannes,
>>>>
>>>> Thanks for your comments. Good and relevant as always. I think I
>>>>
>>>> ---- SNIP ----
>>>>
>>>> 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.
>>>>
>>>> Well, MY record would be an item, i.e. a specific copy of the
>>>> manifestation (the release). Right?
>>>>
>>>> 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.
>>>>
>>>> Again, the one I actually own is an *item* of the manifestation
>>>> (just to make sure we agree on that...)
>>>>
>>>> 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?
>>>>
>>>> I would say that the recording manifestation and the written
>>>> manifestation used for the recording would have strong
>>>> manifestation-to-manifestation relations, but that they would not
>>>> *necessarily* have the same parent expression. The musicians could
>>>> have changed something, made cuts or other things not present in
>>>> the performance material they played from. So we could also have
>>>> sibling expressions here.
>>>>
>>>> I think it's the very right thing you did in moving the
>>>> performance list to <expression>.
>>>>
>>>> Some further complications might arise from the following two thougts:
>>>> (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).
>>>>
>>>> No problem, as I see it. Like in the FRBR example above, that
>>>> would be a new manifestation of the recording expression.
>>>>
>>>> (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.
>>>>
>>>> Good question. This would be a bundle of relations pointing in all
>>>> directions, perhaps. I have no good answer to that right away...
>>>>
>>>> /axel
>>>>
>>>>
>>>>
>>>> See you later,
>>>> Benjamin
>>>>
>>>>
>>>>>> 5)   Finally, an issue related to the FRBR discussion, though
>>>>>> not directly a
>>>>> consequence of it: MEI 2012 allows multiple <work> elements
>>>>> within <workDesc>. I
>>>>> can't think of any situation, however, in which it may be
>>>>> desirable to describe more
>>>>> than one work in a single file. On the contrary, it could easily
>>>>> cause a lot of
>>>>> confusion, so I would actually suggest allowing only one <work>
>>>>> element; in other
>>>>> words: either skip <workDesc> and have 1 optional <work> in
>>>>> <meiHead>, or keep
>>>>> <workDesc>, and change its content model to be the one used by
>>>>> <work> now.
>>>>>
>>>>> Again, I think that this perspective is biased from your
>>>>> application, where it makes
>>>>> perfect sense. Consider you're working on Wagner's Ring. You
>>>>> might want to say
>>>>> something about all these works in just one file. All I want to
>>>>> say is that this is a
>>>>> modeling question, which is clearly project-specific. It seems
>>>>> perfectly reasonable
>>>>> to restrict merMEId to MEI instances with only one work, but I
>>>>> wouldn't restrict MEI
>>>>> to one work per file. This may result in preprocessing files
>>>>> before operating on
>>>>> them with merMEId, but we have similar situations for many other
>>>>> aspects for MEI,
>>>>> so this isn't bad per se.
>>>>
>>>> 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 *all* four
>>>> works, since we would be at top level already.
>>>>
>>>> Best,
>>>> Axel
>>>>
>>>>
>>>> _______________________________________________
>>>> mei-l mailing list
>>>> mei-l at lists.uni-paderborn.de
>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> mei-l mailing list
>>>>
>>>> mei-l at lists.uni-paderborn.de
>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>>
>>> <Bohl_FRBR.jpg>_______________________________________________
>>> mei-l mailing list
>>> mei-l at lists.uni-paderborn.de
>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>
>>
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>


--
Donald Byrd
Woodrow Wilson Indiana Teaching Fellow
Adjunct Associate Professor of Informatics & Music
Indiana University, Bloomington