Introducing MNX [via Music Notation Community Group]

In this post we’re taking the first of a series of steps that will establish a
specification for the notation encoding standard that’s the subject of our
work in this CG. The steps here are focused on a name, a mission and a
high-level approach.

A Name, Of Sorts

We’re proposing the use of a code name for the next standard: something that
we can use as a label, yet which is temporary in nature: it isn’t a committed
naming decision. We feel that it’s not right to stick with MusicXML as the
name for this project: it may suggest to some that it’s going to address the
same use cases in the same ways as MusicXML, or that there may be some bias
against evaluating ideas from other quarters.

For this code name, we’re proposing to call this project “MNX” for the
time being. We don’t have to love this choice yet, because the name is
replaceable. We just need something easy to say, easy to type and a bit
open-ended. It stands for... “Music Notation X”, where X might mean the X in
"extensibility", or the X in "next", or the call of the unknown, or the Roman
numeral 10, or, perhaps, just a plain old letter of the alphabet.

What is MNX About?

Now that we have a name, however temporary, we’d like to make some statements
about what MNX is intended to accomplish. These goals are only partly derived
from the many use cases and scenarios discussed so far. They also represent the
co-chairs’ ideas about how the CG should spend its time, and where the payoffs
lie for stakeholders.

An Open Framework, But A Focused One

MNX provides an overall framework for encoding works of music of many different
kinds. As such, it anticipates that more than one encoding system may be used,
perhaps even within the same document.

The MNX schema will begin by describing a notation-neutral container that is
concerned solely with a document’s metadata, attribution and organization.
This part of this framework does not reference any notational system.

Inside the MNX container are one or more body elements of encoded music
notation. These body elements can contain embedded documents of various types
registered by some mechanism and policy to be determined. An MNX “body type”
consists of an XML schema or sub-schema applying to some MNX body. An MNX body
may also cite one or more document profiles that govern how its body is encoded,
above and beyond the constraints of the XML schema itself.

There will be a way for those who wish to create their very own digital
representation of notated music to do so, and plug that into an MNX document.
However, only some set of recommended types are likely to be supported by other
parties and their software projects. So there is an obvious incentive to use a
recognized type to encode a work, rather than inventing one’s own. The work of
the CG will focus on a small number of such recognized body type.

MNX comes bundled with a ready-made body type that supports Common Western Music
Notation (CWMN), and which is biased towards a semantic representation of music.
The encoded music is not required to reference any specific visual or aural
rendering, although such information can be optionally included. This goal does
not presume that there is a single unitary definition of CWMN, but the ways to
tweak its boundaries must necessarily be limited in order to have a standard
that solidly represents the vast majority of CWMN repertoire. Other body types
will no doubt be invented to accommodate the gaps that result, and which make
different design tradeoffs.

The CWMN body type and its associated document profiles are the heart of MNX:
our primary intent is for MNX to support uses of CWMN across the various user
communities described in our use cases document, serving creative, academic and
commercial interests alike. The hope is that MNX will at least inherit the
degree of support found for MusicXML today, and will hopefully address many
unmet needs of other musical constituencies.

The initial work of the CG, therefore, will lie in elaborating the CWMN body
type for MNX. Other body types will fall inside the circle of recommended types,
of course, while yet others will be works-in-progress or experimental
prototypes. These other body types will, at first, be the work of voluntary
subgroups.

Something Borrowed, Something New

MNX is not starting from scratch: there’s a lot of useful work to draw on. We
should strive to avoid reinventing the wheel. Rather than repeat some of the
areas where MNX intends to innovate (e.g. styling, profiles), this section looks
at some of the key existing work that we can make use of today.

  MEI does a great job of organizing musical texts with their attached metadata
in an arbitrary structure (the “container” spoken of above). MEI’s
approach to metadata overall is very thoughtful and more comprehensive than what
is available in MusicXML.
  MusicXML has a rich semantic vocabulary for CWMN proven by time and adoption.
  MusicXML can cope with a wide range of conflicts between visual notation and
the intended aural rendering
  The MEI CWMN schema has a simpler approach to organizing elements that is more
friendly to a DOM-based approach.
  Other projects including CMME and NeumesXML have looked at encoding neumes and
mensural notation, and these should be examined for potential adoption or
adaptation.

 Next Steps

The best next step would be to create a family of spec documents that begin to
capture the most significant ideas that we want to employ. These initial drafts
will document concrete directions that can be discussed. They will follow the
overall structure and formatting of other W3C specs in HTML, and will draw on
W3C’s internal specification toolset ReSpec.

We propose that the initial emphasis be placed on two specifications:

The MNX container. MEI has already done a great job developing the concepts
needed for a good approach to a container, and it’s possible that not much new
ground may need to be broken here. Perhaps the key challenge here is that the
notion of body type will need to be worked out and elaborated.

MNX support for CWMN encoding. We expect the CWMN encoding piece to draw on the
terms, concepts and vocabulary of MusicXML, but reworked to better support
current encoding and programming best practices. A key part of this work will be
the development of a family of CWMN document profiles that can significantly
lighten the development burden. To leverage MusicXML adoption, the specification
will be developed together with automated software to convert existing MusicXML
files into MNX CWMN files.

We expect another round of discussion on the CG list, naturally, but we wanted
to take this opportunity to share our thoughts so that we can begin together on
the next -- and very exciting -- bunch of work.

Joe Berkovitz, Michael Good and Daniel Spreadbury
W3C Music Notation Community Group Co-Chairs



----------

This post sent on Music Notation Community Group



'Introducing MNX'

https://www.w3.org/community/music-notation/2016/05/19/introducing-mnx/



Learn more about the Music Notation Community Group: 

https://www.w3.org/community/music-notation

Received on Thursday, 19 May 2016 17:53:49 UTC