[MEI-L] Encoding staff positions

Mon Feb 7 21:03:55 CET 2011

Thanks Johannes,

I'm giving your proposal some thought.

One thing I am a bit unsure of is how "divorcing" the physical from the logical will impact us. I thought we would want to keep everything as contextual as possible, including system definitions. But now I'm re-thinking that approach.

I'm in the middle of implementing this, so I'll let you know how it goes!

-Andrew

On 2011-02-07, at 2:27 PM, Johannes Kepper wrote:

> Hi Andrew,
> 
> actually MEI already covers both perspectives with the <body> branch (logical) and the <facsimile> branch (physical) inside <music>. I agree that this might be somewhat confusing, as you don't have the measure directly available inside a <surface> / page, and there is also no system break available here. I just wonder if improving the current solutions might not be sufficient, instead of creating a completely different structured model parallel to the existing solution. Possible improvements I see are:
> 
> - backlinks from <zone> to <measure> (<zone data="measureID"/>, could be other elements as well)
> - typeable <zone> (<zone type="system"/>…)
> - nestable <zone> (<zone type="system"><zone type="measure"/></zone>)
> 
> I think that those are really cheap additions, which don't change the complete model if MEI, but instead preserve the general distinction between graphical and logical perspective. Of course this is still not as convenient as a model solely commiting to the graphical aspects, but it fits better into the existing structures. 
> 
> Do you think that this direction might help to address your problem sufficiently?
> 
> Best,
> Johannes
> 
> 
> 
> 
> 
> Am 07.02.2011 um 20:10 schrieb Roland, Perry (pdr4h):
> 
>> Hi Andrew,
>> 
>> You're absolutely right that <staff> attempts to capture the logical nature rather than the physical nature of staves.  <sb/> is of secondary importance in this approach.
>> 
>> However, Laurent and I have had several conversations about creating a page-oriented version of MEI.  I think this would address your needs as one of the major features of this approach would be a <system> element.  In other words, in this approach the physical layout would be primary.
>> 
>> 
>> 
>> I think turning the current schema "inside-outside" would be a good place to start; that is, the things that are empty now, such as <lb/> and <sb/> will end up being containers and some current container elements will end up being empty.  I think your suggestions a're definitely on the right track, but I'm reluctant to intermingle the logical-is-primary approach with the physical-is-primary method.  So, I think the choice will have to be mutually exclusive, implemented by switching on a page-oriented module.  The big question is, How many of the existing elements will have to make the empty <--> container switch?
>> 
>> 
>> 
>> Is this something we can take up after the next release in May?
>> 
>> 
>> 
>> --
>> 
>> 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Andrew Hankinson, Mr [andrew.hankinson at mail.mcgill.ca]
>> Sent: Monday, February 07, 2011 1:51 PM
>> To: Music Encoding Initiative
>> Subject: [MEI-L] Encoding staff positions
>> 
>> I'm currently trying to work out a method of encoding staff system positions on a page using MEI.
>> 
>> Let's assume that there is a single page of unmeasured music, with four systems on the page and I want to create a <zone> element for each system describing its layout.
>> 
>> Currently, the <staff> element seems to indicate a continuous line of music independent of its layout in systems, with the empty <sb /> element used to indicate a break in the system layout. This empty element has an @facs attribute, but I would be hesitant to encode spatial information with an empty element.
>> 
>> Before I go any further, can anyone think of something I'm missing? Any possible solutions?
>> 
>> If not, I can see two options.
>> 
>> The first is to create an element that is similar to the <span> element (call it "<mspan>"). This element would be a non-wrapping element that is generic and simply supplies a method of wrapping arbitrary information. This would be modelled after the use in the hOCR specification -- you can see an example here: http://code.google.com/p/hocr-tools/source/browse/sample.html
>> 
>> Thus, you might have:
>> 
>> <staff>
>> <mspan facs="123">
>>       .... system 1 ....
>> </mspan>
>> <sb />
>> <mspan facs="456">
>>       .... system 2 ....
>> </mspan>
>> <sb />
>> </staff>
>> 
>> While the <mspan> element would be a pretty powerful addition, its semantic value is minimal. Thus, the other option might be to introduce an explicit <system> element that would be a child of the <staff> and function as an explicit wrapper for a system, in place of the empty <sb /> element; thus
>> 
>> <staff>
>> <system n="1" facs="123">
>>   .... system 1 ....
>> </system>
>> <system n="2" facs="456">
>>   .... system 2 ....
>> </system>
>> </staff>
>> 
>> Any ideas? Thoughts?
>> 
>> -Andrew
>> 
>> 
>> 
>> _______________________________________________
>> 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