[MEI-L] Encoding staff positions

[Roland, Perry (pdr4h)]

Johannes, everyone,

I don't see the real distinction between offering an "official varation" and a "second, equally possible format design to MEI."  To me, it's either officially sanctioned, or not.  If it's not, then it shouldn't be provided.  If it is officially sanctioned, then it must be documented and supported.

I agree that if we decide to create such a customization, then the amount of change is best kept to the minimum that accomplishes the task.

--
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+pdr4h=virginia.edu at lists.uni-paderborn.de [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] On Behalf Of Johannes Kepper [kepper at edirom.de]
Sent: Tuesday, February 08, 2011 2:38 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] Encoding staff positions

Am 08.02.2011 um 14:24 schrieb Laurent Pugin:
>
>
>>>
>>> In my opinion, it can be useful to capture the original source at the
>>> very beginning of an editorial process, but it could also be useful at
>>> the end of the process. If we think of the case where MEI is used to
>>> encode a new edition, this feature could also make it easier to encode
>>> its layout and to represent it. If we have an orchestra score with,
>>> let's say, hundreds of pages, turning a page would require every time
>>> the entire tree to be parsed to get all the <pb> and all the <sb>. I
>>> know software issues are not the starting point when defining an
>>> encoding, but this is seriously not optimal. Why shouldn't I have to
>>> option to have the encoding in a page-oriented way when the edition
>>> reached a publishing stage? And maybe to add some more detailed layout
>>> information for making it easier to read? I don't know, it is just one
>>> way I see to use MEI.
>>>
>>
>> I see your problem, and maybe you're right with this. In Edirom's internal data model we chose a different approach. We always have a double structure inside a source: One perspective is source/movements/measures, the other is source/pages/measures. The logical structure is our main structure, where all objects are actually stored. The page structure contains only pointers to those elements. Of course this produces some overhead, but you may extract it easily from MEI, and you have the best of both approaches all the time. I cannot tell if this is a model for Andrew or you, but it helps us a lot.
>>
>>
>
> Your solution is an excellent one to get both at the same time, which
> is of course ideal. It is a elegant workaround to keep both in memory
> in order to avoid to have to re-parse the tree every single time you
> need to access something that is spread over several branches in the
> hierarchy. But if you think of a large repository of MEI files from
> which you want to quickly access specific pages over the web, you
> would need another solution. Something built in MEI would be nice.
>

But of course you wouldn't keep the whole repository in memory / your local data model. Using xquery on an eXist database for example, you can get a page that holds a given measure in a couple of milliseconds, especially since MEI's switch to xml:id. But you're right, the overhead we produce slows us down significantly. On a medium size piece of music (a total of ~ 2000 measures in 5 different sources), we experienced a slowdown by the factor of 10 to build our second hierarchy (looping through all zones, looping through all measures to find the right @facs). We still have acceptable loading times, but one of our first improvements to MEI will be the already mentioned backlink from zone to measure – it will reduce the slowdown to the factor 2, which seems fair regarding the fact that we build two hierarchies… I see no reason why it shouldn't be possible to extract solely a page-oriented structure in time n with this addition to MEI. But of course, if you don't have a local data model and work on the xml directly, you always have an extra IDREF to follow. But as long as you keep //zone[@type eq 'measure'] in the same order as the measures appear logically on that page, it shouldn't be too expensive.


> Your case also illustrates the fact that, in many applications, having
> access to both representations is necessary. You choose as main
> structure the one that is the most relevant for you. In some cases, it
> can be the other one, and in some cases, only one is necessary. If I
> just want to generate a midi file, the logical representation is
> enough (and better), but if I just want to display a page, it is the
> opposite. So if we can get a good page-oriented representation, with
> maybe a stylesheet to go from one to the other (at least for not too
> complicated cases), I see it as a way to avoid people to have to do it
> internally for each single piece of software that needs it.

What about a compromise? I'm still against adding a second, equally possible format design to MEI. Looking at MusicXML's timewise vs. partwise, which is definitely a less complicated problem, I'm afraid that we will run into lots of problems. One of the more disturbing is clearly the increased cost to learn MEI, as you have to make a decision on how to use it quite early in the encoding process. But, what if we use the benefits we gain from ODD? I could imagine an official variation of MEI that redesigns it in that particular way (<pb/> to <page>…</page and so on). Such a modification could be provided on the website, and the XSLTs you mentioned could be there as well. This way, we would keep the solution out of the "official" MEI design, but we could offer a standardized, well-documented proposal on how to deal with MEI in page-oriented projects. Programmers could take this over and adjust it to their applications without having to do the complete work on their own. I could see that as a solution for your problem, and at the same time it would be a great way to exemplify the benefits of ODD for MEI. So how about that?

Johannes



>
>> Honestly, I don't want to cut this idea short, I'm just somewhat reluctant to introduce another tree possibility. <parts><part> and <score> is something different to me, as they behave absolutely similar below this level.
>
> Yes, it is not the exactly the same, I agree.
>
> Laurent


_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l