[MEI-L] Reconstructed parts
Micah Walter
mwalter at haverford.edu
Wed Jul 24 17:04:51 CEST 2013
Thanks, Perry. This does make a lot of sense, and I don't know why I didn't look into <app> earlier. It certainly looks like the "correct" tag for this situation.
-Micah
On 24 July 2013, at 09:14, Raffaele Viglianti <raffaeleviglianti at gmail.com> wrote:
> 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
>
> _______________________________________________
> 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/755cd9a9/attachment.html>
More information about the mei-l
mailing list