[MEI-L] choice and app

[Roland, Perry (pdr4h)]

Johannes,

> - app isn't allowed within choice, whereas choice is allowed in app

This is exactly what TEI does.  I think this is the proper way to do it.

> - choice is only allowed within measures, app is also allowed above
> measures. Within choice, measures aren't allowed anymore. So when I
> use <score><app><rdg><choice><orig>… I have no chance of getting
> measures in there.

Again, I think this is proper.  A single source usually doesn't/cannot (?)  have different numbers of measures for a single section of music.  That is, source 1 can only have a certain number of measures in section 1.  Variation in the number of measures (source 1 has 3 measures in section A, source 2 has 4 measures, and so on) is covered by

<app>
  <rdg source="s1">
    <measure n="1"/><measure n="2"/><measure n="3"/>
  </rdg>
  <rdg source="s2">
    <measure n="1"/><measure n="2"/><measure n="3"/><measure n="4"/>
  </rdg>

A regularization that somehow combines readings 1 and 2 may be encoded as another reading without pointing to a source --
  <rdg resp="JK">...</rdg>

Alternatively, we may add (as TEI does) a <lem> element for capturing the preferred reading.  But I'd have to think about this more.

<choice> (and its kin) are for capturing variation within a single source.  I don't see anything wrong at all with

>   <app>
>     <rdg source="s1">
>       <choice>
>         <orig>…</orig>
>         <reg resp="JV">…</reg>
>       </choice>
>     </rdg>
>     <rdg source="s2">
>       <choice>
>         <orig>…</orig>
>         <reg resp="JV">…</reg>
>       </choice>
>     </rdg>
>   </app>

This is the "parallel segmentation method" described in the TEI Guidelines.  I don't understand what you're trying to accomplish with @corresp.  If you intend to construct a regularized version of the text of source 1, then a processor chooses within <app> all <rdg>s where @source=s1 and within <choice> elements, <reg> elements where @resp="JV".  The same method works for any source and any form (orig or reg) of that source.

Mixing app and choice is definitely *NOT* an option.

Your last example

>   <choice>
>     <orig>
>       <app>
>         <rdg source="s1">…</rdg>
>         <rdg source="s2">…</rdg>
>       </app>
>     </orig>
>     <reg resp="JV">…</reg>
>   </choice>

leads to overloading choice (and its buddies) like app is overloaded now.  It's technically possible, but I don't recommend it.

Perhaps I misunderstood something?

--
p.

__________________________
Perry Roland
Scholarly Resources
University of Virginia Library
Post Office Box 400155
Charlottesville, VA 22904- 4155
434-982-2702 (w)
pdr4h at virginia.edu
________________________________________
From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Johannes Kepper [kepper at edirom.de]
Sent: Saturday, March 28, 2009 10:09 PM
To: Music Encoding Initiative
Subject: [MEI-L] choice and app

Hi all,

as I'm currently having some last looks on several issues of MEI for
my thesis, I found that choice and app do not work together well yet.
Some examples:

- app isn't allowed within choice, whereas choice is allowed in app

- choice is only allowed within measures, app is also allowed above
measures. Within choice, measures aren't allowed anymore. So when I
use <score><app><rdg><choice><orig>… I have no chance of getting
measures in there.

-  in the second of the Paderborn examples (the Weber), there is a
combination of choice and app. Both sources show different slurs,
which is clearly to be encoded by using app. But then there is also
the editors interpretation as sempre legato, which Perry encoded by
using annot and a verbal description. Since then we have choice now,
and in my eyes a <reg> seems to be the best solution here.

One could do
<choice>
        <orig source="s1">…</orig>
        <orig source="s2">…</orig>
        <reg resp="JV">…</reg>
</choice>
but this isn't how it was meant in my eyes.

Currently I have to use
<app>
        <rdg source="s1">
                <choice>
                        <orig>…</orig>
                        <reg resp="JV">…</reg>
                </choice>
        </rdg>
        <rdg source="s2">
                <choice>
                        <orig>…</orig>
                        <reg resp="JV">…</reg>
                </choice>
        </rdg>
</app>
which is not too nice either. Although a @corresp on reg might allow
to point from the second reg to the first, this is no real solution,
is it? On the other hand, mixing app and choice to one general element
seems to be at least one step to far, as they deal with different
issues. What do you guys think about this? Is something like the
following a possible solution?

<choice>
        <orig>
                <app>
                        <rdg source="s1">…</rdg>
                        <rdg source="s2">…</rdg>
                </app>
        </orig>
        <reg resp="JV">…</reg>
</choice>

In this case the reg would be an equivalent to both readings combined,
which is more appropriate to the situation in the example. What do you
think?


Besides, we have to think about app (and also choice) as milestones
(to borrow from TEI), but not tonight…

thanks for reading such bulky mails
Johannes
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l