[MEI-L] Now with attachments...
Axel Teich Geertinger
atge at kb.dk
Fri Jun 14 11:38:00 CEST 2013
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> [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<mailto: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> [mailto: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<mailto: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<tel:%2B45%203347%204706> | Fax +45 3393 2218<tel:%2B45%203393%202218> | atge at kb.dk<mailto:atge at kb.dk>
> | www.kb.dk<http://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<tel:4069032583> | CVR 28 98 88 42 IBAN
> DK2002164069032583 | Swiftcode DABADKKK
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de<mailto: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<mailto: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<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20130614/3d5140a9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a_02.jpg
Type: image/jpeg
Size: 50986 bytes
Desc: a_02.jpg
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20130614/3d5140a9/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: b_02.jpg
Type: image/jpeg
Size: 46905 bytes
Desc: b_02.jpg
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20130614/3d5140a9/attachment-0001.jpg>
More information about the mei-l
mailing list