Re: [EXTERNAL] Some braille references

Any discussion of Braille math should start by observing the truly unique
and astounding result accomplished by Prof. Nemeth with his Braille
encoding for math.  Almost fifty years before any of the rest of us
recognized the importance of the separation of notation and semantics, in
any realm of computing, Prof. Nemeth created a Braille linear form for math
that captures printed math notation in a way that respects its semantic
structure.

As Neil has pointed out, Prof. Nemeth's stated goal was indeed to capture
the symbols on the page, knowing that if he could "see" the symbols, he
could infer the interpretation.

However, after a careful and thorough analysis of the code, and after
implementing a direct translation from Content MathML to Nemeth Braille, my
experience has been that Prof. Nemeth's understanding of the semantics also
had a clear influence on the design of the code.  The design for nested
opening and closing fraction indicators is just one example.

So in my opinion, Neil's statement that Braille is only encoding the
layout, and not the semantics, is a bit of an over simplification.
Examples exist where the same printed notation results in different Braille
encodings, where an indication of the intent of the markup would resolve
the ambiguity.

(It's been awhile since I looked at these examples, but I seem to recall
that degree-minutes-seconds and primes for feet and inches fall in this
category.)

So my hope is that our design for encoding intent would also support
Braille translation in a natural way, based on the underlying semantics.

Sam

On Fri, Jul 9, 2021, 11:55 AM Neil Soiffer <soiffer@alum.mit.edu> wrote:

> I agree with Deyan's general point that any notation will be used in ways
> that differ from what one encounters through lower-level undergraduate
> math. This means that speech or computation can't make an assumption that
> will be right all the time even for the mfrac/linethickness case. However,
> I don't think Deyan's concerns extend to braille in this case. Because
> braille is encoding the layout, not the meaning, all of those examples that
> use \atop and do so by generating mfrac with linethickness=0 will have the
> same braille representation (at least as far as my understanding of Nemeth
> goes) so a software generator won't have a problem as it will properly
> generate the "directly under" symbol. If they use mtable (as I'm sure the
> pmatrix examples would), then the ambiguity for what braille to generate
> shows up.
>
> My knowledge of braille math codes really only extends to Nemeth and UEB
> (and barely there), so I don't know for sure about my claims that semantics
> is not part of braille extends to other language's braille codes. I hope to
> find someone who can answer that question one of these days.
>
>     Neil
>
>
> On Thu, Jul 8, 2021 at 9:21 PM Deyan Ginev <deyan.ginev@gmail.com> wrote:
>
>> Hi Bill,
>>
>> Luckily (for me), Neil is overly optimistic on exactly the part you're
>> happy to support, so I can contradict you both in tandem. The claim:
>> "as an mfrac with linethickness=0, there is no problem understanding
>> that it is a binomial to a software translator"
>>
>> is only accurate if you've decided this is all you're going to support
>> in your software. And especially in cases using "\atop", rather than
>> "\binom", because - as the name suggests - there is no semantic
>> commitment even in the latex macro, let alone the presentation MathML.
>>
>> As is customary, some freshly collected counter-examples from arXiv:
>>  -- ( · \atop · ) is used for a column vector;
>>    - (C.4) in https://arxiv.org/pdf/0906.3743.pdf
>>    - (1,1), Theorem 2.4, (2.21),... in
>> https://arxiv.org/pdf/0906.2242.pdf
>>    - page 4, in https://arxiv.org/pdf/math/0607411.pdf
>>    - (52), (53) in https://arxiv.org/pdf/cond-mat/0609580.pdf
>>    - with fractional values, bottom of page 8 in
>> https://arxiv.org/pdf/1112.5353.pdf
>>    - (2.9) in https://arxiv.org/pdf/hep-th/0607092.pdf
>>    - "spin part" of the wave function after (4) in
>> https://arxiv.org/pdf/cond-mat/0009028.pdf
>>    - figure 4 in https://arxiv.org/pdf/1909.07663.pdf
>>    - "bispinor", (20) in https://arxiv.org/pdf/1205.6983.pdf
>> --  ( · \atop · ) used to classify Einstein equations:
>>    - start of Appendix A, page 12 in https://arxiv.org/pdf/1302.4875.pdf
>>
>> -- {pmatrix} used to write binomials:
>>    - page 3 of https://arxiv.org/pdf/math/0506006.pdf
>>    - specifically: \begin{pmatrix}n\\ i\end{pmatrix} and
>> \begin{pmatrix}m\\ i\end{pmatrix}
>>
>> I of course also spotted a couple of binomial uses of \atop along the
>> way (such as https://arxiv.org/pdf/cond-mat/0011360.pdf ), in support
>> of Murray's use.
>>
>> I am happy to repeat this point (with examples) as many times as
>> needed. Namely, an assumption that any mathematical notation (i.e.
>> presentation tree) has a *unique* implied meaning is bound to be
>> demonstrably false, when compared against the full body of
>> mathematical writing. It can be a correct assumption if contained to a
>> specific area of writing, such as "K-14 western educational
>> materials". And then we can explicitly enumerate exactly what we mean,
>> with explicit tests and selector patterns. We've discussed such an
>> approach as part of a "Default Intent" effort.
>>
>> As to adding "minimal semantic information available in presentation
>> MathML", we first need to answer "serving which applications?". For
>> the accessibility-oriented ones, the discussions about Intent
>> annotations have been making some progress, and it is a good design
>> choice to think of parallel attributes on top/on the side of the
>> presentation tree. As a baseline, communicating exactly what is
>> written has the great benefit of not making false claims about what
>> was meant.
>>
>> So, to conclude. "an mfrac with linethickness=0" is clearly ambiguous
>> in arXiv, and can't be defaulted to any one meaning, as far as that
>> corpus is concerned.
>>
>> P.S. Side-remark: sometimes an article uses notation so exotic that
>> even knowing that *some* uses of \atop are binomials, still leaves an
>> unsuspecting reader guessing if *all* uses of \atop are binomials, or
>> instead get overloaded for some other purpose. I stumbled on one such
>> document. "Example 21" in it is not for the faint of heart, even if
>> you are fully sighted and prepared to tackle arXiv. Enjoy:
>> https://arxiv.org/pdf/1512.05937.pdf
>>
>> Greetings,
>> Deyan
>>
>> On Thu, Jul 8, 2021 at 9:37 PM Hammond, William F <whammond@albany.edu>
>> wrote:
>> >
>> > (I may be in a top-posting dungeon for a while.  Sorry.)
>> >
>> > Neil writes:
>> >
>> > If the binomial is represented as an mfrac with linethickness=0, there
>> is no problem understanding that it is a binomial to a software translator.
>> But if it is represented using mtable, then there is nothing to distinguish
>> the two in the presentation MathML.
>> >
>> >
>> > Notice that Neil is saying that there is value in having minimal
>> semantic information available in presentation MathML.  (I've said this
>> before regarding the removal of <mfenced>.)
>> >
>> >            -- Bill
>> >
>> >
>> >
>> > ________________________________
>> > From: Neil Soiffer <soiffer@alum.mit.edu>
>> > Sent: Thursday, July 8, 2021 5:57 PM
>> > To: Noble, Stephen <steve.noble@pearson.com>
>> > Cc: Murray Sargent <murrays@exchange.microsoft.com>;
>> deyan.ginev@gmail.com <deyan.ginev@gmail.com>; ljmaher03@outlook.com <
>> ljmaher03@outlook.com>; www-math@w3.org <www-math@w3.org>
>> > Subject: Re: [EXTERNAL] Some braille references
>> >
>> > I heard back from Susan Osterhaus. Her reply was basically that
>> transcribers typically don't know math well so Nemeth code is designed so
>> that it only reflects the symbols on the page, not the interpretation of
>> them since that is beyond what transcribers typically know. That reminded
>> me of what Dr. Nemeth said of MathSpeak (the way to speak math that
>> resembles Nemeth). His readers didn't typically know much math, so he just
>> wanted them to tell him what was on the page so he could write it in
>> (Nemeth) braille on his braille writer and be able to review it.
>> >
>> > I did come up with one notation where someone needs to make a semantic
>> determination: binomial vs 2x1 column matrix. In Nemeth, a binomial is
>> represented with an open paren,  top part, a "directly under" symbol,
>> followed by the bottom part, and finally a close paren; a matrix would
>> occupy two lines. There might be a single line way of doing a matrix for
>> braille displays, but I didn't see it mentioned.  If the binomial is
>> represented as an mfrac with linethickness=0, there is no problem
>> understanding that it is a binomial to a software translator. But if it is
>> represented using mtable, then there is nothing to distinguish the two in
>> the presentation MathML. Typically the subject area would make it obvious,
>> but in isolation, some hint from the author is needed. The same is true for
>> a sighted reader. Many WYSIWYG editors use the mtable form for binomials,
>> so this is not a theoretical problem, but one that is common in MathML
>> usage.
>> >
>> > Susan Jolly sent me email and reminded me that Nemeth was very
>> thoughtful in his choice of dot patterns so that they would be more
>> intuitive. For example, here is a fraction (recall a braille cell is 3x2
>> dots):
>> > ⠹⠆⠌⠒⠼
>> >
>> > There are five braille cells in the expression. The first and last
>> cells are the start and end fraction symbols and the middle cell is the 2D
>> "/". The full column for the start/end is like a fence for fingers and the
>> middle symbol resembles the slash, so this can be easily(?) recognized as a
>> fraction. FYI: the numerator is a '2' (a "dropped" b ['b' starts in the
>> first row, not the second]) and the denominator is a 3 (a dropped c).
>> Another example of an encoding choice that resembles the print form is '='
>> which has the two character braille representation "⠀⠨⠅⠀" ("that is a "⠨"
>> and a "⠅" character with a blank before and after it). That's your braille
>> lesson for today :-)
>> >
>> >     Neil
>>
>