Re: Minutes: MathML "intent" meeting, 1 Oct, 2020

Hi Moritz, all,

I actually agree with all of your points in substance. The unresolved
question from your email is "which way is forward?". I am assuming you
would encourage people to build MathML 3 applications for a11y and
search in 2021, see where they fall short, and then come back to spec
writing in 2022?

As to alternatives, I have been trying to point out some that I am
aware of, e.g. sample RDFa annotations for "properties". Parallel
MathML+RDFa could be reconciled with the schema.org efforts for
Scholarly HTML, which are mostly ignoring math for now.
https://gist.github.com/dginev/be5029e8c4ecf095b9abacd78d81aa9a/

As to additional participants, I think some outreach has already been
done, and we should assume this is the level of interest we can
realistically get in 2020. If you think additional/better members will
be compelled to join if an effort starts fresh in a year (or two?),
that's a case you could make, but predictions of the future are sadly
somewhat hard to make and rely on...

In the interest of being constructive, I have extended my mini latexml
showcase for math-to-speech to also support cross-referenced pMML+cMML
(pre-alpha, expect limitations), and I would volunteer presenting a
direct comparison between the syntaxes in one of the upcoming Thursday
calls. The differences between the pmml+a11y annotations and the
pmml+cmml annotations are quite easy to observe and may recenter the
conversation a little. I again agree fully with Moritz that we can
achieve everything we've discussed with MathML 3 -- my demo is loosely
equivalent to his WikiData-motivated content markup -- if we only had
the content dictionaries and implementer enthusiasm for developing
with Content MathML. There are objective reasons why both of those are
hard to find in 2020.

In addition, I noticed some members have a Goal that isn't actually
about adding new syntax. There is significant hunger for achieving a
"free lunch" accessibility over raw presentation MathML, to cover the
vast majority of presentation-only math currently in existence.
(Method: by assuming that it is mostly standard notations in K12
education). I think those rules can be introduced and specified even
in a MathML 3 context, mapping between Presentation and Content
MathML, and are a largely independent section/chapter in a
specification document. This item could be completed even if no new
syntax gets introduced by this group.

Greetings,
Deyan

On Fri, Oct 2, 2020 at 3:38 AM Physikerwelt <wiki@physikerwelt.de> wrote:
>
> Hi Neil, Patrick,
>
> I suggest replacing
>
> "It will add attributes that allow specification of mathematical intent on Presentation MathML elements to enhance accessibility and searchability of math."
>
> with
>
> "It recommends methods to specify the intent on MathML elements to enhance accessibility and searchability of math."
>
> in section 2-1 MathML4. And following the same spirit replace section 2-2 with
>
> * Test suites and implementation reports for the specification
> MathML Accessibility Techniques
> * Guides on enhancing MathML for accessibility and search
> * A living catalog for annotations beyond those defined in a MathML 4 recommendation.
> * Sample code that converts default Mathml to a persistent form of "intent" enhanced MathML.
> * At least one TeX-to-MathML converter that incorporates accessibility/searchability annotations in its MathML output.
> * Code to convert between strict Content MathML to MathML with accessibility and searchability enhancement.
> * Sample code for conversion of intent enhanced MathML to an external form such as speech or plain text output
>
> I was under the impression that we propose ways to foster semantic annotation beneficial for the applications `accessibility' and `search'.
>
> As expressed before, I think the decision that annotations to presentation MathML is the best way to achieve better accessibility and search is premature. I really respect and appreciate your work and discussions and think the collection of vocabularies and ontologies is a great achievement. Also, we share the goal to simplify and standardize the enhancement process.
>
> However, I would like to avoid confusion on the stability of MathML in the public and guarantee a continuous transformation from the current MathML standard to the next MathML standard. A competing way to express semantics is not beneficial would not be a good message.
> Moreover, I think we should learn from the mistakes done in the past and interact more with other communities. Improving accessibility and search is not something only mathematical formulae have. For instance, SVG images face very similar problems. Also in Europe and in Germany particularly there is now a big push towards using knowledge graphs and schema.org annotations. Maybe there is also something we can learn from those initiatives.
>
> I would therefore ask everyone in this working group to be brave and look beyond the well-known paths what other communities have done or are doing. My observation is that math is special but not as special as I originally thought.
>
> I hope my suggestion finds your consideration. Have a restful weekend and stay healty.
>
> Moritz
>
>
>
>
> On Fri, Oct 2, 2020 at 2:22 AM Neil Soiffer <soiffer@alum.mit.edu> wrote:
>>
>> The meeting was recorded: https://benetech.zoom.us/rec/share/73eQ7NLe4MEuMqo8UrnWouwvwLm6Km3098KPmfhGyEO5bcGjzBabZNAxkhpaUyeS.H9_c2zb8aPdanbag Passcode: CH.k7tYB starts about 7 minutes in
>>
>>
>> Attendees:
>>
>> Neil Soiffer
>>
>> Deyan Ginev
>>
>> Sam Dooley
>>
>> Patrick Ion
>>
>> David Carlisle
>>
>> Murray Sargent
>>
>> Steve Noble
>>
>> David Farmer
>>
>>
>>
>> 1. Charter -- comments?
>>
>> NS: Draft is at https://mathml-refresh.github.io/charter-drafts/math-2020.html
>>
>> NS: Please send suggested changes to Patrick Ion or Neil Soiffer. Alternatively, if you check out the sources, create a branch, make your changes, and do a pull request with either of us as reviewers.
>>
>> 2. Intent values -- continue discussion with Deyan's google doc as a framework
>>
>>    a) More discussion on the meaning/purpose of the various levels
>>
>> DG: I continue working on working values. I’m up to ‘H’. Nothing new, but some interesting ones that are very complicated.
>>
>> DG: Chemistry is interesting. I shared two videos showing how chemistry is used. They are top hits on youtube.
>>
>> DG: Example of balancing equations. He talks about “hydrogen”, etc, but when he talks about the balancing equation, he uses just the letter names.
>>
>> NS: There are other things that change like reading sub/superscripts, [] - concentration.
>>
>> BM: Similar things are done in physics where “momentum”, “energy” are used, but when writing things down, it is ‘m’, ‘e’, etc.
>>
>> BM: are things different for accessibility?
>>
>> LM: if they are read wrong then it is really hard to understand
>>
>> NS: a study with kids was they want the semantics, not the syntax. For their simple math, superscripts were always powers, so there was no bad reading.
>>
>> MS: Dr. Nemeth developed MathTalk that is syntactic and has a 1-1 correspondence with the braille Nemeth code
>>
>> LM: if you want to understand the math, you probably have to see it in braille.
>>
>> NS: JAWS, NVDA, and Safari all generate Nemeth code for braille displays.
>>
>> SN: The reading system should let you hear what you want
>>
>> DG: The markup isn’t necessarily spoken. Just because it is marked as ‘hydrogen’, doesn’t it mean it is spoken. Useful for search. It is not by default they should be read, it is up to the reading.
>>
>> DG: We should defer to aria-label for hard overrides
>>
>> DG: Properties like “twice differentiable” shouldn’t be spoken.
>>
>> DF: pi(x) is the prime counting function. It is pronounced “pi of x”, you don’t pronounce it as “the prime counting function” even if it is marked at the “prime counting function”.
>>
>> BM: ‘intent’ is a key to a dictionary. Not necessarily spoken directly.
>>
>> NS: DG mentioned maybe needing another attribute. That property is different from intent.
>>
>> DF: intent is not necessarily what you want to speak.
>>
>> MS: we have a hotkey that temporarily tells you more info.
>>
>> BM: it argues that you have something semantic like whether or not it is pronounced
>>
>> DF: we such decide on whether intent is a key to info or something to pronounce
>>
>> DG: defaults are there for a reason -- they work 90% of the time but not all the time.
>>
>> DG: it is not sufficient to just to speak a key.
>>
>> DG: even if it is not pronounced, the prepositions that put the expressions together are helped. ‘Pi of’ vs ‘pi times’.
>>
>> NS: in that case, it should have applyfunction vs invisibletimes
>>
>> NS: but do we need a different attribute for a property rather than a name.
>>
>> DG: real-valued, differentiable, …  All could use a different attribute. Worksheets are examples. Several steps. Useful for search.
>>
>> BM: I think having a separate ‘property’ attribute is useful. E.g., saying it is a unit or chemical element.
>>
>> NS: I don’t find those compelling because if we know it is a chemical element, we know what it is.
>>
>> <discussion around guessing/heuristics vs what should be said and what is in the MathML>
>>
>> NS: reminder about what we say we are doing in the charter -- does it need to change?
>>
>> BM: things are related, but not intertwined
>>
>> DG: is this related to pragmatic vs strict content MathML?
>>
>> DG: One things maps to another: implicit -> explicit
>>
>> NS: We don’t want to require everyone to have to markup mfrac as ‘divides’, so defaults should be in the spec.
>>
>>
>> Consensus is that there are implicit defaults that map to the explicit we are defining.
>>
>>
>> Action Item: NS to change “semantics” to “intent” in various proposal docs.  Also # -> @ ( DG thinks ‘$’ might be better).
>>
>>
>> Next week we return to the syntax of ‘intent’.

Received on Monday, 5 October 2020 23:58:55 UTC