[MEI-L] Encoding staff positions

[Laurent Pugin]

On Tue, Feb 8, 2011 at 8:38 PM, Johannes Kepper <kepper at edirom.de> wrote:
>
> 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.
>

It does sound quick enough, it is not the main question. What
interests me is more that with your system, you have got somehow built
in the XSLT we mentioned - for an application that manipulates both
hierarchy, in is unavoidable, I agree. But having to do it every time
does not mean only every time you load it (it is apparently quick
enough), but also for every application that needs it. An application
that focus  only (or mostly) on the second hierarchy would have 1) do
implement the same built-in XSLT, and 2) run it every time it load and
save a file. That is not optimal, no matter how good is the programmer
and how quick is the computer.

The second point is that we are assuming here that both
representations are equivalent. This would be ideal, of course, but I
am not sure that it has to be the case. It might very well be not
possible to keep everything we have in a <system> element in the <sb>
when the hierarchy if flipped. That is, I can decide to use one or the
other because it is more comfortable to use but also because it allows
me to do more. If I need to change to the other representation, I can
do it, knowing that most of it (but not necessary everything) will be
keep. We could see it as TEI encoding using the GE module and where we
would remove all the GE elements and keep the text, but in a more
integrated way.

>
>> 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?
>

There is a huge flexibility in MEI, I don't think that that particular
addition would make it much more difficult to learn. My impression is
that it will make it more complicated to maintain and to explain.

Laurent

> 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
>
>