Consider the following search in TE language:
@((k1,k2,k3,k4..),(!list0.list2:(list2!list3))
Which with some liberal inerpretation I say means, remove the words that match list 0, then select the remaining words that match the list2 schema first list2 except those in list3.
How does the G function in the open source, patent free ontology engine help here? I can mark link as selected or unselected, for example, simplifying the where clause.
where gfun(unselected,rowid); // works as a selection clause because gfun had marked the node on a previous unmatch.
But wait, that's not all that the patent free pointer function can do. I can chain the selected words as you go along, chaining the unselected together in a different list. Now, to get the next, still selectyable word, the Sql stateent need only say:
where rowid = gfun(NextAvailable,0); // Skipping over maybe reams of unselected words without having to move table around.
So this pointer arithmetic, and TE symbolic grammar makes a whole lot of sense, and potentially offers huge shortcuts. Remember, G machine only remembers the current node and one node back. It does this for three tables in the general format:
result = @(self,other);
Using gfun, G machine keeps sync with SQL procedures, they handshake. Potentially gfun can be even more powerful, chaining multiple threads of SET and DESCENTS with varying desendencies. The queries will be backed by a machine that can track schema chains and attributes sets; a chain for multiple operators. In gfun operator weights can be compared, and set closures selected appropriately. Normally I would expect gfun to fire five or more times during an update trigger. Gfuns are like the impulses of a large brain, constantly maintaining pointers and tracks. Keep it hidden in the pointer field, away from the sql side. But everyone in the environment must agree on grammar and precedence for operators.
How are my m4 macros lookin, you ask?
define(SQL_COMMA, ``insert into result select ?,?,?; '')dnl
INSTALL(COMMA,SQL_COMMA,SET_PROPERTY);
There, I have kind of a special triple language. Thee macros generate the format need for G machine to configure operators. In this case, the COMMA operaor is defined to write itself into result. I am using direct write to result from DOT and COMA operators to test pointer arithmetic.
Hows the command line?
It talks TE just fine. I can dot and comma to it all I want, and it can transapantly perform SQL statements.
The standard G machine will come with default operators and properties. The command line is always available and has access to all the gfuns. I can ype in: `select gfun(0,0); This wil fire teh gfun arithmetic from the command line, The command line input, and input from any control files, as well as any select emits, all pass through the same routine, triple routine. Then the triples are disposed of or handed of y the gh handler. I think it is bug free at the moment, except I am still playing with pointers.
No comments:
Post a Comment