[MEI-L] Page-based encoding

[Laurent Pugin]

Hi,


Here are a few thoughts for having a page-based encoding option in MEI. The
idea is to make it possible to encode the positioning of elements directly
in the content tree. This can be useful in some uses of MEI where the
encoding represents one single source with one image per page. It is
typically the case with OMR, where the data is conceptually organized by
pages related to specific input images. Another use can be to create
overlay images to be displayed on top of a facsimile image where the
position of each symbols needs to be encoded. Whilst I am aware that
anything that can be represented with a page-base module could probably
also be represented with the current stage of MEI with a facsimile tree and
references, the page-based module would make it much simpler. It would also
not preclude having at the same time a facsimile tree with references if
necessary.



A page-base organization for specifying the position directly in the
content encoding tree requires two things. 1) The ability to encode the
document (pages) structure as the main tree, and 2) the ability to specify
positioning.



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.



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.



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.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20131029/178ded3c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: page-based-measured-a.mei
Type: application/octet-stream
Size: 13854 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20131029/178ded3c/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: page-based-measured-b.mei
Type: application/octet-stream
Size: 18496 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20131029/178ded3c/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: page-based-unmeasured.mei
Type: application/octet-stream
Size: 33851 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20131029/178ded3c/attachment-0002.obj>