[MEI-L] Reconstructed parts
Roland, Perry (pdr4h)
pdr4h at eservices.virginia.edu
Tue Nov 26 20:14:22 CET 2013
Hi Zoltan,
There's nothing wrong with using <supplied> within <rdg>. Not using <supplied> means you have to rely on the absence of @source on <rdg> to communicate that the material in the <rdg> is an editorial conjecture. Either way is acceptable, but using <supplied> is less ambiguous.
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.
<?xml version="1.0" encoding="UTF-8"?>
<?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"?>
<?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"?>
<measure xmlns="http://www.music-encoding.org/ns/mei">
<staff n="1">
<!-- soprano -->
</staff>
<staff n="2">
<!-- alto -->
<app>
<rdg resp="#ESF">
<supplied evidence="internal">
<!-- one possible reconstruction -->
</supplied>
</rdg>
<rdg resp="#ESF">
<supplied evidence="internal">
<!-- another possible reconstruction -->
</supplied>
</rdg>
</app>
</staff>
</measure>
Best wishes,
--
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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Kőmíves Zoltán [zolaemil at gmail.com]
Sent: Tuesday, November 26, 2013 11:47 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] Reconstructed parts
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<mailto: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<tel:434-982-2702> (w)
pdr4h (at) virginia (dot) edu
From: mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de> [mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] on behalf of Micah Walter [mwalter at haverford.edu<mailto: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<mailto: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<mailto: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<tel:434-982-2702> (w)
pdr4h (at) virginia (dot) edu
________________________________________
From: mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de> [mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] on behalf of Eleanor Selfridge-Field [esfield at stanford.edu<mailto: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<mailto: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<mailto:raffaeleviglianti at gmail.com>>
To: Music Encoding Initiative <mei-l at lists.uni-paderborn.de<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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/d16f00c0/attachment.html>
More information about the mei-l
mailing list