Sorry If this has been asked before but I am not sure what might be the search term …
I am using the $RefKeywords attribute to store keywords for my notes. A note can have no or 1 to n keywords.
What I want to do is to have 1 page (index-page like in a book) where I show all keywords once in a alphabetical order and below the name of the note with href link to the note.
Note1
Not2
Note1
Note3
…
How would you approach this?
Thanks for pointing me in the right direction.
This sounds like an attribute browser task.
Do you need to export this to HTML?
Yes, as html side as part of my web-project
OK. How often do you add new keys to $RefKeywords?
There is no frequency, more often during the development of my book project. A note represents a chapter and during the review process I keep adding, moving or deleting reoccurring keywords per note/chapter.
If the $RefKeywords values represent a vocabulary that changes infrequently, you could easily create an agent that gathers notes for each keyword and sorts them by name.
Yes, this does work. Note, if you’re writing a book with many chapters, you can create cross-referenced index as well to show what chapter sand sections the keywords show up in. If you’re interested, I could look into pulling a demo of this together for you.
Would love to see a small demo of this.
Sounds good. Give me a week or two. I’m heads down on a project that I have to get done.
If the values of $RefWords are “Winken;Blynken;Nod”, we could easily define
Name: Winken agent
AgentQuery: $RefWords.contains("Winken")
And similarly for agents for Blynken and Nod.
This is infeasible if $RefWords has hundreds of values; attribute browser is the answer for that case. But, often, $RefWords has a constrained vocabulary — you can only fit so many characters in a wooden shoe sailing on a river of crystal light, after all. This is actually the common case; attribute browser is for the more difficult, esoteric case.
The reason I spoke up is I believe @satikusala has some book-length projects in Tinderbox where he may have addressed this “assemble and export an index” problem.
I’m assuming dozens of agents, one for each entry in a book index to be exported, might be cumbersome and that A/B is good for viewing but not so much for exporting. Am I wrong?
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:
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.