[Om3] Names for the OM3/MathML3 Content Dictionaries

[Michael Kohlhase]

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
----------------------------------------------------------------------