[MEI-L] Reconstructed parts
Raffaele Viglianti
raffaeleviglianti at gmail.com
Wed Jul 24 15:14:10 CEST 2013
Hi Perry,
Good point, your solution makes perfect sense. I'm stuck with the idea that
rdg = another physical source, but there's no need to be this strict,
especially if @source and @resp can distinguish two different uses. So +1
to app/rdg for Micah's case.
Raffaele
On Tue, Jul 23, 2013 at 10:25 PM, Roland, Perry (pdr4h) <
pdr4h at eservices.virginia.edu> wrote:
> Hello all,
>
> I believe this situation is addressed in section 12.3 of the TEI
> Guidelines, "Using Apparatus Elements in Transcriptions" (
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCTR) --
>
> "It is often desirable to record different transcriptions of one stretch
> of text. These variant transcriptions may be grouped within a single app
> element. An application may then construct different ‘views’ of the
> transcription by extraction of the appropriate variant readings from the
> apparatus elements embedded in the transcription."
>
> The example provided
>
> Virginite is grete
> <app>
> <rdg resp="#ES">perfectio
> <am>
> <g ref="#ii"/>
> </am>
> </rdg>
> <rdg resp="#FJF">perfectio
> <ex>u</ex>n
> </rdg>
> <rdg resp="#PGR">perfectiou
> <ex>n</ex>
> </rdg>
> </app>
>
> isn't music, of course, but it's applicable to Micah's question. Because
> the <rdg> elements have no @wit attribute (@source in MEI), they are not
> tied to a particular witness/source document. In other words, each of the
> readings here is a conjecture/reconstruction by the person identified as
> responsible (ES, FJF, and PGR).
>
> Applying this principle to Micah's example, we arrive at the following MEI
> markup --
>
> <measure xmlns="http://www.music-encoding.org/ns/mei">
> <staff n="1">
> <!-- soprano -->
> </staff>
> <staff n="2">
> <app>
> <rdg resp="#ESF">
> <!-- one possible reconstruction -->
> </rdg>
> <rdg resp="#ESF">
> <!-- another possible reconstruction -->
> </rdg>
> </app>
> </staff>
> </measure>
>
> Of course, this is only one method. There's nothing wrong with Raffaele's
> suggestion. But using <app> in a transcriptional context is simple and
> keeps us from inventing more and more elements for smaller and smaller
> return. Since MEI permits <app> within <staff>, this markup keeps us from
> having to repeat <staff n="2">, which could lead to processing issues. Of
> course, there's no rule that says these different 'views' have to come from
> different people, so this markup also addresses Eleanor's example of
> multiple reconstructions by the same editor.
>
> --
> p.
>
>
> __________________________
> Perry Roland
> Music Library
> University of Virginia
> P. O. Box 400175
> Charlottesville, VA 22904
> 434-982-2702 (w)
> pdr4h (at) virginia (dot) edu
> ________________________________________
> From: mei-l-bounces at lists.uni-paderborn.de [
> mei-l-bounces at lists.uni-paderborn.de] on behalf of Eleanor
> Selfridge-Field [esfield at stanford.edu]
> Sent: Tuesday, July 23, 2013 8:25 PM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] Reconstructed parts
>
> Hi, All,
>
> Micah is addressing an important need of musicologists, and it touches on
> an area that is probably irrelevant to TEI. I'm only perplexed about the
> word "choice". This is not about differing opinions. It could incur in a
> situation in which the editor proposes two or more realizations of lost
> material. (an important court case in France recently addressed this
> subject. The new material was understood to constitute new authorship, in
> contrast to the 1725 music otherwise present.)
>
> To be clear, one would have to say "proposed completion/realization." or
> something similar. Basso continuo realizations are similarly editorial
> creations. In both cases the added material is normally typeset in small
> notes, so unambiguous tags may do double duty in the future.
>
> Best regards,
>
> Eleanor Selfridge- Field
> esfield at stanford.edu
>
>
>
>
>
>
>
>
> <html xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:w="urn:schemas-microsoft-com:office:word"
> xmlns:m="http://schemas.microsoft.com/office/2004/12/omml"
> xmlns="http://www.w3.org/TR/REC-html40">
>
> /* Style Definitions */p.MsoNormal, p.MsoAutoSig, li.MsoNormal,
> div.MsoNormal {margin:0cm; margin-bottom:.0001pt;}@page WordSection1
> {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt;
> mso-header-margin:36.0pt; mso-footer-margin:36.0pt;
> mso-paper-source:0;}div.WordSection1 {page:WordSection1;}
>
>
>
>
>
> Eleanor Selfridge-Field
>
> Consulting Professor, Music (and, by courtesy, Symbolic Systems)
>
> Braun Music Center #129
>
> Stanford University
>
> Stanford, CA 94305-3076, USA
>
> http://www.stanford.edu/~esfield/
>
>
>
>
>
>
>
>
>
>
> ----- Original Message -----
> From: Raffaele Viglianti <raffaeleviglianti at gmail.com>
> To: Music Encoding Initiative <mei-l at lists.uni-paderborn.de>
> Sent: Tue, 23 Jul 2013 12:14:26 -0700 (PDT)
> Subject: Re: [MEI-L] Reconstructed parts
>
> Hi Micah,
>
> The debate around <choice> seems to keep going :) As it is defined now,
> <choice> only deals with editorial "clarifications" of some text on a
> source, either by correction, regularization, expansion.
> This is in line with the TEI use of <choice> and I think it should stay
> like this.
>
> Nonetheless, there seems to be a need for a more generic "alternative"
> element, and it might be worth talking about this more and perhaps look at
> TEI's <alt/> (which, btw, is not widely used as far as I know)
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAAT.
>
> For your case, I'd suggest to more simply make full use of <supplied> and
> its attributes.
>
> <staff n="1"/> <!-- existing staff from sources -->
> <supplied reason="lost" resp="#analyst1">
> <staff n="2"/>
> </supplied>
> <supplied reason="lost" resp="#analyst2">
> <staff n="2"/>
> </supplied>
>
> This encodes strongly, as it were, that there are two different opinions
> because of supplied/@resp. And it encodes weakly that they are exclusive
> because of staff/@n. I wish there were a way to encode the exclusivity more
> strongly, but I don't think there's a way of doing so without tag abuse at
> the moment.
>
> Hope this helps,
> Raffaele
>
>
>
>
> On Tue, Jul 23, 2013 at 2:41 PM, Micah Walter <mwalter at haverford.edu>
> wrote:
>
> > Hello, folks,
> >
> > I have a question about encoding reconstructed parts. The project I'm
> > working on contains complete works that are missing entire parts, as two
> of
> > the parts are contained in a second partbook that is now lost.
> >
> > Different reconstructions are of course possible, and so I'd like to use
> > the <choice> tag. Is the following, then, a reasonable encoding?
> >
> > <choice>
> > <orig>
> > <damage/>
> > </orig>
> > <add>
> > <supplied>
> > <!-- one possible reconstruction -->
> > </supplied>
> > </add>
> > <add>
> > <supplied>
> > <!-- another possible reconstruction -->
> > </supplied>
> > </add>
> > </choice>
> >
> >
> > Thanks,
> > Micah Walter
> >
> > _______________________________________________
> > 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
> _______________________________________________
> 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/20130724/a041cd15/attachment.html>
More information about the mei-l
mailing list