OK, we're talking apples and oranges here.
My approach is pretty simple-minded, aimed at versioning nodes,
your schema is much richer, over my head.
I just want a snapshot which saves node state to a dict / json object.
It's also intended to be somewhat generic, the Leo specific stuff
is in the ``other`` dict.
================================================
def node2dict(self, node=None, string_address=True):
"""Return a dictionary of some node attributes.
Communicate outside the Leo world.
"""
if node is None:
node = self.c.currentPosition()
address = self.get_address(node)
if string_address is True:
# convert ints to strings
address = self.address2string(address)
# some items are To Be Determined
return {
'timestamp': self.gnx2timestamp(node.gnx),
'type': "TBD",
'hash': "TBD", # probably a dict of hashes {'name':headhash,
'content':bodyhash, 'location':UNLhash ...}
'uri': self.fname,
'other': {
'headline': node.h,
'body': node.b,
'address': address,
'gnx': node.gnx,
'key': node.key(),
'level': node.level(),
'uA': node.v.u,
}
}
================================================
An example of what I call address, this UNL:
UNL: /home/ktenney/work/leotools.leo#leotools.leo-->Sandbox-->using
@data nodes-->@settings-->@string VENV_HOME = /home/ktenney/venv
has address:
address: 0-5-0-0-1
BTW, this "address" syntax can be seen in p.key()
key: 150749356:0.151500012:5.151500300:0.151500492:0.151500844:1
On Wed, Dec 21, 2011 at 10:29 PM, Seth Johnson <[email protected]> wrote:
> 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.
>
--
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.
