Minutes: MathML Full meeting 10 Oct, 2022

 Attendees:

   - Neil Soiffer
   - David Carlisle
   - Sam Dooley
   - Deyan Ginev
   - Murray Sargent
   - Bruce Miller
   - Dennis Müller
   - Steve Noble
   - David Farmer
   - Paul Libbrecht

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

   - Louis Maher

<https://sandbox.cryptpad.info/code/inner.html?ver=5.1.0-04#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=5.1.0-04#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports
<https://sandbox.cryptpad.info/code/inner.html?ver=5.1.0-04#cp-md-0-2-record-meeting-have-a-transcript->2.
Record meeting/have a transcript?

NS: I don't think they are too useful. Too many details. Also, restrains
speech.

DC: Good at transcripts for internal meetings. But not for this group.

PL: I thought this was for LM's benefit as a scribe. So just for him not
public.

DC: LM was going to try it with Bert.

DG: It would be useful for me when I add to the minutes after the meeting.

NS: Where does the transcript get stored? Is it public?

Consensus: Let's try the recording but not make it public.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.1.0-04#cp-md-0-3-continue-discussion-on-39-intent-39-name-list-registry-spreadsheet->3.
Continue discussion on 'intent' name list/registry/spreadsheet/...

Last week we focused on the "who", "what", and "why" questions (of the five
Ws). The "who" we discussed are software translator developers and AT
implementers. There was only a little discussion on authors or remediators.
Any more thoughts on this?

Several people felt that an important piece of information that is missing
from the current spreadsheet: an example of the MathML that corresponds to
the intent name. Software translator developers need to know what to
generate for a particular intent. This is part of the "what" and "why". Any
more pieces of info that should be in the list?

Once we are done with those, let's move onto:

NS: summarizes current state (above)

PL: not a bijection

NS: the MathML associated with an intent should have the intent in it so it
isn't ambiguous. Cardinality and Absolute value are examples where the
MathML is the same but adding intent makes them unique

DG: example about natural numbers. The speech is the same, but the meaning
may not. Does it include 0 or not.

DG: ambiguous for content MathML

NS: goes over what is in the current spreadsheet. Maybe the subject should
be type, but maybe that's not important.

DG: The name and the source are the most important columns. The "open" list
is better about sources as they are more exact.

DG: Subject is useful for grouping if someone is working in a specific
category

NS: We didn't list authors as a "who" last week

DG/BM: they could be remediating their own content. They might have macros
that allow them to specify the intent.

DC: I think the source belongs elsewhere. Anyone using the table will only
spend a few seconds on an item.

DC: minus can be done many ways

DC: the sheet doesn't tell me the number of arguments, etc.

DG: (discussing gcd) it can be done many ways. On the mrow or on the mi

DC: but I need to know what is legal

BM: maybe form distinguishes the number of arguments

DC: I think splitting if there are two forms since they are different
number of arguments

DC: maybe the token level ones belong elsewhere

DG: The current Intent table is descriptive, not prescriptive. The table
can't list all notations associated with an intent. Remainder is maybe an
example (we have "r" and "R" listed, but not yet "rem").

DC: take "liter". Can I use liter with 5 args? The table doesn't tell me.

DG: The number of arguments is not important for accessibility in itself.
The main goal to achieve is that the word "liter" gets used as opposed to
the "l" in PMML.

DG: If an intent value usage isn't as indicated by the Core "form", then AT
falls back to the Open baseline usage. E.g, it is spoken as if it is
unknown.

NS: If a literal value is given for intent, should AT translate to another
language? I'm not sure that is a good idea because then there is no way to
actually say "don't translate this".

NS: Maybe all the things written in the list that are on mi/mo/etc don't
need to be there since the default way of speaking them will happen whether
they are in core or open or not listed at all.

NS: This would dramatically shorten the lists.

DG: If the Core list is to host only common (say Western K-14) concepts
that *require* custom treatment for accessibility, then indeed self-voicing
(and/or functional) entries, such as "liter" do not belong. And concepts
with lots of special behaviors, such as "power" do belong.

DG: I think we could move all such entries that are currently in the Core
list out into the Open list, which is meant to be more encyclopedic.

PL: There is indeed some value in having an encyclopedic collection, though
maybe it doesn't need to be the organizing principle of the Core list.

BM: I think the entries are useful because it is good to have an
encyclopedic list.

NS: I agree it is good to have a list of how to pronounce something (e.g,
"apery-constant"). But other languages are important too. So maybe that is
in wikidata and not our list.

NS: Out of time. I encourage others to state what they think in email so we
continue this discussion through the week and can have a running start next
week.