[MEI-L] FRBR in MEI

Tue Nov 20 09:38:37 CET 2012

Hi Johannes,

thanks for your comments (thanks to Perry too!). I just wanted to make sure we agree that this use of expressions is acceptable.

I am very well aware of the performances being expression-specific when listed within <expression>. Probably some projects will not want to distinguish different versions of an opera, while others will. Again, the project-specific decision about what to group as one version, i.e. the amount of variation allowed within an expression, decides where to list which performances. 
I could easily leave it even more open, offering performance lists at both work and expression levels. This way, the editor may decide to list them under the version they represent, or in a general list regardless of version. That would also be the place to list performances where the version performed is not known.

Originally, I had performances listed only at work level. May I remind you that it was your suggestion (though not on this list) moving them to <expression>?  ;-)

All the best,
Axel

-----Oprindelig meddelelse-----
Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Johannes Kepper
Sendt: 20. november 2012 08:34
Til: Music Encoding Initiative
Emne: Re: [MEI-L] FRBR in MEI

Hi Axel,

I totally agree with Perry. These are project-specific decisions about how to use FRBR and MEI in general. We don't want to enforce a specific model here, but leave the implementation open to a certain degree. The current proposal allows to do so, and also has the benefit that shortcuts like yours (performances in an eventList) are still comprehensible enough to be compatible to more specific projects (using XSLT). I think we shouldn't water the concept of FRBR just because we can't come up with better examples right away. Others may, and they couldn't use it in such a way. FRBR itself gives the user some freedom in deciding what constitutes a new version, and if that is modeled as expression or manifestation. We should preserve that in our implementation. 

Axel, you're certainly aware of this, but your model (performances in expression's eventList) requires that every performance is based on exactly one textual version / expression of the work. As soon as more than one set of source materials has been used, this assumption is incorrect. Also, dealing with opera might be cumbersome. If you think of a performance for which you don't have or don't know the used materials, it's hard to assign that to one of your known expressions. Especially since operas have been customized quite heftily, each performance may justify a textual expression, even if the source materials haven't been preserved. I don't have answers to these questions right away, but it might be worthwhile to think about them or at least be aware of them when implementing merMEId. For me, it would probably be sufficient to mention that in the documentation, and leave the software unchanged. 

These issues don't contradict with what I said before. They are project-specific, and they depend on a specific editorial concept, which others may or may not follow. Axel's solutions might be appropriate for some, and will certainly be inappropriate to others. But paired with thorough documentation, the data are still interchangeable across different projects. 

Best,
Johannes

Am 19.11.2012 um 23:49 schrieb Roland, Perry (pdr4h):

> Hi, Axel,
>  
> I don't think the subsitution of <version> for <expression> helps very much.  We're still left with the question of what constitutes a new/different version and the answer to that question will vary.  I suspect it will depend on whether the project is addressing printed music only or printed and manuscript versions, among other things.
>  
> The question of what signals a different version between two manuscript versions is a very thorny one indeed.  Taken to the extreme, I suppose every single intervention potentially creates a huge hierarchical tree of versions.  But this is the province of philology and probably should be addressed somewhere other than in the FRBR entities, say using <app>.  Therefore, I would advise a somewhat loose, not-too-granular approach in the use of FRBR in MEI (and everywhere else for that matter).
>  
> Said another way, it's not very important that something fit precisely into the "correct" <source> or <expression> element, but that one is consistent, uses only the number of entities that achieve the level of descriptive granularity required, and that relationships between the entities are explicitly marked.
>  
> --
> p.
>  
> __________________________
> Perry Roland
> Music Library
> University of Virginia
> P. O. Box 400175
> Charlottesville, VA 22904
> 434-982-2702 (w)
> pdr4h (at) virginia (dot) edu
> From: mei-l-bounces at lists.uni-paderborn.de 
> [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich 
> Geertinger [atge at kb.dk]
> Sent: Monday, November 19, 2012 3:17 PM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] FRBR in MEI
> 
> Hi Perry, Craig,
>  
> Yes, I was of course speaking of the header, where the FRBR-related elements are about to be implemented. In this context my remark about how to "encode performances" was intended to mean "encode information about the historical events where the work (or rather: the expression) was performed"...
>  
> I would still, however, be curious to hear any opinions on the interpretation of the expression level as versions (or, as an alternative, using <version> instead of <expression>), because that is how MerMEId treats them right now. The FRBR-extended schema itself does not enforce that interpretation, but MerMEId does, unless we change the concept.
>  
> /axel
>  
>  
> Fra: mei-l-bounces at lists.uni-paderborn.de 
> [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry 
> (pdr4h) [pdr4h at eservices.virginia.edu]
> Sendt: 19. november 2012 16:26
> Til: Music Encoding Initiative
> Emne: Re: [MEI-L] FRBR in MEI
> 
> Hi, Craig,
>  
> I want clear up any confusion about MEI's <eventList> element.  I don't think <eventList> is what you're thinking of as an "event list"; that is, a place to put timing information.  <eventList> is for recording *historical events using prose*.  <timeline>, on the other hand, is for capturing processable time data.  I believe that's where the kind of thing you're thinking of should go. 
>  
> Multiple <timeline> elements are allowed within <music> and/or within 
> <scoreDef>. <timeline> "[p]rovides a set of ordered points in time to which musical elements can be linked in order to create a temporal alignment of those elements."
>  
> The timing data you provide in 
> http://mazurka.org.uk/webern/dynamics/mvmt1/webern-op27-1-Aitken1961.d
> yn can easily be mapped to --
>  
> <timeline>
>   <when xml:id="event1" absolute="5.518"/>
>   <when xml:id="event2" absolute="6.018"/>
>   <!-- and so on -->
> </timeline>
> while the dynamics can be recorded using <dynam> in the notation part of the tree.  Unfortunately, at present there's no place to record your values on <dynam> ("73.7632", etc.), only integer values in the MIDI value range, i.e., 0-127.  This can be remedied in the short term by customizing the @val attribute.
>  
> Assuming customization of @val, a dynamic can be associated with a 
> timepoint using @when --
>  
> <dynam when="#event1" val="73.7632"/>
> <dynam when="#event2" val="69.4717"/>
> <!-- und so weiter -->
>  
> At present, there's no way to link a <timeline> directly with a FRBR entity, such as <source> (manifestation).  An indirect link is possible by associating a timeline (via its @avref attribute) with a digital recording, then associating that digital file (represented by <avFile>) with a particular source description (via its @decls attribute).  There's no requirement that @decls refer to any particular FRBR entity type (work, expression, manifestion, or item), making it theoretically possible to connect a digital audio file to any FRBR entity; however, practically speaking, a digital audio file is probably best associated with a manifestation; that is, an MEI <source> element.  It would be appropriate to describe the Delos DEL 25407 (1978) recording using <source> as it is the base material from which your encoding of the dynamics and timing information are taken.
>  
> "Performance" scores of the type you're describing can be encoded in 
> MEI by leaving out the duration information at the event level and 
> associating the event with timing information provided within 
> <timeline> --
>  
> <chord when="#event1">
>   <note pname="f" oct="4"/>
>   <note pname="e" oct="5"/>
> </chord>
>  
> There's no defined way yet, however, to record both a "performance" score and a traditional one in the same MEI file.
>  
> Hope this helps,
>  
> --
> p.
> 
> __________________________
> Perry Roland
> Music Library
> University of Virginia
> P. O. Box 400175
> Charlottesville, VA 22904
> 434-982-2702 (w)
> pdr4h (at) virginia (dot) edu
> _______________________________________________
> mei-l mailing list
> 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