Minutes: MathML full meeting 21 December, 2023

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - Bruce Miller
   - Paul Libbrecht
   - Moritz Schubotz
   - Deyan Ginev
   - Cary Supalo

<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0#cp-md-0-regrets>
Regrets

   - David Carlisle

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

NS: Our next meeting will be on Thursday, January 4, 2024.

DG: arXiv has put out around 25,000 papers in MathML. Announcement at:
https://blog.arxiv.org/2023/12/21/accessibility-update-arxiv-now-offers-papers-in-html-format/

DG: Says they will release more papers in stages. There are about 2.3
million papers in total.

NS: Congratulations to DG and BM who made this happen.

PL: Has there been feedback from the authors?

DG: There is a method to send a comment on every HTML page. They have
received about 400 reports in the last four days.

DG: knows of around 2,000 issues.

CS: On Monday of this week, the Braille Authority of North America, BANA,
formally adopted the new chemistry Braille code, 2023 revision. For over a
decade, CS was the chair of the committee which produced the code.

ACTION** NS: The Unicode Technical Committee recommended to the full unit
code committee that 10 additional chemistry symbols be added to Unicode. NS
will send these symbols to CS. These new symbols will be released as part
of Unicode 2025.

PL: Described a system, called Math STAAR, that will combine a touch
screen, with audio output, to help people learn chemistry equations. As the
person moves his finger across the screen, he will hear sound output that
will allow him to trace the shapes of the chemistry symbols in the
equation. This will help people learn the chemical diagrams used in
chemical equations. This was for people with reading problems.

*ACTION* PL will send NS a paper on this subject.

From Moritz Schubotz to Everyone: Add Intent to WikiTexVC
https://github.com/wikimedia/mediawiki-extension
s-Math/commit/4b30c9701a20b5c935c9ffddad071c17dbf71818#diff-3f9db422b7893aeed91e7a81c0ae3796920238fc0650aff36b94e1df69bd5420
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0#cp-md-0-2-large-operators-integral-sum-union-etc-max-5-minutes-issue-didn-39-t-get-opened-from-last-time->2.
Large operators (integral, sum, union, etc.): max 5 minutes (issue didn't
get opened from last time)

DC: In a previous meeting, DC said there are several large operators, like
summation and integration, which are very similar. So why don't we just
have a concept called "large OP", and make these operators be part of the
large op concept?

NS: did not think that that would fit in with the way we name things.

NS: These operators can be applied over a domain (one argument) or over a
range starting somewhere and ending somewhere (giving two arguments).

NS: discussed this using a definite integral case.

DG: I was just wondering whether you avoid repeating yourself or move the
repetition inside the arguments because you will still have to mention
something's a definite integral even if it is a large operator?

NS: suggested to just list out The names of all the operators and say that
these operators are all similar. That would list all the operators
together. He got negative feedback on this idea.

BM: On the one hand, having complicated arguments for a concept is a
negative, but it might be better than the alternative.

BM: Is not sure you have to mention all the cases.

There was a discussion on how you would say the integral from the lower
limit to the upper limit so that it would work in all languages.

PL: thought that the integral would basically read the same in most
languages. If there was a language in which integration is read
differently, then you could use an intent for that case.

MoS agreed.

Dg: said you had to manage the cases of when there were no, one, or two
arguments. He discussed the two-argument case (integrating from "I" to "j"
and said it would be especially complicated if you had multiple subscripts.
You could also have ranges where: I would be less than j which would be
less than k.

*ACTION* NS will create a large operator issue.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0#cp-md-0-3-derivatives-first-higher-order-different-notations->3.
Derivatives (first, higher order, different notations):[

473 <https://github.com/w3c/mathml/issues/473>] max 10 minutes (lots of
discussion)

NS: discussed df/dx (a) which is the first derivative of "f" evaluated at
"a". NS asked how important was this notation.

DG: said that around 8,000 documents had this notation out of 1.57 million
documents.

DG: This case is rare, but not that rare. It cannot be ignored.

DG: discussed the cases where a vertical bar meant "is evaluated at".

DG: The vertical bar has the concept "evaluated at".

NS: Is this something common enough to be supported in core?

DG: Yes.

DG: We need derivative in core. We are discussing which arguments go into
what positions in the concept definition.

NS: The speech should tell the listener how things are written.

NS: The blind need to know how the expression is written. You do not want
to over generalize something so that you cannot tell how things are written.

DG: Discussed using the vertical bar to indicate that some function is
evaluated at "a". Using "a" in parentheses can be a little tricky to
understand.

NS: discussed the case of d/dx where no function is mentioned. He said that
you could indicate the missing function, in the intent, by having two
commas next to each other, or by using an underscore. He did not like using
two commas next to each other because the two commas could be treated as a
typing error.

BM: We do not want an explosion of concepts, thus producing many concepts
for the derivative, and related cases.

DG: We do not want different concept names for different patterns of
arguments in operators like: derivatives, summation, integration, and
partial derivatives.

DG: So, it's much better to have a single principled way to omit arguments
and have fewer concepts that can omit their arguments.

NS: We can say that a derivative always has three arguments and use an
underscore when one of the arguments is missing.

NS: And an interval is always two arguments.

DG: We must be careful. We may need to collect examples because you could
get very confused if you have different missions for different concepts.

DG: In an integral with one argument the argument could be a set that you
integrate over. That is very conceptually different than the integral from
to, which is over a range.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0#cp-md-0-4-a-href-https-w3c-github-io-mathml-docs-intent-core-concepts-core-concept-list-updates-a->4.
Core concept list updates
<https://w3c.github.io/mathml-docs/intent-core-concepts/>
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0#cp-md-0-i-a-href-https-docs-google-com-spreadsheets-d-1eswou1k5nxbdlpvqapdoa9h-s8lg_qjn8fjh64g9izq-edit-gid-1358098730-deyan-39-s-original-spreadsheet-a->i.
Deyan's original spreadsheet
<https://docs.google.com/spreadsheets/d/1EsWou1K5nxBdLPvQapdoA9h-s8lg_qjn8fJH64g9izQ/edit#gid=1358098730>

(left off at line 180, but mainly just large ops/derivatives left)

added "evaluated at"

added "limit" and the arrows indicating approaching the limit from below,
from above, from the left, and from the right.

dg: The arrows are not NC names and therefore are not valid intent values.

DG: We do not have a dictionary for the arrow symbols.

*ACTION* NS: Limits should become an issue.

From Deyan Ginev to Everyone: lim(x,0) lim(x,0,below) lim(x,0,above)

NS: "outcome" refers to probability. NS did not add it.

Added "operator-range"

Decided "transform" was not core

Did not add velocity, acceleration, or position.

Added "average" as mean.

add "repeating-digits"

" nth-derivative" already added.

"polynomial" is not core.

We arrived at chemical terms which will have the chemistry property.

We arrived at "units".

We finished DG's list.

Received on Friday, 29 December 2023 03:42:50 UTC