Bargraphs and Semantics
- Copyright 2008 David Dodds
Bargraphs and Semantics
As you recall from episode 397 we saw the sea of angle brackets called
myfoo_barchart.xml .svg. In that file was a line '<myfoo:what>widget
growth bar graph' and in this episode we talk about that.
'<myfoo:what>' is part of an SVG Description element in that SVG
program. The 'myfoo' namespace defines a number of elements forming a
structure which packages a description of the SVG graphics in the file
which the description is embedded in. Ordinarily an SVG Description
element content is not output by an SVG displaying program, it sits
rather inertly in the text of the SVG code acting more or less the way
a Comment does in other computer languages. The SVG specification says
that both the Title and the Description element may have a namespace
used in them. It would be incumbent then upon any processor dealing
with such an SVG text file that the namespace be read as XML readers
read any namespace material. The content and 'tags' are placed into
the DOM (Document Object Model) as constituting part of the overall
XML (SVG) file. Also remember that (the SVG Title and) the Description
element may have XML IDs associated with them.
The '<myfoo:what>' is used to contain information about 'IS what', or
'IS x', the copula verb in English which is about (named) 'being' or
named 'exists x' where x is just the name or label assigned (by a
culture) to the thing or concept that 'IS'. In this case x is 'widget
growth bar graph'. So there is the suggestion that the SVG 'picture'
is an instance of 'bargraph thing'. The modifier (adj phrase) 'widget
growth'can be parsed to provide some nuance information about the
'bargraph thing'. '<myfoo:what>' is (what(ie, a description) 'is'
We can see that the system 'knows'/has expectancies about what
evidence to find/look for to confirm 'bar graph-ness' by virtue of
using the following ontologies:
The NASA JPL SWEET ontologies, in particular space.owl and numeric.owl
and also the ontology.dumontierlab.com/statistical-graph-primitive.
The system knows that using these ontologies may be beneficial to
"understanding" the SVG file because the system has found 'graph' in
the '<myfoo:what>' element content, and can use 'graph' to identify
the semantic domain to search/examine in order to 'make sense' of the
SVG file content, including the Description element and its scene-graph.
Using the PCS facility which was described in previous episodes, we
can cross-tie-into SWEET space.owl and numeric.owl because parts of
'ontology.dumontierlab' leave some important/ relevant 'knowledge'
unsaid/not explicit. We discuss this next.
(Sorry that Yahoo totally trashes rational whitespace in XML code. Ive
tried a couple of different ways to retain rational spacing and
indentation but to no avail. See PDF version of this post for decent
dumontierlab material below is Copyright dumontierlab.com
(some of the text below is my text and it is under my Copyright 2008
<!-- http://ontology.dumontierlab.com/Bar -->
<!-- http://ontology.dumontierlab.com/BarGraph -->
<rdfs:comment>A graph that uses bars to display data.</rdfs:comment>
<!-- http://ontology.dumontierlab.com/Graph -->
An information graphic that displays the relationship among tabular
numeric data and/or functions.
Well, the system is able to recognize that the text 'bar graph' from
the '<myfoo:what>' SVG Description element is the same as 'BarGraph'
in the above Dumontierlab ontology snippet.
The ontology starts off with some Dublin Core information including
that the subject is 'graph' and the format of the ontology is OWL/RDF/XML.
<!-- http://ontology.dumontierlab.com/.. -->
An ontology of statistical graphs and their components.
Notice that the Dublin Core 'description' is just a comment, a string
of text with no references to any ontology or other info-source. The
text which constitutes the content of the <dc:description> is meant
for human eyeballs only, it is only there the string of text has any
meaning. At least the system analyzing the SVG file can use the
dc:subject (graph) to determine that this particular ontology is
likely to have valuable (useful) ontological information in it
regarding the making-sense of the SVG picture. If the the human who
made the bar graph SVG description had lied and put ferris wheel
instead of bar chart things would proceed much more slowly. (How such
things are handled we see in another episode.)
Ok, so far the system analyzing the SVG file with the SVG Description
of <myfoo:what>widget growth bar graph has located an ontology
'ontology.dumontierlab.com' which says it is about 'graphs', and a
term '. /BarGraph' which the ontology says is a 'subClassOf
It (ontology.dumontierlab) goes on to show: '"./Bar">' is a
But does not provide any qualification or description of the nature of
'Bar' being a 'subclass of' 'GeometricObject.' Whereas we see that
there is information precisely about these missing qualifications or
descriptions in the NASA JPL SWEET ontologies. In a near future
episode we will continue this thread by showing what the SWEET items
are and how PCS is used to virtually merge these ontologies into one
coherent knowledge source about the SVG bar chart file and its contents.
A final thought for this episode, next (example) we see that the
ontology.dumontierlab has a provision '"./hasSource"' which associates
the 'widget growth' (text) part of the bargraph's SVG file, its SVG
Description in particular, as being the 'source' of info for the
graph. Widgets (this is stated colloquially, actually it is the
time-series of the widget values which) are the topic. Here the
'source' (of numeric data). Ontology.dumontierlab also contains
knowledge about other components in the SVG picture such as the
end-lines, the titles, the axis-labels and so on. Next episode we see
how the SVG bargraph is analyzed further; and, hence, 'made sense of'
using the ontologies above.
<!-- http://ontology.dumontierlab.com/hasSource -->
The relation between an entity and its source of origin.
Stay tuned for the next thrilling episode of Captain Semantic.