Re: Minutes: MathML "intent" meeting, 1 Oct, 2020

Hi Neil, Patrick,

I suggest replacing

"It will add *attributes *that allow specification of mathematical intent
on Presentation MathML elements to enhance accessibility and searchability
of math."

with

"It recommends methods to specify the intent on MathML elements to enhance
accessibility and searchability of math."

in section 2-1 MathML4. And following the same spirit replace section 2-2
with

* Test suites and implementation reports for the specification
MathML Accessibility Techniques
* Guides on enhancing MathML for accessibility and search
* A living catalog for annotations beyond those defined in a MathML 4
recommendation.
* Sample code that converts default Mathml to a persistent form of "intent"
enhanced MathML.
* At least one TeX-to-MathML converter that incorporates
accessibility/searchability annotations in its MathML output.
* Code to convert between strict Content MathML to MathML with
accessibility and searchability enhancement.
* Sample code for conversion of intent enhanced MathML to an external form
such as speech or plain text output

I was under the impression that we propose ways to foster semantic
annotation beneficial for the applications `accessibility' and `search'.

As expressed before, I think the decision that annotations to presentation
MathML is the best way to achieve better accessibility and search is
*premature*. I really respect and appreciate your work and discussions and
think the collection of vocabularies and ontologies is a great achievement.
Also, we share the goal to simplify and standardize the enhancement
process.

However, I would like to avoid confusion on the stability of MathML in the
public and guarantee a continuous transformation from the current MathML
standard to the next MathML standard. A competing way to express semantics
is not beneficial would not be a good message.
Moreover, I think we should learn from the mistakes done in the past and
interact more with other communities. Improving accessibility and search is
not something only mathematical formulae have. For instance, SVG images
face very similar problems. Also in Europe and in Germany particularly
there is now a big push towards using knowledge graphs and schema.org
annotations. Maybe there is also something we can learn from those
initiatives.

I would therefore ask everyone in this working group to be brave and look
beyond the well-known paths what other communities have done or are doing.
My observation is that math is special but not as special as I originally
thought.

I hope my suggestion finds your consideration. Have a restful weekend and
stay healty.

Moritz




On Fri, Oct 2, 2020 at 2:22 AM Neil Soiffer <soiffer@alum.mit.edu> wrote:

> The meeting was recorded:
> https://benetech.zoom.us/rec/share/73eQ7NLe4MEuMqo8UrnWouwvwLm6Km3098KPmfhGyEO5bcGjzBabZNAxkhpaUyeS.H9_c2zb8aPdanbag
> Passcode: CH.k7tYB starts about 7 minutes in
>
> Attendees:
>
> Neil Soiffer
>
> Deyan Ginev
>
> Sam Dooley
>
> Patrick Ion
>
> David Carlisle
>
> Murray Sargent
>
> Steve Noble
>
> David Farmer
>
>
> 1. Charter -- comments?
>
> NS: Draft is at
> https://mathml-refresh.github.io/charter-drafts/math-2020.html
>
> NS: Please send suggested changes to Patrick Ion or Neil Soiffer.
> Alternatively, if you check out the sources, create a branch, make your
> changes, and do a pull request with either of us as reviewers.
> 2. Intent values -- continue discussion with Deyan's google doc as a
> framework   a) More discussion on the meaning/purpose of the various
> levels
>
> DG: I continue working on working values. I’m up to ‘H’. Nothing new, but
> some interesting ones that are very complicated.
>
> DG: Chemistry is interesting. I shared two videos showing how chemistry is
> used. They are top hits on youtube.
>
> DG: Example of balancing equations. He talks about “hydrogen”, etc, but
> when he talks about the balancing equation, he uses just the letter names.
>
> NS: There are other things that change like reading sub/superscripts, [] -
> concentration.
>
> BM: Similar things are done in physics where “momentum”, “energy” are
> used, but when writing things down, it is ‘m’, ‘e’, etc.
>
> BM: are things different for accessibility?
>
> LM: if they are read wrong then it is really hard to understand
>
> NS: a study with kids was they want the semantics, not the syntax. For
> their simple math, superscripts were always powers, so there was no bad
> reading.
>
> MS: Dr. Nemeth developed MathTalk that is syntactic and has a 1-1
> correspondence with the braille Nemeth code
>
> LM: if you want to understand the math, you probably have to see it in
> braille.
>
> NS: JAWS, NVDA, and Safari all generate Nemeth code for braille displays.
>
> SN: The reading system should let you hear what you want
>
> DG: The markup isn’t necessarily spoken. Just because it is marked as
> ‘hydrogen’, doesn’t it mean it is spoken. Useful for search. It is not by
> default they should be read, it is up to the reading.
>
> DG: We should defer to aria-label for hard overrides
>
> DG: Properties like “twice differentiable” shouldn’t be spoken.
>
> DF: pi(x) is the prime counting function. It is pronounced “pi of x”, you
> don’t pronounce it as “the prime counting function” even if it is marked at
> the “prime counting function”.
>
> BM: ‘intent’ is a key to a dictionary. Not necessarily spoken directly.
>
> NS: DG mentioned maybe needing another attribute. That property is
> different from intent.
>
> DF: intent is not necessarily what you want to speak.
>
> MS: we have a hotkey that temporarily tells you more info.
>
> BM: it argues that you have something semantic like whether or not it is
> pronounced
>
> DF: we such decide on whether intent is a key to info or something to
> pronounce
>
> DG: defaults are there for a reason -- they work 90% of the time but not
> all the time.
>
> DG: it is not sufficient to just to speak a key.
>
> DG: even if it is not pronounced, the prepositions that put the
> expressions together are helped. ‘Pi of’ vs ‘pi times’.
>
> NS: in that case, it should have applyfunction vs invisibletimes
>
> NS: but do we need a different attribute for a property rather than a name.
>
> DG: real-valued, differentiable, …  All could use a different attribute.
> Worksheets are examples. Several steps. Useful for search.
>
> BM: I think having a separate ‘property’ attribute is useful. E.g., saying
> it is a unit or chemical element.
>
> NS: I don’t find those compelling because if we know it is a chemical
> element, we know what it is.
>
> <discussion around guessing/heuristics vs what should be said and what is
> in the MathML>
>
> NS: reminder about what we say we are doing in the charter -- does it need
> to change?
>
> BM: things are related, but not intertwined
>
> DG: is this related to pragmatic vs strict content MathML?
>
> DG: One things maps to another: implicit -> explicit
>
> NS: We don’t want to require everyone to have to markup mfrac as
> ‘divides’, so defaults should be in the spec.
>
> Consensus is that there are implicit defaults that map to the explicit we
> are defining.
>
> Action Item: NS to change “semantics” to “intent” in various proposal
> docs.  Also # -> @ ( DG thinks ‘$’ might be better).
>
> Next week we return to the syntax of ‘intent’.
>