dginev
commented
2 weeks ago To add two more:
Entries which should be Properties
As the seeding list predates the "property" capability of intent, its coverage is too broad. An example is bijection, which is typically a kind of relation, as with f:bijection.
These should either get completely erased, or moved to a separate "Open Properties" resource.
Argument order errors
For entries with >1 arguments, it is important that the "speech template" and "notation" (Comments??) columns agree. For example, in amalgamated-product, the presentation order is A, then C, then B, so they ought to map to $1,$2,$3 (currently C is $3) with the (currently correct) speech template "Free product with amalgamation of $1 and $3 with respect to $2".
davidcarlisle
NSoiffer
Now the first pass over the open list has been made providing mathml/intent examples some general issues are noticeable that on the call of 2024-06-20 I agreed to note in an issue here.
I'll give links to examples in the open list although those links may break over time as things are adjusted. I'm listing them here as a single meta-issue rather than opening separate issues for each problematic entry as fixing the entries is probably easy once the basic principles are agreed.
Unrelated concepts with same name combined.
I don't think there are many instances in the current list but one is barrel which is used for both the archaic unit and barrelled space.
This kind of accidental clash is the easiest to fix, we simply need to separate a new row, say
baralled-spacefor the vector space concept.Related concepts combined with same concept name,
There are many more of these and more options on how to fix.
error-function has both
erfanderfcmodified-spherical-bessel-function has examples with different letters for the different kinds unlike the standard bessel function which has separate entries for first and second kind. These could be split into separate named concepts
...first-kindor an extra kind argument added so(1,x)or(2,x)that does not correspnd to an argument in the normal notation but to the function letter used.Indexed functions
There are many indexed functions say $W_n(x)$ denoting the "n-th wibble function of x" some are coded as arity 2 so
wibble(n,x)some as arity 1wibble(n)and some as both. The arity 1 form is needed to discuss the abstract function, $W_n$, the application could then be encoded using a constructed function head:wibble($n)($x)but it (might?) be more natural to allow an arity 2 formwibble($n,$x).If we want that, rather than duplicate the entries for multiple concepts it might be possible to have a meta-templace listing arity [1/2] with a speech template that makes it clear the template is "n-th wibble function" if used with 1 argument and "nth-wibble function of x" if used with two.
Sometimes there is more than one annotation so it might be arity [2/3] for $W_{i,j}(x)$ for example.
Differential operators
The markup for differentiation is being discussed elsewhere #473 and would affect some entries here
n-ary operators
The markup for n-ary operators and quantifiers is being discussed #482 elsewhere and would affect several entries here. This is similar to the indexed function case listed above as these operators typically take multiple arguments in a way that can possibly be formalised to give a mor compact listing eg arity 0
sum, arity 1sum over $Xarity 2sum from $a to $b,sum from $a to $b of f(x)... etc.Simple errors
The above describe structural issues, but apart from that there are almost certainly simple errors/typos that could benefit from review.edits. the current list has 1012 concepts and 1300 mathml examples that have been semi automatically extracted from the original sources and semi automatically converted from google docs to yaml and added mathml + intent. Some level of validation has been done but some will be wrong.