Re: Same symbol, different SMuFL semantics

On 1/31/2017 6:21 PM, Michael Good wrote:
> Dear all,
>
> I would like to get some discussion going on a topic that is currently
> holding up MusicXML 3.1 development on some of the remaining SMuFL issues.
>
> What should MusicXML 3.1 do with symbols that have the same general
> appearance, but depending on context can have different semantics and
> different SMuFL glyphs? The in-progress issue where this currently comes
> up is extending MusicXML 3.1 to complete its support for the SMuFL
> handbells range. This is issue 79 at:
>
> https://github.com/w3c/musicxml/issues/79
>
> Of all the symbols mentioned in this issue, only the belltree symbol is
> a new symbol with a shape that is not used anywhere else in MusicXML
> 3.0. Most of the rest can be represented with either the arrow or
> stopped elements, but that would lose the handbell-specific semantics.
>
> SMuFL and MusicXML 3.0 have different design philosophies here. SMuFL
> gives different glyph values to symbols that in general may look alike
> but have different semantics. This allows more semantic encoding and
> greater typographic flexibility. MusicXML in general does not do this -
> for example, the various semantic uses of the + symbol are all
> represented with the stopped element.
>
> MusicXML's original design philosophy was that the semantics of symbols
> is context-dependent. That context is often not fully knowable or known
> at the time of encoding. So the thought was that it would be best to
> have a single element for a single symbol, even if that symbol is used
> in different ways. This also helped to simplify the design of the new
> format.

I guess part of the question is not only about the MusicXML semantics, 
but also really raises the question of the the semantics of the various 
applications that do MusicXML encoding. If the application has the 
"semantics can only be inferred from context" philosophy, then its 
encoder to MusicXML can hardly know the semantics. But the application 
should know more about the context, if anything electronic does. If only 
the human operator of the program understands the context, then the 
application cannot invent it. However, if the application knows & uses 
SMuFL, then the repertoire of symbols available includes all the glyphs 
for all the symbols, and the human operator should be able to pick the 
one that is appropriate for the context... and that choice should be 
respected and retained.


> At this point I think most of us are in favor of adding more semantics
> to musical markup. On the other hand, MusicXML 3.1 is a release of quite
> restricted scope. Where should the balance fall here? Should we start
> introducing new elements for similar-appearing glyphs. Or is it best to
> wait until MNX to take a more comprehensive look at how to best resolve
> this issue?
>
> My current preference, definitely subject to change, is to defer this to
> MNX. This is in part because I think we could get a better solution if
> we are less constrained to fitting into the existing MusicXML 3.0
> design. It would be great to hear how others feel about this, since this
> is an important part of MusicXML 3.1's goal of providing better SMuFL
> support.


Well, it seems to me that if MusicXML uses the same glyph in the XYZ 
font to represent different concepts, that is OK, because the XYZ font 
doesn't have multiple separate glyphs or character codes for those 
different concepts. But when using SMuFL fonts, that do have different 
glyphs, that the use of a glyph homograph (homoglyph?) would be 
incorrect according to SMuFL.  Which of the various homoglyphs would 
MusicXML choose to misuse for the wrong purpose? How could it seem 
appropriate to use a non-handbell code & glyph for a handbell purpose, 
or how could it seem appropriate to use a handbell glyph for a 
non-handbell purpose?

It would seem that applications that offer both SMuFL and non-SMuFL 
fonts for use would have to have a mapping of the homoglyphs. Converting 
from SMuFL to non-SMuFL sounds like it could be automated by doing a 
simple lookup, but converting from non-SMuFL to SMuFL might require 
interrogating the human operator to obtain the missing semantics, if the 
application doesn't retain the semantics in other ways.

The application using a non-SMuFL font _could_ (but I have no idea how 
many do) offer symbol subsets to the user when inserting a symbol... the 
user would choose "insert symbol", then "handbell symbol" and then be 
offered a choice of appropriate symbols for handbells... and even though 
some of the symbols may overlap with the symbols for other categories of 
use, the application _could_ retain the semantics of what category of 
symbols the symbol/glyph was chosen from.  In this scenario, the 
application would then have sufficient context to do an automated 
conversion from a non-SMuFL font to a SMuFL font.

If, however, the application using a non-SMuFL font simply present a 
huge collection of symbols to the user to choose from, without 
categorization, or if, after presenting categorized symbols, it retains 
only the character code of the symbols, then there would either be no 
context to preserve, or the context would be lost, and converting to a 
SMuFL font would require heuristic analysis of the encoded music, 
interrogation of the human user, or misuse of particular SMuFL homoglyphs.


>
> Best regards,
>
> Michael Good
> VP of MusicXML Technologies
> MakeMusic, Inc.
>

Received on Wednesday, 1 February 2017 03:00:28 UTC