For the open source ontology engine. But, I am thinking about how we can use sqlite statements for rapid block scanning, as a seacrh traverses the mesh. Background processes that manage the mesh leave structural hints in the records, it internal to the process. These hints greatly sped up the scanning process. The trick is keeping hierarchical setting within a nested graph. The graph laid out in nested order as linear records allows sql to scan record for a blok of OR functions, say, (a,c,d,...). Sql prearranges the expansion of the syntax so a select can step through the matches. Or sql an select all matches in the and list of specified hierarchy.
If I recall, from this blog, the way we store networks in linear data bases was to point up and down the hierarchy, adding the pointer in the record set. Then reading the original tree in descending order, creating records for the sql table. So, one gets a linear instruction set, I select the tops ode of a bunch of OR an AND siblings.
A scan through some table of nested mesh yields either null or a resource pointer. The resource pointer may be another table of nested mesh. So we use sqlite to skip through blocks of nested ontology graphs very rapidly. The machine architecture becomes simple, but the function MATCH, sort of at the bottom becomes interesting.
The external format remains the same (operator|keyword|link) where link is always relative to the local nest. All entries have this form. But he functionality supports any type of language lists, like geographical terms, word grammars, any commonly used ontology can be thrown in. Any retrieval is a search term of the form : (k1,k2,k3,..).((k5,k6,..). and so on (certainly including more operators in the future). Again, XML is not the native language here, bu XML is an exchange format. What makes this work is the simplicity of the engine, and the model of semantic graph traversal with call backs to proprietary vendors functions. Hence, really a format for semantic machine instructions.
No comments:
Post a Comment