[MEI-L] How to encode choices...?

Thu Jun 13 22:59:52 CEST 2013

Hi Johannes and Zoltan

Thank you for your input. I am not completely convinced by either approaches - using multiple <orig> in <choice>, or a number of <rdg> elements in <app>. I think I need be a little more specific about the nature of the work in question. The piles of cards are labeled A to V. The composition must begin with one of the cards A2 to A12 (bar 1), followed by one of the cards B2 to B12 (bar 2) etc. This means that the cards cannot be shuffled - each card can only appear in one particular place, so each pile of cards really does represent different texts at the "same point in the text", and that is why I thought <choice> would be the right element to use, because that's what it is: a choice one has to make at that particular point in order to perform or render the piece.

Using <app> and <rdg> does not sound right to me, because they are for use with the critical apparatus (which is an editorial device, as I see it). The guidelines clearly say that "An app element always encapsulates the differences between varying sources". But here, the entire set of cards is _one_ source, and the alternatives are not variant readings in the sense used in a critical apparatus. They are not about disagreement between sources, but intentionally different options and exactly equally valid. 

As you say, the editorial elements within <choice> come in pairs, so <orig> signals to me that there will follow a <reg> element or something of that kind providing a (slightly) different (i.e. corrected, regularized etc.) encoding of the _same_ content. The guidelines say that <orig> "Contains material which is marked as following the original, rather than being normalized or corrected." It is not obvious to me how multiple <orig> siblings within <choice> should be understood. I was just hoping to be able to put <section> or <measure> or the like into <choice>; that would make sense to me in this case. I see that this may imply turning <choice> into another one of these scary elements that - like <rdg> - may contain just about anything and really are open to encoding all sorts of rubbish...

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: 13. juni 2013 21:13
Til: Music Encoding Initiative
Emne: Re: [MEI-L] How to encode choices...?

Dear Axel,

this is an interesting problem. I'm sure there are better answers around, but here's a first take from me. 
<choice> is about the "same point in a text", as you pointed out.  Normally, you encode the alternatives in its child elements, which are normally paired (<abbr> and <expan>, <sic> and <corr> etc.). It is absolutely possible to have a set of <orig> elements. However, when interpreting the "same point in a text" in a verbose way, <choice> seems to be the wrong choice. Your example has a set of different texts, which may be shuffled or selected randomly, but most importantly, they are different texts. Also, my understanding of the elements from the edittrans module is that they should be used to enrich encodings with additional background knowledge of the editor. Here, everything seems to be in the sources (though this is certainly arguable.). 

I would probably encode every card as a separate section (or even mdiv), and then use an <app> / <rdg> structure referring to these to encode a virtual "walkthrough". Given you know that eleven cards should be played, it would look like so:

<app label="firstCard">
	<rdg target="#card1/>
	<rdg target="#card2/>
	.
	<rdg target="#card22/>
</app>
<app label="secondCard">
	<rdg target="#card1/>
	<rdg target="#card2/>
	.
	<rdg target="#card22/>
</app>
.
<app label="eleventhCard">
	<rdg target="#card1/>
	<rdg target="#card2/>
	.
	<rdg target="#card22/>
</app>

I'm not fully convinced of this approach, as it relies on the interpretation of the cards as different texts, but it should work nicely with an application doing the actual selections in each <app>. 

Other interpretations?

Best,
johannes

Am 13.06.2013 um 19:18 schrieb Axel Teich Geertinger <atge at kb.dk>:

> Dear list,
>  
> We are preparing a little experimental digital edition of a piece named "Kaleidakustikon" (c.1820) by Friedrich Kuhlau. It is an aleatoric piece of music of the same kind as, for instance, Kirnberger's "Der allezeit fertige Menuetten- und Polonaisencomponist" and the "Musikalisches Würfelspiel" attributed to Mozart.
> It consists of 21 piles of cards, each card containing one bar of music. The player selects one of the 11 cards in each pile by throwing dice. Put together, these cards form a little waltz. The project is of course to make it an online game, at the same time giving us some experience with MEI workflows.
>  
> The question is: How should we encode the multiple alternatives for each bar? The guidelines explain that the <choice> element "groups a number of alternative encodings for the same point in a text". Sounds perfect for this purpose. However, it only allows editorial markup elements like <abbr>, <sic>, <corr>, <reg>, <orig>, <unclear>, <subst>, and <expan> as child elements (BTW, the guidelines p. 163 also mention <add> and <del>, but not <abbr>, <expan>, and <subst> - a mistake?).
>  
> How do we encode choices among a number of alternatives provided by the composer as part of the compositional concept?
>  
> Best,
> Axel
>  
> <image001.jpg>
> Det Kongelige Bibliotek
> Nationalbibliotek og Københavns Universitetsbibliotek Axel Teich 
> Geertinger Forsker, ph.d. | Researcher, PhD Konstitueret centerleder | 
> Interim Head of Centre
> 
> Det Kongelige Bibliotek | The Royal Library Dansk Center for 
> Musikudgivelse | Danish Centre for Music Publication P.O. Box 2149 | 
> DK-1016 København K tel +45 3347 4706 | Fax +45 3393 2218 | atge at kb.dk 
> | www.kb.dk
> 
> Besøgsadresse | Visiting address | Søren Kierkegaards Plads 1 
> Leveringsadresse | Delivery address | Christians Brygge 8 | 1219 
> København K
> 
> EAN 5798 000 79 52 97 | Bank 0216 4069032583 | CVR 28 98 88 42 IBAN 
> DK2002164069032583 | Swiftcode DABADKKK
>  
>  
> _______________________________________________
> 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