Dealing with large square tables by tagging them with triples

Existing, large application specific tables should be expanded because G machines can make them look like nested order with triple tags.  Then, using case statements, the sql sequence can further direct the match to a nested order selection of  one column.  So there is a general form for specifying the nested order of columns, existing tables have interfaces written with case statements, and these sql sequences can overload the normal set and descent operators.  The rows themselves indexed in nested order with a triple per row.  Ontology tagging makes proprietary tables more popular, makes it possible to have as many row and columns in any nested order, post defined on existing tables. So again, we have the grammar issue.  We can force the nested order on rows, or select from an existing nested order.  Operator weightings and names space agreement comes up again.

The other thing about proprietaries, they can run their own G machine and overload all the operators, even overload the alias tables, as long as they conform to graph syntax at the match points.

We need the definitive typeface definition that takes us from the bit graph to the world graph, something we can all write to.