<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<br>
<br>
Thanks Raffaele for this analysis. I didn't even know that there was such an element as ossia.
<div><br>
</div>
<div>Currently we encode the cards as sections, since there are six piles of cards that are one and a half measures long appearing at the starts and endings of repeats. Each section has an unique xml:id constructed by pile and card number. </div>
<div><br>
</div>
<div>The encoding is done such that I write whole tunes each with cards with the same number. <br>
<br>
</div>
<div>Then we have written xquery for retrieving any tune given the their coordinates (pile,card)</div>
<div><br>
</div>
<div>Sigfrid<br>
<br>
<span style="font-size:100%">Skickat från Samsung Tablet</span></div>
<br>
Raffaele Viglianti <raffaeleviglianti@gmail.com> skrev:<br>
<div>
<div dir="ltr">Hi Axel,
<div><br>
</div>
<div style="">This is a fascinating problem and I also think that <choice> would also be more appropriate than <app> in this case. Though <choice>, de fact more than by definition, is used for alternatives justified by the elements that <choice> can contain,
such as <sic>, <corr>, <orig>, etc. So it's more editorial than what it seems. </div>
<div style=""><br>
</div>
<div style="">I would argue that <ossia> would be closer to what you're looking for, because these are alternatives suggested by "the text on the source". One caveat of ossia is that the alternative has to be provided within the same source, but you seem to
consider the cards as being one source, so maybe this will work. </div>
<div style=""><br>
</div>
<div style="">If I understand correctly, the cards can be consider as part of one "score", though a score that only gets determined by chance. Nonetheless, I would group the cards in a score element and assume that they only form one "movement" or section.</div>
<div style=""><br>
</div>
<div style=""><mdiv></div>
<div style=""> <score></div>
<div style=""> <section></div>
<div style=""><br>
</div>
<div style=""> </section></div>
<div style=""> </score></div>
<div style=""></midv> </div>
<div style=""><br>
</div>
<div style="">In <section>, I would create a "measure" for each of the 11 piles. Each represents the hypothetical measure that one of the alternative contents will fill. </div>
<div style=""><br>
</div>
<div style="">
<div><mdiv></div>
<div> <score></div>
<div style=""> <choice></div>
<div style=""> <measure n="1"/></div>
<div style=""> <measure n="2"/></div>
<div style=""> <measure n="3"/></div>
<div style=""> <!-- etc. --></div>
<div style=""> </choice></div>
<div> </score></div>
<div></midv> </div>
</div>
<div style=""><br>
</div>
<div style="">At this point, the content of each card is expressed as a staff within <ossia>. You can use @decls to point to the description of the card as physical object.</div>
<div style="">If you have more than one instrument, each one will need their ossia because of the measure-wise structure of MEI.</div>
<div style=""><br>
</div>
<div style="">
<div><mdiv></div>
<div> <score></div>
<div> <choice></div>
<div> <measure n="1"></div>
<div style=""> <ossia></div>
<div style=""> <staff n="1" decls="#card1"></div>
<div style=""> <!-- card content --></div>
<div style=""> </staff> </div>
<div style=""> <staff n="1" decls="#card2"/><br>
</div>
<div style=""> <!-- etc. --></div>
<div style=""> </ossia></div>
<div style=""> <ossia></div>
<div> <staff n="2" decls="#card1"/> </div>
<div> <staff n="2" decls="#card2"/><br>
</div>
<div> <!-- etc. --></div>
<div> </ossia></div>
<div style=""> </measure></div>
<div> <measure n="2"></div>
<div style=""> <!-- same for second pile! --></div>
<div style=""> </measure></div>
<div> <!-- etc. --></div>
<div> </choice></div>
<div> </score></div>
<div></midv> </div>
</div>
<div style=""><br>
</div>
<div style="">And that's it. One thing that it's not encoding is the selection criteria (the dice). But arguably, that's a performance issue and can be expressed with a <dir> somewhere. Or you can customize the verbose definition of <ossia> in ODD to specify
that a computer program can pick any of the alternatives at random.</div>
<div style=""><br>
</div>
<div style="">Another way of looking at this problem is to keep the act of "putting the pieces together" completely out of the MEI. You can take a "documentary" approach by encoding the cards as separate objects, and their relationship get expressed elsewhere,
either in a script's logic or with some subject-predicate-object triple structure.</div>
<div style=""><br>
</div>
<div style="">Best wishes,</div>
<div style="">Raffaele</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Jun 13, 2013 at 4:59 PM, Axel Teich Geertinger <span dir="ltr">
<<a href="mailto:atge@kb.dk" target="_blank">atge@kb.dk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
Hi Johannes and Zoltan<br>
<br>
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.<br>
<br>
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.<br>
<br>
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...<br>
<br>
All the best,<br>
Axel<br>
<br>
<br>
<br>
-----Oprindelig meddelelse-----<br>
Fra: <a href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a> [mailto:<a href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a>] På vegne af Johannes Kepper<br>
Sendt: 13. juni 2013 21:13<br>
<div class="im">Til: Music Encoding Initiative<br>
Emne: Re: [MEI-L] How to encode choices...?<br>
<br>
</div>
<div class="im">Dear Axel,<br>
<br>
this is an interesting problem. I'm sure there are better answers around, but here's a first take from me.<br>
</div>
<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.).<br>
<div>
<div class="h5"><br>
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:<br>
<br>
<app label="firstCard"><br>
<rdg target="#card1/><br>
<rdg target="#card2/><br>
.<br>
<rdg target="#card22/><br>
</app><br>
<app label="secondCard"><br>
<rdg target="#card1/><br>
<rdg target="#card2/><br>
.<br>
<rdg target="#card22/><br>
</app><br>
.<br>
<app label="eleventhCard"><br>
<rdg target="#card1/><br>
<rdg target="#card2/><br>
.<br>
<rdg target="#card22/><br>
</app><br>
<br>
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>.<br>
<br>
Other interpretations?<br>
<br>
Best,<br>
johannes<br>
<br>
<br>
<br>
Am 13.06.2013 um 19:18 schrieb Axel Teich Geertinger <<a href="mailto:atge@kb.dk">atge@kb.dk</a>>:<br>
<br>
> Dear list,<br>
><br>
> 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.<br>
> 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.<br>
><br>
</div>
</div>
> 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?).<br>
<div class="HOEnZb">
<div class="h5">><br>
> How do we encode choices among a number of alternatives provided by the composer as part of the compositional concept?<br>
><br>
> Best,<br>
> Axel<br>
><br>
> <image001.jpg><br>
> Det Kongelige Bibliotek<br>
> Nationalbibliotek og Københavns Universitetsbibliotek Axel Teich<br>
> Geertinger Forsker, ph.d. | Researcher, PhD Konstitueret centerleder |<br>
> Interim Head of Centre<br>
><br>
> Det Kongelige Bibliotek | The Royal Library Dansk Center for<br>
> Musikudgivelse | Danish Centre for Music Publication P.O. Box 2149 |<br>
> DK-1016 København K tel <a href="tel:%2B45%203347%204706" value="+4533474706">+45 3347 4706</a> | Fax
<a href="tel:%2B45%203393%202218" value="+4533932218">+45 3393 2218</a> | <a href="mailto:atge@kb.dk">
atge@kb.dk</a><br>
> | <a href="http://www.kb.dk" target="_blank">www.kb.dk</a><br>
><br>
> Besøgsadresse | Visiting address | Søren Kierkegaards Plads 1<br>
> Leveringsadresse | Delivery address | Christians Brygge 8 | 1219<br>
> København K<br>
><br>
> EAN 5798 000 79 52 97 | Bank 0216 <a href="tel:4069032583" value="+14069032583">
4069032583</a> | CVR 28 98 88 42 IBAN<br>
> DK2002164069032583 | Swiftcode DABADKKK<br>
><br>
><br>
> _______________________________________________<br>
> mei-l mailing list<br>
> <a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">
https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
<br>
<br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
<br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</body>
</html>