[MEI-L] FRBR in MEI

[Axel Teich Geertinger]

Hi Benni

some quick comments here and there...

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 better leave it to the more technically skilled people to answer most of it, but I have just a few comments.



> >

> > 4)   There is a problem possibly emerging from the notation-centric nature of

> MEI, or perhaps it is really a FRBR problem; namely the handling of performances

> and recordings. FRBR treats them both as expressions, i.e. as "siblings" to what I

> (and MerMEId) would regard as different versions of the work. We encode

> performances using <eventList> elements within expression/history, i.e. as (grand-

> )children of <expression>, which really makes sense to me. A performance must

> be of a certain version (form, instrumentation) of the work, so I strongly believe we

> should keep it this way. It's just not how FRBR sees it. On the other hand, as far as

> I can see there is nothing (except the practical an conceptual difficulties) that

> prevents users from encoding e performance or a recording as an expression, so

> FRBR compliance is probably possible also in this respect. I just wouldn't

> recommend it, and I actually suspect FRBR having a problem there rather than

> MEI.

>

> I haven't looked this up, but are you sure that performances and recordings are on

> the same level? I would see performances as expressions, while recordings are

> manifestations. Of course a performance follows a certain version of a work, like

> the piano version (=expression). But, the musician moves that to a different

> domain (graphical to audio), and he may or may not play the repeats, and he may

> or may not follow the dynamic indications of the score. There certainly is a strong

> relationship between both expressions, but they are distinct to me. I see your

> reasons for putting everything into an eventList, and thus subsuming it under one

> expression, but that might not always be the most appropriate model. Sometimes,

> it might be better to use separate expressions for the piano version and it's

> performances and connect them with one or more relations.

>



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:



w1 J. S. Bach's Six suites for unaccompanied cello

e1 performances by Janos Starker recorded partly in 1963 and completed in 1965

m1 recordings released on 33 1/3 rpm sound discs in 1966 by Mercury

m2 recordings re-released on compact disc in 1991 by Mercury

e2 performances by Yo-Yo Ma recorded in 1983

m1 recordings released on 33 1/3 rpm sound discs in 1983 by CBS Records

m2 recordings re-released on compact disc in 1992 by CBS Records



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.
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.

That is exactly the problem I'm having with FRBR's view on performances. I think of performance and recording as quite parallel to printed and manuscript sources: a recording is a sort of "printed performance", i.e. one that may be reproduced in multiple copies and re-releases. A performance, like a manuscript, is a unique "event", so just like a manuscript can only have one location (1 item), the performance manifestation also has just one item (it happens at a certain place at a certain time and is not repeatable until we invent time travel). And I tend to think that the performance must represent a specific expression of the work, but it may be more complex than that. However, to me all this indicates that performances should be treated as manifestations. But FRBR sees it differently. And since I treat them as events, I may have simply evaded the problem...

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<mailto:mei-l at lists.uni-paderborn.de>

https://lists.uni-paderborn.de/mailman/listinfo/mei-l

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20121114/186afe36/attachment.html>