[MEI-L] How to encode choices...?
Benjamin Wolff Bohl
bohl at edirom.de
Fri Jun 14 08:52:39 CEST 2013
Hi Sigfrid,
hi Axel,
great that someone else thinks of how to encode combinatorial games in
music ;-)
I can very much understand your idea of using <choice> it would make
things so straightforward, wouldn't it? And also Zoltan's idea to use
<rdg> seems very plausible when reading the respective element
descriptions. Nevertheless as has been mentioned, these elements were
for editorial additions and the like.
I tried to encode Francesco Saverio's Guida Armonica and still am on
overhauling it and (maybe) bringing it to MEI. And in this context I
stumbled over the attributes @prev and @next their description
respectively say: "points to the next/previous event(s) in a user
defined collection"
Although not hitting the spot absolutely, I could imagine an encoding
using mdiv elements to group the stacks (A, B, &c.) and sections for the
individul cards. With @prev and @next on the sections pointing to
possible next sections; something like this one:
<mdiv xml:id="A">
<parts>
<part xml:id="piano">
<section xml:id="A2" next="B">
<measure><!-- card content --></measure>
</section>
<section xml:id="A3">
<measure><!-- card content --></measure>
</section>
<!-- &c. -->
</part>
</parts>
</mdiv>
<mdiv xml:id="B">
<parts>
<part xml:id="piano">
<section xml:id="B2" next="C" prev="A">
<measure><!-- card content --></measure>
</section>
<!-- &c. -->
</part>
</parts>
</mdiv>
Hope that helps,
Benjamin
***********************************************************
Musikwissenschaftliches Seminar Detmold/Paderborn
BMBF-Projekt "Freischütz Digital"
Benjamin Wolff Bohl
Gartenstraße 20
D--32756 Detmold
Tel. +49 (0) 5231 / 975-669
Fax: +49 (0) 5231 / 975-668
E-Mail: bohl at edirom.de
http://www.freischuetz-digital.de
***********************************************************
Am 14.06.2013 08:06, schrieb Sigfrid Lundberg:
>
>
> Thanks Raffaele for this analysis. I didn't even know that there was
> such an element as ossia.
>
> 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.
>
> The encoding is done such that I write whole tunes each with cards
> with the same number.
>
> Then we have written xquery for retrieving any tune given the their
> coordinates (pile,card)
>
> Sigfrid
>
> Skickat från Samsung Tablet
>
> Raffaele Viglianti <raffaeleviglianti at gmail.com> skrev:
> 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
>
>
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20130614/321523e9/attachment.html>
More information about the mei-l
mailing list