Minutes: MathML Full Meeting 3 August, 2023

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Sam Dooley
   - Murray Sargent
   - Deyan Ginev
   - Paul Libbrecht
   - Bruce Miller
   - Cary Supalo
   - Bert Bos

<https://sandbox.cryptpad.info/code/inner.html?ver=5.4.0-rc5#cp-md-0-regrets>
Regrets
<https://sandbox.cryptpad.info/code/inner.html?ver=5.4.0-rc5#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=5.4.0-rc5#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

NS: The charter has gone out for a vote. Three or four ACSes have responded
positively. We have had no negative votes. The vote may close this week.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.4.0-rc5#cp-md-0-2-deyan-raised-commented-on-some-issues-i-think-we-should-briefly-go-over-them-to-raise-awareness-but-leave-discussion-to-the-issue-if-possible->2.
Deyan raised/commented on some issues. I think we should briefly go over
them to raise awareness but leave discussion to the issue if possible:
<https://sandbox.cryptpad.info/code/inner.html?ver=5.4.0-rc5#cp-md-0--a-href-https-github-com-w3c-mathml-issues-425-39-intent-39-should-be-specified-as-translatable-a->'intent'
should be specified as translatable
<https://github.com/w3c/mathml/issues/425>

NS: I spoke with James Craig (Apple/ARIA), and he suggested that we
investigate making intent be marked as translatable. He said that tells
systems that they can automatically translate the value. Aaria-label is an
example of this. The ARIA spec references the HTML spec about this. James
also mentioned translation can be tricky and said there were ways to enable
better translation (with respect to word order, etc.) by embedding info in
the string. He also said he's not sure if auto-translation makes sense for
math.

DG: I read through the HTML and ARIA links, and I think it would indeed be
appropriate to add a small subsection Translatable Attributes that includes
intent, like how ARIA has done that. And we likely also want to include alt
text as translatable.

NS: Alt text can be LaTeX, and he is not sure what translatable means.

DG: We don't have to do anything besides marking them.

PL: Discussed language variations as separate intents issue #434
<https://github.com/w3c/mathml/issues/434>. In the process of working on
the translation of the raw intents that David F presented last Thursday,
which took me less than 2h (but not including Unicode symbols), I realized
that the speak-aloud column in French may be richer than in English and
that many more languages is going to trigger many more variations. This
issue is to discuss how much intents can cope for this expectation. Clearly
handcrafted enrichments of intents can do it in many cases. Should the
predefined intents' keywords ("core intents") simply ignore the variations?

DG: Suggests that the base concepts should be expressed in English.

DG: And then a hypothetical open list should be able to also have concepts
in the different languages. And then some out of spec method can connect
the non-English language with English.

DG: So how do you do it? That's the beauty of it. We don't have to specify
how we do translation for the translatable attribute at least.

DG: It's a matter of what algorithm you are going to use for translation.
Are you going to do it symbolically? Are you going to do it with the neural
nets? Because if you're going to do it with a neural net, you're going to
get the English thing completely spelled out in English and then translate
that.

BM: We ought to be able to leverage automatic translation to get us out of
the problem of translating all our intents. Using intents produces an
English language result which can be automatically translated.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.4.0-rc5#cp-md-0--a-href-https-github-com-w3c-mathml-issues-432-list-of-core-intents-a->List
of core intents <https://github.com/w3c/mathml/issues/432>

(About chemistry and other sciences)

DG: Enumerated seven or eight STEM sub-topics. We discussed math most. We
should say what is in scope before we go very far with our concept list. Do
we work with all the stem fields taught in K-12, or just math?

PL: We should aim at an intersection of all the STEM topics taught in K-12.
We may not put all those topics into core. Just math in core.

BM: We put things in core, not because they are common, but because they
are unclear. An example is power, which can mean power in physics, or
exponentiation.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.4.0-rc5#cp-md-0--a-href-https-github-com-w3c-mathml-issues-454-references-in-a-function-head-a->references
in a function head <https://github.com/w3c/mathml/issues/454>

DG: Is there any other open comment which needs to be discussed?

We discussed [Intent Properties, ordering & references}(
https://github.com/w3c/mathml/issues/449)

NS: This issue is meant to pull together some threads on how properties are
handled, whether there is an order, and what happens if there is a
conflict. Any other conceptual issues related to properties are also
appropriate here. Their syntax is part of #448. I am probably missing some
issues raised elsewhere: (#446, ???), but here's a starting list:

   1. How should a headless property "headless" be interpreted (standalone
   and when referenced).
   2. If multiple properties are given, does the order matter?
   3. If a property exists on a referenced item and the referencing item
   has a property, if order matters, what's the order that should be used?

NS: How does navigation work.

NS: Maybe I should open a new issue on what happens to navigation with
intent.

BM: The first point of view is, should you be navigating According to the
intent tree? And if you end up on a node that is effectively invisible to
that intent tree, conceivably, you might want to put intent on it for that
isolated case; but, I don't quite see how the intents that intended to make
that node invisible should be affecting the speech if you navigated.

We discussed what intents should be used for the absolute value of x.

NS: This topic could be an implementation issue.

*ACTION* DG: I think we should have a little bit of text, in the spec,
clearing up intent mitigation and presentation navigation. And I agree NS
should open a new issue to bookmark that we should do that.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.4.0-rc5#cp-md-0--a-href-https-github-com-w3c-mathml-issues-469-svg-mathml-interop-for-accessibility-a->SVG
+ MathML interop for accessibility
<https://github.com/w3c/mathml/issues/469>

DG: We have tens of thousands of examples in archive with SVG and MathML.
And ideally you would like to make those accessible because all the
information is there. You just need to specify how you walk through the
diagram. Is the existing mechanism enough, or do we need to do something
more like intent?
<https://sandbox.cryptpad.info/code/inner.html?ver=5.4.0-rc5#cp-md-0-3-main-focus-for-the-meeting-paul-39-s-work-item-to>3.
Main focus for the meeting: Paul's work item to

expand the list of core concepts
<https://polx.github.io/mathml-docs/intent-core-concepts/>

NS: Paul's list will help us decide on a philosophy of what should and
should not be on the list.

PL: The idea was to make a list that is complete. He took it from MathML
content. Which as far as he knows includes Open Math 4, but he needs to
verify that.

PL: In the table, I wanted to document the property, possibly conditions,
and then a speech template. He has not finished.

PL: He did this in French and English.

PL: When you see a star in his table, that symbolizes the default.

PL: Did not need arity. Most functions are arity one like sin.

NS: Well, I think function tends to be the default. So, I would have
thought that, you know, hyperbolic sign is defaulting to function.

DC: It depends if you say sinh x or sinh of x.

DC: I usually say sinh x which is the prefix.

NS: If you had a more complicated argument to the sinh, you would not say "
sinh complex argument", you would say "sinh of complex argument. An example
would be sinh of x squared plus y squared.

DC: But the difference in prefix and function is only a speech issue.

NS: Being in core means the AT is free to speak it.

PL: was wondering what symbols he should use in his table. While he could
use any symbol he wanted if he documented it, this would lead to a unique
set of symbols. PL wanted to use a symbol that is already accepted by the
community.

PL: People say prime for derivative.

DC: Prime is not a core concept. It is not a concept at all. It is a
notation.

PL: You use prime for many different things. If you wanted to, you could
use intent to call a derivative prime.

NS: There are multiple derivative notations, and they are spoken
differently.

DC: Some people use dots to show derivatives.

NS: The Problem with prime and a horizontal bar is that software generates
different things to show them.

DC: If you use the Unicode characters for these symbols, that will not
happen.

BM: In physics primes and dots tend to be used for different implicit
derivatives. Primes tend to be spatial, and dots tend to be temporal
derivatives.

BM: If you're going to say prime, you're not disambiguating anything, and
you really shouldn't be saying anything with intent.

NS: MathCAT accepts many characters for prime and calls them prime.

DG: If you want to say prime, use an underscore.

DG: Power in physics is a concept.

NS: The concept name should be meaningfully spoken. You cannot use
exponentiation for power.

NS: Things can move from open to core, but AT does not know about the
transfer. For this reason, you want to use concept names that are generally
understood so that it will not matter when something moves from open to
core.

DG: Power is a core concept.

NS: We should have one rule for how to name core things.

DG: Power is a concept and can be an alias for exponent. There is physics
power and exponentiation's power.

DC: This also happens for the word root which can be used in a square root
or could be the root of an equation.

NS: In the open list, what can we do for concepts. Open concepts are
complicated.

DG: Certain concept names are not readable. However, Wikipedia has examples
of these things being readable. For example "Exponentiation of a positive
real number be with an arbitrary real exponent x".

The "logical equivalence of a and b" is long, but it is proper English and
is readable.

PL: I mean that the most common way of saying should be the thing that is
proposed as the speech template, so I don't think I want logical confidence
to be the speech template.

DG: The speech template should not be the concept name. Those are 2
different things because the speech templates are very bad for organizing
principles because they're so different. People say things differently. We
don't have encyclopedias for speech templates.

DG: We have encyclopedias for concepts. So that gives you an anchoring
point to say we can organize based on this because everybody knows the
concept name.

DG: International English could be different from local English. Also,
speech templates can be much more language specific than the concept names.

DG: I think it's much easier to say there's a universal language of
mathematics where all languages share the concepts if you use the name of
the concept.

DG: You risk that people will give up on the core rather than the names
because I'm quite certain that it's going to be messy if you don't have an
organizing principle.

PL: How to structure the concept file. Have a separate table for each STEM
topic but keep all the tables in one file.

PL: We can rename things. We have MathML content that we can use for our
starting point.

NS: PL has given us something to discuss. NS asks pl to continue working on
the table.

DC: The open list has more columns than PL's table.

PL: Should I add more columns? Source might be useful.

NS: If people have ideas, please send them to the email list.