[MEI-L] FRBR in MEI

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



> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20121113/5dc20bdb/attachment.html>