I must have built a SPARQL machine

Or else the SPARQL folks are getting their research from the same place I got it. But G machine does a SPARQL architecture, once mapped properly. The keywords select, where are buried in the operator script and operator properties. They introduce the match operator, ?, which G machine hereby adapts, thank you very much.  They have the schema operator, :. I don't have to go far to pick these operators,  we have adopted an informal consensus in the industry.

SPARQL adopts the temporary solution to regex, the byte level search and replace. They just adpote the standard as an operator. We want to move beyond that, selecting a common operator set regardless of the byte compaction.

Their language makes clear the SQL engine underneath, like the G machine they intend adapters to graft ontology grammar onto table stores.  I see they use sql compound operators to designate alternative outcomes.  The intent of G engine is to remove the traces of tables, let the sql programmers go hog wild underneath, generating sql microcode.  Keep that entirely separate is the function of the new language Typeface Explosion.  Incomprehensible strings of text is the standard in graph traversal, deal with it.

The important thing here is that SPARQL is a target market for G machines, and the G machine is free source code (280 lines of engine), comes with a TE compatible interface, uses sqlite3 and can implement SPARQL.
Now G machine only generates tripple formatted graphs in G format, same format as its input.  So,  when the where clause of SPARQL  list a series of matches,  in G the where clause is becomes:
where descending_matches;  The entire were close driven by the Gfun call backs on descending_node and maches. The general is always:
insert into result select key,link,pointer from self, other where...;


Underneath,the G machine maintains the match rowids at the last match point. Also, the queries are built around the match of one graph to another. So, formally, the G machine and the SQL programmer understand the grammar of start and stop, as built not TE. So underneath the where clause is even simpler because it ultimately involves an operation specific match on identical triples. So the form is constant, only the match mask is relevant. The matching masks are set by prior agreement in the properties of operators. So any call to gfun of the form:

where matchop(triple:self,triple:other);
can be made to work.  Mainly because a prior call to gfun allowed gfun to pick off the match properties of the controlling operators on either graph.  Seriously, adopt this approach, adopt some form of TE, and then boom times on the web.