<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1250">
<style id="owaParaStyle">P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body fPStyle="1" ocsi="0">
<div style="direction: ltr;font-family: Arial Unicode MS;color: #000000;font-size: 12pt;">
<p>Hi Zoltan<a></a>,</p>
<p> </p>
<p>There's nothing wrong with using <supplied> within <rdg<a></a>>. Not using <supplied> means you have to rely on the absence of @source on <rdg<a></a>> to communicate that the material in the <rdg<a></a>> is an editorial conjecture. Either way is acceptable,
but using <supplied> is less ambiguous.</p>
<p> </p>
<p>Using <supplied> also provides a method for capturing the evidence for the supplied material; that is, via the @evidence attribute. Using this attribute with one of the suggested values ('internal', 'external', 'conjecture') is more reliable than using
more generic attributes; that is, @type (on rdg) and/or @reason (on supplied). In the following example, I used the value 'internal' because the supplied material is derived from the content in the extant parts.</p>
<p> </p>
<font color="#8b26c9">
<p></font><font color="#000000"><font size="2" face="Courier New"><?xml version="1.0" encoding="UTF-8"?><br>
</font><font color="#8b26c9"></p>
<p></font><font color="#000000" size="2" face="Courier New"><?xml-model href="http://music-encoding.googlecode.com/svn/tags/MEI2013_v2.1.0/schemata/mei-all_anyStart.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?><br>
<?xml-model href="http://music-encoding.googlecode.com/svn/tags/MEI2013_v2.1.0/schemata/mei-all_anyStart.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?><br>
</font></p>
<p><font size="2" face="Courier New"><measure xmlns="http://www.music-encoding.org/ns/mei"><br>
<staff n="1"><br>
<!-- soprano --><br>
</staff><br>
<staff n="2"></font></p>
<p><font size="2"><font face="Courier New"> <!-- alto --></font><br>
</font><font size="2" face="Courier New"> <app><br>
<rdg resp="#ESF"><br>
<supplied evidence="internal"><br>
<!-- one possible reconstruction --><br>
</supplied><br>
</rdg><br>
<rdg resp="#ESF"><br>
<supplied evidence="internal"><br>
<!-- another possible reconstruction --><br>
</supplied><br>
</rdg><br>
</app><br>
</staff><br>
</measure></font></font></p>
<p> </p>
<p>Best wishes,</p>
<p> </p>
<p>--</p>
<p>p.</p>
<div>
<div class="BodyFragment"><font size="2">
<div class="PlainText"><br>
__________________________<br>
Perry Roland<br>
Music Library</div>
<div class="PlainText">University of Virginia</div>
<div class="PlainText">P. O. Box 400175</div>
<div class="PlainText">Charlottesville, VA 22904<br>
434-982-2702 (w)<br>
pdr4h<a></a> (at) virginia<a></a> (dot) edu<a></a></div>
</font></div>
</div>
<div style="FONT-FAMILY: Times New Roman; COLOR: #000000; FONT-SIZE: 16px">
<hr tabindex="-1">
<div style="DIRECTION: ltr" id="divRpF451554"><font size="2" face="Tahoma"><b>From:</b> mei-l [mei-l-bounces@lists.uni-paderborn.de] on behalf of Kõmíves Zoltán [zolaemil@gmail.com]<br>
<b>Sent:</b> Tuesday, November 26, 2013 11:47 AM<br>
<b>To:</b> Music Encoding Initiative<br>
<b>Subject:</b> Re: [MEI-L] Reconstructed parts<br>
</font><br>
</div>
<div></div>
<div>
<div dir="ltr">Hi All,
<div><br>
</div>
<div>Please let me pick up this thread again! I am joining Micah's efforts in the project where we are dealing with reconstructed voices.</div>
<div><br>
</div>
<div>I may be over-complicating the issue, but my thought was to use <supplied> <i>
within</i> the <rdg>:</div>
<div><br>
</div>
<div><span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"><measure xmlns="</span><a style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px" href="http://www.music-encoding.org/ns/mei" target="_blank">http://www.music-encoding.org/ns/mei</a><span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px">"></span><br style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px">
<span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"> <staff n="</span><span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px">1</span><span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px">"></span><br style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px">
<span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"> <!-- soprano --></span><br style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px">
<span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"> </staff></span><br style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px">
<span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"> <staff n="2"></span><br style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px">
<span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"> <app></span></div>
<div><span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"> <rdg</span><span style="FONT-FAMILY: arial,sans-serif; COLOR: rgb(80,0,80); FONT-SIZE: 13px"> resp="#ESF"</span><span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px">></span><br>
</div>
<div>
<div style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"> <supplied reason="reconstruction"><br>
</div>
<div style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"> <!-- one possible reconstruction --></div>
<div style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"> </supplied></div>
<span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"></span><span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"> </rdg></span><br style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px">
<span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"> <rdg</span><span style="FONT-FAMILY: arial,sans-serif; COLOR: rgb(80,0,80); FONT-SIZE: 13px"> </span><span style="FONT-FAMILY: arial,sans-serif; COLOR: rgb(80,0,80); FONT-SIZE: 13px">resp="#ESF"</span><span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px">></span></div>
<div>
<div style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"> <supplied reason="reconstruction"></div>
<div style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"> <!-- another possible reconstruction --><br>
</div>
<div style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"> </supplied></div>
<span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"></span>
<div style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"><span style="COLOR: rgb(34,34,34)"> </rdg></span><br>
</div>
<span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"> </app></span><br style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px">
<span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"> </staff></span><br style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px">
<span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"></measure></span><br>
</div>
<div><span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px"><br>
</span></div>
<div><span style="FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px">This way we could also strongly encoded the fact that the "material is </span>supplied by the transcriber or editor in place of text which cannot be read [...] because of physical damage". </div>
<div><br>
</div>
<div>Or do you think it's too much? And perhaps redundant if type="reconstruction" is added to the <app> element? Any opinion?</div>
<div><br>
</div>
<div>Thanks</div>
<div>Zoltan</div>
<div><br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2013/7/25 Roland, Perry (pdr4h) <span dir="ltr"><<a href="mailto:pdr4h@eservices.virginia.edu" target="_blank">pdr4h@eservices.virginia.edu</a>></span><br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
Hi Micah,<br>
<br>
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.<br>
<div><br>
--<br>
p.<br>
<br>
__________________________<br>
Perry Roland<br>
Music Library<br>
University of Virginia<br>
P. O. Box 400175<br>
Charlottesville, VA 22904<br>
<a href="tel:434-982-2702" target="_blank" value="+14349822702">434-982-2702</a> (w)<br>
pdr4h (at) virginia (dot) edu<br>
<br>
<br>
<br>
</div>
From: <a href="mailto:mei-l-bounces@lists.uni-paderborn.de" target="_blank">mei-l-bounces@lists.uni-paderborn.de</a> [<a href="mailto:mei-l-bounces@lists.uni-paderborn.de" target="_blank">mei-l-bounces@lists.uni-paderborn.de</a>] on behalf of Micah Walter [<a href="mailto:mwalter@haverford.edu" target="_blank">mwalter@haverford.edu</a>]<br>
Sent: Thursday, July 25, 2013 11:18 AM<br>
<div>
<div>To: Music Encoding Initiative<br>
Subject: Re: [MEI-L] Reconstructed parts<br>
<br>
<br>
Another idea: Would <app type="reconstruction"> be a good way to clarify the purpose of the reading? Or is @type reserved for another use?<br>
<br>
<br>
-Micah<br>
<br>
<br>
<br>
<br>
<br>
On 24 July 2013, at 09:14, Raffaele Viglianti <<a href="mailto:raffaeleviglianti@gmail.com" target="_blank">raffaeleviglianti@gmail.com</a>> wrote:<br>
<br>
<br>
Hi Perry,<br>
<br>
<br>
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.<br>
<br>
<br>
Raffaele<br>
<br>
<br>
<br>
On Tue, Jul 23, 2013 at 10:25 PM, Roland, Perry (pdr4h) <<a href="mailto:pdr4h@eservices.virginia.edu" target="_blank">pdr4h@eservices.virginia.edu</a>> wrote:<br>
<br>
Hello all,<br>
<br>
I believe this situation is addressed in section 12.3 of the TEI Guidelines, "Using Apparatus Elements in Transcriptions" (<a href="http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCTR" target="_blank">http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCTR</a>)
--<br>
<br>
"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."<br>
<br>
The example provided<br>
<br>
Virginite is grete<br>
<app><br>
<rdg resp="#ES">perfectio<br>
<am><br>
<g ref="#ii"/><br>
</am><br>
</rdg><br>
<rdg resp="#FJF">perfectio<br>
<ex>u</ex>n<br>
</rdg><br>
<rdg resp="#PGR">perfectiou<br>
<ex>n</ex><br>
</rdg><br>
</app><br>
<br>
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).<br>
<br>
Applying this principle to Micah's example, we arrive at the following MEI markup --<br>
<br>
<measure xmlns="<a href="http://www.music-encoding.org/ns/mei" target="_blank">http://www.music-encoding.org/ns/mei</a>"><br>
<staff n="1"><br>
<!-- soprano --><br>
</staff><br>
<staff n="2"><br>
<app><br>
<rdg resp="#ESF"><br>
<br>
<!-- one possible reconstruction --><br>
<br>
</rdg><br>
<rdg resp="#ESF"><br>
<br>
<!-- another possible reconstruction --><br>
<br>
</rdg><br>
</app><br>
</staff><br>
</measure><br>
<br>
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.<br>
<br>
--<br>
p.<br>
<br>
<br>
__________________________<br>
Perry Roland<br>
Music Library<br>
University of Virginia<br>
P. O. Box 400175<br>
Charlottesville, VA 22904<br>
<a href="tel:434-982-2702" target="_blank" value="+14349822702">434-982-2702</a> (w)<br>
pdr4h (at) virginia (dot) edu<br>
________________________________________<br>
From: <a href="mailto:mei-l-bounces@lists.uni-paderborn.de" target="_blank">mei-l-bounces@lists.uni-paderborn.de</a> [<a href="mailto:mei-l-bounces@lists.uni-paderborn.de" target="_blank">mei-l-bounces@lists.uni-paderborn.de</a>] on behalf of Eleanor Selfridge-Field
[<a href="mailto:esfield@stanford.edu" target="_blank">esfield@stanford.edu</a>]<br>
Sent: Tuesday, July 23, 2013 8:25 PM<br>
To: Music Encoding Initiative<br>
<br>
Subject: Re: [MEI-L] Reconstructed parts<br>
<br>
Hi, All,<br>
<br>
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.)<br>
<br>
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.<br>
<br>
Best regards,<br>
<br>
Eleanor Selfridge- Field<br>
<a href="mailto:esfield@stanford.edu" target="_blank">esfield@stanford.edu</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<html xmlns:o="urn:schemas-microsoft-com:office:office"<br>
xmlns:w="urn:schemas-microsoft-com:office:word"<br>
xmlns:m="<a href="http://schemas.microsoft.com/office/2004/12/omml" target="_blank">http://schemas.microsoft.com/office/2004/12/omml</a>"<br>
xmlns="<a href="http://www.w3.org/TR/REC-html40" target="_blank">http://www.w3.org/TR/REC-html40</a>"><br>
<br>
/* 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;}<br>
<br>
<br>
<br>
<br>
<br>
Eleanor Selfridge-Field<br>
<br>
Consulting Professor, Music (and, by courtesy, Symbolic Systems)<br>
<br>
Braun Music Center #129<br>
<br>
Stanford University<br>
<br>
Stanford, CA 94305-3076, USA<br>
<br>
<a href="http://www.stanford.edu/~esfield/" target="_blank">http://www.stanford.edu/~esfield/</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
----- Original Message -----<br>
From: Raffaele Viglianti <<a href="mailto:raffaeleviglianti@gmail.com" target="_blank">raffaeleviglianti@gmail.com</a>><br>
To: Music Encoding Initiative <<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a>><br>
Sent: Tue, 23 Jul 2013 12:14:26 -0700 (PDT)<br>
Subject: Re: [MEI-L] Reconstructed parts<br>
<br>
Hi Micah,<br>
<br>
The debate around <choice> seems to keep going :) As it is defined now,<br>
<choice> only deals with editorial "clarifications" of some text on a<br>
source, either by correction, regularization, expansion.<br>
This is in line with the TEI use of <choice> and I think it should stay<br>
like this.<br>
<br>
Nonetheless, there seems to be a need for a more generic "alternative"<br>
element, and it might be worth talking about this more and perhaps look at<br>
TEI's <alt/> (which, btw, is not widely used as far as I know)<br>
<a href="http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAAT" target="_blank">http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SAAT</a>.<br>
<br>
For your case, I'd suggest to more simply make full use of <supplied> and<br>
its attributes.<br>
<br>
<staff n="1"/> <!-- existing staff from sources --><br>
<supplied reason="lost" resp="#analyst1"><br>
<staff n="2"/><br>
</supplied><br>
<supplied reason="lost" resp="#analyst2"><br>
<staff n="2"/><br>
</supplied><br>
<br>
This encodes strongly, as it were, that there are two different opinions<br>
because of supplied/@resp. And it encodes weakly that they are exclusive<br>
because of staff/@n. I wish there were a way to encode the exclusivity more<br>
strongly, but I don't think there's a way of doing so without tag abuse at<br>
the moment.<br>
<br>
Hope this helps,<br>
Raffaele<br>
<br>
<br>
<br>
<br>
On Tue, Jul 23, 2013 at 2:41 PM, Micah Walter <<a href="mailto:mwalter@haverford.edu" target="_blank">mwalter@haverford.edu</a>> wrote:<br>
<br>
> Hello, folks,<br>
><br>
> I have a question about encoding reconstructed parts. The project I'm<br>
> working on contains complete works that are missing entire parts, as two of<br>
> the parts are contained in a second partbook that is now lost.<br>
><br>
> Different reconstructions are of course possible, and so I'd like to use<br>
> the <choice> tag. Is the following, then, a reasonable encoding?<br>
><br>
> <choice><br>
> <orig><br>
> <damage/><br>
> </orig><br>
> <add><br>
> <supplied><br>
> <!-- one possible reconstruction --><br>
> </supplied><br>
> </add><br>
> <add><br>
> <supplied><br>
> <!-- another possible reconstruction --><br>
> </supplied><br>
> </add><br>
> </choice><br>
><br>
><br>
> Thanks,<br>
> Micah Walter<br>
><br>
> _______________________________________________<br>
> mei-l mailing list<br>
> <a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><br>
> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">
https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
><br>
><br>
<br>
<br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
<br>
<br>
<br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</body>
</html>