How do we know a keyword is matchable?

Dublin Core, it has to have an rdf form called matchable text. The machine doesn't care except it needs to know when the overload requires it. Right now, all keys are matchable by default, unless over ridden.

How I am seeing things.
When the general statement is running and sql requests directions from the machine the state of the ongoing binary operation @(g1,g2) is very limited, and the partitions of actions small:

The graphs g1 and g2 may be matching nodes whose respective triple are in one one or both of:

(g1.node,g2.node)
[bounded op][any] // pointers indicate bounded operator ahead
(!)[,:][any] // either or both indicae schema, set element, with or without inverse
(!)[.][.] // and so on
(!) [key][key]
[row==end][any]

This list is organized by light headedness, lighter ops are bounding ops.
OK, what are my states, really for any general statement?
{collection, uncollecting, or stopping} right, we are either continuing the descent, with or without collection, or we have sqlite_done somewhere.

So, the code can work with an expressive opcode, with enough fields to handle each of the five events, and three states; in one opcode, I hope. Hence, maybe one opcode per event, and one event per bounding operator. I idea here is to reduce, by great amounts, the amount of code I step through.

The other thing to note is that with such few events, there is a limit to bounding ops in the current hierarchy, otherwise events tend to merge. So this match structure really hold opcodes for five events taken, say in a three element ordered list, most of which are default. An event comes in, the machine steps it through 3 at most interpretations, each of which represented by a wide opcode The opcodes alter current state, adjust row pointers and check , make key matches as needed. Once the four of five constructed opcodes in the typical sub query are ready, the actual execution has the option of just binding onto some part of some opcode, in some fasion, yet to be defined. But the opcdes direct alternatives during sql runs.

But looking at intelligent sql, sql runs that recognize and handle certain events internally, the machine never sees them. Or sql man only report events that adjust row indexes, start and end. Sql really helps if it can detect when a key match is needed, and do that for the machine.

So prepping the statement. Go through a list of filters that identify the sub graphs g1,g2; and their filter is in the unready state. If syntax is correct, the filter is the bottom of a small descending chain of bounding filters, maybe two or three. The dispatcher just ascends the chain and constructs an opcode for any parent filter that has anything to say about any of the events. Push that opcode onto the ready stack, until the top filter says nothing. The opcode ready stack, then can be quickly descended on a match event, during an sql run. Find the event, in the list, it is the interpretation of that event by the lightest weight bounding modifier. Always get the shortest path to a conclusion. The event action list, by riority, is like an optimum compound statement in sql. On binds, here are options for partial processing, reduce one event to a smaller subset in a compound element, calling back to the machine less often.