A. Strotmann: Proposal presented at 5th OpenMath Workshop, Bath.
OpenMath Layer: Expression
Note: I'm still trying to find a good name for the components that make up
the expression layer. The problem is that all the "good" names I can
think of carry specific meaning in some area of mathematics and
computer science or other. Possiblities include "fundamental concepts",
"class", "fundamental mathematical structures".
- Basic "Categories"
- Constructor "Categories"
- Rules of Composition
- Representation Rules and Interpretation Rules
- Relation to Contexts
- Some Reasons
- Some Issues
For want of a better alternative so far, I reluctantly call them "category"
An SGML example
<function context=user> f </function>
<constant context=RealTrig> π </constant>
<constant context=arith> 234 </constant>
- Representation (uninterpreted data)
- Domain (or Type)
- Constant (or domain element)
- Relation (or predicate)
- Truth Value
- Conjunctions (and, or, not, ...)
- Sectioning Command
- Operation (command)
- ... others ... ?
Scope, binding, structure sharing
- Attribution (or annotation)
Expression and Data Structure
An example ("X+1000"):
expression = application
/ | \
/ | \
fn var dom.el.
+ x 1000
data-structure= ------- (i.e. non-homogeneous sequence)
/ | \
/ | \
/ | \
symb symb -----------
/ | /\ / | \ \
/ | / \ / | \ \
ctx entry ctx entry symb int32 bool vector-of-int32
/ | [.|.|.|.|...]
[where "ctx" is short for "context"; a 'bigint' is used for
i.e. the data structure level provides more detail.
Interpretation Rules govern the mapping from data-structure to
Representation Rules govern the mapping from expression to
Example representation rules:
apply(f, x1, x2, ... xn) --> (f x1 x2 ... xn)
symbol --> triple(name, context, category)
where (a b ... c) is a shorthand notation for a non-homogeneous sequence
with elements a,b,...,c .
Example interpretation rules are the inverse mappings of above rules.
NOTE: Streamlined implementations may not need to generate separate
data structures for these levels. The separate layers may either be
realized in a single complex data structure with separate fields for
the components of each layer, or the data structures and expressions
may in fact be "real" only by virtue of a calling graph of the encoding
Rules of Composition
APPLICATION of FUNCTION to DOMAIN ELEMENT yields DOMAIN ELEMENT
APPLICATION of FUNCTION to DOMAIN yields DOMAIN
APPLICATION of DOMAIN to DOMAIN ELEMENT yields DOMAIN ELEMENT
APPLICATION of PREDICATE to DOMAIN ELEMENTS yields TRUTH VALUE
- help user understand the mathematical structure of a document
without having to understand all the details
- Useful for SGML markup (see example earlier)
- default handling of 'user' or 'unknown' symbols of a "category"
(e.g. printing function symbols different from variable symbols).
- facilitate cooperation between computational logic and computer
algebra systems: Roughly, each side leaves the other's components
of an object untouched when processing, and each side may
possibly disregard certain information not in its realm when it
doesn't understand it in full detail. Similarly, a graphics
system might just disregard anything but the image data embedded.
- provide a common framework for those who need to define
model-theoretic semantics for their Contexts (e.g. ANSI working
group in the area of knowledge interchange)
- try to capture a usefully small and intuitive set of "categories"
that are pervasive in mathematical papers or software. As a guideline,
it should be hard to imagine any field of mathematics that does
not require instances of such a "category" in marking up a paper
from that field.
Is it really necessary...
Other issues include:
- ... to have more than a minimalistic expression layer (which would
just say that sequence (a b ...) represents application of a to
- ... to have, in particular, ...
- ... logic "categories"? E.g.: one could get away with just
boolean functions instead of predicates and conjunctions
- "category" APPLICATION instead of specific "categories"
such as, e.g., FUNCTION APPLICATION, QUANTIFICATION,
- ... structured symbols (we could keep that additional information
in the corresponding Context instead)
- CONSTANTS (as opposed to zero-argument functions)
- ... to consider "Is it really necessary" questions?
Some guidelines that might help decide:
- handling scoping and binding of variables and structure sharing
- are Domain and Type the same (or close enough)?
- doing it right...
- try for an "intuitive" user interface for marking up mathematical
- provide support for important clients of OpenMath (databases/searching,
typesetting, formula display, computational logic, numerics,
- not too much, not too little...
This page is part of the OpenMath Web archive,
and is no longer kept up to date.