[MEI-L] Problem: Encoding omissions: slur positions

[Eleanor Selfridge-Field]

Just a general comment on Johannes's slur example: We've encoded a great deal of Handel in MuseData (long before MEI came along) and in the manuscripts there are often slurs of ambiguous length.  In the scholarly world, a lot of ink has been devoted to the subject of how to interpret Handel's slurs (as well as his dotted rhythmic figures and divisi parts that begin abruptly in the absence of a preceding composite part, e.g. violin and oboe).  Handel is almost a special case for encoding, because most of these problems are rarely found in the manuscripts of his peers.  

If you belong to the "no interpretation in encoding" school, then you do want some indication of the fuzziness of the source.  This leads to the question of whether it is advisable to indicate in a header whether the following data should be understood as "uninterpreted" (virtual facsimile of the source).  This can be good for efficiency but not conducive to avoiding dependencies.  

In this discussion, lots of workable solutions have been proposed.  The question is: Which ones will work across many different circumstances?  Which ones are "local" to one repertory?  And how do we prioritize efficiency in relation to exactness?

CMME (http://cmme.org/) deals with some of these kinds of questions--with more focus on mutable graphics--for mensural music (no slurs of course) and, like MEI, remains a work-in-progress.  


Eleanor







-----Original Message-----
From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Johannes Kepper
Sent: Saturday, February 11, 2017 4:46 AM
To: Music Encoding Initiative <mei-l at lists.uni-paderborn.de>
Subject: Re: [MEI-L] Problem: Encoding omissions

Dear Rolf,

I tend to suggesting a new <ignored> element, because you're absolutely right that <choice> and <supplied> work on different levels, and there is currently no equivalent to <supplied> in the sense of an editorial omission. Unless you're willing to not encode the thing in question – in which case you may use <gap> as an indicator – there is no way to say something like "yes I know it's there, but let's ignore it for now…". However, I'm not sure if we shouldn't advertise the <choice>-solution instead. In your example, you want to get rid of a slur completely, with no replacement. A problem that seems at least equally common is the need to "reposition" the slur on one or both ends. For such cases one would definitely use <choice>. Isn't the complete omission just a special case of that very same problem?

I wonder if TEI ever discussed this problem. Maybe they didn't, because in my (limited) understanding (verbal) texts usually don't have this "sugar topping" that our slurs, articulations etc. are. But maybe Peter or Raff have more insight?

Best,
jo



> Am 11.02.2017 um 12:28 schrieb Rolf Wissmann <Rolf.Wissmann at gmx.net>:
> 
> Dear Agnes,
> 
> thank you very much for your quick answer.
> I like your suggestion but I'm not sure if I should use it. In my 
> opinion your proposal is not an equivalent to the <supplied> element.  If I apply the <choice><orig><reg> model in this case, than I have consistently to replace all the <supplied> elements, for example slurs, with <choice><orig><reg>. I'm curious to hear your opinion!
> 
> Are there any other recommendations or opinions?
> 
> Greets,
> Rolf
> Gesendet: Donnerstag, 09. Februar 2017 um 17:34 Uhr
> Von: "Agnes Seipelt" <aseipelt at mail.uni-paderborn.de>
> An: "Music Encoding Initiative" <mei-l at lists.uni-paderborn.de>
> Betreff: Re: [MEI-L] Problem: Encoding omissions Dear Rolf,
> 
> 
> in my opinion, the equivalent to <supplied> could be, like you have it in your version, <choice> with the elements <orig> and <reg>. So you can encode the slur in the <orig>-Element, because it is the original. And for the omission, what is in your case a regularization, you can encode the notes without the slur in the <reg>-element. Of course, you should add a @resp.
> 
> Maybe someone has another solution?
> 
> 
> Greets,
> 
> Agnes
> 
> Von: mei-l <mei-l-bounces at lists.uni-paderborn.de> im Auftrag von Rolf 
> Wissmann <Rolf.Wissmann at gmx.net> Antworten an: Music Encoding 
> Initiative <mei-l at lists.uni-paderborn.de>
> Datum: Donnerstag, 9. Februar 2017 um 17:20
> An: <mei-l at lists.uni-paderborn.de>
> Betreff: [MEI-L] Problem: Encoding omissions
> 
> 
> Dear MEI-L:isteners,
> 
> 
> can anyone help me how to encode an editorial decision to omit a slur which is present in the source?
> 
> 
> I have some proposals, but I'm not satisfied with anyone.
> 
> 
> 1.) This version doesn't fit because it's too strong to say that this 
> slur is a mistake. I only would like to say
> 
> that it makes no sense in the musical context.
> 
> <choice>
>             <sic>
>                 <slur/>
>             </sic>
>             <corr resp="#RW" evidence="conjecture" /> </choice>
> 
> 2.) This version doesn't fit because it's my proposal to omit the slur and it's not based on a source.
> <app>
>             <lem resp="#RW" reason="Previous measures without slur"/>
>             <rdg resp="#source" >
>                 <slur/>
>             </rdg>
> </app>
> 
> If I understand the Guidelines in a right way, than it's not possible 
> to use the <del> element in this case because it's not a part of the source material.
> I couldn't find a equivalent to the element <supplied>.
> 
> I hope, someone can help me.
> Best regards,
> Rolf Wissmann
> 
> 
> _______________________________________________ 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