Version 26 (modified by clange, 4 years ago)

AI mashup abstract

  1. Demos
    1. Predecessors (standalone, to be integrated into JOBAD)
  2. Publications
  3. Design
    1. Knowledge Representation
  4. Environment
    1. Server
    2. Client
  5. Use cases

JavaScript API for (J)OMDoc-based Active Documents

Demos

Predecessors (standalone, to be integrated into JOBAD)

Publications

Design

For historical remarks, see The original blue note

  • GUI for performing actions on selected objects
    • different GUIs for different purposes, e.g. context menu, local toolbars, global toolbar, keyboard shortcuts
      As a general pattern the context-menu can only provide access to the services that are available only on the selected part(element or a selection) of the mathematical expression like (symbol definition lookup, folding) and the services that are responsible for the expression/formula as a whole would be handled from a different GUI element.
  • abstraction layer for handling events, to be prepared for other browsers (but see Environment below)
    • e.g. Firefox can't handle events directly on MathML elements but only on document level
    • e.g. Firefox and Internet Explorer have a different representation of clicked mouse buttons in event objects (Florian knows details)
  • convenience functions/objects for frequently occurring document manipulations and patterns of information exchange with web services
  • flexible mapping of events (from the browser or from our own GUI elements) to actions (document manipulation or server requests)

Note that we rely on an expressive knowledge representation in order to enable this; see below.

Knowledge Representation

When a single OMDoc document is transformed to XHTML+MathML, as much as possible of the original semantics of the semantic markup should be preserved.

  • formulas
    • the browser displays Presentation MathML. But we assume that the semantics of any formula is available as content markup, which is interlinked with the presentation markup using parallel markup
    • The Presentation MathML also needs some structure. E.g. we should have <mrow><mi>a</mi><mo>+</mo><mrow><mi>b</mi><mo>×</mo><mi>c</mi></mrow></mrow> instead of just <mi>a</mi><mo>+</mo><mi>b</mi><mo>×</mo><mi>c</mi>, as the former indicates the nesting of terms and saves us from querying the parallel content markup for that purpose.
    • This is provided by the existing implementation of the JOMDoc renderer, but maybe details need improvement
  • anything else (e.g. document structures, rhetorical structures, not-too-formal mathematical structures)
    • RDFa, using appropriate ontologies, such as the OMDoc and OpenMath? ontologies, or Dublin Core for metadata.
    • This is not yet implemented consequently. A proper implementation via an integration of the  Krextor XML->RDF extractor with the OMDoc XSLTs remains to be done, but is considered feasible and reasonable.

If more information is needed than we have in a single document (such as declarations of symbols or notations that are not made in the same document), the client-side JavaScript needs to retrieve them from an appropriate server-side system (SWiM, panta rhei, TNTBase, …) via Ajax.

Environment

Server

See JOBADServer

Client

Our preferred browser is Firefox, because it has the best support of MathML and most other relevant standards (JavaScript, CSS, XHTML). But our API should be sufficiently generic, to be prepared for other browsers. For example:

  • recent Opera versions support MathML
  • WebKit? (the rendering engine powering Safari and Google Chrome) will support MathML some time

We do not support Internet Explorer. There is the  MathPlayer plugin, but it does not allow for scripting within a formula, e.g. handling events on elements.

Use cases

See also The original blue note (most use cases targetted at formulas)