<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Sigfrid,<br>
hi Axel,<br>
great that someone else thinks of how to encode combinatorial
games in music ;-)<br>
<br>
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.<br>
<br>
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"<br>
<br>
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:<br>
<br>
<mdiv xml:id="A"><br>
<parts><br>
<part xml:id="piano"><br>
<section xml:id="A2" next="B"><br>
<measure><!-- card content
--></measure><br>
</section><br>
<section xml:id="A3"><br>
<measure><!-- card content
--></measure><br>
</section><br>
<!-- &c. --><br>
</part><br>
</parts><br>
</mdiv><br>
<mdiv xml:id="B"><br>
<parts><br>
<part xml:id="piano"><br>
<section xml:id="B2" next="C" prev="A"><br>
<measure><!-- card content
--></measure><br>
</section><br>
<!-- &c. --><br>
</part><br>
</parts><br>
</mdiv><br>
<br>
Hope that helps,<br>
Benjamin<br>
<pre class="moz-signature" cols="72">***********************************************************
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: <a class="moz-txt-link-abbreviated" href="mailto:bohl@edirom.de">bohl@edirom.de</a>
<a class="moz-txt-link-freetext" href="http://www.freischuetz-digital.de">http://www.freischuetz-digital.de</a>
***********************************************************</pre>
Am 14.06.2013 08:06, schrieb Sigfrid Lundberg:<br>
</div>
<blockquote
cite="mid:9rpwh2ha3vda0144drluyrmf.1371188694636@email.android.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<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 <a class="moz-txt-link-rfc2396E" href="mailto:raffaeleviglianti@gmail.com"><raffaeleviglianti@gmail.com></a> 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 moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a>
[mailto:<a moz-do-not-send="true"
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 moz-do-not-send="true" 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
moz-do-not-send="true"
href="tel:%2B45%203347%204706" value="+4533474706">+45
3347 4706</a> | Fax
<a moz-do-not-send="true"
href="tel:%2B45%203393%202218" value="+4533932218">+45
3393 2218</a> | <a moz-do-not-send="true"
href="mailto:atge@kb.dk">
atge@kb.dk</a><br>
> | <a moz-do-not-send="true"
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
moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
mei-l mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
<a class="moz-txt-link-freetext" href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a>
</pre>
</blockquote>
<br>
</body>
</html>