[MEI-L] Encoding staff positions

Mon Feb 7 22:43:10 CET 2011

Hi all,

As Perry mentioned it, we already had conversations about adding the
opportunity to use another hierarchy depending one the goal being
pursued. The case given by Andrew a typical one where it would be much
easier with a page-oriented hierarchy. Of course, if things are well
organized, it should be possible to automatically change the
hierarchy. Nodes in the tree would become milestones (i.e. leafs), and
reverse. With reasonably complex cases, I don't see any reason why it
could not be lossless. So one might say, if we can encode it with the
current schema and just convert it to another hierarchy internally,
why would we need another way of encoding it?

If think that the first point is that being able to choose the most
appropriate hierarchy would make the encoding and the processing much
simpler. To some extend, it would not necessary be very different from
the score vs parts representations. And as for score and parts, it is
very ofter possible to go from one to the other, but not always, and
we could also have more complex cases where it would not be possible
to go back and forth between a page oriented and a score/parts
oriented representation.

One interesting thing to look at is the TEI module for genetic
editions, and for our discussion in particular points 1.3 (document
vs. text) and 3 (the document level)
http://www.tei-c.org/Activities/Council/Working/tcw19.html

It goes far beyond the simple example we are discussing here, and with
such complex cases being able to change the hierarchy without losing
anything seems very challenging. I am not sure we have to go so far,
but we should think about it because it would not necessary create
backward compatibility with the current schema. It would mainly make
it easier to use it when the goal is to encode a document with more
focus on the physical aspect of it.

Laurent

On Mon, Feb 7, 2011 at 9:38 PM, Johannes Kepper <kepper at edirom.de> wrote:
> Hi Andrew,
>
> it's the usual distinction between document and text, which sometimes helps and often does not. If you could arrange with this with small(er) changes to the schema, I would favor this solution. I'm a little bit anxious to introduce a completely different approach in MEI when not absolutely necessary. And although XML clearly favors one hierarchy, I think that milestones (like <sb/>) are an absolutely valid way to introduce a second (third…) hierarchy into the data.
>
> Good luck with your implementation, and I'm sure we're all happy to hear more from it.
>
> Johannes
>
>
>
>
>
> Am 07.02.2011 um 21:03 schrieb Andrew Hankinson, Mr:
>
>> 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
>>
>>
>> _______________________________________________
>> 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
>
>