[MEI-L] FRBR in MEI

[Benjamin Wolff Bohl]

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

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

-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20121114/2d5a3452/attachment.html>