[MEI-L] FRBR in MEI

[Axel Teich Geertinger]

Hi Peter

It is not exactly the customization we are using, which also includes the use of TEI:listBibl, but as to the FRBR stuff the one you can see from September seems to be up to date, as far as I can see.

In the proposal, a hierarchy is imposed only on the relationship between work and expression, and between source and item. That's safe, since work and expression have a 1:n relationship, like source and item. There is no hierarchy implied between those two sub-trees in the encoding, i.e. between expression and manifestation. They are connected only by relations. Any other relations (to other levels or the same) can be defined too.

Best,
Axel

> -----Oprindelig meddelelse-----
> Fra: mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de [mailto:mei-l-
> bounces+atge=kb.dk at lists.uni-paderborn.de] På vegne af Peter Stadler
> Sendt: 14. november 2012 09:56
> Til: Music Encoding Initiative
> Emne: Re: [MEI-L] FRBR in MEI
> 
> Dear Axel et al.,
> 
> beeing not very familiar with the topic and the correspondent discussion within
> MEI, I have just some minor notes and further enquiry:
> I guess your email relates to issue 55 (http://code.google.com/p/music-
> encoding/issues/detail?id=55 -- opened in March) where I find some ODD files. Is
> the latest the customization you are talking about?
> Second, I see some references to articles int the ODD and the ticket. If anyone has
> some pointers or could mail them to me off-list that'd be highly appreciated. Many
> thanks in advance!
> 
> Now for the note:
> Kevin Hawkins presented a paper in 2008 about "FRBR Group 1 Entities and the
> TEI Guidelines" [1]. Skimming through the text I find some very interesting points,
> mainly that the "idea of a hierarchy for FRBR is problematic" [2] and secondly he is
> inspecting a whole range of elements within the text. That is to say, the application
> of the FRBR ontology is not necessarily restricted to the header.
> 
> Best
> Peter
> 
> [1] http://www.ultraslavonic.info/preprints/20081102.pdf
> [2] ibidem, p. 3
> 
> Am 13.11.2012 um 11:33 schrieb Axel Teich Geertinger <atge at kb.dk>:
> 
> > Dear list,
> >
> > as some of you know, we have been experimenting for some time with
> implementing FRBR group 1 entities (work, expression, manifestation, item; see
> http://www.ifla.org/publications/functional-requirements-for-bibliographic-records)
> in <meiHead> to be able to clearly distinguish these four levels of description.
> With <source> translating to FRBR manifestation, we have two of them already
> (work and manifestation), so we have added the two others along with some
> container and linking elements. In my opinion, the results so far are very promising,
> and I think this is the time to discuss whether and how to go ahead with it. As with
> the <bibl> discussion, I need to know which way to head in order to get MerMEId
> ready for release. So, I hope we can get to an agreement about what is going to
> be in the next MEI schema, at least in general terms. This will probably get a bit
> lengthy, but I hope some of you will have a look at it.
> >
> > For the time being, we are using a customization (thanks to Johannes), extending
> the MEI 2012 schema as follows:
> >
> > 1)	In <work>, we have introduced the element <expressionList>, a container
> for <expression> elements, which have the same content model as <work>.
> <expression> has a child <componentGrp>, an ordered list allowing <expression>
> child elements; it is intended to represent a sequence of sections such as
> movements. This can be nested; it enables us to describe the structure of, say, an
> opera, divided into acts, acts into scenes, and scenes into subsections of scenes
> (recitative, aria etc.), each with their own incipit etc.
> > Actually, <work> also allows <componentGrp> as a child, though we are not
> using it; I am not sure whether it may be useful or not.
> >
> > 2)	Likewise, in <source>, we have an <itemList> containing <item> elements,
> i.e. descriptions of individual copies/exemplars of a source. As with <work> and
> <expression>, <source> and <item> share the same content model (though we do
> not use all elements at both levels - more on that later). Also <source> and <item>
> have an optional <componentGrp> to describe their constituents.
> >
> > 3)	All four FRBR entity elements have a <relationList> child, containing
> <relation> elements. These establish the relations between entities not immediately
> deductable from the XML tree, such as expression-to-manifestation (these are the
> main links between the <workDesc> and <sourceDesc> sub-trees), manifestation-
> to-manifestation (for instance, identifying one source as a reprint or copy of
> another one; this also allows the encoding of a stemma), or external relations such
> as work-to-work.
> > These new elements replace <relatedItem> now found in <work> and <source>.
> >
> > Apart from an agreement on the overall structure, there are a number of issues to
> address. I will try to list them here as good as I can, though I am sure there are
> more.
> >
> > 1)	The naming of elements. For now, we have defined a generic
> <componentGrp> element available at all four levels, meaning that the schema
> allows for such rubbish as putting works into items, since <componentGrp> allows
> <work>, <expression>, <source>, and <item>. We may choose renaming them into
> <expressionComponents> etc. or something like that in order to control their
> different contents, or leaving it to the individual encoder (or schematron) to avoid
> such nonsense.
> > Speaking of element names, the good old name <sourceDesc> does not sound
> quite right to me. Especially if we introduce <expressionList> and <itemList>, I
> think <sourceList> would be more appropriate. The actual description of sources is
> what I would expect to find *inside* <source>. But I know that may too late to
> change...
> >
> > 2)	The content models of <source> and <item>, respectively. Obviously,
> some (well, most) elements will be needed at both levels, but to minimize
> confusion, I would suggest a few restrictions. The most obvious one would be to
> move <physLoc> out of <physDesc> and allowing it in <item> only. <watermark>
> may or may not be banned from <source> (would it make sense to describe the
> watermark of a print edition, or of individual copies only? I am not sure).
> >
> > 3)	Variations FRBR (http://www.dlib.indiana.edu/projects/vfrbr/). Would it be
> desirable to aim at offering fully VFRBR compliant encoding? It seems we are
> pretty close already, though not all VFRBR attributes are matched precisely by MEI
> elements. I must admit I have no opinion on whether it is important.
> > Perhaps the only element really missing from VFRBR compliancy is <extent> in
> <expression>. It should be no problem introducing it, I guess.
> > And now we're at it, certain projects have requested to be able to specify the
> duration (<extent>) of a work. Usually, this could and should be placed in
> <expression> rather than <work>, but what about the situation where the composer
> actually prescribes a specific duration for her work - an instruction that the actual
> expressions may or may not follow?
> >
> > 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 into the details of recordings metadata yet, but I guess we'll
> have to address that too at some point. Without having given it much thought, I
> see two options here and now (apart from <expression>): <bibl> and <source>,
> depending on the recording's relation to the encoding. We may want to add a
> number of elements to <source> to accommodate recording information.
> >
> > 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.
> >
> > Any comments greatly appreciated :-)
> >
> > All the best,
> > Axel
> >
> > _______________________________________________
> > mei-l mailing list
> > mei-l at lists.uni-paderborn.de
> > https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> 
> 
> 
> --
> Peter Stadler
> Carl-Maria-von-Weber-Gesamtausgabe
> Arbeitsstelle Detmold
> Gartenstr. 20
> D-32756 Detmold
> Tel. +49 5231 975-665
> Fax: +49 5231 975-668
> stadler at weber-gesamtausgabe.de
> www.weber-gesamtausgabe.de
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l