A quick recap on the open source ontology engine

Here at Imagisoft, we want to clear up the ontology issue so we can return to  imagining. So I give a quick recap.

 First what is it? Authors dump huge quantities of text into the web and the ontology engines chews through the stuff. Readers submit complicated or simple queries to the thing. Otherwise the engine itself, is a quite simple software process that runs everywhere.

• The ontology engine is open source and built on top of sqlite3
• The ontology engine performs mutual traversals between standard ontology graphs.
• The ontology engine comes with an Imagisoft symbolic algebra that allows proofing query proofing.  The language is called typeface explosion, TE for short.
• The ontology engine is extendable for proprietary applications.
• A core, but not restrictive, symbolic grammar is defined for the open source release.
• The engine handles graphs in the form of nested order semantic maps stored in sql object stores.
• The symbolic grammar allows extendable sqlite3 routines to match new operators introduced.
• One single software operation comprises the engine, the graph convolution ot two graphs.

The basic record upon which it is built, the ontology object code format, is the following scheme:'
<keyword> <link operator> <relative pointer>

The link operator conforms to a defined grammar in the typeface explosion  language TE. For example, the two main open source operators are the sibling OR and descending AND.  In TE they appear as:
 a.(b,g,t.y.u).


The open source engine supports two defined wild cards, the asterisk and the hatch, *,#

  In syjmbolic TE that would be:

*.a.(b.#.c,g,h)

But operators must also include support for script variables the (+-/*)  So, right away Imagisoft screwed up a bit, with the asterisk.  The point is, the engine and the symbolic grammar support constructs like:

(variabke=0, keyword.*.(variable++))

So the open source engine support a minimal grammar, but three essential rules make the system work. 1) The classification between sibling and descending links operators; 2), the match function that determines when two graphs agree that they match each other on a particular node; 3) All graphs must morph into nested blocks. I will define the nest block again in a moment.  I should mention one final rule of grammar,  branches of an ontology must end with a returned match value or an external link. If not, the engine will supply the default terminating match funtion.

OK , a quick example of an ontology graph in nested order:

Record	Keyword	operator	pointer
0	K1	OR	3
1	K2	AND	2
2	K3	MATCH	0
3	K4	OR	4
4	K5	AND	0

.
.
Notice I introduced the fundamental match operator? Anyway, that is nested order, the pointer allows the engine to skip over and test the ORs, or seect all the ANDs in a sequence.  Matches can often be performed within the sql with proprietary function embedded by vendors.

The engine itself simply performs G3 = convolve(G1,G2) where G1 ad G2 are nested objects as above.
G = convolve((count=0,#.count++),(a,b.c.f,n).c) = 5; G out is the graph having a single node terminating in the number five.

So we need a discussion of when the output graph, Gout, is pushed, popped or saved. The default behavior is the match result is pushed onto Gout with the proper operator link, and the relative pointer updated.  This will come naturally, I think, not much of a problem.

What does the ain loop of the ececion engine do?  Traverse G1 until a match is required then traverse G2 until it matches, and so on.  On a traversal fail, pop Gout, and jump to the next node.  On match, push Gout, and go on.  Excution of operators inks is often done by SQL instruction passes for maximum efficiency, hence we rely on TE, our grammar, as a proofing link between new operators, their sql steps.

The key to the market success of the open source ontology engine is that it is only a neuron, a little single loop  nucleus that pumps Gout on  matches between two Gins.  The amount of code is miniscule, but it works anywhere there is a sqlite3.  Proprietary vendors can extend the record definition all they want, add new embedded sql scripts all they want, add operators. Or they can add DUI, or adapt existing GUI.  It only has one fundamental variable, the nested graph. It only does one fundamental operation, graph convolution.