Semantic Interpretations and Heuristics depending on Speech rules or Modalities

[pkra]

When creating "deep" speech output, I usually leverage data-semantic-prefix during navigation, i.e., combine it with data-semantic-speech during exploration. Experimenting with (Nemeth) braille output, I noticed that data-semantic-prefix has "plain English" content, e.g., "Numerator".

Assuming this is not just a bug, can prefixes be ignored for (Nemeth) Braille? Or is there some way to provide a similar benefit during navigation?

[pkra]

Similarly, is the following too simplistic?

  nodeWithSpeech.querySelectorAll('[data-semantic-speech]').forEach(
      node => {node.setAttribute('data-semantic-braille', nodeWithBraille.querySelector('[data-semantic-id="'+node.getAttribute('data-semantic-id')+'"]').getAttribute('data-semantic-speech'))}
  )

I.e., could the trees "diverge" in some way?

[pkra]

As per a conversation with @zorkow, prefix is its own modality (in the SRE sense) and Nemeth doesn't have it (so falls back to English). Since Nemeth is a print format it lacks similar indicators that would serve during exploration. I.e., it would require inventing some, ideally submitting them to the Nemeth board - which is a very long play.

[pkra]

Similarly, is the following too simplistic?

  nodeWithSpeech.querySelectorAll('[data-semantic-speech]').forEach(
      node => {node.setAttribute('data-semantic-braille', nodeWithBraille.querySelector('[data-semantic-id="'+node.getAttribute('data-semantic-id')+'"]').getAttribute('data-semantic-speech'))}
  )

I.e., could the trees "diverge" in some way?

This is now too simplistic - see #439 (comment)

[zorkow]

In principle there should not be discrepancies between the semantic trees for speech or Braille or different rule sets.
In other words heuristics should either be employed or not but not depend on the particular choice of speech rules.
However, there are exceptions:

• Clearspeak uses a naive interpretation of simple functions, i.e., f,g,h,F,G,H are always assumed to be functions unless otherwise stated via a preference setting. That interpretation is explicitly switched.
• Nemeth often emphasises the visuals, that is transcribers try to translate print as faithfully as possible into Braille. E.g., that's a reason for the cycle heuristic, where authors simply write (123). For the untrained eye looks like a single number in parenthesis, while it should really be translated into a sort of row vector (1 2 3).

Having said that, the current heuristics that fire on Braille only should all work in the general case, eventually. However, they will need some rewriting of speech rules. And I will not do that before 4.0 is out and the revamp of the speech rule syntax is complete, as the latter will make it easier to do it consistently for all locales.

[pkra]

And I will not do that before 4.0 is out

Ah, this makes me somewhat anxious since I might have to roll back to a working version.

Could you tell me when the braille heuristic for cycles was introduced? The release page does not help me figure it out.

[zorkow]

v3.2.
At the moment it looks like the revamped speech rules will be part of v4.0. Then I can merge the heuristics as well.

[pkra]

Thanks, Volker.