<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
> Another topic I have been looking at related to the indexing and<br>
> uuid's is the representation (reification?) of nodes, or lack<br>
> thereof.<br>
><br>
> One difference in vivace graph versus other tstores I've played with<br>
> is the ability to reference nodes as first class "things".<br>
<br>
</div>Maybe because they resolve to first class Lisp objects and don't<br>
resort to mediating the inferior objects spat out by lesser non-lispy<br>
sources :)<br>
<br>
No doubt this will eventually change once the VG2<br>
transaction/persistence/indexing stuff is better established<br>
(hopefully sooner than later).<br>
<div><br></div></blockquote><div><br></div><div><br></div><div>Ok, actually i worked out a pleasant node/namespace/package/symbol mapping automation last evening last night based on the "graph-words" which i'm using as the canonical node representation with lambdas (fdefinitions) and symbol-values to dereference and map back and forth.  It's simply housekeeping but it's convenient, even more-so than the "bang reader" macro, so if there is any interest i'd be happy to post a more thorough description or code snippet.  </div>
<div><br></div><div>I like the graph-words convention and looked a little bit into combining the above with ContextL, which i believe could be used to nice effect in order to provide a conveniently namespace-aware symbol mapping like the above, but with symbols mapped based on dynamic context established with something like a "with-graphs" macro.  ContextL is pretty fast at switching between these dynamic symbol mappings, although (important note) the packages (namespaces) themselves are static.  The "contents" (symbols) are dynamic.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
>part 2<br>
><br>
> This sort of blends into another indexing-model question, related to<br>
> the current model which is based on a hierarchical index structure?<br>
> Couldn't additional speed be achieved though multi-constituent<br>
> indexing?  IE and SP index, PO, index etc in which multiple nodes of<br>
> a single triple are hashed in the aggregate to allow for direct<br>
> lookup.<br>
<br>
</div>Having spent some more time looking at the linear-hashing papers Kevin<br>
provided I'm have trouble see this as an either/or situation,<br>
e.g. underneath its all gonna eventually wind-up as hash-tables<br>
arrays, integers and de-referenced bucket/node/leaf/offset pointers :)<br>
<br>
I'm interested to learn from Kevin how much of the linear-hashing<br>
scheme he believes is already "built-in" to the existing VG-2<br>
code-base.<br>
<br>
In particular, if most of the footwork for the linear-hashing work is<br>
already in place?<br>
<br>
And, if not whether there is some drop-in data-structure capable of<br>
implementing the linear-hashing scheme he envisions.<br>
<br>
And, if not what does he anticipate is required to implement a<br>
functional linear-hashing scheme as he envisions.<br>
<div><br></div></blockquote><div><br></div><div>So, in effect, multi-constituent indexing should be easy to tack on later down the road? </div></div>