So the schema operator as I see it

It overloads a graph g to match only by schema id, but collect the data; in it default operation. So:
_:(A,B.C,E)

Is, as follows, the null key word and schema link applied to all of key words in the nested order on output. (default). Schemas can nest, why not.

How is it used?

_@(_:(A,B),Somelargetable)

How might one declare a schema on an existing graph?
_:(A,B).(Graph)

Some of this is immaterial to the machine, as all it wants is to make sure the current schema populates a nested order, so it can descend it predictably as it picks off the columns of SQL.

But this is not difficult. The g fun has been outfitted with a column scanner by name in the call back. So all it really needs is to pick off the schema names in order. Collect the row, and then just execute the schema sequence and let it pick off the columns it wants.

So, I riged the machine so that the main execution unit is both re-entrant with respect to the c code ad with respect to the table. At any given time the call backs can switch the controlling triple store fro one of three, the config, self and other stores. Since each are descending, and since the schema is light weight, I can re-run schema pattern straight from the table it appears, over and over again. The machine already support subroutine calls on tripe sequences.

So for now, a schema is an executable sequence in a G graph, not a problem, the machine will handle it naturally.