Sunday, December 18, 2011

Let them eat a byte

The amount of space the bson standard wants on the link field in our triplets. So far, the graph layer has grabbed the first byte, bson the second, and two free bytes in the total definition of a 32 bit predicate.

What can we do at the graph layer?

But, the news here, the actual graph functions only need four bits, so there are four bits to specify one of 16 different preset formats for any enclosed domain in triplet nest store. We have built in schema operations for matching, filling in, or constraining subgraphs. Just define the 16 most common small ranked graphs that might make great arguments for micro functions in ontology.
In the implementation, we just write actual c code that does the most optimum transfer of triples from the convolution to the output table. We have this capability with graph methods to efficiently built nested store on the run.

This capability makes it very handy for sql data preparers to match table schema to combinations of the preset forms, query optimization for free. Combining preset forms with the row call back function, using the pointer, the system should be very fast in all forms of EAV, SPO, ontology, or any vertical table application. At the graph layer, the micro sequences based on schema forms would closely follow the sqlite3 virtual machine model, but its schema definitions closely follow json definitions, and utilize anything the bson byte gets us.

Lets do ultra fast name value pairs

We even have the ability to link random sets of name value pairs. If the TE committee agrees on some mild opcode/pointer restrictions, then we can use the point field for a specific interlinking of name value pairs over a table. Name value triples, a one or two triple combinations, however we do it. But it becomes an indexing overlay, user defined, that can independently link sub graphs in a table. We can even resue the colon a a special name/value schema:

Name:value implies Name:(value) which is two nodes. At the graph layer we call it the immediate schema definition, an isolated atom of two triples. We can do this, it then leaves at least one pointer open for indexing according to that name, or that value, or both. (Define the default) Same rules apply, get a code snippet guy and a lawyer for the TE committee. JSON has them, so we have a good case. TE grammar can be context specific, we don't rate that a high priority. Now we have this pointer field that, in the default case, should skip through all members according to the Name and values within the name.
The thing about indexing name value pairs is that we can guarantee they are Turing complete, unless some web bot does periodic checks.

Constraints and defaults:

Build them right in using BSON expressions, which will be coming.
MySchema:(int$(_ < 4)) // I always use the default char _ when I am unsure! Do schema names have hidden counts?
MySchema:(int$MyInt < 4) // Dunno, talk to the experts

But whatever the answer, it will be tied up in what we get for a set of simple bson operations on keywords, for that defines how the graph layer can be influenced by graph variables. The best way to figure out bson expression, graph variables, sets and descents for bson sequences, and all that; is to try something and see what simplifies in the code and seems intuitive for the enlightened client.

At the graph layer, a bson sequence is simple one or more triplets with he overload active. Otheise he graph layer can match and coral bson sub graphs like any other. One issue is when a bson key word should be matcheable, generally not, I would think. So a bson expression sequence can appear in an attribute, as long as the clietn and TE committe and coding geek agree on how it makes sense.  Perhaps:
MySchema:(int$MyInt . (MyInt < 5))  // That becomes accepted syntax??

At the graph layer, no problem, it meets minimal nested order syntax.  The graph layer can even match this to anything, execute the bsons down the link, and so on.    The question is, is his how we express ourselves? Dunno, if I keep blabbing, the technocrati will eventually respond. But, et me say in finality, the pointer also offers some scoping, he idea that some aggregate variables may be defined for a table, as part of a header.  Row counts and so on.  These, could all be controlled by a javascript like system that gets the graph layer. You know, a javascript that gets how to use the pointer, gets the idea of enclosed sub graphs, a very fast javascript, one for high speed micro sequences precompiled into triplets.

No comments: