On Wed, Dec 21, 2011 at 10:28 PM, Kent Tenney <[email protected]> wrote: > On Wed, Dec 21, 2011 at 6:36 PM, Seth Johnson <[email protected]> > wrote: >> >> Reading more carefully, I should say that if I understand the >> distinction I think you're drawing, I think I'm doing both at the same >> time: every "node" has the full address for its context with it. > > I'm reading your description as having 2 components, > - a graph of pointers to nodes > - the nodes referenced by the pointers > > the graph defines addresses, the nodes are the data > > Is this correct?
The pointers are the address. But a set of pointers for standard components that make up an "address" (a set of addresses, one for each component) that together designate how each node and its relevant data are being used. The "nodes" (conceived as points in an outline) are also pointers. But you can at least see an outline at the level of "nodes." Let's set aside data for now -- they are stored granularly, per attribute, and they have a fuller "address" specification. For now, just looking at "nodes": You have a table, with columns for: State: that's three columns: Space Location Standpoint Context: that's three columns: Use Type Link Type Use The above are all "pointers" -- they are unique key values, which here also include URLs. And then, a column for what we can call a "node": Link That's also a "pointer" with a key value like the rest, but for now let's just pretend it's a useful text field like a Leo headline. You can call the Space and Context keys the "address" of the "node" which is in the Link column. There can be many Links, and each of those Links is another record in this table, with all the same columns. What brings those Links together into one "outline" is their having common key values in the State and Context columns. After that, you have the tree structure fields: Parent Link Counter/Sibling Order By your terminology you could call the Parent Link field a "pointer" to "nodes." Maybe the totality of "nodes" and "pointers" in that sense is your "graph." But the "node" -- the Link -- has a fully specified address in the State and Context columns. It *also* has tree structure pointers in the Parent Link column. Seth > But >> the outline structure is like a linked list, sort of. >> >> >> Seth >> >> >>> A linked list where every "node" has the context fully specified. And >>> the fact there's only one "tree structure value" per record (the >>> parent key) keeps things simple, with everything in a simple, flat >>> denormalized data structure that's as fast to work with as >>> conceivable, as well as massively scalable -- perfectly amenable for >>> NoSQL backends, for instance. >>> >>> That flat structure lets you extend the basic concept of db relations >>> to what I call a context (so it has all the functions you need >>> regardless of specific context, rather than being simply joins of two >>> tables representing particular entities in the real world). >>> >>> >>> Seth >> >> -- >> You received this message because you are subscribed to the Google Groups >> "leo-editor" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/leo-editor?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "leo-editor" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/leo-editor?hl=en. > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
