Some specific intent examples

[davidfarmer]

This issue is to determine if we agree on some common examples of intent markup. I encourage others to describe specific examples.

Example 1: multiline expressions with a big curly brace on the left. This could be a system of equations, or it could be a "cases". For example: https://mathml-refresh.github.io/intent-lists/intent5.html#IDbracedsystemofequations

In that example, the intent is on the mo containing the left brace. I think it should either be on the outer mrow, or it should be on the mtable. (I think mrow, but I can implement whatever is better for AT.) I also think it should be a property, meaning intent=":system-of-equations", because otherwise AT has to know to treat it specially and not just say system of equations instead of reading out the contents.

Example 2: open interval, as in https://mathml-refresh.github.io/intent-lists/intent5.html#IDopen-openinvertedbracket

I think that example is good as-is. It is reasonable to expect that AT knows that open-interval is in core and that the words "from" and "to" should be added (depending on the verbosity level). If the notation had parentheses instead of reversed square brackets, the intent would be the same. We should discourage any other way of marking that intent.

Example 3: superscripts which are not powers, as in the H^2 example here: https://mathml-refresh.github.io/intent-lists/intent5.html#ID2ndCohomology I do not think either of those examples are good, because (as we discussed on a call) it is confusing for AT to say "H 2", because that hides the fact that the "2" is in a superscript (and not a subscript).

I suggest that this is reasonable: <msup><mi>H</mi><mi intent="superscript">2</mi></msup> or (which I prefer) <msup><mi>H</mi><mi intent="index">2</mi></msup> Since AT has to examine the contents of the msup, to know whether to say "squared", this markup conveys the information that the expression is not a power.

This example only works if AT knows the meaning of that intent, and that the intent value is not supposed to be pronounced literally. Should "superscript" or "index" be a property instead?

[davidfarmer]

These two examples are fairly simple, but I include them just to confirm that we agree.

My interest is knowing that this markup is acceptable, so it is okay for me to produce this markup. In both of these cases, I think that what I write is the preferred way to indicate that intent, and I suggest that the documentation should indicate that preference.

Example 4. The expression "8 x 8" as in "chess is played on an 8 by 8 grid". Note that I am intentionally using the wrong symbol for the "by" character, because the specific character is ignored by AT.

<mn>8</mn><mo intent="by">x</mo><mn>8</mn>

This is similar to some of the markup on lines 5-8 of the example list https://mathml-refresh.github.io/intent-lists/intent1.html except that I have not wrapped it in an mrow.

Some of those similar-looking examples also have a prefix pronunciation, like "product of a and b", but this "by" example only works (in english) with an infix reading.

Example 5: Absolute value. Exactly as here: https://mathml-refresh.github.io/intent-lists/intent1.html#id10

It seems that there is no other good way to markup that intent?

[dginev]

Re: "by" value

To me "by" reads like a literal, since it is an English preposition rather than a concept. So I would write that _by. Similarly, I would use _по in Bulgarian, which is the matching preposition for this case, as in:

<mn>8</mn><mo intent="_по">x</mo><mn>8</mn>

The matrix wiki article claims that "2 by 3 matrix" and "matrix of dimension 2 by 3" are synonymous, so I would loosely guess the concept at play here is "dimension". From there I could imagine a Core value "dimension" used as:

<mrow intent="dimension($rows,$columns)">
  <mn arg="rows">8</mn>
  <mo>x</mo>
  <mn arg="columns">8</mn>
</mrow>

and vocalized by AT as "by" in English and "по" in Bulgarian. In case such a value didn't make it to Core, annotators would have to resort to the _by and similar literals.

[davidcarlisle]

<mn>8</mn><mo intent="by">x</mo><mn>8</mn>

looks OK to me. If you wanted to use a more mathematical name such as dimensional-product or some such it would have to be in core so it had a rule to get read as "by" and I'm not sure what standard name we'd pick so by seems fine.

but this "by" example only works (in english) with an infix reading.

yes so using it on the mo works, or if it is non-core and you want to place it on the mrow by:infix(8,8) is same.

It seems that there is no other good way to markup that intent [ absolute-value($x)]?

Probably not. If you had some horrible mathml with a long flat mrow and no specific container for |x| and you don't want to add an mrow just for the abolute value you could do this but I'm not sure it's "good"

  <mo intent='absolute-value'>|</mo>
  <mi>y</mi>
  <mo>-</mo>
  <mi>z</mi>
  <mo intent='end-absolute-value'>|</mo>

https://mathml-refresh.github.io/intent-lists/intent5.html#IDvertxabs

and

https://mathml-refresh.github.io/intent-lists/intent5.html#IDxplus2timestheabsolute-valueofyminusz

[NSoiffer]

Example 1: multiline expressions with a big curly brace on the left. This could be a system of equations, or it could be a "cases".

I just implemented something for David C and what seems logical is:

<mrow intent='$table'>
  <mo>{</mo>
  <mtable arg='table' intent=':cases'>
     ...
   </mtable>
</mrow>

The outer mrow is the decoration that gives some meaning to the table, but it is the table itself that carries the content to speak. Hence, that's where the property makes sense. Because we lack a way to refer to the children (i.e, we decided against allowing *, etc), it can't be something like intent=cases(*).

This pattern works for matrices and determinants also. For a system of equations, no outer mrow is relevant and a intent=':equations' works. Would you find that reasonable to generate?

Different topic: I agree with Deyan that _by is probably more appropriate. However, I suspect almost any word used for an operator is really a literal and not the name of a concept except coincidentally. Hence, unless the spec works hard in some way to make it very evident that they are literals, the underscore won't get used on mos. It won't matter for the speech though.

[davidcarlisle]

I agree with Deyan that _by is probably more appropriate. However, I suspect almost any word used for an operator is really a literal and not the name of a concept except coincidentally. Hence, unless the spec works hard in some way to make it very evident that they are literals, the underscore won't get used on mos. It won't matter for the speech though.

Currently a "literal" is "any name not handled by the application" so I'd expect to see a leading _ used to force a literal interpretation used rather infrequently, mostly to avoid a core function. power(x,2) probably makes "x squared" but _power(x,2) is "power of x comma 2" if you need that .

[davidcarlisle]

@davidfarmer

I also think it should be a property, meaning intent=":system-of-equations", because otherwise AT has to know to treat it specially and not just say system of equations instead of reading out the contents.

Neil has now implemented this (as :equations) see

https://mathml-refresh.github.io/intent-lists/intent5.html#IDbracedsystemofequations

where this is used to give a "displayed equation" reading despite the leading { decoration that would otherwise make mathcat choose a "cases" reading, as seen in the (grey) column 2.

[dginev]

Btw @NSoiffer, don't be surprised very few entries look like concepts if you are consciously switching away from known concept names to shorthands. :system-of-equations was based on a search I did in wiki, where David C had also mentioned :simultaneous-equations which wiki redirects to the same concept page (it's another name for the same construct).

:equations is certainly shorter, but doesn't mean the same thing. This will be felt whenever the property gets used as an accessible description, where "equations" is a less informative description than "system of equations".

[davidcarlisle]

@dginev :system-of-equations .

Yes I wondered about that too. Also I was reading somewhere recently, but couldn't find it this morning, a discussion about how different communities use or do not use "equation" in this context to include inequalities. In tex, and in english it is sort of OK to refer to \begin{equation} x < y \end{equation} as "equation 1" but I gather calling an inequality an equation doesn't always translate well.

I'm not sure we'd want :system-of-equations , :system-of-inequations , :system-of-approximate-equations ...

The (french) systeme package for LaTeX calls these \systeme without implying what they are a system of.

[brucemiller]

I'm not sure we'd want |:system-of-equations| , |:system-of-inequations| , |:system-of-approxmate-equations| ...

Perhaps not in core, but this may also be a case where multiple properties could be useful. Like ":matrix:diagonal-matrix" or ":unit:length:si-unit" or such. This allows providing more mathematical precision for informative asides (such as tooltips), while still providing the more fundamental property which perhaps most affects speech.

I'm guessing that for most purposes, knowing that an mtable represents a "(collection of) equations" is most relevant to speech, at least in the sense of distinguishing from a cases or general matrix; whether or not they are simultaneous or a system is probably less relevant.

[davidfarmer]

Since 8 × 8 could be "times" or "cross" or "by" or ..., it seems odd to me that some of them would start with an underscore and not the others. But maybe that is the same as arguing the difference between intent="multiplication" and intent="_times".

For "cases" vs "system", I really like Neil's implementation of intent="$table" on the mrow, and intent=":cases" on the mtable. (If there is no big curly left bracket then there is no need for the mrow.)

For a system of equations or inequalities, in my work I have been using "system" in all cases. I think that intent=":system" is reasonable terminology. (Maybe I am assuming other languages have a common word for system of equations and system of inequalities.) If it is necessary to say that those are equations and not inequalities, we can just add another property: intent=":system:equations".

A related situation I call a "derivation", as in

   (a+b)^2 = a^2 + 2 a b + b^2
           <= 2 a b + b^2
           = b (2 a + b)

Unlike a :system, in which each line is an independent expression, in a :derivation each subsequent line starts with a relation and is logically linked to the previous line. That needs to be read differently because it is confusing to call each separate line an "equation".

[dginev]

@davidfarmer thumbs up for the mention of :derivation, there is a related discussion in https://github.com/w3c/mathml/issues/402#issuecomment-1188463119

In an ideal world I would expect an ambitious AT system to be aware of the common aliases used for standard constructs (as I've shown above, wikipedia is aware of some of them and adds redirects). The larger discussion about multiple possible names ties into https://github.com/w3c/mathml-docs/issues/40 which got moved to a different repository, in wait of creative ideas. But having to do any additional reasoning to figure out that :system:equations, :system-of-equations, :simultaneous-equations and :simultaneous:equations all refer to the same conceptual structure is probably a little too heavy a burden. Some broad convention may help reduce the surface of possible legal names...

[davidcarlisle]

@davidfarmer

That needs to be read differently because it is confusing to call each separate line an "equation".

https://mathml-refresh.github.io/intent-lists/intent5.html#IDalignedderivation

Currently there is no specific property, but you can stop it saying "equation" Your example comes out as

derivation of, 3 lines, line 1; .....
line 2; .....
line 3; ......

[davidfarmer]

I had a mathematical conversation last week (meaning, standing around, nothing written). The other person mentioned that something was an element of "kew root kew". The first "kew" is the rational numbers, often denoted ℚ . The second "kew" was the letter q , in this case representing an integer. The object mentioned is $\mathbb Q(\sqrt{q})$, which is notationally related to the free algebra discussed earlier.

After the math conversation ended, I mentioned our MathML discussions and pointed out his potentially confusing "kew root kew" statement. We both felt that "kew root kew" was unambiguous to anyone who was able to understand the mathematics we were discussing. (An expansive reading might be "the rationals adjoin the square root of q". It is not uncommon to say things like "Q of root q", even though saying "of" is not technically correct.)

Where I am headed is that there are many mathematical constructions of the form X(a) which are not function evaluation. Instead, that describes a new mathematical object which is a type of "extension" of X. A field extension, like ℚ(<msqrt>q</msqrt>) is one example, and a free algebra is another. Polynomial rings and formal power series are other common examples. I propose that an :extension property is sufficiently common to warrant spacial treatment.

One can use intent=":extension:free-algebra" or intent=":extension:polynomial-ring" to indicate the type of extension. Or just have intent=":extension" to clarify that it is not a function.

Would these go on an mrow and reference the contents, or on the mo and not have any arguments?

[NSoiffer]

Btw @NSoiffer, don't be surprised very few entries look like concepts if you are consciously switching away from known concept names to shorthands. :system-of-equations was based on a search I did in wiki, where David C had also mentioned :simultaneous-equations which wiki redirects to the same concept page (it's another name for the same construct).

:equations is certainly shorter, but doesn't mean the same thing. This will be felt whenever the property gets used as an accessible description, where "equations" is a less informative description than "system of equations".

I'm definitely not locked in on the names. I choose "equations" to be consistent with the other names "lines", "cases", etc., which are the names used to announce the table and rows ("3 equations, equation 1, ..."). The name of the property or concept doesn't need to match the name used in speech.

I also realized that we have two ways of doing the same thing... something that is worrisome to me since it adds to confusion ("an author will ask which is right/better?") and adds to implementation burden. One way that is pretty natural for matrix and determinant is to put an intent on the mrow as in:

<mrow intent='matrix($table)'>
  <mo>(</mo>
  <mtable arg='table'>
     ...
   </mtable>
   <mo>)</mo>
</mrow>

and the other method is to use properties:

<mrow intent='$table'>
  <mo>(</mo>
  <mtable arg='table' intent=':matrix'>
     ...
   </mtable>
   <mo>)</mo>
</mrow>

The problem cases are when there aren't "decorations" around the table to indicate that you want it read as "lines", "equations", or something else. In those cases, there isn't an mrow around the table so it would seem that only properties can be used. However, it could be done by adding an mrow just to hold the intent:

<mrow intent='system-of-equations($table)'>
  <mtable arg='table'>
     ...
   </mtable>
</mrow>

Is one easier to generate than the other? What are the pros/cons of using a concept name vs a property for these tabular notations?

[dginev]

To me there is a very clear ARIA-like distinction: matrix($table) contributes "matrix" to the accessible name for that element, while intent=":matrix" contributes "matrix" to the accessible description for that element.

Where "contributes to X" is meant loosely as in "should take action that will impact X", and is not exclusive:

• [optional] both Name and Description can be impacted, if AT desires to do so

Neil's example above shows :matrix changing the main speech (accessible name), but one could also imagine the matrix($table) variant used as a cue for AT to auto-add properties :n-rows:m-columns as a summary of the matrix, changing the accessible description.

[davidcarlisle]

Is one easier to generate than the other? What are the pros/cons of using a concept name vs a property for these tabular notations?

I see them as separate and have used both on the same term in some of the examples.

The properties are a fixed list of supported reading styles, like fixity hints, the names of the properties are or could be, unrelated to speech just as :infix is never spoken as infix.

So I can have rank($m) with <mtable arg='m' intent=':matrix'

and the non-core function rank gets read as usual, and the mtable gets read in matrix style

so rank of the 2 by 2 matrix ....

Of course some core functions may be "expecting" a matrix or a system of equations or whatever so not need the property, that's OK and same as saying some core functions default :infix or whatever

[dginev]

@davidfarmer I would suggest that if you can imagine :extension, I think it is an easy step from that to also imagine :restriction, as in $\mathbb{R}_{>0}$.

[davidcarlisle]

@NSoiffer or to put it another way rank($m) is the rank function applied to a matrix. :matrix says this is-a matrix, and matrix($m) is probably sub-optimal.

[brucemiller]

I think the "decorations" point may just confuse the issue: The decorations, as I understand it, would be clues that AT might use to infer an intent; ie. whether a construct is a cases, matrix or set of equations. However, if an intent is explicitly given, those decorations are not really relevant (other than that they may cause extra mrows).

That said, I see the concept name vs property distinction a between something function-like and asserting an isa-like property. "matrix($table)" seems to say that the thing is a matrix whose row or element is given by $table, whereas "$table:matrix" is asserting that $table is a matrix and should be spoken appropriately. The property :matrix is handy since it can be placed directly on the mtable, even if there aren't extra mrow wrappers.

Maybe an equations example draws the distiction more clearly:

<mtable intent="equations($eq1,$eq2,...)">
   <mtr arg="eq1">...

vs

<mtable intent=":equations">
  <mtr>...

So, I can potentially see that some such names may be useful both as core functions and properties, but that they'd be used quite differently.

[dginev]

@davidcarlisle is vector() also sub-optimal compared to :vector ?

<mrow intent="vector(1,0,0)">
  <mo>(</mo>
  <mn>1</mn><mo>,</mo><mn>0</mn><mo>,</mo><mn>0</mn>
  <mo>)</mo>
</mrow>

<mrow intent=":vector">
  <mo>(</mo>
  <mn>1</mn><mo>,</mo><mn>0</mn><mo>,</mo><mn>0</mn>
  <mo>)</mo>
</mrow>

[davidcarlisle]

@dginev no that's like the equation example Bruce just gave. vector there just coincidentally has the same name. The function form is taking arguments that construct the vector, whereas the matrix() example above was not taking the elements (or rows) as arguments but the whole matrix. It was not a function making a matrix from something, it is just an assertion that something is a matrix, written in functional form.

[well the names are not coincidentally the same, it is common for an object constructor to have the same name as the object but they are still different things]

[brucemiller]

On 4/3/23 12:39, Deyan Ginev wrote:

@davidcarlisle https://github.com/davidcarlisle is |vector()| also sub-optimal compared to |:vector| ?

You didn't ask me, but :>

We've been (or at least, I have been) implicitly thinking of :cases, :matrix, :equations as assertions of how to interpret the rows and columns of an mtable. So, if your example had involved an mtable with a single row or column, I'd say that they were essentially equivalent, and I'd have no strong preference.

But given your mrow example, I don't know how the 2nd case should be interpreted without searching around for things that might be the vector components; does that make it sub-optimal or wrong?

[davidcarlisle]

Practically speaking there may be some core functions but all other function names are valid and read as literal, so

vector($a,$b) will get read as vector of a comma b

:vector will have no effect on speech (but may affect other things)

Obviously the list of properties that affect speech is fluid at the moment but it is currently

prefix infix postix function silent
equations cases lines matrix determinant

[dginev]

You didn't ask me, but :>

Oh hello! :>

So, if your example had involved an mtable with a single row or column, I'd say that they were essentially equivalent, and I'd have no strong preference.

I see. Wait, a vector in an mtable? They get spaced a bit oddly, but I guess one could try:

• row vector:

  ```xml ( 1 , 0 , 0 ) ( 1 , 0 , 0 ) ( 1 , 0 , 0 ) ( 1 , 0 , 0 ) ```

• Edit: column vectors render much better

  ```xml ( 1 0 0 ) ( 1 0 0 ) ( 1 0 0 ) ```

I think another conclusion from these examples is to prefer the intent form over the property form for any "unusual" markup that is likely to be unsupported by AT.

Both your and David's reply seem to indicate this notion of a "marker" usage for intent, where "matrix($arg)" marks the inner argument as a matrix.

That's a bit surprising to me, since in my mind the function heads were always either self-voicing ("matrix of $arg") in the Open realm or "specially handled" due to Core. But how I imagined the special handling was exactly AT reaching into $arg and checking if the element is an mtable, then going through the rows and cells. Compare to a use that is not on the mtable:

<mrow intent="matrix@prefix($arg)">
  <msup arg="arg" intent="M-star">
   <mi>M</mi>
   <mo>*</mo>
  </msup>
</mrow>

How does an implementation have the right behavior without checking the presentation tree behind $arg? Or is the Core use of matrix tied to the <mtable> arg?

[brucemiller]

Well, I was thinking more of:

<mtable intent=":vector">
<mtr><mtd><mn>1</mn></mtd></mtr>
<mtr><mtd><mn>0</mn></mtd></mtr>
<mtr><mtd><mn>0</mn></mtd></mtr>
</mtable>

I don't quite understand what you mean by "marker", but I think it's the opposite of what you're saying. I would use the property <mtable intent=":matrix">... to mark the mtable as being a matrix, and use the intent form <mxxx intent="matrix($row1,$row2,...)">... to specify a matrix with the given rows. The construct matrix($m) where $m refers to an mtable strikes me as somewhat non-sensical (or unintentional); a matrix of a matrix?

[dginev]

a matrix of a matrix?

a matrix of a table, being the key difference (if it's not annotated, the mtable isn't a matrix). Also, not how I've thought about it either, mostly following up on David C's description:

whereas the matrix() example above was not taking the elements (or rows) as arguments but the whole matrix. It was not a function making a matrix from something, it is just an assertion that something is a matrix, written in functional form.

[davidcarlisle]

@dginev

<mrow intent="matrix:prefix($arg)">
  <msup arg="arg" intent="M-star">
   <mi>M</mi>
   <mo>*</mo>
  </msup>
</mrow>

How does an implementation have the right behavior without checking the presentation tree behind $arg?

Currently (and I think correctly) there isn't a core matrix function, so the above makes

matrix m star

There is nothing to check.

Not relevant to this example, but currently the :matrix property only has an effect on mtable and would be valid but ignored elsewhere, just as :infix is ignored if not used with a function.

  <msup intent="M-star:matrix">
   <mi  intent=":matrix">M</mi>
   <mo>*</mo>
  </msup>

would give is-a matrix properties on M and M* if you wanted that (but they wouldn't affect the speech)

[brucemiller]

I'm suspecting that @davidcarlisle 's mention of matrix($table) wasn't actually supporting the idea that a matrix function should take an mtable as an argument, but that several layers of counter-examples and lost context may make it look that way. My use of that sample was intended to indicate that I found it non-optimal, but that tone may have gotten lost in the shuffle.

[davidcarlisle]

I'm suspecting that @davidcarlisle 's mention of matrix($table) wasn't actually supporting the idea that a matrix function should take an mtable as an argument, but that several layers of counter-examples and lost context may make it look that way. My use of that sample was intended to indicate that I found it non-optimal, but that tone may have gotten lost in the shuffle.

yes exactly. I'd want foo($table) to be a function applied to the matrix so rank or inverse but for the suggested use of "read this table as a matrix" a :matrix property seems more natural. Going back to @NSoiffer question of whether to use properties or functions here.

[NSoiffer]

From an AT point of view, using a function head will force some speech if the function head is unknown and guide speech if known. Properties will be ignored if unknown and will guide speech if known (and appropriate for that element).

As David pointed out, something like <mi intent=':matrix'>M</mi> probably won't effect speech because an "M" will be said the same whether it represents a matrix or a function. It could be used in something like $|M|$ to infer that the speech should be "determinant of M", but if someone is using properties, they probably would have had intent='determinant($m) on a surrounding mrow. So it is likely a waste of time to write a rule to pick up that case (i.e., in practice, the property is ignored for speech).

For conceptual heads that are known, in #435 we agreed that if the known intent required n args and m args were given, then it is treated as an unknown intent (the example was "ray" where I assumed a 2-arg form and David wrote a one arg example). I think this further extends to an element being referenced. For example, if we have a "matrix" core name, matrix($table) likely only makes sense if $table is an mtable. Maybe Bruce's "mtr" children also makes sense -- the details (#of args, object it makes sense on, ???) should be spelled out in whatever core definitions (functions and properties) we come up with. If the object is not appropriate, then the function should be treated as if it is an unknown intent. I'm less sure, but I think if it has a property that contradicts its known intent (e.g, intent='matrix:prefix($arg)', then again it is treated as an unknown intent -- why else would someone add the property?

When AT reads a list, it announces "list of 5 items" so that the listener knows what is coming. The same is done for a table. Similarly, I think it makes sense to do the same for tabular items in math. Hence, I think matrix, vector, etc., should be part of core so that the number of rows and/or cols can be announced. Whether matrix, etc., are conceptual heads or known properties or both remains unclear to me, but I am clear that they need to be known in some form.

[dginev]

intent='matrix:prefix($arg)', then again it is treated as an unknown intent -- why else would someone add the property?

Aren't properties meant to be used with Core intent to modify the narration? Is factorial@function(x) vs factorial@postfix(x) or transpose@function(A) vs transpose@postfix(A) not a viable way for the author to specify a preferred reading?

The current spec test also has an example included for this question:

For example union is in the Core dictionary with speech patterns "$1 union $2" and "union of $1 and $2". An intent union :prefix ($a,$b) would indicate that the latter style is preferred.

Edit: I guess the question is if giving the Core Intent "matrix" to a variable "contradicts" giving the Core intent "matrix" to an mtable. The wiki article on matrix also has the notations $(a{ij})$ or $[a{ij}]$ to specify a mathematical matrix, but not a tabular one. Maybe these cases fit a :matrix property better than a matrix(...) intent.

[NSoiffer]

Yes to your edit: if the property contradicts what the core intent is described as doing, then I would say that the AT should follow the property rather than ignore. There is an exception I suppose when properties contradict themselves (e.g, infix and prefix) -- that case, I'd say the behavior is undefined/system-dependent.

In your examples with factorial and transpose, the speech is likely the same regardless of whether those properties or other airity properties are given and whether or not the "factorial" and "transpose" are in core (i.e., a core reading likely should allow either one). A better example would be "open-interval". open-interval:prefix likely (we haven't specified it yet) should override a core reading. Why someone would do that, I don't know. But if they did, I think the system should honor it.

[dginev]

A better example would be "open-interval". open-interval:prefix likely (we haven't specified it yet) should override a core reading. Why someone would do that, I don't know. But if they did, I think the system should honor it.

Right, I follow the reasoning, and that is sensible.

As to why one might do that, here are some motivating overrides:

intent="open-interval@prefix(_between, $a, _and, $b)"
intent="open-interval@prefix(_from, $a, _up-to, $b)"
intent="open-interval@prefix(_между, $a, _и, $b)"

[NSoiffer]

Your always thinking of specifying text to speak ;-)

[dginev]

Just that kind of a long Monday... As a token of good will, I offer arXiv:1501.06430, where you will find a function <mi>I</mi> that constructs closed real intervals over its point argument. So, while not strictly needed in that paper, an extension of that technique would be:

<mrow intent="open-interval($x)">
  <mi>I</mi>
  <mo>(</mo>
  <mi arg="x">x</mi>
  <mo>)</mo>
</mrow>

for the "open interval of x". Although this is tricky, since it's really "assigned to x" or "at x" or "around x", and I'd likely be reaching for underscores again while proof-listening.

The good news is that I(x) is perfectly readable without any intent annotations, as far as 1501.06430 is concerned, so this isn't a required remediation. Likely the mrow in this example is better helped by a couple of properties (where applicable), e.g. intent=":open-interval:closed-real-interval".

[davidcarlisle]

Aren't properties meant to be used with Core intent to modify the narration?

Er, I think so, although you effectively quoted bits from @NSoiffer and and bits from me which is probably showing some different emphasis.

Recent changes in the spec and in mathcat have brought things in to much closer alignment and I think show a path to a final workable system but we aren't there yet. The spec wording there is vague as properties were changing at the time it was written, and we have never really tied down how properties or arity affect matching against a system's dictionary.

As other parts of the spec are hopefully more stable it probably makes sense to decide what we want to happen here.

In my head, a system's intent concept dictionary can match against name+arity+properties eg a sketch for transpose is here

https://mathml-refresh.github.io/intent-lists/core/#transpose

by which transpose:function($arg) should match and make transpose of x

Currently as seen here

https://mathml-refresh.github.io/intent-lists/intent5.html#id-0-3ac78e651639dc54379e9f69563d6bd1

the property is ignored and it makes x transpose.

_($op, _of, $arg) makes transpose of x but I really never want to do that:-)

So there are certainly gaps here. We need to decide how this is supposed to work and adjust the spec to say whatever is decided.

[davidfarmer]

We have been talking about "transpose" as a core intent which goes on the msup, as in: <msup intent="transpose($a)"><mi arg="a">x</mi><mi>T</mi></msup>.

Is it also possible to do it as a property on the superscript? As in: <msup><mi>x</mi><mi intent=":transpose">T</mi></msup>.

We said that we don't like having two ways to do the same thing, so which of these is better?

I think it is relevant that some people write the "T" on the left. One can have "x transpose inverse" written with a "T" on the left and a "-1" on the right. (People who advocate for putting the "T" on the left cite that example to support their claim that the "T" on the left is better and more natural.)

[davidfarmer]

A similar but more common situation is the transpose of a subscripted matrix, in LaTeX: x_i^T .

If I put the transpose intent on the msubsup then the argument of the intent has to be the x_i, but that is not something I can directly reference. But it works fine to put the :transpose property on the mi.

[davidcarlisle]

I think transpose needs to be a function, unlike "read like a displayed equation" or "read in postfix order" it does relate to function and needs to generate translate as text.

There are examples of $X^T$ and ${}^T X$ at

https://mathml-refresh.github.io/intent-lists/intent5.html#IDxtranspose

and

https://mathml-refresh.github.io/intent-lists/intent5.html#IDxtransposepre-sup

arguably there could additionally be a property such as :annotation that tells msup not to generate superscript

[davidcarlisle]

$x_i^T$

Hmmm I put a couple of examples here

https://mathml-refresh.github.io/intent-lists/intent5.html#IDxsubtranspose

The second doesn't work at all, using a highly speculative :postfix property. Other suggestions on what the markup might be welcome.

[dginev]

To maximize the quality of speech+navigation, we would use as many references as possible and push the intent values as down as possible to the leaf nodes.

That is possible for matching up "T" and "transpose", but not for the index operation which is realized via the subscripted presentation (and i is its second argument). So "index", if mentioned explicitly, has to be annotated on the "msubsup" element.

Guessing on "msubsup" is probably too hard in general, as there are usually 2 content operations implied by the single presentation element. So the AT engine would have to guess the missing operation besides "transpose" and then guess the precedence. "M transpose at index i" and "M at index i, transpose" are different mathematical objects.

So, I would imagine:

<msubsup intent="index($op($M),$i)">
  <mi arg="M">M</mi>
  <mi arg="i">i</mi>
  <mi arg="op" intent="transpose">T</mi>
</msubsup>

and if we were indexing a specific cell, rather than a row or column, that could be:

<msubsup intent="index($op($M),$i,$j)">
  <mi arg="M">M</mi>
  <mrow>
    <mi arg="i">i</mi>
    <mi arg="j">j</mi>
  </mrow>
  <mi arg="op" intent="transpose">T</mi>
</msubsup>

[davidfarmer]

If we are going to put a "transpose" attribute on an mi, then AT has to know not to say "to the transpose", and we also will have 1-argument transpose on the mrow and 0-argument transpose on the mi.

I am missing what we can't do by always using the :transpose property on the leaf. The property causes AT to say something, which can be translated.

<msubsup>
  <mi>M</mi>
  <mi>i</mi>
  <mi intent=":transpose">T</mi>
</msubsup>

If double subscripts need to be specified as an index, then add that property.

<msubsup>
  <mi>M</mi>
  <mrow intent=":index">
    <mi>i</mi>
    <mi>j</mi>
  </mrow>
  <mi intent=":transpose">T</mi>
</msubsup>

The typical meaning of B_{ij}^T is "the ij entry of B transpose". If the author means "transpose of the ij entry of B", the typography will have to be different because a sighted person would misinterpret. Maybe {B_{ij}}^T of more clearly (B_{ij})^T.

[davidcarlisle]

On Fri, 7 Apr 2023 at 17:02, David W. Farmer @.***> wrote:

If we are going to put a "transpose" attribute on an mi, then AT has to know not to say "to the transpose", and we also will have 1-argument transpose on the mrow and 0-argument transpose on the mi.

I am missing what we can't do by always using the :transpose property on the leaf. The property causes AT to say something, which can be translated.

function names can be an open list, apart from a few core names they don't need special coding, they just get read as is. Conversely properties that affect the generated speech need specific coding. You want a small fixed set that corresponds to the style of speech. here it is not "transpose" that is the speech property as it could equally be hermitian-transpose, or adjoint or conjugate... the style/property is "postfx" so I think using :postfix is most natural, although you could say that should be the default if the superscript has an intent so perhaps

<msup>
<mi>x</mi>
<mi intent="transpose">T</mi>
</msup>

is enough

[davidfarmer]

Are you saying that instead of the intent=":transpose" property on the leaf, it would be better to have intent="transpose" on the leaf?

[davidcarlisle]

Are you saying that instead of the intent=":transpose" property on the leaf, it would be better to have intent="transpose" on the leaf?

you need that anyway so the function is pronouned transpose you (may) also need a property so it gets read as "x transpose" just as you (may) need a property on transpose(x) if you want "x transpose" rather than "transpose of x".

If transpose is core the property might be defaulted, but presumably H hermitian-transpose wouldn't be core.

[davidfarmer]

It seems workable to me to put intent="transpose" on the leaf, so I will change my code to produce that output. I like the fact that it is lower and does not have an argument. I assume AT will know not to say "to the transpose".

If later it is decided that AT needs it to be on the msup with an argument, I will switch it back (reluctantly, because I still don't see a good way to handle a simultaneous subscript).

If I also put a :matrix property on the base, like this:

<msup>
<mi intent=":matrix">x</mi>
<mi intent="transpose">T</mi>
</msup>

does that conflict with the previous discussion about the :matrix property?

[davidcarlisle]

does that conflict with the previous discussion about the :matrix property?

No, although I think it has no defined effect on an mi (so far).

As Neil merged the latest changes, the spec says this about :matrix

https://w3c.github.io/mathml/spec.html#intent_table_hints

[davidcarlisle]

If later it is decided that AT needs it to be on the msup with an argument, I will switch it back (reluctantly, because I still don't see a good way to handle a simultaneous subscript).

This isn't so bad, and works now:

https://mathml-refresh.github.io/intent-lists/intent5.html#id-0-333306ff438b6b20371f34b4e4ab2898

[NSoiffer]

I don't like index as a core name because it doesn't speak well if not known, something I think is an agreed (mostly?) unstated design principal. That leads me to think of it as a property. So my feeling is that the example is best written as:

<msubsup intent='transpose(msub($base, $sub))'>
  <mi arg='base'>M</mi>
  <mrow arg='sub' intent=':index'>
    <mi>i</mi>
    <mi>j</mi>
  </mrow>
  <mi>T</mi>
</msubsup>

where I'm assuming that all the MathML elements are in core and essentially recursively apply their rules. MathCAT doesn't do this, but I don't think it would be hard to do.

[dginev]

I don't like index as a core name because it doesn't speak well if not known

@NSoiffer You also shouldn't like power, times, plus, or divides by that reasoning.

Isn't the main point of Core to assume the values in the list are known?

In an open setting you can indeed expect:

<msubsup intent="_($op($M),_at,index,$i)">
  <mi arg="M">M</mi>
  <mi arg="i">i</mi>
  <mi arg="op" intent="transpose">T</mi>
</msubsup>

for authors that decide they want to ensure a good narration outcome for ATs that lack coverage of index.