In science and engineering mathematical models are increasingly important to describe natural phenomena and design artifacts. Our goals is to make the notion of “mathematical models” more explicit and precise as well as to build up knowledge repositories for searching, exploring, combining, and sharing models. With the Web of Mathematical Models, WoM, we provide a platform to host such models on the Web. Models follow an explicit, content-related schema.
2. How to manage and present them in an open model platform?
To answer the first question, we established a small initial user community of applied mathematicians and identified the following requirements:
A model should have an informal description that introduces the model and explains which phenomena or artifacts are modelled. It may be supported by graphical or video visualizations of the model.
A mathematical description characterizes the model in terms of its mathematical properties. It explains the parameters of the model. In principle, it should be expressible in a formal language. Software support allows simulating the model with different parameter settings. The software should be realized in a component-based way such that models can be composed.
Linking and metadata relate the model to other models and related documents, and provide support for classification and structured search.
These requirements are fulfilled by an XML-based schema. This schema does not only structure the model definition, but also relates it to visualizations – graphics or videos – and (interactive) simulation programs. It supports two kinds of simulations: pre-fabricated simulations that are embedded into the Web user interface and create – based on a set of parameters – a result, e.g., a picture or a movie, and open simulation programs that are embedded into an interactive environment, which allows the user to experiment with and to explore the model in interactive sessions.
WoM provides the possibility to integrate remotely usable simulation programs without in-depth knowledge of Web technologies. Since we anticipate authors to be mathematicians or engineers, but not Web developers, we expect that WoM simplifies the publishing of models for them.
To answer question two, we identified four requirements which enable us to store, relate, query, search, use, and compose models:
Community support: Construction, collection, classification, and linking of models is only possible with support from a user community. Accordingly, the platform should encourage participation, and foster the development of a self-sustainable community.
Model construction: The platform should support the schema-conformal construction and modification of models. It should combine Wiki functionality with an offline editing possibility. In particular, models need a declarative and platform independent representation that can be downand uploaded.
Web accessibility: Models and all their functionality should be accessible and usable on the Web. In particular, simulations should be possible without download and shareable between users. Evolvability: To stepwise realize our vision, many changes of the schema for model representation and ontologies for classifications have to be managed in the future. In particular, the existing model representations have to evolve together with the schema and ontologies in a consistent way. This is only achievable with mechanical support by the platform.
Addressing these last four requirements, we developed a web-based model platform1. It is centered around a repository for our schema-based model representation. We expect the schema to be crucial for evolvability.
Web accessibility is ensured by the integration of the ALOE system into the WoM infrastructure. ALOE2 is a web-based and generic social resource sharing platform developed at the Knowledge Management group of DFKI3. ALOE allows contributing, sharing, organizing, and accessing arbitrary types of digital resources such as text documents, music, or video files. Users are able either to upload resources or to reference them using URLs. Furthermore, the platform offers common user management features and Web 2.0 interaction possibilities like tagging, rating, and commenting on resources.
This paper focuses on the schema used for the representation of mathematical models (Section 2). It
extends the overview paper [
Our approach is built around a structured representation of models. Based on an XML-based schema, we started to build up a model repository. Having an explicit, content-related schema distinguishes the approach of WoM from classical Wiki platforms and enables stronger computer-support for model use and management. The schema is called XModel Schema and is internally defined by an XML Schema. LATEX serves as the default input language – in particular for formulas. Thus, we provide a LATEX implementation of the XModel Schema. Future versions may also support other input languages like MathML. In this section we introduce the current state of the XModel Schema.
The XModel Schema defines an XML representation of a model. The components of an XModel – an instance of the XModel Schema – are shown in Figure 1 and described in the following paragraphs. Describing a Model. Besides a title, an XModel essentially consists of an informal description and a formal description. The informal description is basically a textual representation of the model. It is a compound of paragraphs, lists, (simple) tables, and images. In addition, elements to emphasize content and for referencing are supported as well as mathematical expressions. Although they are permitted, these expressions do only have a descriptive character and are not associated with any special role.
In contrast, the formal description defines a model using mathematical expressions, which have special meaning. They are used to define the model’s set of input parameters I, output parameters O, and miscellaneous parameters M. The latter may serve as constants or other variables. Each parameter is defined by a name, a domain/type, and a short textual description. These parameter blocks are followed by the model’s definition, which describes how the model is implemented using the beforehand defined parameters. Therefore, this consists of text content similar to the informal description’s one. To (re)use these parameters, special elements to refer to a parameter’s name, domain/type, and description are added (parameterName, parameterType, parameterDescription). But the essential part of the definition block is a set of model equations/formulas R that define the relationships between the parameters, such that for each o 2 O at least one equation/formula r(I0 [ M0) 2 R exists with I0 I and M0 M. R may also contain equations/formulas that allow to bind some miscellaneous parameters m 2 M for further use in other equations.
1A snapshot of a development prototype is available here: http://angren.cs.uni-kl.de/WoMstatic/. Use womguest as username and password to login.
2http://aloe-project.de 3German Research Center for Artificial Intelligence
model title keywords status relatedTo
history * naPmareameter domain/type description <<reference>> simulation * program resource type program parameter name position description visualization
* author contributor
editor holder of rights * * * * * AMS
*
Visualizations and Simulations. In addition, a model may contain visualizations and simulations. The
visualizations can range from simple images to complex videos. Simulations are provided by software
packages that allow for online experimentation with the model. They usually take some input
parameters and – in the case of pre-fabricated simulations – return an image or video as result. These program
parameters should correspond to the (input) parameters of the formal model. Therefore, the formal
description’s parameters can be referenced by the program parameters. Thus, the program parameter’s
role (name, description, and possibly domain/type) can be easily inferred. In addition to these
correlated parameters, a simulation may also have parameters to control particular aspects of the simulations.
Currently Matlab- and Sage-based simulations are supported. The Sage framework [
While the previously described way to use simulations by referencing an external program resource, for instance a Matlab or Sage file, is already supported by the WoM, we are currently developing modelembedded simulations, which are (Sage-based) programs that allow to define a simulation directly inside the XModel. Therefore, the XModel Schema allows code snippets that are parts of the formal description’s parameters and equations/formulas. An accordingly extended schema is depicted in Figure 2. It shows the extension of the parameters and equations with the new element simulation code that encapsulates the additional code. Using IDs, each simulation code element is associated with the simulation to which it belongs. Because the order of the snippets in the description may be different to their order in the program, additionally, each simulation code element has to be numbered. For code, which does not
formal description directly belong to a formal description’s component, such snippets can be defined within the body of the corresponding simulation element.
Metadata. The XModel Schema also includes metadata such as the model’s authors, contributors,
holders of rights, and editors as well as keywords, the model’s status that can be stable, experimental, or
checked, and a bibliography, whose structure is based on the BibTeX syntax. Using a classification, a
model can be related to standard classifications. Currently, WoM supports the AMS 1991 Mathematical
Subject Classification [
The XModel Schema is designed in a way that allows to evolve the models over time. For
example, models may be classified according to a new classification ontology or may be extended with new
simulations and visualizations. Of course, changes in other parts of the model are possible as well.
Consequently, a model may have different versions and provides access to its history.
Processing an XModel Document. As mentioned in the beginning of this section, we currently
provide a LATEX document class, which roughly describes the syntax of XModel. The LATEX source is
translated into an XModel document. Because of that, LaTeXML [
LaTeXML BibTeXML XSLT
XSLT
XSLT
In Figure 4, the result of such an additional transformation is shown. It exemplarily illustrates the
XHTML representation of a model for the “Horizontal Shot”. Furthermore, it shows the integration of
a pre-fabricated Matlab simulation in section 4. Simulations. A separate link to a corresponding Sage
simulation is shown at the end of that section. Figure 5 gives an impression of the Sage interface.
Several communities work on different aspects to support math in the Web. Some of them focus on
providing visual aids for mathematical algorithms, like the proprietary platform available under [
Another approach are math-related Wikis, which are based on several freely available software
projects. A wide range of them use the OMdoc [
Services. They are linked via keywords or explicit user input. This project’s main goals are on-the-fly conversion of units, and document visualization style. Neither interactive models nor structured models are provided.
The PlanetMath project [
Platforms like ActiveMath [
While the WoM and the OKSIMO project (formerly known as Planet Earth Simulator [
In summary, the described approaches have different focuses, but usually share some technical aspects. For instance, JOBAD uses a similar model repository approach, namely TnTBase – a database assembled from Subversion and Berkeley DB XML. Except platforms aiming at formalizing mathematical expressions, all (web-oriented) platforms support LATEX-based inputs without any pre-defined additional structure. A distinguishing feature of the WoM approach is that it supports its models/entries by an explicit schema. 4
We introduced the Web of Models, a platform for storing, searching, exploring, and sharing mathematical models. In this paper, we focused on the structured representation of a model as an instance of the XModel Schema. It defines the scope of WoM and, besides others, allows to classify models as well as relate them to each other. It standardizes the model’s structure and thus improves model consistency. It allows to integrate simulations whether as references to an already existing program or directly inside the model’s description via model embedded simulations. With the help of such simulations the user can explore and experiment with the models. Created from a LATEX document an XModel instance can be transformed into different representations like XHTML. Finally, XModel is the cornerstone of WoM, of the model platform built around, and for all available transformation and processing options. Moreover, it supports any future evolution steps by automated processing capabilities.