Openmath: a need, and potshots (fwd)
warp at polymath.cecm.sfu.ca
Tue May 6 19:05:19 CEST 1997
Seems to me that there are conflicting issues at play here :).
> RF> In work that I am doing, I would like to be able to say that openmath
> RF> represents a solution to a representation problem that has actually
> RF> occurred in some activity here. Unfortunately, each time I look at an
> RF> Openmath document it seems to fall into shreds.
OpenMath is indeed designed to solve a representation problem. It
is meant to deal with an issue that needs to be solved before all the
very useful other things that other teams are working on (including my
own) can be brought together - a common language for mathematics
that can be handled quickly, efficiently, and globally, by _computers_.
It is not suppose to be a language that humans manipulate, because,
in general, OM->Human-Readable is an easy problem, as it represents
a semantic flattening (indeed, we have OpenMath-like language->LaTeX
converters working here in PolyMath).
[ Some RF material deleted - description of what we might hope for in,
say, and OCR output]
> RF> The solution we seek is an encoding of the material we
> RF> have scanned in a form or forms that are suitable for re-use by
> RF> 1. display and re-typesetting programs
> RF> 2. search engines
> RF> 3. computer algebra programs
> RF> 4. direct viewing by humans
> RF> ..................
> TH> A minor point here: it's my understanding that your
> TH> goal (4) has been somewhat neglected in the current
> TH> definition of OpenMath for at least two reasons.
> TH> Firstly, if the OpenMath project succeeds, there will be
> TH> a good selection of both standalone display programs and
> TH> other OM-compliant applications with well-designed user
> TH> interfaces. Hence, the need for direct viewing of
> TH> OpenMath code would be rather limited. Secondly,
> TH> although the SGML-type encoding produces code that's
> TH> rather unpleasant for a human to read, it can be parsed
> TH> using existing software. Why reinvent the wheel?
Exactly. Indeed, we've worked on intelligent LaTeX->OpenMath conversion.
The big problem, in general, is getting to _any_ semantic form, which,
in general, requires a lot of understanding of context. Converting
to other semantic forms is easy. The SGML encoding just provides a
globally accepted standard of transmission. Semantic recognition is
a big problem, but it's not a problem that OpenMath is supposed to address.
It just lets those of us working on the big problems finally use our
stuff together, some day in the future.
[ Some more stuff deleted that other folks can comment upon]
> RF> The use of SGML-like syntax seems only to promote visual clutter, and
> RF> possibly the impression to <??> that something "formal" is being
> RF> stated, when the material is not.
> TH> I'm sure anyone would agree that the CD's look rather
> TH> cluttered indeed. However, there's a tool being built
> TH> to convert the CD's into an HTML format that's much
> TH> easier to read using a Web browser. Moreover, the
> TH> syntax can be parsed using existing software, as I noted
> TH> above.
SGML is just one way of encoding a semantic tree. Indeed, in any
future system, I think we can generally expect that _any_ ASCII
encoding will be little-used, and that most OpenMath transmission will
by via object-oriented networking (e.g. CORBA, RMI, etc, transmission
of the complete OM object). The great power of OpenMath is not just
communication between math input, math typesetting, and symbolic systems,
but in the creation of fully-active mathematical documents which can
be analyzed by intelligent agents, interactively used by humans,
and collaboratively shared around the world. OCR, typesetting, good
symbolics are all crucial things, especially for general use of
mathematics, but we need the glue, and the glue will let us go a
lot further, one day.
That's just my tuppence worth :). I think we're all working on very
exciting things, and issues that do need to be addressed ASAP. We're
all creating things that may have a significant impact on how science
is done around the world. Indeed, like Prof. Fateman, I'd love a standard as
soon as possible. It'd certainly make daily life in my team easier <grin>.
Stephen P. Braham _ PolyMath Project Manager
warp at cecm.sfu.ca = Centre for Experimental &
(604) 291-5617 o o Constructive Mathematics
(fax) 291-5614 Simon Fraser University
http://pdg.cecm.sfu.ca/~warp/ Burnaby B.C. CANADA V5A 1S6
PolyMath: Where Network Systems Engineering Meets Science
More information about the Om