Minutes: MathML semantics meeting, 17 Sept, 2020

The meeting was recorded:
https://benetech.zoom.us/rec/share/5pQI6CGkJoagm5PJ0QIy5GICQan-3bLadV7WH5r9RVmi9OPr4qcIBgvgswLXn2b5.rAXycNIEv_0yhFAH
Passcode: 21U!IHUu (meeting starts about 7:30 in).

Thanks to Patrick for taking minutes this week.

Attendees:

Neil Soiffer

Deyan Ginev

Louis Maher

Bruce Miller

Sam Dooley

David Farmer

Patrick Ion

David Carlise

Steve Noble

Murray Sargent

1. Semantics names -- continue discussion with Deyan's google doc
<https://docs.google.com/document/d/1DwNZkFDfI7uZclOeCDcOWVeWv87WjAII-MgE2rTmwfs/edit>
as a framework   a) More discussion on the meaning/purpose of the various
levels

Many but not all had read DG’s document

DG: I wanted to have 2 pages, but it’s needed to explain.  I think we have
a baseline starting point, i.e. pMML and its tree.  We’re not doing
algebra, but the presentation tree is almost understandable anyway; so what
to add as annotation is ‘fuzzy’,.  I start with 3 aspects of meaning …

[screen shared doc at this point: explanation not transcribed]

NS: Is this under the semantics attribute of before or a new one?

DG: this is notationally under a different attribute from the previously
considered

Semantic one; that’s because it addresses different matters.

<<<

NS: are you imagining that receiving software can work with this extra
‘metadata’ and

do things for display; it’s not just for Search then

DG: yes, e.g the Coulomb example

BM: if you know ‘m’ is a unit but not which one then you perhaps could mark
more up;

If it’s a TeX macro package you might not know which supported unit it is.

NS: it’s not something you want to read out

DF: you could make a TeX macro that typesets units correctly in Rpoman but
doesn’t tell you any more.  SO Bruce has a point.

DG: the Narrative structure part, where arguments are distinguished isn’t
much discussed.

The Second part concerns Concrete vs. Subject annotations;  This
corresponds to earlier discussion and I added examples

DG: Hydrogen etc.

PI: Translation

MS: just convert a standard English into a token and then have a phrase
book, we do that already well

NS: a problem is there’s no notion of the language we’re in.

DF: if we know its an element and is given as ‘H’; then it’s clear its
hydrogen; it is not the author’s choice it’s the readers

DG: These are all keys that can be worked on in the receiving displayer

MS: ther;’s the conception of verbosity and its appropriate level in screen
reading

NS: screen readers change pitch for caps; the chemist want it it say ‘cap

: isn’t that wrong; it shouldn’t be in the content itself

NS: if you throw in the word Sodium then you wanted that

BM: Sodium might provoke for chemist just ‘Na’

<<<

DG: I’m suggesting annotations; it’s a different question as to what gets
spoken or quieted.

BM: if you put Hydrogen then that’s what gets said probably

SN: is it possible to have a ‘chem’ tag like the natural language tags that
switch language?

NS;  there’s special chem notation pronounced in easy not suitable for math

LM: a screen reader allows setting ‘cap’ or pitch change for capitals;
aMathMl shouldn’t

be messing with that

NS: chem group will have to decide what ought to be read

BM: we’re making an annotation token and how it’s read is not our issue

NS: in a textbook the level of pedantry varies with amount of exposition;

Maybe if you want to force a reading you should use aria-label

MS;

DG: There are 3 pieces: authoring software;  rendering software;
accessibility software

We need to pass suitable information through so later stages can do what’s
needed.

BM: as soon as you leave saying specifically what you mean you’re limiting
the user agent in customizing for a specific reader

SN” like using an ‘alt’ text

DG: Finishing off the document. An inner product with a dot or angular
brackets; you annotate differently depending on what you wish.  The doc
suggests adding the name of the operation.

Subject annotations are a parallel mechanism, but one which can save a lot
of markup.  You then have level list of subject areas (note subtlety:
chemistry vs. chemistry formula vs. chemical formulas)

NS: e.g. brackets mean concentration in chem equations

DG;  Pros and Cons in summary …..


NS; Thank you very much for getting a lot of stuff down we have discussed.
Very useful.

SD: a lot to absorb

NS: that subject notions seem to bring up things that might have to be
done; …

Mostly we have to hope the software that generates this will get it right;
maybe over the years

ZDF: I don’t object or disagree, but I’d like to see how examples are
marked up; i now have idea about how authors will do markup

Zns; I’d say subject is useful because it allows authors to do a lot less
work

DF: I think of books; knowing its linear algebra helps a lot for a whole
books worth; I’d look for examples of how much more an author might be
having to do; e.g. (a,b) for pair, innner product, interval etc.

NS; given TeX examples I could generate the markup needed easily enough (in
draft form)

BM: what exactly goes into MML is question; mini-semantics

NS: subject on math elt; you don’t have access to the document

BM: concrete and subject area is refactoring some software into at least
two layers; pattern matching rules for pronunciation leading to rendering
ina verbalization; if you have full concrete annotation you don’t need
pattern matching, which you do for subject annotation that requires you to
group your rules into modules

MS: as a tool to test out the ideas I was thinking of a case where the
concrete annot is not mentioned and that gets filled in as
specified;subject areas could change defaults; concrete markup overrides
local defaults from subject

Apple screen readers knows little; just about squares and cubes; much more
needs doing

I’d hope we can provide clues to be used to do much better everywhere,

BM; Subject to concrete conversion offline, and then author checking and
tweaking for concrete overrides would be a simple way

DG: if you have a module system in a programming language you can …. Then
compilation to bytecodes

It would be great for the authoring language …

Then the complexity is sorted out at the authoring stage; therenderng from
a concrete syntax would be easier

NS: but most math won’t be well tagged for a long time; you have to work
with this

There’s a lot for legacy MML out there and legacy tools to change as well

BM: the conversion I mentioned could well be offline

PI: It worries me that it is unclear what goes into a MathML spec. We
should say how to provide clues for how they go into MathML.



[PI: Sorry my system just completely collapsed on me as I was expressing my
compunctions

about the amount of work actually needed doing to demo and support a spec
which provides

the suggested sorts of meaning annotations.  I really find attractive the
idea of subject contexts

and making authoring easy enough.  The practice of that is going to
require  a lot of work and

a cleverness in specifying ways that people can develop and distribute
subject profiles in

accordance with a MathML spec.]