Agents, aliases and maps

Hi Folks,
Two questions about best practice please:

  1. When an agent gathers notes that you want to use in a map view of a container other than the agent, is best practice to alias all the notes the agent has gathered and move those aliases of the agent-gathered notes into the map view? Or is there action code that can automatically create an alias of all notes gathered by an agent and automatically ensure those aliased notes appear in a selected new container (such as the container you want to work with in map view)?
  2. In the attribute browser view, what steps are required (ideally some keyboard shortcuts) to quickly add or remove further containers to the attribute view, where those containers comprise notes gathered by an agent (such as the agent that gathers notes with a particular text string in the name or text). The idea here is that as a phrase of interest is typed, it is automatically detected and the note in which it appears is assigned to a container that can be invoked to appear as one of a number of container elements for notes displayed in the attribute view.
    Regards, J

#1. By setting the $Container of the alias via an agent action, that alias will move to the specified container (i.e. map). Do note that the agent will regenerate a new alias, unless the action changes the original in such a fashion as to make it no longer match the agent query. Otherwise, each cycle of the agent the new alias will be moved to the new map, duplicating the previously moved alias.

#2. This misunderstands how AB view works. What you describe—“…a phrase of interest is typed, it is automatically detected…”—is a query-based scope. To do this in AB view, set the container scope as tightly as convenient: whole doc if unsure, a branch of the outline if all content of interest is within it. Then set the AB view’s agent to look for the phrase in the appropriate attribute(s). If editing the phrase into the query is too much effort, set the agent query to pull the phrase from $MyString in a key attribute of a note elsewhere, i.e. so that editing that note’s $MyString in its key attributes updates the AB view query.

I’m not sure the rest of this is possible. Plus, I see an issue. Your method describes adding these just-in-time analysis containers but not how they are removed. This strikes me as an approach that scales badly.

Bear in mind that originals and all aliases run their rules and edicts. Also, the more aliases you have the more careful you need to be about your queries lest you inadvertently match an alias you didn’t mean to.

These issues don’t bite if all you are doing is phrase (string) matching. BUT, they will bite when you that want to use Tinderbox’s analysis/automation tools. Put another way, the problem is not the initial task, but that your may be building on sand when it comes to the value-add part of the process of building on initial findings.