I'll state the case, sort of succinctly and then I can refer back to this post.
The context is creating storage presented in the form subject, predicate, object; with ontological navigation on the subject, the the from of the semantic relations implemented as a nested graph. Under these assumptions, every subject, predicate, triple (lets call it a triple) is a subgraph, having one or more triples, that is triples can be embedded. The object is a triple counter, it counts the number of triples in the object.The goal is to create the regex of semantic relations, a convolution operator on the two graphs. This is the market, or the market that will dominate, that is my assumption.
What are some requirements? Well, locate any sub graph anywhere damn fast. Now within a local base of triples, SQL makes that quite easy, every row is a triple and all rows are indexed with a sequential counter of rowid. Named graphs are simple, because the matchable name is on the subject, and that can be indexed by the rowid. Locating the next subgraph a snap, the arithmetic is rowid + object, it lets you skip over the current subgraph. Sequencing through a sub graph is a snap counting sequential rowids.
The fundamental triple is the triplet, which contain the minimum for ontological key word navigation. Triplets become triples when we add the BSON overloads, but the mapping is yet to be defined completely.
Anyway, it is a slam dunk, why re-create the wheel. I will get back to this post and improve it and refer back to it. Use SQL as the micro-code layer.
No comments:
Post a Comment