As has been noted, an agent-per-topic approach doesn’t scale well. I’d accord with AB view for quick review: for long-term projects, designing outline/attributes for easy use with AB view (i.e. not needing complex per-view filters) is enlightened self-interest. With large datasets (++notes) a frustrating limitation of AB view is easily being able to see just the categories/counts, i.e. collapsing the per-category listings and showing only the category banners.
Taking another perspective on the assembly of the ‘index’ I like to create notes per category (item, keyword, entity - i.e. a note per thing). Once you have this you can ‘index’ usage a number of ways:
- Links. Use action code to link the ‘index’ note to any notes using the relevant term in whatever contexts you choose (text, specific attributes, etc.)
- List/Sets/Dictionaries. Again action code can be used to record a note name (if unique, or $ID/$IDString† instead).
If using action code, with size/degree of use a trajectory is to migrate code from rules to edicts to stamps; from long experience, I generally skip the rule stage, but that’s not a requirement. Gong from edict to stamp does require thought.as you’re trading automation (edicts running on their own) for finer control over what code is running and when albeit with you having to be come the ‘automatic’ part. Size/complexity of the TBX is the factor and likely most users won’t reach that problem.
Once populated, an index note can either store the name (identities) of the associated notes, or link to those notes. Neither is ‘better’, it’s partly stylistic choice and partly reflects what the current project involves. Anyway, from this explicit (link) or implicit (attribute value) data it is then possible to construct export-able data for a ‘printed’ index. But, do note that Tinderbox won’t export links to notes transcluded (included) in other exported notes, e.g. exporting everything as a single output file. There are workarounds for that issue but if of interest I’d suggest raising that in a new thread to avoid thread drift.
†. As noted in this forum thread use of note ID-based data is not something most users will need as $Name or $Path should suffice. Once doing large/complex things and with a lot of the work happening abstracted into action code, ID-based work becomes a boon. Plus, it’s really not that hard to migrate from normal Name/Page-based code to using IDs if the need arises. A novice user shouldn’t need to think about ID-based code in their initial work.