That doesn't sound hard to do:

Make an agent to find the descendants of all top level items. To make this easier, I'd put all my 'chapter' notes in a single outline container - let's call it "BOOK". Into that we now move all the "CHAPTER" notes.  Our agent query is now:

descendedFrom("BOOK")

This will match all the children of BOOK, the children of those children and so on down. The next point is important, any action in agent needs to consider whether it acts on the alias (in the agent) or the original of that alias. for instance, aliases can have their own basic (note-to-note) links - only text links (text-to-note) are common to both alias and original.

Also consider prototypes here. If you give different prototypes to chapters, sub-chapters, topics, references and ideas it's easier to assign different link types to the links you'll make.

Also note that outline order has no effect on the map (other than stacking order if notes overlap). Conversely, map position has no effect in outline. Adornments show up only in maps. Separators show up only in outline.

Busy just now and I return later to the linking action, but that should help get started. Once the links are added you can then set $Container to flatten the outline.

Last tip: make a copy of your file and work with that until you've got all the details safely figured out.

Mark A, thanks for laying out the logic and steps here. Your detailing of how an agent would work, in creating links whenever it found $ChildCount etc, is very useful.

Here is a question I ask for clarification—my own, and perhaps the original writer's too. I believe that if a user wants, at the same time, to have an outline view showing the hierarchical relationship depicted above, and also a map view showing the linked representations of the hierarchical relationship, then either the map view or the outline view must be built with aliases.

Right? Because, as I understand it, the original versions of the notes must, by TB definition, exist in one or the other of two mutually exclusive states. Either the originals are all in the same container, which is to say at the same outline level (so they can be shown, as originals, on the same map); or else they are in a hierarchy of containers (so they will have a nested parent/child relationship in an outline.) But they can't be both.

And to spell this out: if you had an agent that took what had been child items, and moved their originals to the same level as the parents so they could appear (with links) on a map, then the originals could no longer appear in the desired way in the outline. Right?

So if the original question was how a user could create an outline view, and then automatically generate a corresponding linked-map view, but also preserve the outline view, am I right in thinking that the answer would have to involve aliases in one view or the other?

Thanks

After a number of blind-alley experiments, I think I have a solution for a map-before-outline method that preserves - or rather pre-stores - a outline structure for a map. There are a few assumptions to the following technique but I'll put them at the end as they'll make more sense once I've explained the process.

We start with a map, in a container*, BOOkMAP. We make a prototype p_mapitem. Set the map container $OnAdd: $Prototype="p_mapitem". In the prototype set $RuleDisabled to true (tip: un-tick the 'enabled' box in the Rule inspector for that item). Add a new String attribute $ParentItem and set it as a key attribute for the prototype. Give the prototype the rule: linkTo($ParentItem).

Now, make a stamp. Set the action to: $ParentItem=$Name(parent)

Now select all descendants of BOOK in the outline and apply the stamp.  This assumes* all notes that have children have a unique $Name.

Now, still in Outline view and with the above selection, drag the whole selection into BOOKMAP. Note this drag flattens the selection so all moved items are now siblings.

Open the map view of BOOKMAP. You will need to move all the times as some may overlap each other. But you should notice the items are now linked.  This is what I see (after some manual arrangement) of the items:



*Assumptions:

• The map is in a container, rather than at the root of the doc so we can address everything in the map via an inside() or descendedFrom() query.
• Items on the map have unique names. If there are other notes of the same name outside this map you can get away with using the $Path of the target item in $ParentItem instead of just the name.  If you want to auto-link via a rule, you can't have >1 item of the same name in the same map as even a $Path won't differentiate them. Sadly, commands like linkTo() don't allow

Of course, if you now change $ParentItem for an exiting note, it will add a link to the new parent but you'll need to manually delete the link to the old parent. To automate that you'd need to add a further String attribute $OldParentItem. Then add this to the existing prototype rule:

if($OldParentItem){unlinkTo($OldParentItem);$OldParentItem=;}

You can have the map and outline at the same time.  So I think what you need to do is make aliases of your outline objects and place them in a single container elsewhere, to form your map. I'd make the aliases manually rather than use an agent map as agents don't always keep the same alias from query cycle to cycle. This matters if you want to see the links between the aliases and/or control placement of items on the map. Note that if you select multiple notes and then use Edit menu -> Make Alias (Cmd+L) then all selected notes will gain an alias next to their original in the current view. You can then select the aliases and drag them to your map.

Short answer: yes you can, but you need to cite the target by full $Path and not just the $Name)

You should be able to use the linkTo() (and similar link/unlink operator) to link to or from an alias as long as the alias' original is in a different container. This is because you can specify the linked to/from note by a $Path rather than a name. Actually, if you specify the linked item(s) via a find() then you can work around this restriction by testing $IsAlias in the query (see more).

You may find this article useful in explaining when aliases do/don't share their original's links.

Aliases created manually always have the same $ID as long as they exist. Aliases in agents may change their $ID over the life of the doc. In short, if a while a note ceases to match a query, the alias to it is deleted; when the note re-matches the query a new alias with a new $ID is created.

An agent query aims to match each note once. It will only match an alias (and make an alias of an alias!) if the alias is in query scope but not the aliases original. By contrast, find() matches originals and any aliases and doesn't de-dupe them.

You can have a map of aliases (as described up-thread) with links between them to mimic an outline, but not vice-versa. This is because aliases can't have children - i.e. you can't nest them in an outline-like manner.

Sorry for such a range of seemingly unconnected things but they're all edge case parts of what you're trying to do.

Great, happy you're making progress.  

Thanks for sharing.  I think it's really helpful to others starting out to see proof positive of someone successfully turning the advice and references into something working.

A nice nuance of your solution is the way notes' like 'idea' are filtered out by use of prototypes.

The map image reminds me of one aspect of aliases - although aliases of container notes look like containers in a map, if you drill down, there's nothing there (aliases can't have actual children). You can, if you like, hide the viewport part of the icon (the sub-map) by dragging the bottom of the title area (see more). Note however that this change affects both original and all aliases as $TitleHeight is not intrinsic.