[Om3] Names for the OM3/MathML3 Content Dictionaries
Michael Kohlhase
m.kohlhase at jacobs-university.de
Mon Jan 28 07:23:19 CET 2008
Dear OM3 group, dear Math WG,
an important issue came up over the weekend, and it is so important that
we should discuss it on the mailing lists to get maximal exposure (/I am
crossposting to the OM3 and member-math mailing lists since this is
where the technical discussions happen; does anybody think we should
also involve the general OM and public W3C-Math mailing lists?/).
*Problem*: What should the names of the content dictionaries be for the
OM3/MathML3 CDs be?
Up until now, we have been operating on the tacit assumption that we
would just use the MathML CD group from the OpenMath CDs as a basis and
keep the names from that collection, and merge the names somehow with
the MathML2 token names.
[[/Background: The MathML CD Group is a set of OpenMath2 CDs that was
designed for MathML compatibility, but the design goal is seems to have
been to allow to express the same set of mathematical objects (in a more
principled way), not to make mapping simple. We are currently trying to
merge information from the MathML2 spec and this CD Group to come up
with a set of CDs that will be jointly endorsed by the W3C Math Group
and the OpenMath Society./ /See
https://svn.openmath.org/OpenMath3/cd/MathML for the current state/.]]
Now that we are discussing the specifics like the eventual names of the
summation operator we begin to see problems:
* <sum/> is an operator that takes an expression with a bound
variable as an argument in MathML2, and we would like to have
<csymbol name="sum" cd="????"/> for strict MathML3 to make the
strict2pragmatic mapping in MathML3 as simple as possible.
* <OMS cd="arith1" name="sum"/> is an operator that takes a set of
closed expressions (no bound variables) as an argument, but of
course we would like to keep this behavior for backwards
compatibility with OpenMath2.
But sumation is not the only instance of this problem; it also applies
in spirit to product, integrals, ...
[[/Background: see also issues 17, 23, 24, and 25 at
https://trac.kwarc.info/OM3/report/3/]]
In this situation, we seem to have three options
1. we map <sum/> to <csymbol cd="sum" name="XXX"/>, where XXX !=
arith1, even though <plus/> is mapped to <csymbol name="plus"
cd=="arith1"/>.
2. we map <sum/> to <csymbol cd="sum" name="arith1"/>, and rename the
OpenMath2 <OMS cd="arith1" name="sum"/> to something else.
3. we map <sum/> to <csymbol cd="sum" name="XXX"/>, where XXX !=
arith1, and <plus/> is mapped to <csymbol name="plus" cd="XXX"/>
and <OMS cd="arith1" name="sum"/> is renamed to <OMS cd="XXX"
name="YYY"/>, where YYY=sumset or something better.
All three options are not terribly attractive, in particular:
1. breaks the MathML strict2pragmatic mapping an therefore makes the
deployment of content MathML3 much more difficult, but does not
break backwards compability of MathML. We could say that it breaks
forward compatibility if such a thing exists.
2. breaks backwards compatibility of OpenMath in an unaccepatable way
3. this option is to basically invent new CD names for all the CDs in
the MathML CD Group of OpenMath2. This does not technically break
backwards compatibility of OpenMath, since the MathML CD Group
continues to exist, but will fragment the OpenMath code base, and
thereby counteract some of the benefits that we are hoping to reap
from the unification of MathML and OpenMath we are currently
undertaking.
I think we are facing a classic Trilemma here; maybe someone has a good
idea how this problem may go away?
James Davenport suggested that option 3 might be made more palatable by
introducing a new kind of FMP to content dictionaries, so that we could
write (assuming solution 3.)
<FMP type="alias">
<OMOBJ>
<OMA>
<OMS cd="relation1" name="eq"/>
<OMS cd="arith1" name="sum"/>
<OMS cd="XXX" name="YYY"/>
</OMA>
</OMOBJ>
</FMP>
This would presumably reside in the old arith1.ocd and allow people to
transparently (and maybe automatically) move over to the new joint CDs.
I am hoping for creative and insightful feedback here.
Michael
--
----------------------------------------------------------------------
Prof. Dr. Michael Kohlhase, Office: Research 1, Room 62
Professor of Computer Science Campus Ring 12,
School of Engineering & Science D-28759 Bremen, Germany
Jacobs University Bremen* tel/fax: +49 421 200-3140/-493140
m.kohlhase at jacobs-university.de http://kwarc.info/kohlhase
skype: m.kohlhase * International University Bremen until Feb. 2007
----------------------------------------------------------------------
More information about the Om3
mailing list