-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some specific intent examples #456
Comments
These two examples are fairly simple, but I include them just My interest is knowing that this markup is acceptable, Example 4. The expression "8 x 8" as in "chess is played
This is similar to some of the markup on lines 5-8 of the example list Some of those similar-looking examples also have a prefix Example 5: Absolute value. Exactly as here: It seems that there is no other good way to markup that intent? |
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
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 |
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
yes so using it on the mo works, or if it is non-core and you want to place it on the mrow
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"
https://mathml-refresh.github.io/intent-lists/intent5.html#IDvertxabs and https://mathml-refresh.github.io/intent-lists/intent5.html#IDxplus2timestheabsolute-valueofyminusz |
I just implemented something for David C and what seems logical is:
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 This pattern works for matrices and determinants also. For a system of equations, no outer Different topic: |
Currently a "literal" is "any name not handled by the application" so I'd expect to see a leading |
Neil has now implemented this (as 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. |
Btw @NSoiffer, don't be surprised very few entries look like concepts if you are consciously switching away from known concept names to shorthands.
|
@dginev 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 I'm not sure we'd want The (french) systeme package for LaTeX calls these |
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.
|
Since For "cases" vs "system", I really like Neil's implementation of For a system of equations or inequalities, in my work I have been A related situation I call a "derivation", as in
Unlike a |
@davidfarmer thumbs up for the mention of 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 w3c/mathml-docs#40 which got moved to a different repository, in wait of creative ideas. But having to do any additional reasoning to figure out that |
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
|
I had a mathematical conversation last week (meaning, standing around, After the math conversation ended, I mentioned our MathML discussions and Where I am headed is that there are many mathematical constructions One can use Would these go on an mrow and reference the contents, or on the mo |
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
and the other method is to use properties:
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
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? |
To me there is a very clear ARIA-like distinction: Where "contributes to X" is meant loosely as in "should take action that will impact X", and is not exclusive:
Neil's example above shows |
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 So I can have and the non-core function so 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 |
@davidfarmer I would suggest that if you can imagine |
@NSoiffer or to put it another way |
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.
|
@davidcarlisle is <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> |
@dginev no that's like the equation example Bruce just gave. [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] |
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?
|
Practically speaking there may be some core functions but all other function names are valid and read as literal, so
Obviously the list of properties that affect speech is fluid at the moment but it is currently
|
Oh hello! :>
I see. Wait, a vector in an mtable? They get spaced a bit oddly, but I guess one could try:
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 <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 |
Well, I was thinking more of:
I don't quite understand what you mean by "marker", but I think it's the opposite of what you're saying. |
a matrix of a table, being the key difference (if it's not annotated, the
|
Currently (and I think correctly) there isn't a core
There is nothing to check. Not relevant to this example, but currently the
would give is-a matrix properties on M and M* if you wanted that (but they wouldn't affect the speech) |
I'm suspecting that @davidcarlisle 's mention of |
yes exactly. I'd want |
Your always thinking of specifying text to speak ;-) |
Just that kind of a long Monday... As a token of good will, I offer arXiv:1501.06430, where you will find a function <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 |
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 https://mathml-refresh.github.io/intent-lists/core/#transpose by which Currently as seen here https://mathml-refresh.github.io/intent-lists/intent5.html#id-0-3ac78e651639dc54379e9f69563d6bd1 the property is ignored and it makes
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. |
We have been talking about "transpose" as a core intent which goes on the Is it also possible to do it as a property on the superscript? As in: We said that we don't like having two ways to do the same thing, so which of I think it is relevant that some people write the "T" on the left. One can have |
A similar but more common situation is the transpose of a subscripted matrix, in LaTeX: If I put the |
I think There are examples of 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 |
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 |
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 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> |
If we are going to put a "transpose" attribute on an I am missing what we can't do by always using the
If double subscripts need to be specified as an index, then add
The typical meaning of |
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
|
Are you saying that instead of the |
you need that anyway so the function is pronouned If transpose is core the property might be defaulted, but presumably H hermitian-transpose wouldn't be core. |
It seems workable to me to put If later it is decided that AT needs it to be on the If I also put a
does that conflict with the previous discussion about the |
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 |
This isn't so bad, and works now: https://mathml-refresh.github.io/intent-lists/intent5.html#id-0-333306ff438b6b20371f34b4e4ab2898 |
I don't like
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. |
@NSoiffer You also shouldn't like 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 |
If "index" is supposed to be a property and "transpose" is supposed to be in core
Except for saying "to the transpose", Mathcat does okay on that already. I don't see how the markup get any simpler than that. |
ooh seems possible (if a little weird). What works now and doesn't require anything in core is to use
see https://mathml-refresh.github.io/intent-lists/intent5.html#id-0-4dc5e6b2ea853d5abb0821f3494a7950 |
oh you are forcing the other nesting, we'd been assuming an interpretation of transpose of M_i not the transpose of M, indexed at i (although of course you need to be able to do either). Certainly we should be able to have a recommended markup without resorting to |
Indeed, I mentioned the alternative nesting leads to different speech here. And that, depending on how the pieces are composed together, the resulting speech conveys a different mathematical object.
A dangerous certainty. Custom ad-hoc properties can be painful in practice, since it appears hard to predict when they do or don't activate in AT, and if the composition with other partial annotations is going to produce high-quality narration (or not). In David Farmer's last example: <msubsup>
<mi>M</mi>
<mrow intent=":index">
<mi>i</mi>
<mi>j</mi>
</mrow>
<mi intent="transpose">T</mi>
</msubsup> It is unspecified/unpredictable whether transpose or index have higher precedence (both in terms of what the author meant, and how AT would combine them). For cases in the Open realm, we need the underscore form whenever a custom connector word (or several, or custom order) is needed. One could alternatively try to invent additional tiers of clarifying markup, The Separately,
The script words are a little bit like This also gave me an inkling that if someone was trying to stay close to the presentation elements So I am a lot more certain about using |
yes either we specify (say) subscript binds tightly, or we can use a functional form on the msup, nesting in whichever order is needed.
It's available if someone really wishes to force a particular word order, but forcing a specific wording is a non-aim of intent so I don't think there are any cases where using
It's an infix function for indexing I chose to call
Using a function of |
Any chance this can be softened? I would like to strive for The |
Not really, it's just a statement of fact that it wasn't an aim of the design. That doesn't mean the end result can't include a mechanism to specfy words, but any such mechansm even without the weird If |
I'm inclined to think that if you want to control exact speech and be like aria, you should use aria. That aria currently doesn't "see" the MathML doesn't seem like a valid reason to reinvent a second version of aria, but rather is a reason to get aria (or it's context) fixed. |
@brucemiller We have a mandate/preference by the ARIA group to reach parity to relevant features of it in MathML itself, without resorting to ARIA, granted to us here: The main unresolved discussion appears to be whether exact speech overrides are a requirement for MathML Intent or not. In my view they are. If the group leans otherwise, MathML Intent should have a note on inter-operating with |
We have a mandate/preference by the ARIA to reach parity to relevant features of
it in MathML itself, without resorting to ARIA, granted to us here:
I don't see a mandate for parity there, only a recognition that a MathML
specific intent is necessary.
|
Certainly it is not a requirement but all versions of intent have provided this by making liberal use of the existing freedoms. Whether it is |
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 shouldeither be on the outer
mrow
, or it should be on themtable
. (I thinkmrow
, but I canimplement 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?
The text was updated successfully, but these errors were encountered: