[MEI-L] Layout discussion

Wed Nov 14 20:09:45 CET 2012

Hi,

Thanks to Johannes and Laurent for sending along their explanations. I'm not able to make it to the meeting today (sorry!), so I'll put forward my 2 cents on this issue.

In Johannes' approach, the primary benefit is that all information is maintained within a logical tree with no new mechanisms needed. Indeed, it is potentially more expressive, since different sources can include as much or as little information as needed to express the differences between it and the 'common' representation. As such, this proposal could operate both in the logical and in the graphical domain. This also makes hand encoding much easier, since an encoder can essentially do a one-pass encoding of each source and then use software to automate the generation of the 'common.xml' file.

The drawbacks to this approach are that the logical and graphical differences are intermingled, simply by virtue of using the same mechanism to express them. This makes automated processing harder, since an app/rdg structure could represent a simple layout difference (e.g., a piece printed on octavo vs. quarto paper) or a correction in two sources (e.g., a wrong note in one edition that was corrected in a subsequent source). This also means that all source files must be distributed with the common file, and incurs extra processing and storage overhead for making sure that the links present in the common file can be resolved.

Laurent's proposal seems much more targeted specifically at resolving layout differences and separating the graphical domain from the logical domain (content vs. presentation). The benefits are that it makes a clean separation between differences in musical content (represented by app/rdg) and graphical (represented by laidOutElement). This makes it very easy for parsers to ignore the layout tree completely if they are not interested in the graphical differences.

The main drawback of Laurent's approach is that it adds a new set of elements to the MEI spec, and that it is slightly more difficult for hand encoding, since an encoder must do one pass to encode the logical content, and then subsequent passes to encode the different layouts in each source. 

To me, the layout tree argument makes more sense. With app/rdg and different source files you're interleaving logical and graphical differences; with the layout approach you're making a clean break, albeit at the expense of some expressiveness.

There seems to be a lot of duplication of effort required in the source/common file structure, and I think it's a potential vector of confusion since it will be difficult to define 'the most important differences'. With the layout structure it's quite well defined that it only encodes positioning differences between two sources. 

So, for what it's worth you can mark me down as supporting the addition of the new layout tree since I think it creates a cleaner separation between the logical and presentational aspects of multiple sources.

Thanks,
-Andrew

On 2012-11-14, at 5:50 PM, Laurent Pugin <laurent at music.mcgill.ca>
 wrote:

> Hi,
> 
> First of all, not to overload the list, I would recommend people interested in the discussion to have a look at our ismir paper
> http://ismir2012.ismir.net/event/papers/505-ismir-2012.pdf
> 
> The module as describe in the paper works well for OMR where we need to be able to store exact positions for all the elements on the page. We also tested it for comparing the content of several sources, where we end up with one single sub-tree with the musical content, with <app> and <rdg> for differences. We can call it the logical tree, (e.g., note pitches and note durations). The positioning information is stored in sub-trees, one for each sources. The link is accomplished by xml:id in the layout sub-tree referencing elements in the logical sub-tree. In other words, the logical sub-tree is autonomous, which is not the case of the layout sub-trees.
> 
> A while ago, we had a discussion about introducing a page-based representation in MEI:
> https://lists.uni-paderborn.de/pipermail/mei-l/2011/000280.html (very long thread!)
> At that point, this option did not appear to be necessary. However, as Johannes explained, we came up to the conclusion in New Orleans that it might be a good idea to re-evaluate the relevance of such a page-based representation in the light of what we learned by designing the layout module since they are quite similar in what we would like to achieve. We could say that the main difference is that with the layout module approach, the information about the layout information is subordinated to a traditional content representation of the music (stored in another sub-tree), whereas that with a page-based representation approach, everything is (or can) be represented in one single tree. As Johannes explained, we could also decide to have page-based representation files with only layout information and referring to other MEI files, and in that case they would act exactly as the layout module sub-trees.
> 
> Best,
> Laurent
> 
> On Sat, Nov 10, 2012 at 4:35 AM, Eleanor Selfridge-Field <esfield at stanford.edu> wrote:
> I'm lurking too and pass on one practical issue: web browsers.  I've been
> noticing recently that
> Chrome has trouble resolving the printing parameters of attachments
> received on A4 paper (it may be the reserve elsewhere).  Presumably some
> intermediate software will always stand between MEI and any screen
> display.
> 
> For me screen layout is the next question after page layout.  Instinct
> tells me that separate semantic content from all layout and rending
> questions is the better path.  The SCORE approach may be instructive: the
> program uses virtual units to etablish the desire aspect ratio.  It also
> has a virtual relationship to the physical page.  Note though that in the
> music printing industry page sizes may not have the same aspect ratio as
> those used with desktop printers.  (AT the AMS I had a discussion about
> this with Douglas Woodfill-Harris from Bärenreiter.)
> 
> 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/
> 
> 
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de
> [mailto:mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de] On
> Behalf Of Byrd, Donald A.
> Sent: Friday, November 09, 2012 11:22 AM
> To: Music Encoding Initiative; Johannes Kepper
> Subject: Re: [MEI-L] Layout discussion
> 
> I'm just emerging from a long period of lurking -- with a lot of ignoring
> :-| . I (for one) would love to see "a thorough introduction of our layout
> tree proposal and its specific qualities."
> 
> --Don
> 
> 
> On Thu, 8 Nov 2012 14:45:11 +0100, Johannes Kepper <kepper at edirom.de>
> wrote:
> 
> > Don't blame it on me ? some of you requested to have the following
> > discussion completely in public, and I think we should follow that
> > suggestion. I expect this thread to be somewhat lengthy. What we
> > should try to resolve is how MEI deals with layout-specific
> > information, its relationship to the semantic parts of MEI, separating
> > out layout info in a similar way than CSS does for HTML, relationship
> > of various units (and types thereof), page-based approaches to MEI
> > etc.
> >
> > I will try to summarize the model I briefly introduced in New Orleans
> > last week. I would love to see Laurent replying to that, ideally with
> > a thorough introduction of our layout tree proposal and its specific
> > qualities. This should introduce lurkers to our current state, and
> > from there, we can refer back to our proposal from last week and see
> > where the discussion leads us?
> >
> > The basic situation is that we want to preserve differences between
> > multiple sources. The most obvious way for doing this is to use the
> > <app> / <rdg> elements, which provide a very intuitive way for doing
> > so. But, as soon as we also want to preserve detailed information
> > about layouts, we have to add many more attributes to each note etc.,
> > so it becomes more likely that differences between the sources will
> > result in additional <app>s and <rdg>s. Eventually, this will lead to
> > a separate <app> / </rdg> for almost every note. While this is still
> > possible, it might be regarded as somewhat impractical. The
> > alternative for this is to use one file, let's call it common.xml, to
> > store all the commonalities between the sources, but also the most
> > important differences. Basically, this file contains only @pname, @oct
> > and @dur for every note. It will split up into <app>s and <rdg>s where
> > the sources differ in this regard, but it will not consider stem
> > directions, exact positioning etc.
> > Every single source is also represented by a separate file, let's call
> > it sourceXY.xml. These files do not contain <app>s and <rdg>s at all,
> > they just reflect the musical text as given in the according source.
> > They contain elements for all notes etc., but they omit the basic
> > attributes as specified in the common.xml. Instead, they use a
> > reference to the corresponding elements in this file. Here's an
> > example:
> >
> > common.xml:
> > <note xml:id="noteX" pname="c" oct="4" dur="1"/>
> >
> > sourceXY.xml:
> > <note stem.dir="up" sameas="common.xml#noteX/>
> >
> > It is easily possible to point to a note within a <app>/<rdg> in case
> > the basic parameters already differ.
> >
> > With this strategy, layout information can be separated out quite
> > completely. <sb/> and <pb/> are stored only within the sourceXY.xml
> > files (though they could be provided in the common.xml within <app>s
> > and <rdg>s as well). If one wants to extract a source file completely,
> > he just has to resolve all pointers. This is cumbersome when doing
> > manually, but with an xml database and an index on xml:ids, it
> > shouldn't be too hard. Also, it is still possible to extract
> > information about differing stem directions etc., but it requires more
> > processing than the <app>/<rdg> approach. Basically, this is a
> > compromise somewhere in the middle between source separation and
> > integration, which tries to address the most common cases in the most
> > convenient way, while accepting some additional hurdles for corner
> > cases. Of course it is open for discussion which attributes should go
> > in the common.xml, and which attributes should be separated out to the
> > individual source files.
> >
> > The benefit of this approach is that it completely relies on existing
> > MEI ? it does not require any further additions to the standard and
> > works "out of the box".
> >
> > But, it does not address all requests catered for with a distinct
> > layout tree, which I hope Laurent will introduce.
> > jo
> >
> >
> >
> > _______________________________________________
> > mei-l mailing list
> > mei-l at lists.uni-paderborn.de
> > https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> >
> 
> 
> 
> --
> Donald Byrd
> Woodrow Wilson Indiana Teaching Fellow
> Adjunct Associate Professor of Informatics & Music Indiana University,
> Bloomington
> 
> 
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20121114/f2b02243/attachment.html>