Breakthrough: identity-based links vs. content-based links
Edward K. Ream
concerning links. This new distinction has important repercussions
for data management.
The "prototype" for my thinking has been Kent's remarks, made several
years ago, about wanting to "reuse" writing.
It is precisely this situation for which clones are unsuited. The
problems with clones have generated an endless stream of similar
feature requests, none of which get to the heart of the matter. Now
we can see why.
Leo's clones create **identity-based** links. Indeed, the identity of
nodes never change after they are created: the identity is the node's
gnx: global node index.
There are many situations when identity-based links are natural. When
I fix a bug, I clone nodes related to the bug and gather the cloned
nodes in a single place. The gathered nodes have no common attributes
*except* that I selected them. I want *this* node, and *this* node,
but not *that* node. So identity is *all* that matters.
But there are many other situations in which the identity of a node is
much less important than its contents. Yesterday's Aha was:
Don't *link* to nodes, *search* for nodes!
For the most part, when writing, or in this case *assembling*
documents, the identity of the nodes containing text is completely
irrelevant! All we care about is the text itself, and possibly the
**context** in which the text appears.
But in Leo, **context is another form of content.**
Aside: Could this be the true form of the Leo Aha?? It might be!
Therefore, we can imagine a script that creates @rst trees by scanning
one or more .leo files.
Do you see? This script will probably care *nothing* about identity
of nodes: but it will care a lot about headlines, body text, and
(quite possibly) outline structure. The script could even use uA's:
they are another form of content.
Aside: The c.all_unique_positions() iterator uses node identity to
remove duplicate nodes, but that's about the only way identity will
come into the picture.
So the concept of content-based link (that is a search of content)
creates:
1. a whole new class of scripts and, much more importantly,
2. **a whole new way to think about content**.
**Design content for searching**
If a script can *find* for the content, a script can reorganize and
reformat the content in any way. In particular, scripts can create
@rst trees.
Of course, scripts are not going to *produce* new content. But
document-assembling scripts should go a long way toward solving the
problems that Kent has discussed. Imo, we are close to the holy grail
of document production.
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> Imo, the most important of yesterday's work was a new distinction
> concerning links. This new distinction has important repercussions
> for data management.
Just so I can get on the same page - differences between what you're
thinking about now and UNLs?
Cheers -Terry
Edward K. Ream
> Just so I can get on the same page - differences between what you're
> thinking about now and UNLs?
UNL's are what might be called "breakable" content, because they will
change when the outline structure changes.
So you could say that UNL's are another kind of link.
Edward
Edward K. Ream
> **Design content for searching**
That is, searching by special-purpose Leo scripts. We aren't talking
about Leo's search command here!
The Aha: Leo scripts can assemble content in a domain-specific manner.
For example, I'll soon create a script that will assemble (part of)
Leo's documentation for commands by finding all docstrings for all
nodes that define a Leo command.
At first, it will suffice to incorporate the entire docstring into the
docs. Later, if necessary, I could defined conventions to be used in
docstrings that would guide the assembly of the docs.
Edward
Kent Tenney
> On Mon, Oct 17, 2011 at 11:32 AM, Edward K. Ream wrote:
>
>> **Design content for searching**
>
> That is, searching by special-purpose Leo scripts. We aren't talking
> about Leo's search command here!
Sounds kind of like defining a "view" of a dataset.
The script species what to extract from a chunk, and how to
present it to the world.
... isn't that what a "query" is? ...
Is this LQL: Leo Query Language?
>
> The Aha: Leo scripts can assemble content in a domain-specific manner.
>
> For example, I'll soon create a script that will assemble (part of)
> Leo's documentation for commands by finding all docstrings for all
> nodes that define a Leo command.
>
> At first, it will suffice to incorporate the entire docstring into the
> docs. Later, if necessary, I could defined conventions to be used in
> docstrings that would guide the assembly of the docs.
>
> Edward
>
> --
> You received this message because you are subscribed to the Google Groups "leo-editor" group.
> To post to this group, send email to leo-e...@googlegroups.com.
> To unsubscribe from this group, send email to leo-editor+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
>
>
Edward K. Ream
>>> **Design content for searching**
>>
>> That is, searching by special-purpose Leo scripts. We aren't talking
>> about Leo's search command here!
>
> Sounds kind of like defining a "view" of a dataset.
> The script species what to extract from a chunk, and how to
> present it to the world.
>
> ... isn't that what a "query" is? ...
> Is this LQL: Leo Query Language?
You could look at it that way. For now, I am happy to use scripts to
define the queries.
Then we could augment the scripts with tools...
Edward