Friday, December 9, 2011

Implementing the subject,predicate,object clause

Having the basic machine, we decided that all the action was in the 35 lines of unwritten, undebugged match. We claim at Imagisoft, that everything below match is structurally indistinguishable from a mechanical pin ball machine. The ready loop simply flushes tables (performs update, close, append) as requested by match. Then the ready loop finds the ready graph and runs the general select or general insert into for advanced sql script. Reminding everyone, sql and overloads should write directly into result, and SQL may run thousands of rows before reporting back to G.

Anyway, it the pin ball machine.

We are left with this idea that we can kick out of the loop at match, and run a standard Dublin overloads on the link element. What over load? Things like rdf:int maybe, or rdf:name, I think they had. Another was rdf:creator, I think that was God. The rdf overloads lead to a dll call, and the routines in that dll have access to input tables and output tables, all tables, what we said? as many tables in any order from as many convolutions in any nested order that the human can dream in TE. All available to the kickout routine, supplied by third partys. Most kickout points likely make a large list of proprietary triples available in one of the tables.

Not a problem, hey, give me a constructor for a bio-ontology, and run with it. What else can we kick out at match? Table and URL jumps. How does a URL jump work? Another machine somewhere becomes a nest in this machine graph. This machine delivers the nested strand that jumped at a match point, again, self directed graphs. No brainer, open a connection to the other machine, ship over the graph with a return URL, then this machine can continue playing pinball. No ned to tack connections, just close the connection and pretend it never happened, match should make sure all tables preserved. Eventually, a g graph arrives, but they arrive all the time, so just give it a truthiness filter and let it run general selects.

From the pinball perspective, we are simply playing relay ball, a form of mechanical pinball for multiple players. So, hey, URLs a snap, a days work, hell, didn't we do this exact thing on this blog a few months ago?. What do we call? GetXML? Not when the machine is just next door. G machine may simply be connected via digital exchange switches, digital thingies that just switch the inputs and outputs of G risk machine, with parallel channel. So, no XML won't work for machine to machine exchange. Nor will HTML. What else is there? There is ftp, a great tool. There is network file system, not bad, and their is raw, get me raw, lots of raw where the fiber is clear all day. Get G talking going just after error correction in the channel.

Hmmmm. My thinking is leave it to the network file system, and get that system to switch faster.

But tables!!! Local tables, lots of local tables, square tables, nested tables, hybrid triples with row extensions, give the g machine every damn table you have. And these will kickout with the new table overload, my favorite. Give me an rdf for that! Say, how do we translate rdf into the upper three bytes of link? Or do we go to 64 bit? Hmmm...

But, I hereby define the table overload, and give it an rdf as int rdf:table, or was that rdf$table? Doesn't attribute mean operator overload? Dunno, past my pay grad. But her at Imagisoft, we will imagine an rdf for table, maybe even one for square table, for hybrid table. And we will imagine a table graph, one that describes tables! Not a problem:

tables$MyGraph,... And lickidy split, on the match we just swap in the table, install the operators and run self directed general selects into the pinball machine.

No comments: