[MEI-L] Page-based encoding

Fri Nov 8 15:52:39 CET 2013

Hi Eleanor,

This is fascinating example! It is indeed very challenging and would
require more thinking. Perry just mentioned to me that TEI has a way to
deals with right-to-left writing - not surprisingly. This might be a good
place to look at as a starting point. However, I would suggest to make this
a separate discussion thread so we do not loose focus. I hope you are OK
with this.

In the meantime, I have uploaded to the incubator an updated version of the
customization with two examples (measured and un-measured).

Following Raffaele's comment, I created a separate /pages element for this
so we could have a page-based encoding together with a traditional
score-based encoding. The example of measured music follows the option b)
with staves within measures (i.e., unflipped) that keeps the page-based
representation closer to the standard MEI one. We could potentially allow
both, but I am not sure how to do this in the customization. We would also
certainly need a schematron rule to forbid a mix of them.

I am not sure if the ways things are redefined in the customization is
appropriate. This goes beyond my knowledge of ODD, sorry about this.
However, the example files are valid and it seems to work.

https://code.google.com/p/mei-incubator/source/browse/#svn%2Fpage-based

Best,
Laurent

On Tue, Nov 5, 2013 at 12:14 AM, Eleanor Selfridge-Field <
esfield at stanford.edu> wrote:

> Reading this discussion caused me inadvertently to think of a few
> repertories that might be flipped in other ways:
>
>
>
> 1.       Benedetto Marcello psalm settings based on music from Hebrew
> liturgy.  He attempted to render the music right to left.  As you can see,
> a  modern rendering introduces lots of complexity to the process of
> character formation.
>
>
>
>
>
> 2.       Calvinist psalters used in Turkey (current research by a young
> German colleague), where the nature of the text has features similar to,
> but not exactly the same as, those in Marcello, such as text underlay in
> Turkish script.
>
>
>
>
>
> Granted MEI is not likely to be called upon to deal with these kinds of
> cases in the foreseeable future, but since flippability is under
> discussion, it may be worth thinking about the general issue of
> extensibility at every tier—notes, lyrics, staff, system.
>
>
>
> Best regards,
>
>
>
> Eleanor
>
>
>
>
>
> Eleanor Selfridge-Field
> Consulting Professor, Music (and, by courtesy, Symbolic Systems)
> Braun Music Center #129
> Stanford University
> Stanford, CA 94305-3076, USA
> http://www.stanford.edu/~esfield/  +1/ 650 725-9242
>
> *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of
> *Laurent Pugin
> *Sent:* Saturday, November 02, 2013 12:42 AM
> *To:* Music Encoding Initiative
> *Subject:* Re: [MEI-L] Page-based encoding
>
>
>
> Hi Raffaele,
>
>
>
> Thanks for you comments, more below
>
>
>
> On Thu, Oct 31, 2013 at 8:52 PM, Raffaele Viglianti <
> raffaeleviglianti at gmail.com> wrote:
>
> Hi Laurent, thanks for sharing this, a few comments:
>
>
>
> On Tue, Oct 29, 2013 at 11:02 AM, Laurent Pugin <lxpugin at gmail.com> wrote:
>
>
>
>
>
> 1) For the document structure to be encoded, we need to have page and
> system elements. The content of a score becomes a list of /page. Each /page
> contains a list of /system. In un-measure music /system contains a list of
> /staff. In measured music, we can imagine a) /system containing a list of
> /staff containing a list of /measure (and then /layer), or b) /system
> containing a list of /measure containing a list of /staff. Solution a)
> seems more natural to me (if we think how music is written on paper, we
> first have staves and then add measure). Solution b) has the advantage of
> being closer to the standard MEI focusing on content. This needs to be
> discussed.
>
>
>
> It makes sense that when the page hierarchy is flipped, the system
> hierarchy gets flipped as well, so that you can encode layout data on
> systems too. Though I don't think the same logic applies to staff and
> measure so I'd be tempted to go with b), because it would make switching
> between a page-based encoding and a "standard" encoding easier.
>
>
>
> I think this is the most difficult thing to decide. Your point makes sense
> and it would indeed make it easier to adopt. Any other opinion on this?
> Shall we have both options?
>
>
>
>
>
>
>
> 2) For the positioning, we need to add attributes the elements that can
> have a position. Basically, any element with the @facs. We can solve this
> by making the att.facsimile class member of att.coordinated. This provides
> us with the necessary @ulx, @uly, etc. for specifying the position. We also
> need to specify to which image the position refers to. A simple approach is
> to add a @surface to /page. As mentioned before, all this does not preclude
> to use the standard @facs and facsimile tree scheme at the same time, for
> example if a higher resolution image needs to be added for specific
> elements. We also need to have a @unit in /page and presumably also be able
> to specify if the positioning is absolute or relative.
>
>
>
> +1. Those would be good to have around even outside of a page-based
> module, I think.
>
>
>
>
>
> Another point to be discussed it if we want to keep this in the score
> subtree or if such encoding could be put into another subtree. One option
> would be a /pages element at the same level of /parts and /score. In other
> word, this would be a third representation option in MEI.
>
>
>
>
>
> Yes, I'd keep it in a different subtree, so that content can be linked in
> the same file if necessary.
>
>
>
> I agree. I do it for the next version of the customization.
>
>
>
>
>
> In general: I see why this approach to encoding is useful, though if we
> make it part of MEI, we should make quite clear when it's ok to encode in
> page-based fashion and when it's not. Basically we should discourage this
> approach unless it's required for specific (scholarly, justifiable)
> reasons.
>
>
>
> Agree too. I am sure people won't use it unless necessary ;-)
>
>
>
> Laurent
>
>
>
>
>
> Raf
>
>
>
>
>
> I already made a customization for unmeasured music and I am willing to do
> one for measured music for option a) or b) and when we agree where to put
> it. The sample file attached for unmeasured music was generated from the
> OMR output of Aruspix.
>
>
>
> Best,
>
> Laurent
>
>
>
>
>
>
>
> _______________________________________________
> 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
>
>
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20131108/78f140bc/attachment.html>
-------------- section suivante --------------
Une pi?ce jointe autre que texte a ?t? nettoy?e...
Nom: image001.jpg
Type: image/jpeg
Taille: 29183 octets
Desc: non disponible
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20131108/78f140bc/attachment.jpg>