[MEI-L] Reconstructed parts

Kőmíves Zoltán zolaemil at gmail.com
Tue Nov 26 17:47:57 CET 2013


Hi All,

Please let me pick up this thread again! I am joining Micah's efforts in
the project where we are dealing with reconstructed voices.

I may be over-complicating the issue, but my thought was to use <supplied>
*within* the <rdg>:

<measure xmlns="http://www.music-encoding.org/ns/mei">
  <staff n="1">
    <!-- soprano -->
  </staff>
  <staff n="2">
    <app>
      <rdg resp="#ESF">
        <supplied reason="reconstruction">
          <!-- one possible reconstruction -->
        </supplied>
      </rdg>
      <rdg resp="#ESF">
        <supplied reason="reconstruction">
          <!-- another possible reconstruction -->
        </supplied>
      </rdg>
    </app>
  </staff>
</measure>

This way we could also strongly encoded the fact that the "material is supplied
by the transcriber or editor in place of text which cannot be read [...]
because of physical damage".

Or do you think it's too much? And perhaps redundant if
type="reconstruction" is added to the <app> element? Any opinion?

Thanks
Zoltan




2013/7/25 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>

> Hi Micah,
>
> To quote the Guidelines, "@type characterizes the element in some sense,
> using any convenient classification scheme or typology."  The attributes
> @type and @subtype provide a kind of ad hoc extension and restriction
> mechanism, so the values can be anything you want.  Of course, the downside
> is you can't expect others to utilize the same values you've chosen.
>  There's only one instance where @type is reserved -- on <meiHead> --
> strictly to mimic TEI's use of @type is its <teiHeader> element.
>
> --
> 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 Micah Walter [
> mwalter at haverford.edu]
> Sent: Thursday, July 25, 2013 11:18 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] Reconstructed parts
>
>
> Another idea: Would <app type="reconstruction"> be a good way to clarify
> the purpose of the reading? Or is @type reserved for another use?
>
>
> -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
> _______________________________________________
> 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/20131126/7c1b871c/attachment.html>


More information about the mei-l mailing list