This article (part 2) continues discussion about
MathML metadata in SVG code


<math xmlns="http://www.w3.org/1998/
Math/MathML">
<apply>
<eq/>
<ci>y</ci>
<apply>
<plus/>
<apply>
<times/>
<cn>5</cn>
<apply>
<power/>
<ci>x</ci>
<cn>2</cn>
</apply>
</apply>
<apply>
<times/>
<cn>3</cn>
<ci>x</ci>
</apply>
<ci>c</ci>
</apply>
</apply>
<annotation encoding="gFortran 2008">
y = 5*(x**2) + 3*x+c
</annotation>
<apply>
<csymbol definitionURL="http://www.open-meta.
com/function_spaces.html#my_DefMajestic12"
encoding="text">
Majestic12
</csymbol>
<ci>x</ci>
<ci>y</ci>
<ci>c</ci>
</apply>
<annotation-xml encoding="OpenMetaComputing">
<OMC xmlns="http://www.open-meta.com/
OpenMetaComputing">
<OMS cd="Majestic12" name="Majic"/>
<OMI> URI=NASA.JPL/SWEET/numeric
<owl:Class rdf:about="#Quantity">
+// \ <owl:unionOf rdf:parseType="Collection">
// <rdf:Description rdf:about="#Scalar"/> \</OMI>
<OMI> URI=NASA.JPL/SWEET/numeric
<owl:Class rdf:about="#GeometricalObject_1D">
</OMI>
<OMI> URI=NASA.JPL/SWEET/numeric
<owl:Class rdf:about="#Line"></OMI>
<OMI> URI=NASA.JPL/SWEET/numeric
<owl:Class rdf:about="#Peak"></OMI>
<OMI> URI=*/myfoo_barchart.svg
<Bag>bar1,bar2,bar3,bar4,bar5,bar6,bar7,bar8,bar9,
bar10,bar11,bar12,bar13</Bag></OMI>
</OMC>
</annotation-xml>
</math>


Looking at the MathML code located in the SVG
metadata element content of the SVG barchart (shown
previous part of this article) we see that there are two
annotations there. Annotations may have an encoding
argument which indicates the name of the encoding
used in the representation appearing in the content part
of the same annotation element. The first annotation
shows a Fortran assignment statement. It says that
(the variable named) y is equal to the quantity
calculated on the right hand side of the equal sign.
In Fortran * means multiply and ** means to the
power of. Fortran is specially good at fast efficient
programs for calculating mathematical things,
benchmarking even better than C++. Of course a
wizard mathematician who also happens to be an
especially good assembly language programmer
might be able to best even Fortran code. Few
such people exist and are terribly expensive to
utilize and so Fortran sits on the top of the heap
for mathematical type programmming. There is a
plethora of Fortran code available in Fortran for
calculating just about anything. Library after library.
C++ programmers can code mathematical things
too but NASA, JPL, Boeing, McDonnel-Douglas,
CERN, etc etc have stayed with Fortran. When GCC
is used to do the Fortran (gFortran Fortran 2008) it is
possible to combine mixed code into one executable.
gFortran could have C code, Java code in it forming
the executable. There are of course interesting libraries
of code in C and in Java which this opens up usage of.

Following the first annotation we see there is a csymbol
element. the purpose of a csymbol element is to allow
MathML users to introduce symbols (the calculations
which the symbol stands for) which are not already
defined
in the standard MathML symbol set. (The standard
MathML symbol set can be seen in the MathML
Specification documentation.) In this case we see that
the Majestic12 symbol is added to the standard
MathML symbol set. The encoding shown is text,
like it says. What the symbol 'means' is depicted by
means of the material referenced by the definitionURL.
In this example it is a part of an html document (text).
We will look at this material in another article on that
particular subject. Also part of this csymbol element
is a set of arguments; x, y, c; which perform
functionality like variables in a programming language.

Following the cysmbol element we see a second annotation.
This annotation has XML in its content and MathML
spec says to use an annotation element indicating so,
annotation-xml. In this annotation we see that the
Majestic12
symbol is linked with elements from ontologies. In this
case it is the numeric ontology which one of the dozen
ontologies comprising the NASA JPL SWEET. In future
examples we will see other ontologies referenced including
those in addtion to the NASA JPL SWEET. From the
numeric ontology we see that there are four items
specified in this annotation. They are: #Quantity,
#GeometricalObject_1D, #Line, #Peak. These four
numeric ontology items have meaning by virtue of the
graph structure associated with their occurrence in the
ontology. In another article we will see how this graph
is made explicit by converting it into equivalent
natural language statements. What these four numeric
ontology references convey is that the calculation
(y = blah blah) is a *"#Quantity*, in English it's a quantity.
It is also defined to be *#GeometricalObject_1D*,
a geometrical object having one dimension. This is a
different concept than being a quantity. A reasoning
program could put the two together and figure out that a
quantity and a one dimensional geometric object represent
the same thing. Big news to a bunch of organized sand crystals,
but part of a huge repretoire constituting what is called common
sense to you and I. Also, simultaneously, the MathML depicts
a line and a peak.Since no one is home in the computer it has
to apply reasoning program to 'realize' that a line and a one
dimensional geometric object are 'the same' concept.
The term peak, for humans, has at least two meanings / uses:
the greatest magnitude element of a set of (numeric) elements,
and also the physical location of a physical entity (which might
be a drawing) which REPRESENTS the greatest
magnitude element of a set of (numeric) elements [depicted
via spatial location in a coordinate system].
By allowing the computer to 'realize' by virtue of this
annotation element, that these things
(#Quantity, #GeometricalObject_1D, #Line, #Peak.)
are 'equivalent', in the sense of being simultaneously true,
the computer can 'realize' (detect in the ontologies).
In English we'd say that the numerical value calculated by the
equation to get Y 'is' / represents the peak (top) of a / the
bar. The quantity is also a line, a one dimensional
geometric object. (The bars are 2D in the picture because
a bar graph comprised of one pixel thick bars is much less
visually appealing than the same values as bars with a coloured
fill.) We see similar numerical <==> spatial concepts explicitly
shown in the dumontierlab ontology (that was discussed in the
article on the meaning of the bargraph visual elements).
The annotation element example also contains a URI to the
bargraph.svg itself, where the IDs of the particpating items
(the bars) are named in a bag element (like a list, used in
DAML). In other articles we see how reasoning programs
are able to utilize these metadata contents to 'see' / 'figure out'
a number of interesting things. A discussion of the discovery
program BACON is part of that.