<div><br></div>I am still reading though all the homework recommended in recent posts :)  Really good stuff.  I hope my questions are not a distraction from the important topics at hand but just contribute toward general discussion and (at least my) understanding of the project, its goals, how I can utilize VG and perhaps, in some way, try to contribute to the effort, if possible.<div>
<br></div><div>part 1<br><div><br></div><div>Another topic I have been looking at related to the indexing and uuid's is the representation (reification?) of nodes, or  lack thereof.  One difference in vivace graph versus other tstores I've played with is the ability to reference nodes as first class "things".  This is called a "node" in wilbur, and is represented by a simple object composed of the canonical identifier (uri-namestring) and a flag to indicate "resolution", which, for wilbur, indicates identification to a short/long namespace mapping, but I think the concept can be extended to also perhaps refer to hashing or other deferrable operations.   In the Directed Edge model, nodes are apparently considered "Items" and have a somewhat richer archetype.</div>
<div><br></div><div>In VG, this is not the case?  Triples are (currently) represented by time based uuid as previously discussed, and nodes themselves are not hashed and indexed.  Maybe this is going to change naturally in the course of moving to v5 uuid?  </div>
<div><br></div><div>part 2</div><div><br></div><div>This sort of blends into another indexing-model question, related to the current model which is based on a hierarchical index structure?  Couldn't additional speed be achieved though multi-constituent indexing?  IE and SP index, PO, index etc in which multiple nodes of a single triple are hashed in the aggregate to allow for direct lookup.  This would of course decrease the upper bounds on the number of triples previously discussed if housed in a single-rooted index structure, as there would be (eventually) collisions between these incongruent indexing schemes.  So maybe a multi-rooted index strategy is something that should be considered and incorporated early on.  I think this is already partially implemented as spogi, gsopi, etc, but is still "single-constituent" hierarchical?  As a concrete example -- in case my question has been as clear as mud :) --  i'd cite the cassandra-spoc-index-mediator of de.setf.resource, which leverages multi-constituent indexes extensively. </div>
<div><br></div><div>Apologies (as usual) if I am missing something obvious or distracting from more useful conversation.</div><div><br></div><div>Dan<br><div><br></div><div><br></div></div></div>