The conformal SQL query for G graphs

Consider:
k1,k2,k3,k4@list1,list2
Trying to find occurrences of key words in two lists. Notice right away I need no blocking operators, the @ is he lightest weight operators, and will no trounce on the set operators on the left or right.

How should SQL be written against those comma operators?

How about:

insert or replace into result self.key,Link,0 from self,other
where self.key == other.key and
ResultRow() == result.rowid and
OtherRow() == other.rowid and
SelfRow() == self.rowid;

First, link, that is a field that SQL can mark up, it can actually change the property of the link and mark output as, say, unselected. Second, there needs some agreement between the SQL programmer and G about what he OtherFrow, SelfRow,.. functions do. The agreements determines the grammar and weighting properties of operators.

Everything in G is based upon a keyword match, even the rejection criteria is based on matches. So, by prior agreement, the SQL and G folks agree on how the NOT operator is managed. Select the matches, but discard them in the result, by pointer adjustment?   There is also the wirdcards, which are not realluy operators, but special keywords.  These wildcards have to have some agreed definition in terms of, like, match but pass or match but collect.  Even more are the wild cards for repeat indefinitely or just match in place.  I can see the repeat indefinitely property to support wild cards, but in version two, he queries can carry counters:
*.count++.count < MAX
Where we require the limit to be explicit. Graphs keep their own variables, who updates their values?  Probably G will do simple expression.

 SQL routines can also use filters on the link value:
where self.link & MASK != NOT;
So we want to understand how properties and operators ids are carried in the link field. The better we agree, the more likely we get some very serious SQL development behind graph query over the web.

SPARQL is almost their, they have mapped as closely as possible to industry standards, but keep pushing them and we get a complete traversal language.


So we have to understand the value ranges of operators and how can we sepate properties from function.