commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryce Nordgren (JIRA)" <>
Subject [jira] Commented: (MATH-237) Implement an OpenMath Phrasebook
Date Tue, 30 Dec 2008 19:47:44 GMT


Bryce Nordgren commented on MATH-237:


Perhaps both?

Certainly the registry itself should be an easily extensible framework, as you're going to
want to reuse the framework for every symbol.  The framework itself would be applicable to
other implementations as well, not just commons-math (e.g. jscience).  So the framework is
a good candidate for a sandbox project.

The bindings to commons-math, I would envision, would be statically maintained...preferably
by an item or items in the same package as the implementation to which they refer.  I would
envision "distributed" bindings which are as close to the implementations as possible, rather
than centralized bindings, all maintained in one place.

Obviously, once the first Object is returned from the system, all subsequent Phrasebook operations
on that object need to operate on objects of that type.  So the framework cannot allow a mixture
of jscience mappings and commons-math mappings and "custom user defined" mappings unless the
Objects are compatible.  So to your question of  "is it user extensible?" I would answer with
a "qualified yes".  It is extensible by clients of the library so long as the user code returns
objects compatible with the remainder of the type system.  (e.g. the user may not register
an implementation which returns a jscience object if the remainder of the Phrasebook registry
items return commons-math items;  however, if the Phrasebook is defined in terms of jscience
objects, this would be perfectly legal.)

In short, I do very much believe that there is a large chunk of logic which could be reused
by other java math projects, as well as a portion of the logic (specifically the bindings)
tied very closely to the particular implementing library.  However, as you pointed out, even
tightly bound functionality need not be maintained as the same project.  So...I may be proposing
two new projects instead of one: a Phrasebook framework project and a commons-math binding

However, if this two-project approach is taken, I would suggest that the generic phrasebook
project be (or become at some future point in time) bigger, capable of representing OpenMath
expressions in memory, serializing these implementation-neutral expressions to OpenMath or
Content MathML, and executing the expressions on demand (using an implementation-specific
Phrasebook).   This may give the project a good development arc: starting small and manageable
while maintaining a clearly articulated target for growth. 

> Implement an OpenMath Phrasebook
> --------------------------------
>                 Key: MATH-237
>                 URL:
>             Project: Commons Math
>          Issue Type: New Feature
>            Reporter: Bryce Nordgren
>            Priority: Minor
>         Attachments: OpenMathPhrasebook.ods
> The two major XML grammars for mathematical information on the web are OpenMath and MathML.
 Both grammars construct mathematical expressions using the symbols from OpenMath content
dictionaries.  A reference set of stable content dictionaries is maintained by the openmath
society, such that fixed mathematical concepts have a fixed/permanent location within their
"namespace".  This offers a unique opportunity to map the implementations in commons math
to a universal conceptual space such that users of the library can request a "concept" without
necessarily knowing what class implements it.
> A "Phrasebook" is a concept articulated by the OpenMath standard as the item bearing
the responsibility for matching a symbol in the content dictionary with an implementation
on the host system.  Including a "Phrasebook" in commons math would facilitate mapping of
the orthodox OpenMath symbolset to code provided by the library.  
> I would envision this as a registry, with the function of a multimap (unique keys/multiple
values).  Keys would be the fully qualified name of the OpenMath symbol, and values would
be the code to execute.
> Thoughts?

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message