[MEI-L] FRBR in MEI
Benjamin Wolff Bohl
bohl at edirom.de
Fri Nov 16 17:34:26 CET 2012
Hi Axel et al.,
first tanks for correctiong my repeationg mistake concerning the items,
which certainly did not increase clarity.
My head has continued working on the problematic dealing of FRBR with
recordings and I tried to graphically sort out my thougts (as you can
see in the attached image or [in case it doesn't go through] under
http://homepages.uni-paderborn.de/bwbohl/MEI/Bohl_FRBR.jpg).
The graphic is sort of a table with work, expression, manifestation and
item being the column labels. The contents first show a work with an
edition and an auograph source, then a performance ("Interpretation by
Kepper/Roland") and a recording (in red), and last some records (I just
realize I missed putting an experssion before the records, sorry for
that). Blue lines show hierarchical dependencies whereas green lines
indicate a "based upon" relationship.
The idea behind it is, that a interpretation of a work by a certain
conductor could be viewed as expression with him conduction a certain
orchestra being a manifestation and the actual performance one a certain
data at a certain location being the item (physical by means of the
sound waves;-)
A recording again is another experssion of the work although depending
on a certain interpretation-perfomance
I'm not a FRBR expert so I don't know how this all conforms with the
FRBR paper(s) but I would be happy to sort things out with you!
/benjamin
Am 14.11.2012 20:36, schrieb 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
>
>
>
> _______________________________________________
> 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/20121116/857e7425/attachment.html>
-------------- n?chster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname : Bohl_FRBR.jpg
Dateityp : image/jpeg
Dateigr??e : 262190 bytes
Beschreibung: nicht verf?gbar
URL : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20121116/857e7425/attachment.jpg>
More information about the mei-l
mailing list