MathML package: Allow n-ary function definitions?

[sbmlsecretary]

The whole cell workshop happened to really chafe at the omission of 'min' as a function. Moreover, they couldn't even implement it as a functionDefinition with an overridden meaning, because SBML function definitions have a fixed number of arguments.

Allowing 'min' is of course already on the 'to-do' list, but one thing that hasn't been broached yet is the idea of allowing other mathML constructs, one of which is the idea of the generic definitionURL: we define a small subset of things this way, but one of the packages could allow arbitrary definition URLs. This would allow modelers in the future to create shorthand for functions that never made it into MathML (perhaps domain-specific things, like the NeuroML predefined functions.)

Good idea? Bad idea?

Reported by: luciansmith

Original Ticket: sbml/sbml-specifications//294

[sbmlsecretary]

This sounds like a good idea if MathML can allow it somehow.

Chris

Original comment by: ccmyers

[sbmlsecretary]

What is the current state of this? Should we put it on our agenda for the next editors meeting?

Original comment by: andreas-draeger

[sbmlsecretary]

Thanks for bringing it up.

This sounds a lot like using Strict Content MathML 3.0 (https://www.w3.org/TR/MathML3/chapter4.html#contm.strict) and OpenMath content dictionaries: (http://www.openmath.org/cdgroups/mathml.html) which I have, in the past, suggested a number of times as a possible way forward for SBML math :-)

In theory, it could be as easy as defining a MathML 3.0 Strict package that overrides all MathML 2.0. However, from past discussions it became clear that this would require a lot of effort to implement and support - especially for the SBML libraries. Nevertheless, this might still be preferable to creating a shadow solution.

Original comment by: bgoli

[sbmlsecretary]

My intention was for this to be part of the discussion of the new 'Let's include the rest of MathML' packages that are on the docket for us to work on once L3v2 is out.

I suppose a different proposal might be 'Let's allow function definitions with an aribitrary number of arguments', but I think that might be solvable in the MathML packages, too, especially since the number of arguments to a FunctionDefinition is encoded in the MathML, which can be expanded and even replaced.

Original comment by: luciansmith

[sbmlsecretary]

Looking at this again:

By making the 'math' child of a FunctionDefinition optional, if it is gone, that means that there's no way to tell how many arguments it has, effectively allowing n-ary functions... with no definition. Progress!

At this point, a package could step in and say 'hey, here's a construct that semantically replaces the 'math' child, and by the way, it allows n arguments.' Alternatively, a MathML package could introduce some new concept to replace 'bvar' that would also allow n arguments.

It's worth noting that while 'min' and 'max' are now allowed in the SBML MathML subset, it is still impossible to create a FunctionDefintion equivalent of 'min' with n arguments. (The same is true of 'plus', 'times', and other MathML n-ary constructs, though, and we've struggled on without that in the past.)

No definite proposal at this time; just a comment on the current state of affairs for this issue.

Original comment by: luciansmith

[sbmlsecretary]

• summary: Allow n-ary function definitions? --> MathML package: Allow n-ary function definitions?

Original comment by: luciansmith