[MEI-L] Choice
Axel Teich Geertinger
atge at kb.dk
Fri Jun 14 13:10:38 CEST 2013
Yes, perhaps it is too much to expect from an encoding system like MEI.
In this particular case, there is no written explanation with the cards, but I am quite sure there has been one. Our copy is not complete: The lid of the box as well as 8 cards from the H pile are missing, which is the only one we have been able to locate (if anyone knows of another copy please let us know!!). The answer to your question, whether one would be able to understand the concept without an explanation, would certainly be yes (unless we have misunderstood it, obviously...). So for now, let us assume these rules are part of the composition.
The encoding of a compositional concept that goes beyond the mere notation may indeed be outside the scope of MEI. I just thought it would be nifty to describe within in a single MEI encoding not only the contents of the cards, but also the way they are organized (i.e. which options there are at each point in the piece).
The actual selection of one particular path through the material is something different, or rather a next step. Your choice of cards equals an editorial decision and could very well be recorded using <app>/<rdg>, as I see it.
Technically there are many ways of handling the logic, of course. As Sigge explained, he has encoded each of the layers (the first one being a2, b2, c2, d2... etc.) in a separate file, so we have 11 files, each containing a complete waltz. On request, the programmed logic selects the first measure from one of the files, appends the next measure from another one (or the same) etc. No problem.
But to me, the interesting question here is whether MEI is or should be capable of semantically encoding a source of this kind.
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: 14. juni 2013 12:07
Til: Music Encoding Initiative
Emne: Re: [MEI-L] Now with attachments...
Hi all,
I see the argument for <ossia>, and maybe extending it to allow its appearance further up in the tree is the way to go, but I wonder if there is an explanation available on the card deck. In other words: Would someone not familiar with the background recognize the purpose of the cards just by looking at them? Is the "processing" really a part of the music that you transcribe, or is this algorithmic logic better addressed elsewhere? This seems to be a specific case of musical rules, to be applied on a strictly defined corpus (the cards.). I'm not sure if MEI is the right format to address these rules adequately. This answer is clearly not satisfactory, as there is no such format yet (Benni?), but Raffaele's pointer to RDF seems reasonable for a quick solution. Another possibility, if you prefer to have everything in XML (though RDF can be expressed in XML as well), would be to include a snippet of XSLT somewhere in the header. I'm not suggesting that you actually use this XSLT for processing the files, but for documenting the algorithm. Well, there are many ways of driving oneself insane when modelling music.
Best,
Johannes
Am 14.06.2013 um 11:38 schrieb Axel Teich Geertinger:
> Right, I forgot the attachments. Here they are.
>
> /axel
>
> Fra: mei-l-bounces at lists.uni-paderborn.de
> [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Axel Teich
> Geertinger
> Sendt: 14. juni 2013 10:01
> Til: Music Encoding Initiative
> Emne: Re: [MEI-L] How to encode choices...?
>
> Raffaele,
>
> Thanks a lot. Ossia may indeed be the key to the solution, in principle at least. However, since <ossia> is a child of <measure> (or <staff>), I cannot apply it at a higher level including 1) more than one measure and 2) more than one staff.
> The problem with your solution to the latter problem is that <choice> cannot contain <measure> (or <section>, which probably would be most useful here).
>
> Benjamin, I was happy to learn about your interest in these dice games at the conference in Mainz too. Your solution using <section> for the alternatives and @next/@prev to navigate through the piece surely works, only it does not really describe the compositional idea of these concepts, does it? I was hoping to find a solution explicitly marking the points of choice as such as well as the options in each case.
>
> I am attaching two of the cards (a2 and b2) for your information. As Sigge mentioned, some of them include an upbeat or (at the section ends) the two beats of the next bar - that's why we need something above <measure> level.
>
> Best,
> Axel
>
>
>
> Fra: mei-l-bounces at lists.uni-paderborn.de
> [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Raffaele
> Viglianti
> Sendt: 13. juni 2013 23:50
> Til: Music Encoding Initiative
> Emne: Re: [MEI-L] How to encode choices...?
>
> Hi Axel,
>
> 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.
>
> 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.
>
> 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.
>
> <mdiv>
> <score>
> <section>
>
> </section>
> </score>
> </midv>
>
> 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.
>
> <mdiv>
> <score>
> <choice>
> <measure n="1"/>
> <measure n="2"/>
> <measure n="3"/>
> <!-- etc. -->
> </choice>
> </score>
> </midv>
>
> 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.
> If you have more than one instrument, each one will need their ossia because of the measure-wise structure of MEI.
>
> <mdiv>
> <score>
> <choice>
> <measure n="1">
> <ossia>
> <staff n="1" decls="#card1">
> <!-- card content -->
> </staff>
> <staff n="1" decls="#card2"/>
> <!-- etc. -->
> </ossia>
> <ossia>
> <staff n="2" decls="#card1"/>
> <staff n="2" decls="#card2"/>
> <!-- etc. -->
> </ossia>
> </measure>
> <measure n="2">
> <!-- same for second pile! -->
> </measure>
> <!-- etc. -->
> </choice>
> </score>
> </midv>
>
> 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.
>
> 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.
>
> Best wishes,
> Raffaele
>
>
> On Thu, Jun 13, 2013 at 4:59 PM, Axel Teich Geertinger <atge at kb.dk> wrote:
> 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
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
> <a_02.jpg><b_02.jpg>_______________________________________________
> 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
More information about the mei-l
mailing list