Outcomes of match

graphs continuously run insert from or select from, it is the default purpose of the machine. Outcomes of match determine when to start the Statement on a sub segment of a nest. Match also indicates when to close, any or all of te three tables.

Outcome = match(node1,node2,priors) has results: open new statements on sub graph, close one of more sub graphs on tables. Outcomes also includes the natural link overloads for table linking over g machines. Outcomes are a standard set that the mechanical pinball machine can step through, closing and updating tables, setting the next filter on the ready list. The mechanics of nested tables is a breeze, the mechanics of nested logic not quite.

Wen two graph are schema graphs, including the default schema, their outcome is the match result from the Statement execution over themselves. Schemas match schemas, even if the machine supplies a default schema for one side. Graph traversal, moving the row counters really, just happens in whatever order is on the list, everything local means any general statements on two sub segments is independent of any other. Except for nested logic, how one graph may effect matches of an enclosing graph.

Nested logic, on filter handing down inherited truthiness to a child filter. How does it work? Dunno, the code is a mass of notes, I will get around to it.

Been thinking mostly about link overloads I want to write, if the machine were in working order. I mean, writing the standard Dublin Core over sqlite3? There must be some dollars in that?