Having heard no objections, James, Michael, and myself will continue as we
conspired, which means that Friday next week I will give an OpenMath talk via
Zoom, tentatively titled
"Complex complex domains,
and self-documentation of Formal Mathematical Properties"
From a strict logical perspective those are two separate topics, but work on
one inspired the other, so it makes sense to use the first as a case to be
studied using the latter.
I'm expecting a mixed audience, so I'll take care to both introduce the math
we'll see in the first part — concretely Riemann surfaces as domains of complex
extensions of e.g. elementary functions — and the OpenMath features that we
encounter; in the second part we will give attributions some (much needed?)
exercise.
PRACTICAL ISSUE: Should we strive for a recurring Zoom link, or generate a new
one every meeting? (Need to decide before sending out the announcement proper.)
ON THE FORMAT
This particular talk is traditional OM workshop material — presenting work one
might publish as a paper in the workshop proceedings (had there been any of
those) — but looking forward we don't have to stick to that formula. We could
alternatively name a particular area as the topic for a meeting and combine
surveys of best practices (or tutorials) with discussions on how to move
forward.
One area I think needs some attention is that of associating notation with OM
symbols. Consider the case of Dr. A. M. Athmatician, who has a history of using
computers to carry out major calculations on pure math problems; recently he
completed an impressive enumeration of all regular widgets of order 17 (or
rather, he wrote a program that did this). Being a modern scientist in the era
of Open Research Data, Dr. Athmatician seeks to adhere to the FAIR principles
by having his widget-enumerating program generate the output in OpenMath
format. (This isn't too hard, even without any OM phrasebook library, because
OM-XML is just text with a specific recursive syntax. You could generate it
even from programming languages with very primitive string processing and no
dynamic memory to speak of, if you're fine with the program being as recursive
as the output it is tasked with generating. (Of course, *parsing* OM is a very
different matter.)) This does require inventing some new symbols to state the
whole thing, but that makes sense to Dr. Athmatician: these widgets of his are
rather advanced concepts, so one cannot expect a standard to have them
pre-defined — there are professors at his department who don't grasp the finer
points of this! Having defined new symbols, Dr. Athmatician wishes to also lay
down the notation for these symbols, however for all that he looks he cannot
find any documentation of how to do that… So what would our community advise
Dr. Athmatician to do?
I suspect sTeX is by now quite big in how much notation it has associated to
semantics, so is that how we do this nowadays, or is the de facto solution to
hack XSLTs? Are we comfortable with whatever the state of the art is in this
matter? What even is the state of the art? Perhaps early February we can hear
some opinions on the matter. Or perhaps we will hear something else.
Lars Hellström
_______________________________________________
Om mailing list
Om@openmath.org
https://mailman.openmath.org/cgi-bin/mailman/listinfo/om
