On Thu, Dec 22, 2011 at 1:16 PM, Seth Johnson <[email protected]> wrote:
> Okay, I think I have a sense of where you're situated. What do those
> 5 key components of the address represent?
They are a set of child indexes
0-5-0-0-1
root
\
0
1
2
3
4
5
\
0 my address is 0-5-0
\
0
\
0
1 my address is 0-5-0-0-1
make sense?
The Leo file can be reconstructed from these addresses:
address 0 is the first root node
address 1 is the second root node
address 0-4 is the fifth child of the first root node
etc.
Or is it just arbitrarily
> a 5-part key value, one large key that happens to be made up of 5
> "meaningless key" parts?
>
> I get that you are grabbing the state, and the json objects that
> result will then be stored in something larger that keeps versions. I
> feel I can't comment intelligently unless I get the nature of that
> address you're using.
>
>
> Seth
>
> On Thu, Dec 22, 2011 at 1:54 PM, Kent Tenney <[email protected]> wrote:
>> 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.
>>
>
> --
> 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.
