My apologies - this landed in my Spam bucket, and I've only just seen it. I think you've misread the standard: it says ""application: the symbol may appear as the first child of an OpenMath application object", but that certainly doesn't preclude it from appearing elsewhere.
I don't understand what you mean by ""application(apply,sin,x)", which seems to have two layers of application - how do they differ? -----Original Message----- From: om-boun...@openmath.org [mailto:om-boun...@openmath.org] On Behalf Of Richard Kaye Sent: 04 May 2018 13:27 To: om@openmath.org Subject: [Om] Comments on applications in OpenMath 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 _______________________________________________ Om mailing list Om@openmath.org http://mailman.openmath.org/cgi-bin/mailman/listinfo/om _______________________________________________ Om mailing list Om@openmath.org http://mailman.openmath.org/cgi-bin/mailman/listinfo/om
