Minutes: MathML intent meeting 20 Jan, 2022

 Apologies for the late minutes
Attendees:

   - David Carlisle
   - Sam Dooley
   - David Farmer
   - Deyan Ginev
   - Louis Maher
   - Bruce Miller
   - Moritz Schubotz
   - Murray Sargent
   - Neil Soiffer
   - Steve Noble
   - Bert Bos
   - Paul Libbrecht

Regrets:

   - Patrick Ion

Announcements/updates

NS: MathCAT now works with NVDA. It is being tested.

DG: I'm working on a fork of MathCAT and may have something to discuss in
the future.
Progress on aliases for level 1 names? --
https://github.com/w3c/mathml/issues/257

NS: Intent parameters guide speech and not content definitions.

DG: Both the terms common log and natural log can be aliased as log.

ACTION: We had a discussion on what it means to be an alias.

DG: Conclusion for the day: overall, still under deliberation. Partial
summary:

   - An "alias", as proposed, is an alternative name (technically,
   alternative intent value), for a primary name in the Intent Core or Intent
   Open lists.
   - In some cases, the "alias" name is clearly an ambiguous shorthand
   (e.g. interval can be an alias for open-interval or closed-interval
   or...).
   - In other cases, the "alias" is instead a rarer name, but of equally
   primary character (e.g. euler-mascheroni-constant is a rarer name for
   the euler-constant).
   - Annotators may have reasons to choose one name over another.
   Alternatively, the group must decide on a single name. We can avoid an
   entire domain of design choices by allowing the full variation from
   real-world scientific writing. One often impossible question: Which is the
   "official" name? One possible answer: let the author decide.
   - DG has suggested that primary names can be thought of as
   "encyclopedic", and can have an accompanying URL to an authoritative
   resource that describes them. Aliases, in turn, may or may *not* be
   encyclopedic. For example, "log" is a symbolic alias for "logarithm", while
   "in" is a colloquial alias for "member-of". Neither of them would be listed
   as a standalone entry for a mathematical concept.
   - In some limited cases, this information is sufficient to create a
   "content symbol", and even a full content tree. While this is not a primary
   goal, we may be able to extract additional utility from the same effort.
   With an explicit connection between aliases and primary names in the Intent
   Core + Intent Open lists, we would have a better handle on which pieces are
   clearly ambiguous, and between which choices.
   - An "alias" mechanism still allows for a "strict" use of the Intent
   Core list. An application that *requires* from annotators to use the
   primary names (such as software for conducting exams), will not have any
   additional ambiguity to resolve. The primary names are proposed to be
   encyclopedic and distinct from each other.

NS: How does AT know if something is a natural log.

DG: We will write: Intent = natural log.

DG: We will maintain a core list and an open list.

DG: the entry is log, and the alias is log and natural log. If the base for
a log term is supplied, the AT knows how to speak the logarithm.

DG: is suggesting that one name can have several math definitions: E.G. log
can be the natural log or the common log.

PL: We must have a way to overwrite the default speech of math terms. If we
want log to be spoken as a common logarithm, we need a way to make this
happen.

NS: the word alias has the wrong connotation. We need a clearer term than
alias.

PL: suggests using "common name" instead of "alias".

SD: A short name can stand for several concepts.

DG: likes the term "encyclopedic name" for a name whose definition is
accepted by most people.

NS: Let's continue the discussion of what we should call the primary and
secondary names on the issue.
Plan for unifying/disunifying level 1 name. --
https://github.com/w3c/mathml/issues/254

NS: Is log with a base the same thing as log without a base?
Do we have to have both square root and root or just root?

DG: Having just "interval" is a good graceful degradation.

NS: If we say interval, we must tell the listener if it is a closed or open
interval on both the left and right sides. We must accurately describe the
type of interval it is.

NS: If you are taking a test, you need your math to be read accurately.

DF: There should be as many names as possible. For example, we can specify
a set by listing numbers, or by using set builder notation.

NS: When you have a large operator symbol like a summation sign or an
integral sign, you must accurately describe its subscripts and superscripts
so that the listener can know the range over which the summation or
integration is being made.

NS: More names are better. This is more work for the developer.

BM: These arguments are very confusing. There are a lot of options to be
considered when determining how to speak a mathematical term.

BM: We should not default by saying interval without saying if it is open
or close. We must be precise.

NS: the French use left and right parenthesis to say if an interval is open
or closed. This would make syntax checking exceedingly difficult when the
checker wants a closed parenthesis for every open parenthesis.

DG: Knowing something is an interval saves you from thinking it is a vector.

DG: When we encounter a plus sign, and we want addition, we need to have an
intent of plus because the plus symbol is used for other things than just
addition.

BM: We need a list of names that everyone agrees on.

DG: When a symbol has a Unicode definition, we can assume that the symbol's
meaning is defined. This symbol should not need an intent entry since its
meaning is agreed upon.

NS: This policy might shrink the core numbers of names.

NS: We will have a table of things that are self-named and do not need an
intent.

NS: If people use a circle with a plus inside, they must define it with an
intent.

NS: We will split a table according to whether a symbol is self-defined or
needs an intent.

SD: The writer needs to know what the AT output is going to be before he
determines if he needs to give an intent definition for the symbol.

BM: Plus must be in some list or people will misuse it.

DG: Characters should be understood and should not go into a table. Math
operators that have a Unicode definition can be assumed to be agreed upon.

MUS: Letting Unicode symbols define what is agreed upon may not be a good
way to go. The Unicode names are stable and will not be changed even if
they are in error.

BM: Let us start implementing things and see what errors come up. It is too
early for us to decide all the solutions to things.

NS: There needs to be a direction. Without a direction, you cannot
implement things.
Naming scheme for level 1 name

NS: There should be a way to choose a name so that more than one person
will agree to it. We need an algorithm to generate names.

NS: We have agreed to use dashes instead of camel notation.

SD: for encyclopedic names longer is better. for aliases shorter is better.