[MEI-L] More "precise" <app>s

[Raffaele Viglianti]

Hello,

As Andrew said, @source helps, as it expresses the fact that both readings
are from one source.

Though if I understand Thomas' issue correctly, he's also interested in
encoding the fact that the two apps can form one apparatus entry.

Imagine for example an apparatus entry that says:

Measures 1-2; System: Flutes; Comment: values of rests are incorrect in
source A; source B has correct values.

This can be split in two apps, like in the example that Andrew wrote.
However, using only @source wouldn't reflect the fact that the two apps are
part of one editorial statement.

A use case for using @prev and @next would be to be able to generate the
apparatus entry above from the encoding (I have seen this done in TEI).

I don't think it's particularly urgent, but I can definitely see value in
having @prev and @next on app. At least it would compensates for the fact
that one app can contain several staves in one measure at once, but not
multiple measures in one staff.

Best,
Raffaele


On Sun, Jul 15, 2012 at 1:53 PM, Andrew Hankinson, Mr <
andrew.hankinson at mail.mcgill.ca> wrote:

> Hi Thomas,
>
> I think you're looking for @source on <rdg>.
>
> <meiHead>
> ....
> <sourceDesc>
>   <source xml:id="sourceA">
>     <pubStmt/>
>   </source>
>   <source xml:id="sourceB">
>     <pubStmt/>
>   </source>
> </sourceDesc>
> ....
> </meiHead>
> ...
> <measure n="1">
>    <app>
>      <rdg source="sourceA">
>
>        <staff n="1">
>          <!-- Some music -->
>        </staff>
>      </rdg>
>      <rdg source="sourceB">
>
>        <staff n="1">
>          <!-- Some variant of the music -->
>        </staff>
>      </rdg>
>    </app>
>    <staff n="2"/>
>    <staff n="3"/>
>    <staff n="4"/>
>    <staff n="5"/>
>    <staff n="6"/>
>    <staff n="7"/>
>    <staff n="8"/>
>    <staff n="9"/>
>    <staff n="10"/>
>  </measure>
>  <measure n="2">
>    <app>
>      <rdg source="sourceA">
>
>        <staff n="1">
>          <!-- Some more music -->
>        </staff>
>      </rdg>
>      <rdg source="sourceB">
>
>        <staff n="1">
>          <!-- Continued variant of the music -->
>        </staff>
>      </rdg>
>    </app>
>    <staff n="2"/>
>    <staff n="3"/>
>    <staff n="4"/>
>    <staff n="5"/>
>    <staff n="6"/>
>    <staff n="7"/>
>    <staff n="8"/>
>    <staff n="9"/>
>    <staff n="10"/>
>  </measure>
>
> @source can take a space-delimited list of xml:ids too.
>
> -Andrew
>
> On 2012-07-15, at 2:24 AM, TW wrote:
>
> Dear MEI family,
>
> how does one encode variant readings that only affect a certain
> "strand" of events? For example, if we have a full orchestral score
> where there are different readings of the flute's measures 1 and 2, I
> see the following options:
> 1a) One big <app> around measure 1 and 2, containing all staffs twice,
> like so:
>  <app>
>    <rdg>
>      <measure n="1">
>        <staff n="1">
>          <!-- Some music -->
>        </staff>
>        <staff n="2"/>
>        <staff n="3"/>
>        <staff n="4"/>
>        <staff n="5"/>
>        <staff n="6"/>
>        <staff n="7"/>
>        <staff n="8"/>
>        <staff n="9"/>
>        <staff n="10"/>
>      </measure>
>      <measure n="2">
>        <staff n="1">
>          <!-- Some more music -->
>        </staff>
>        <staff n="2"/>
>        <staff n="3"/>
>        <staff n="4"/>
>        <staff n="5"/>
>        <staff n="6"/>
>        <staff n="7"/>
>        <staff n="8"/>
>        <staff n="9"/>
>        <staff n="10"/>
>      </measure>
>    </rdg>
>    <rdg>
>      <measure n="1">
>        <staff n="1">
>          <!-- Some variant of the music -->
>        </staff>
>        <staff n="2"/>
>        <staff n="3"/>
>        <staff n="4"/>
>        <staff n="5"/>
>        <staff n="6"/>
>        <staff n="7"/>
>        <staff n="8"/>
>        <staff n="9"/>
>        <staff n="10"/>
>      </measure>
>      <measure n="2">
>        <staff n="1">
>          <!-- Continued variant of the music -->
>        </staff>
>        <staff n="2"/>
>        <staff n="3"/>
>        <staff n="4"/>
>        <staff n="5"/>
>        <staff n="6"/>
>        <staff n="7"/>
>        <staff n="8"/>
>        <staff n="9"/>
>        <staff n="10"/>
>      </measure>
>    </rdg>
>  </app>
> This already seems like overkill, although I didn't even fill the
> staffs with music.  And facing such a monster, you'd have to look very
> closely to spot the actual variant readings, so this is certainly not
> the way to go.
>
> 1b) To avoid filling the staffs twice, one could of course use @copyof
> the second time. But this might break ID references.
>
> 2) Split this in two <app>s, like so:
>  <measure n="1">
>    <app>
>      <rdg>
>        <staff n="1">
>          <!-- Some music -->
>        </staff>
>      </rdg>
>      <rdg>
>        <staff n="1">
>          <!-- Some variant of the music -->
>        </staff>
>      </rdg>
>    </app>
>    <staff n="2"/>
>    <staff n="3"/>
>    <staff n="4"/>
>    <staff n="5"/>
>    <staff n="6"/>
>    <staff n="7"/>
>    <staff n="8"/>
>    <staff n="9"/>
>    <staff n="10"/>
>  </measure>
>  <measure n="2">
>    <app>
>      <rdg>
>        <staff n="1">
>          <!-- Some more music -->
>        </staff>
>      </rdg>
>      <rdg>
>        <staff n="1">
>          <!-- Continued variant of the music -->
>        </staff>
>      </rdg>
>    </app>
>    <staff n="2"/>
>    <staff n="3"/>
>    <staff n="4"/>
>    <staff n="5"/>
>    <staff n="6"/>
>    <staff n="7"/>
>    <staff n="8"/>
>    <staff n="9"/>
>    <staff n="10"/>
>  </measure>
> This looks preferable to me, especially because it allows
> "overlapping" variants, e.g. when there is another phrase with variant
> readings, but this time for the basses from measure 2 to 3.
> Unfortunately, I don't see a really good way to indicate that any two
> or more <app> elements form a logical unit. I think that the
> att.common.anl family of attributes might be useful for this,
> especially the @prev and @next attributes because they imply the
> concept of a "collection".  The next best solution might be to use
> @prev and @next on the contained <lem> and <rdg> elements, but
> providing them on <app> would make things much clearer and easier.
>
> Therefore, shouldn't att.common.anl be allowed on <app>?
>
> Thomas
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120715/570147fc/attachment.html>