Still think query scripts

Looking at this bag of key words:
"addressbook blanchard street washington state"

Pretty obvious I am looking for a lost address somewhere in Washington State. But it is semi-ordered, so part of the query structure is in the first position. The industry and clients strictly agree to take the first term as a hash that gets us to the entity addressbook. Event hash the first and second, weighted hash. Do they have weighted hashes yet or should I unpatent it?

So the goal, of eliminating reserved words and sticking with the uglies, may be to impose internals in the thing addressbook, internals like a schema definition. I mean sql engineers translate that query into machine language all the time.

So we can have all the key words we want, as long as they are int he data, ad we can get to the top of the data pile. Hadoop, the some new things have intelligent hash entries, they all have the same assumption, the lead semantic makes the biggest jump to a destination. The point of agreement between human and computer.

Fro the ppit of view of us all having personal Watson's then, we will all causally make thousands of lists, knowing any casual mention of a list must at least be the first key word first. It is like a Schur , the reduction, the second semantic is another independent slice of the query, the next independent variation in the answer. So its really like a pacman eating the dots, chewing through the sequence.

The Fresno design can do that, no problem. I mean, that's a natural for nested store, right? What makes it simple is mobility for the graphs, the small graph. A has table needn't do much more than launch the requesting graph through the router, no other states involves.

Anyway, this is the Watson technology, it is the one the industry wants to do.

Group by, Order by don't work well in this model, leave them out and let some genius solve it later. I think we can skip the reserved words all together.

Let's name it Shannon. We can have a Watson vs Shannon face off.