Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <1834213676.1230666464220.JavaMail.jira@brutus>
Date: Tue, 30 Dec 2008 11:47:44 -0800 (PST)
From: "Bryce Nordgren (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (MATH-237) Implement an OpenMath Phrasebook
In-Reply-To: <1791867474.1230410686240.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/MATH-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659906#action_12659906 ] 

Bryce Nordgren commented on MATH-237:
-------------------------------------

Hmmm.

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

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: https://issues.apache.org/jira/browse/MATH-237
>             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.