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.
Thanks @eastgate that works just fine for my purpose
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.
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.
Has this turned out to be unexpectedly hard to do? Is the approach already covered in a video or somewhere else? If so where, and I can try to hunt it down.
The real need if any for the agents is seeing matches in the UI, though as you mention AB view I’d say the latter is a lot more useful in the same basic role. People still with agents as it’s some of the first automation covered in the basic tutorials (and not everyone pushes on further). Plus in small docs/small scale there’s no real impact. But, making an agent for every one of for one hundred discrete terms or phrases? Perhaps not.
But whilst AB view is great in-doc and can export RTF and textual tables, it is less easily used in formatted (a.k.a. ‘HTML’) export. However, that’s easily got around using ^include()^ and find() to replace exporting an agent either as a separate file (HTML, Markdown, XML, JSON, whatever format) or as part of a large cascading single file export.
So, old scenario, we have an agent with query $Tags.contains("complete") that is exported as a note. Instead we:
^include(find($Tags.contains("complete")),"tag-export")^find() queryThe export output of the note is now formatted data (list, table, whatever) of info from the same notes that the original found in the agents we no no longer need. I use this model a lot in my large research docs. After a while agents just get in the way and need to be throttled back to allow other automation to run smoothly. No such reporting agents, even better—not that I don’t still use agents for more specific tasks. But, 0s or 00s of agents just listing value occurrence, no.
I’m on deadlines right now so no demo, but it ought to be easy for an experienced user to make a working model from the instructions above.
It is a bit more mis-en-place to make a single exportable listing note but a much more powerful export affordance when done. The normal argument against this is being familiar with agents and unwilling to learn new methods, but I see that as self-defeating.
Sorry there’s no demo file but HTH. 
I think I get the general idea. But need more specifics on how to implement it. This is the part I am interested in.
Yes, I know…I just submitted the next major draft of my dissertation (let’s hope this is the near-final draft…fingers crossed). Now that this is done, I can turn to this. I’l schedule some time to try to pull something together for you by next week. Sorry for the delay, but I really needed to get the dissertation out
Hi @sumnerg just finished an indexing demo, check it out: Tinderbox Meetup Saturday 10 February 24: ExportFileName, Highlighting, Creating an Index. Let me know what you think and if you have any questions.
Thanks for this! The holidays are upon us over here. But working through the tbx and the video. There’s a lot to digest!
Taking @satikusala impressive example a step at a time I think I’ve got bare bones indexes working for me. One set attribute and, as I have often found with Tinderbox, just a few bits of shockingly compact code - here all in functions called by ^value() in the text of an index note.
Index-table-test.tbx (236.0 KB)
Questions:
If I wanted, how could I get case insensitive sort? (Here all uppercase sorts together to the top.)
When trying to rely on what I think of as the “built-in” markup with <p> etc to create a “text format” index rather than “table format” index why do I get the desired export markup and preview when calling the functions from a stamp, but not when calling the same functions by ^value() in the text of the note (which I’d rather do)?
Illustration of my problem here:
Index-text-test.tbx (232.8 KB)