[MEI-L] datatype [imt][1-6]

Sun Jul 8 00:39:02 CEST 2012

comments inline…

Am 07.07.2012 um 12:38 schrieb Roland, Perry (pdr4h):

> Raffaele,
>  
> In this context "one pass encoding" means capturing all information available at any given point in the encoding at one time. For example, while you're on a given note, it means capturing info about any ties, slurs, beams, etc. that start on that note.  MEI accomplishes this primarily with attributes; that is, @beam, @slur, @tie.
>  
> "Two pass encoding" means capturing the note information first and the beam, tie, and slur data later, relating the second pass to the first, of course.  This method results in note, chord, etc. elements  followed later by tie, slur, etc. elements with @tstamp or @startid attributes.
>  
> The beam element is slightly anomalous in that it encloses notes, but it's really part of the one-pass method.  It's difficult to treat other things, like slur, tie, etc. that might overlap each other the same way as beams. And even for beams, when overlapping occurs one must switch to beamSpan.
>  
> I still believe one-pass encoding has a place in MEI, at least until any hand encoding (meaning editing of the MEI file in a non-graphical environment) is no longer necessary.  However, these attributes should certainly be better documented and perhaps moved to a separate module instead of being eliminated altogether. We could even go so far as to define them as unacceptable in "canonical" MEI as long as we provide conversion from the attribute method to the element method.  In addition to their usefulness in hand-coding, these attributes are helpful when transforming data already in a one-pass-oriented form, such as MuseData and to some extent MusicXML, to MEI.
>  
> I agree that keeping @tie while eliminating the other "one-pass attributes" is inconsistent.  This is another reason for not getting rid of @slur, etc. entirely.  

It would be inconsistent if our aim would be to eliminate all one-pass solutions, which is not the case. We're trying to solve an apparent problem arising from a certain datatype. It's just a side-effect that this means we loose a one-pass on these things. If we'd know an unambiguous one-pass, we'd certainly implement that one instead (suggestions welcome…). 

>  
> When hand-coding is no longer necessary, then @slur, etc. including @tie can go away, but I don't think we're completely there yet.
>  

Dropping all mentioned one-passes shouldn't be our goal at any time. MEI aims at people who should really care about their data, meaning they should know about MEI good enough to be able to check what applications do for them. Not everyone will encode by hand, but that's certainly a possibility we don't want to loose at any time!

I'm not arguing to throw away these attributes without further notice, I just want to get them "out of the way" to prevent future confusion about how to use them, which will eventually result in confusion on how to interpret MEI files using them. There is still sufficiently little use of MEI to do such changes right now, but that's certainly a closing time slot…

> Just my two cents,
>  
> --
> p.
>  
>  

and my two euro-cents,
jo

> 
> __________________________
> 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 Raffaele Viglianti [raffaeleviglianti at gmail.com]
> Sent: Saturday, July 07, 2012 6:07 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] datatype [imt][1-6]
> 
> Hello,
> 
> On Fri, Jul 6, 2012 at 11:23 PM, Johannes Kepper <kepper at edirom.de> wrote:
> 
> Basically, this change would mean that we drop the possibility for a one-pass encoding here and require a second pass. That's certainly a drawback
> 
> A second pass towards what? Do you have a specific transformation in mind? Once the XML tree is parsed, knowing that a note is beamed (and whether its i/m/t) by its attribute value or by its ancestor::beam + position should be equivalent (beamspan is more complex, but that's already the case) .
> 
> I'm also slightly concerned about keeping @tie if we get rid of @slur and @beam. Even though @tie is less ambiguous and so has a different datatype, they all just seem to be part of the same category to me.
> 
> Best,
> Raffaele
>  
> .
> 
> Thanks again, and still listening to other opinions,
> Johannes
> 
> 
> 
> Am 06.07.2012 um 23:17 schrieb TW:
> 
> > I agree with this, as well.  I never felt comfortable with this kind
> > of beam/slur indication as it scatters information about a single
> > object over several others, and the object itself doesn't even exist
> > as an entity of its own.  @beam/@slur attributes would make sense to
> > me if they were plists/idrefs pointing to the beam/beamSpan/slur
> > element they belong to.
> >
> > For lyrics however, i|m|t totally convinces me as it indicates the
> > relationship between different entities.
> >
> > Thomas
> >
> >
> > 2012/7/6 Raffaele Viglianti <raffaeleviglianti at gmail.com>:
> >> Dear all,
> >>
> >> In general, I would agree with both of Andrew's points:
> >> - get rid of the datatype for beam and other "spanners" like slurs and
> >> tuplets (and the related attributes);
> >> - keep i/m/t for wordpos (can't think of any other places where this could
> >> be needed, though as a rule of thumb, if 1-6 is not needed then i/m/t might
> >> be worth keeping.
> >>
> >> Best,
> >> Raffaele
> >>
> >>
> >>
> >> On Fri, Jul 6, 2012 at 5:48 PM, Maja Hartwig <Maja.Hartwig at gmx.de> wrote:
> >>>
> >>> Dear Johannes and Perry!
> >>>
> >>> Actually I used this datatype, but never for encoding beams, rather for
> >>> slurs, though my understanding was a different one.
> >>> I used the "i1" for the first slur in a measure, "i2" for the second one
> >>> also when the first beam ended before.
> >>> So I didn´t use the "i1" twice in one measure, because I think that would
> >>> be confusing to get the appropriate "i´s" and "t´s" together.
> >>> I was always wondering about the limit of 1-6, because in my way of using
> >>> that datatype, I couldn´t encode more than 6 slurs in a measure.
> >>> Now I switched over to encode slurs with @tstamp and duration or @startid
> >>> and @endid.
> >>> To encode beams, I always use the <beam>/<beamSpan>, and I think I
> >>> wouldn´t miss the i/m/t 1-6!
> >>> Best,
> >>>
> >>> Maja
> >>>
> >>>
> >>> -------- Original-Nachricht --------
> >>>> Datum: Fri, 6 Jul 2012 18:16:41 +0200
> >>>> Von: Johannes Kepper <kepper at edirom.de>
> >>>> An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de>
> >>>> Betreff: [MEI-L] datatype [imt][1-6]
> >>>
> >>>> Dear MEI-L,
> >>>>
> >>>> this is a somewhat technical question that I still would like to ask all
> >>>> of you, although it's particularly interesting to hear developer's
> >>>> opinions.
> >>>>
> >>>> MEI offers several attributes with a datatype of [imt][1-6], that is one
> >>>> letter out of i, m or t, follwed by a digit from 1 to 6. It is used to
> >>>> indicate the beginning ("i"), middle ("m") or end ("t") of a feature
> >>>> which may
> >>>> overlap. The number distinguishes between those overlapping occurences.
> >>>> For
> >>>> instance a
> >>>>
> >>>> <note beam="i1">
> >>>>
> >>>> indicates the beginning of a beam. If a second, independent beam would
> >>>> start before the first ends, it would be start with a value of "i2". If
> >>>> it
> >>>> would start after the end of the first one, it would reuse the "i1"
> >>>> value.
> >>>> Trying to clarify such details in the Guidelines, Perry and me are
> >>>> wondering
> >>>> if this behaviour is particularly comprehensible, or if we should take
> >>>> this
> >>>> feature away completely. You may encode beams using either the <beam> or
> >>>> <beamSpan> element, the first one being extremely comfortable, the
> >>>> second
> >>>> extremely flexible. Besides beams, the same datatype is available for
> >>>> tuplets
> >>>> and slurs, which also offer other encoding possibilities. Is anyone
> >>>> actually using the functionality of this datatype, or do you have strong
> >>>> opinions
> >>>> for other reasons?
> >>>>
> >>>> It would be great if we could get some feedback in the next couple of
> >>>> days
> >>>> in order to make a decision about this soon.
> >>>>
> >>>> Thanks very much,
> >>>> Perry and Johannes
> >>>> _______________________________________________
> >>>> 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
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l