The ontology framework depends on gfun for pointer control in nested formats. The gfun keep the finite state of the last match point for the three triple tables. It ust deal with descending weights, or perhaps utiple property chains as SQL skips, but its total vaiable set looks like:
Each of the three tables have something like:
current match rowid, operator, current match mask property
all in the G machine at any given time. So there is a limited matrix of possibilities of how the gfun should perform for any given call. The calls to gdun likely limited to around ten major calls differentiated with two two three variable. A lot more possibilities of manipulating the limited state information. But the limited et of grammars that we want to support makes it very possible for gfun to have a look up table, something which can be proven, outside of gfun, to be complete.
The goal here, for software, is to break out gfun into its own module. It is a self contained messaging with SQL, stateless, and via a table may contain all the control G needs ( along with sql operator installs). I can get this thing very close to SPARQL because the basic flow in G has all the paths and control loops. Break out the gfun, combined with operator installs, and tackle a SPARQL implementation.
Why not? make it part of the gfun test and expansion plan for the next day or so.
No comments:
Post a Comment