Re: multi-symbol variables

On Fri, Oct 8, 2021 at 11:50 PM Neil Soiffer <soiffer@alum.mit.edu> wrote:
>
> double prime -- as David C pointed out, there are multiple ways to write the double prime in MathML. Some of them will result in "prime prime" and the "right" way will use the Unicode double prime character

I completely agree here, the two "mo" elements are indeed viable ways
of writing this in MathML 3. And I agree with the 5 suggestions in the
other thread as to remediating that. I myself had mentioned the
question whether "canonical mrows" are a good best practice when doing
the intent annotations, where the mrow structure follows the concept
structure. Not as a requirement, but as a recommendation.

I disagree that using U+2033 ″ is a "right way", unless we buy into
the "semantic Unicode" paradigm as a primary source of truth for AT,
which I claim (and have claimed before) is insufficient.
The "double prime" reading of the Unicode character *coincides* with
the intended reading in this specific case of an embellished variable
"B-double-prime", but would not coincide with the reading of "inches"
or "arcseconds", or indeed "прим-прим" in cyrillic.

> and likely will result in the AT saying "double prime". I spent some effort in MathPlayer (and more in my upcoming MathPlayer replacement) working on cleanups, and merging primes is one of them. Of course for things like "*", there is no "**" character in Unicode so there's not much that can be done other than maybe merging them into a single <mo> (something I haven't done). However, it is not clear that "double-asterisk" or "double-star" is better than "star-star".

Yes, it is not clear which name is best in general. But it is usually
clear to a very important person - the author of the document being
remediated.

>
> I think we all agree that if the author cares about how it is pronounced, they should have a way to make that happen.
>

We do? That is wonderful!

> But there is also an alternative way to think about it and that alternative is likely a reason why it is taking us so long to figure out intent:
>what if the author doesn't care about the specific wording but wants to just make sure the concept is conveyed correctly? In that case, the exact words aren't important, but it is important that appropriate words are used.

This is a mystifying description to me: "What if the author doesn't
care about the specific wording but wants to just make sure the
concept is conveyed correctly?"

Are the concepts not conveyed using specific wording? Are you
referring to cases that have multiple equally viable names in
mathematical practice, and the author doesn't care which one the AT
system uses? That is also compatible with my suggestions, it's the
"alias" mechanism I've introduced in the spreadsheet.

There is no contradiction really. Language has structure too, and
people can make the difference between a grammar error and a
vocabulary error. So authors are likely to correct the wrong
"power($1,$2,$3)" to "power($1,$2)" (a grammar correction) rather than
to immediately give up and write in "x-to-the-m-plus-n", abandoning
the entire mechanism.

> For example, suppose an author wants to say that <msup> is a power.

Also note that the current discussion was exclusively about
mathematical atoms, such as embellished variables and operators. On
the level above, I think we also have a group consensus that operator
trees, such as <msup intent="power($1,$2)"> have benefits from being
annotated compositionally (i.e. grammatically). Benefits both for AT
narration quality and for enabling other application domains.

> They could specify that a particular example should be spoken as "x-to-the-m-plus-n". Is that good? Maybe not.
>For someone who is blind, they wouldn't know when the power came to an end if the <msup> was followed by "+1".

You mean <msup>...</msup><mo>+</mo><mn>1</mn> ? Of course the system
can take action to make it clear the "msup" has completed, the
presentation tree offers enough information there.
The problem you describe would be encountered if an author wrote
intent="x-to-the-m-plus-n-plus-1" without making clear the last "+1"
is on the baseline. And I agree: such long speech-near strings
shouldn't be encouraged, as it is easy to make mistakes, and impair AT
output quality.

But why should it be Prohibited? I can see this technique as a way to
empower an author to work around any major bugs in an AT tool, by
overriding broken bits with strings that *do* work, on a short notice.
Without having to wait on further patches from developers and updates
from their institution. It could make the difference between fixing a
large document with a few small mistakes in an hour, rather than
months.

> Another issue, which Steve might raise, is that adding "end power" (or whatever) at the end might be good for someone who is blind, but bad for someone with dyslexia. So while supplying the exact wording is good in many cases, in others, it is not so good.

Indeed, the AT software has plenty of legitimate reasons to customize,
so the structure is helpful, no disagreement there.

> Allowing an author to state their "intent", not the speech, might be better.

This is not an either-or in my proposal, so, sure. An open-ended
standard should allow both capabilities. And indeed this is the
exciting aspect of the encyclopedic naming scheme - each name *has*
both capabilities.

> But it will only be better if the intent is something the reader's AT recognizes and knows how to speak. I'm not sure how to reconcile this two ideas, however I'm slow starting to convince myself that maybe both need to be supported via an aria-label(like) attr and an intent attr that is less directly tied to the speech...
> like the approach of pointing to Wikidata that Moritz and Deyan (I think) are advocating. That (hints? suggests?) a wording, but is also something AT can know about and use its own appropriate wording based on what it thinks is best for a reader using its technology. If both are given, I would say the aria-label(like) solution should win, but as with most things, that's debatable.

I am really not sure what the confusion is here, but I'm happy to keep
hashing out the details until everyone is satisfied.

After all of these constructive comments, a final counterpoint. I am
unsure whether the "functional" suggestions work for anything beyond
toy examples. It happens way too often that very suspicious caveats
get invoked such as:
"If we exclude all exceptions which we have already hardcoded, such as
sin(), there are no exceptions".

The way I would summarize the big split here is that you and Sam have
leaned towards a "prescriptivist" stance, where the standard controls
what math syntax is allowed to exist. I have taken a "descriptivist"
stance, where I am pushing for a standard able and willing to
accommodate all math syntax that does indeed exist AND allowing
authors to state custom preferences. Usually these two positions don't
get the luxury of middle-ground compromise, but the encyclopedic
naming scheme gets us halfway there.

Deyan

>
>     Neil
>
>
>
> On Fri, Oct 8, 2021 at 1:34 PM Deyan Ginev <deyan.ginev@gmail.com> wrote:
>>
>> Hi Neil,
>>
>> 1. Yes, "natural" readings can be derived from the presentation tree
>> and Unicode, I think this is a point of group consensus we should
>> cherish and build upon. Those need no further annotation, presentation
>> MathML 3 is enough.
>>
>> ---
>>
>> 2. "B-double-prime" is already an example that is not natural, as it
>> makes a custom choice on how to narrate the variable name.
>> The "natural" choice is different, derived from walking the tree - "B
>> prime prime" or even "B Superscript prime prime".
>> (Aside: the compositional leaf narration is indeed the standard in
>> Bulgarian and Russian - "Б прим прим").
>> I think this is a great example since the entire group can follow along.
>>
>> Yes, current AT systems have a rule for double-prime. That is great,
>> since until now there was no way to annotate it, it makes sense it had
>> to be hardcoded.
>> But AT systems today don't have rules for all potentially "double-"
>> and "triple-" embellished names.
>> I tested SRE and it gave me the "Superscript asterisk asterisk" and
>> "Superscript plus plus" readings for B^{**} and B^{++}. The "double"
>> and "triple" need to come from somewhere. I can also quickly come up
>> with B^{!!}, B^{--}, B^{††}, B^{↑↑}, B^{??}.
>>
>> There are also cases where the "natural" speech will sound iffy, such
>> as word abbreviations. A paper I was debugging today had f_{att} as a
>> name for "the attention function". Maybe an author would prefer having
>> it narrated as "f-attention" rather than "f-att", which could create
>> rather unpleasant speech. In that case you would have an <mi
>> intent="attention">att</mi>, which answers your call for an <mi>
>> example.
>>
>> To my perspective, in scientific discourse a math expression is a
>> linguistic description first, and not immediately a symbolic component
>> from a computational runtime.
>> Sure, sometimes it is both, and one can enable both CAS and AT
>> applications. But if the author named a variable as
>> "B-triple-asterisk" or "B-triple-plus" or even "B-third-star" and
>> "B-third-plus", I see no reason why we should prevent them from
>> annotating their chosen name, so that the AT user can have a clear
>> common language with the author.
>>
>> I suspect this discussion could be simpler if it were a part of the
>> ARIA group, as an aria-intent would have been able to simply leverage
>> the aria-label attribute directly and combine the two paradigms
>> appropriately. Luckily we can still do this with a single intent
>> attribute, as long as we choose a naming convention akin to
>> wikipedia's encyclopedic organization.
>>
>> Greetings,
>> Deyan

Received on Saturday, 9 October 2021 17:13:17 UTC