[Om] Comments on applications in OpenMath

[Richard Kaye]

I am a big fan of the OpenMath standard.  It seems to get an awful lot
of things right or very nearly right and pushes the user/designer into
thinking in the right directions and putting down ideas in correct
(relevant) places.  The built-in redundancy (e.g. including functions of
zero arguments as well as constants) is there for good reason and this
part is well thought out.  The flexibility of CDs allows extremely
subtle semantic points to be expressed, points that (as a mathematician)
I regard as necessary options - unlike all other systems I can think of,
none of which allows me to express semantically the mathematics I
actually do.

There are a couple of issues, however.  I am coming up against them
whist writing some (hopefully OM compliant) software.  (More on this
later.)

This post concern applications, with some queries on these that I have
come across in my work.  (I also have some issues to do with
attributions but this is a tad more complicated and I haven't got my
questions straight there yet.)

Sorry if some of this has been raised before.  I didn't know where to
look.

---

To start with, it is a bit of a pity that the way the standard is
documented, and in particular the CD files themselves are written, seem
to discourage functions as first class objects. This is not a problem
with the standard, just how it is used. I certainly would prefer to work
with, for example, "application(apply,sin,x)" for some appropriate
symbol "apply" rather than application(sin,x).  (Here, sin is from
"transc1" but the same remarks apply to all the others.)

I understand from 2.1.4, "the role ... is a restriction on how [the
symbol] may be used" and "application: the symbol may appear as the
first child of an OpenMath application object", that symbols with the
application role are restricted to only appear as the first child of an
object. (In other words "may" is being used in the restrictive sense
"may only".)  In which case "application(fnplus,sin,cos)" is not
possible because "sin" and "cos" have the wrong roles.

This is not an essential point, because I can write my own CDs and
redefine everything all over again but it very much limits the utility
of the current CDs.

In any case, the fact that "application" is the exception to the rule
that says that all the derived constructs are informed by literal
symbols acting as "keys" (to attributions, binder symbols, errors) is
rather odd.  If there was a possibility to reconsider I would very much
suggest a standard "apply" symbol as above in a standard CD, and insist
that applications like all the other constructs must take a literal
symbol with the application role as the first argument.  This would make
for (a) more consistency and (b) encourage users to provide functions
such as "sin" as first class objects (symbols with the "constant" role).

This change would also signal to any user of the standards the correct
place to look up specific details.  As things stand, an expression such
as "application( f , 21.3 )" is allowed where f is one of a number of
arbitrary OM expressions.  So where does someone look up how to
interpret these expressions, especially when f is somewhat complicated?
In the OM standard itself, of course, because the key notion to
understand here is "application(". And unfortunately the details are not
explained there. However, to understand "application( apply, f , 21.3 )"
the user will of course look to the CD for the "apply" symbol in the
first instance, which is the correct place to look.  (Ideally users will
specialise "apply" to give better semantic information as well.)

If there were to be a revision of the OM standard and you were to
provide a standard generic "apply" symbol (and give the CD of course)
and say that all previously allowed "application(f,21.3)" are deprecated
but to be regarded as semantically equivalent to
"application(apply,f,21.3)" I don't think anything much would be lost
and a lot might be gained.  Just my suggestion :)

Richard