[MEI-L] Problem: Encoding omissions

Sat Feb 11 15:32:20 CET 2017

Hello,

<gap> is supposed to be the opposite of <supplied> because it encodes
editorial omissions (from the guidelines
<http://music-encoding.org/documentation/3.0.0/gap/>: "Indicates a point
where material has been omitted in a transcription, whether as part of
sampling practice or *for editorial reasons* described in the MEI header").
By definition, <gap> is empty because the text is omitted (FWIW TEI gap
<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-gap.html> now
allows description elements as its content to further describe the
omission, but the text is still not to be provided, otherwise it's not an
omission!).

For the case being considered, I think using <choice> with orig/reg is the
best way to indicate that there was some original text that was "normalized
to nothing", or omitted in the edited text.

We could also try and flip the problem on its head: instead of marking the
omission of the slur, we could mark that the slur was in the original text,
but needs flagging for some reason. <orig> can be used outside of <choice>
to this effect. In TEI this is typically used to mark up unusual spellings
without providing a regularization (perhaps because a regularization is not
appropriate, e.g. regularizing to which spelling of which time period?). A
combination of @type and @evidence could be used to determine, when
rendering, whether to show this "original" text in the edition or not.

<measure>
<orig type="superfluous" evidence="conjecture"><slur/></orig>
</measure>

Raff

On Feb 11, 2017 07:45, "Johannes Kepper" <kepper at edirom.de> wrote:

> 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
>
>
> _______________________________________________
> 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/20170211/413a6bbd/attachment.html>