Minutes: MathML Semantics meeting Aug 27, 2020

The meeting was recorded:
https://benetech.zoom.us/rec/share/xZZeLvLT531JQpH9zHHbQvBiE5juT6a823dPrqJcnh0NH--LZJeUAzPNUZdPQ4tr
Passcode: VdC3!d%W  (starts about 16 minutes in)

Minutes are limited this week -- listen to the recording if you want to
know what happened in the “...” sections

Attendees:

Neil Soiffer

Deyan Ginev

Louis Maher

Murray Sargent

Bruce Miller

David Farmer

David Carlise

Patrick Ion

Steve Noble

Regrets: Moritz Schubotz


Charter is at
https://docs.google.com/document/d/1W-oYUbOMueaqb3KFSWkjWVBwR6AzSEBizHwQhvSwfDc/edit#
1. Charter -- discussion on motivation/naming for semantics.

NS: “semantics” conflicts with content MathML

DG: We need to be more specific. “Semantics” is an element in MathML and it
too is poorly named.

DG: We should change the attr name of “semantics”.

PI: The element was meant to allow one to bring in meaning from other
systems.  For accessibility, it is more focused. It only addresses one
aspect of semantics -- aimed at accessibility.

NS: Worried about leaving out “search” which is called out in the charter

DG: It is an operator tree.

NS: CS uses “expression tree” or “abstract syntax tree”.

MS: What about “meaning”?

PI: I think you need to use a word that this is a “hint” or “clue” to the
meaning.

DG: I was hunting for a more technical word

DG: I think AST is not too bad

NS: Attr is not the tree

BM: This is used to move us towards a meaning, but not too specific. What
bothers me is less the wishy washy language is more the baggage that any
word has acquired. “Semantics” carries the baggage of CMML and OpenMath.

PI: Perhaps we should be aiming at the AAM.

PI: If we say the attrs that we are going to provide are intended to
improve a11y and searching.

NS: We need a more concise way to say these.

DC: Last time we called “semantics” “content”...

BM: It shouldn’t be a major issue to word smith around it.

DG: We are trying to build AST and grounding symbols.

BM: We should push on AST because we haven’t said what is being abstracted.

DC: The annotations may not be a tree. Calling it an AST seems dangerous.

2. Semantics names -- continue discussion   a) Names --agreement on using
hyphenated names?

NS: I think we agreed on hyphens

No objection
        Should the names brought over from Content MathML be changed to
follow this naming convention?

PI: I suggest that a consistent set of names with hyphens be used and that
CML names be aliased in as ‘grandfathered’.

Aliases:

NS: do we want one or more names

DC: why do we need to specify names at all?

NS: how do I know what to do with ‘divides’ if it doesn’t have a name I know

DC: there are some exceptions for basic math

DC: but most of the time you just say the name that someone wants. E.g, my
thesis uses a script P but has a specific name for pronunciation.

NS: there are actually a lot of names, consider all the units or currency.

NS: Is the idea we just list and everything else is what it is.

DG: That sounds great and aligns with what I’ve done.

PI: When something is so commonplace that it has different ways of
speaking, are we developing that?

DG: There is an open ended way of speaking things. Maybe there was a 30s
way of doing it and there is a modern way. The alias list would include
that, but not say this is the alias to use. The document should probably
use the 30s way of doing it if that is intended.

PI: Yes, the terminologies have changed and the words used may distinguish
between the notations used for them.

DG: Out of scope and in scope…

PI: Will we be able to allow authors to specify readings in a document?

NS: aria-label allows authors to force a specific reading over-ruling a
default

… discussion of chemical element naming…

PI: Note that numerical annotation on an element, such as ‘H’, might get it
pronounced Deuterium or Tritium

PI: There is surely a standard list of chemical elements developed by
chemists

….

?: Trig functions

NS: these are clearly for level 1; and well-known

BM: do you need to have ‘sin’ explicitly, when you have function as the
annotation and sin is its name and has a special pronunciation

MS: you’ll end up with #2061 in there

….

DG:


BM: We should be focusing on enabling rather than prescribing. We should
think about a way to have longer outside lists

NS: Are you saying that mfrac shouldn’t default to “divide”?

BM: No.

NS: We need to make things easy. So defaults are useful.

DG: We will end up a list of subject areas. I think it will end up like
openmath.

PI: I’d like to underline BM’s comment that the spec should be enabling
rather than comprehensively descriptive; it should suggest how to do
certain things and illustrate with basic examples

PI: The other point that should be made I suspect is that it seems we are
just wanting to reference subject onologies.  Chemistry and physics have
reasonable ones available

Already.  Math does not, and the CG thinks we know what should be in there,
but we haven’t made one.  That’s the fuller form of the function list
notion.  You can argue DLMF is a pretty good basis for  an ontology of
special functions.  But ontology is maybe even worse jargon (for the
production of unnecessary confusion) than semantics.  For an illustration
of that see the report of the Fields institute meeting in 2016