[MEI-L] Encoding staff positions

[Laurent Pugin]

Hi,

yes, I agree that the cases described by the genetic encoding group
are rather extreme ones for which the best thing to do for music would
probably be to use MEI within TEI together with the GE module.

It should not preclude us to improve MEI itself for the 80% of the
situations, and I also agree the it can be a 'small' solution. My
impression is that with <pb> and <sb> becoming <page> and <system>, we
would have pretty much everything we need for the new hierarchy.
Inside it, the sub-tree is likely to stay the same, but some
containing elements (such as <measure>) would definitely have to
become milestones. That is the big question, as Perry said, but if
they are not too many of them, I see it as a small solution that would
do it.

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.

Laurent

On Mon, Feb 7, 2011 at 10:53 PM, Johannes Kepper <kepper at edirom.de> wrote:
> Hi again,
>
> I agree that TEI's genetic encoding approach is something we should try to combine with MEI, but as Raffaele suggested, we should try to (re)use their namespace as much as possible. This thing is definitely designed for more complicated situations than most of us will encounter on a daily basis. For me, the main question is if there is a need for a smaller solution within MEI's namespace that addresses something like 80% of the situations out there. It's just like <zone> vs. SVG: Simple solution within the format vs. mighty solution by including something else. The only problem then is to find where those 80% might end, and what is needed to get there…
>
>
>
>
> Am 07.02.2011 um 22:43 schrieb Laurent Pugin:
>
>> 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.
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>