[MEI-L] FRBR in MEI

[Peter Stadler]

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