Indexing on my mind

I have to deal with it sooner or later. The engine itself won't do it, there will be special operators run after and occasionally that maintain the indexing tables. But just to get things in and out I have to sort of get indexing, so as to avoid messing with stuff the smarter than I will do. Think of names from the ground up. Local names are consumed on Json input, they are for the engine itself. Once one or two triples hit the default graph layer, then what is a name?

The graph layer sees name:value. Assume value is a primitive, then the name is then, inserted into the default local indexed name list. So, that name has to be inserted somewhere, by someone, other than the engine software geek. Like managed with a preconfigured/ installed sql operation sequence.

Then that name will reference the value, by table:rowid whenever the name is used. That is going to be part of the match function, how will the underlying sql code do it faster? Hmm...

I think some ingenuity and patent opportunities should drive that solution. It stretches my ability.

But I think this works. Sql experts write a default sql routine that inserts names value pairs into the local index table. The default grammar executes the operator when it has to deal with the ':'. Then there is another sql operation called look up, and this can be called when the default grammar has to do the match.

What is the difference between an attributes with constant names, vs a named value?
Dunno, still learning that myself.