I’ve created several user attributes, and I typically create agents with query code for each of them.
I’m wondering if there’s some automated way to create query agents for each value (or select values) that’s assigned to certain attributes (i.e., in a sense, creating exploding value-querying agents, if you will). Hope this makes sense; happy to explain further, if needed.
I don’t expect this is possible, but…you never know!
Why to you need a permanent agent for each attribute? I suspect you don’t if the need to to simply view notes for that criteria. Now we have the Attribute Browser view, for most uses AB view can replace most single-context-review agents (i.e. per-attribute agents). In addition, AB view is note configurable in terms of giving you feedback about the range of values for the target attribute.
Also, unless you’re using the agent result to trigger another set of processes or results, you’ll only be looking at one note at a time. So, you could look at using an attribute in the agent pull a value into the query. This method is easier than editing the query all the time. Example:
The query $qItem(agent) will look at the value in $qItem and search for it.
I’m certain open to configuring AB views that can accomplish what I’m seeking in this regard. The two main issues, and reasons why I haven’t pursued this earlier, are because I’ve often found the AB view a bit confusing for set up views (in fact, I’m not exactly clear on how to accomplish this for what I’ve just outline at the top of this post), and because I’m working on a TBX file collaboratively with people who don’t have very little background in Tinderbox, so they’d find it even more difficult to set up. By comparison, setting up discrete agents in Outline view is much easier for my team members.
Anyway, I’m happy to give it a shot, and understand that it would be better to use fewer agents, in general. Ideally, I’d love to figure how to save AB configuration so that I don’t have to redo them each time. Is that possible? Or something that Tinderbox might develop in the future?
Thanks again for your thoughtful input.
I’m not sure I follow all of this. Can you point me to an example of the kind of output this would produce?
Thanks so much.
Have you not tried the saved tabs gallery?
Holy cow. This is a revelation! Thank you.
Ok, so the saved tabs gallery is a game changer, and I now want to try my hand at making the AB view work. I’m trying to get a better handle with AB view, in general, and am determined to get there.
(@satikusala - perhaps you should consider making a video on this!)
Anyway, is there a way to accomplish what I’m seeking — query notes per each value affiliated with its respective attribute (for a set) — in AB view? And can you provide some assistance for how I can accomplish this?
I tried to set it up today but wasn’t able to produce the most basic results. I’ve been re-reading posts on AB view set ups, and kept wondering if I need to first figure out what kind of code to plug in at the bottom. Happy to read more posts about this first, if there are some that provide especially good instructional background. I welcome whatever guidance you could provide, both specific to what I’m aiming to do and for more, general instruction on AB view set ups.
Thanks.
OK, let’s say you’ve 10 attributes at present for which currently you build an agent for each. Now you could:
Note that there is no simple mechanism to to ‘just’ copy a (saved) tab from one TBX to abother but there are a number of workarounds for that. If needed, best addressed when needed to avoid a small essay here.
The basics of AB view are its scope and its target attribute. By default, scope is the whole document but can be any single container (and descendants ). In addition, the selected containers contents/descendants can be modified by an agent (defined in the AB view), e.g. to filter only those notes using a particular prototype.
The user-selected attribute dictates how the main view contents are displayed. Whilst scope selects which notes are listed, attribute selects what is shown for each note and the order of listing. There are lots of customisations which are all explained in this section of aTbRef; as that’s easily looked up, I wont’ go into it here.
Once you’ve tried AB view out I think you’ll find your per-attribute agents, whilst working, are a more cumbersome approach. One upside of the AB view approach—where it is pertinent—is fewer agents running for no loss of access to information.
One comment to add to MarkA’s explanation, you can also add columns (attributes) to the view and therefore give you a broader context of your default value. If I am not mistaken, simply right clicking on the column will allow you to add the attributes. Here is a link from the forum on how to use the AB you might find useful. How to use the Attribute Browser and here Sense-making of Academic Literature Using Tinderbox - #10 by Desalegn
Hope this helps,
Tom
Thank you both, very much.
One quick question… I created some query agents for complex searches (e.g., combinations of attributes and agents), and now see that I can create and save those kinds of searches within AB view. I’m happy to consider doing that in lieu of a permanent agent. But I’m curious how much better it is than just just having “permanent agent” – and why it’s preferred. Is it just that agents consume much more energy? It seems like using query code for some searches within AB view would run the same amount of energy, no?
Just trying to make sense of this… Thanks!
A collection of agents is ideal for examining a specific set of values.
For example, if your firm has offices in Zurich, Basel, and Stockholm, you might have agents collect the latest orders for each office. When the Paris office opens in the Fall of 2024, you’ll make a fourth agent. Many problems are like this: you want to partition notes based on a closed set of values.
If the set of values is not closed — if we’re talking not about your firm’s offices but the factories of its customers — this becomes a headache: you’re making new agents every day. One way to think of Attribute Browser is that it’s a family of agents that select notes based on a query, and then partition the results based on an open set of values. It’s very powerful, though it’s not something everybody needs to do.
Attribute Browser isn’t better or worse than agents. It’s simply different.
It’s not generally ‘energy’ so much as the fact—attested above—the agent-per-case tends to scale badly. IOW, you end up with a lot of agents. If you’re just adding agents because you’re unaware of other mechanisms such as AB view then it’s worth trying them. But if you feel most comfortable with a lot of agents that’s fine.
This issue arose because in recent threads (here and via DMs) I get lost in the maze of agents when trying to find which we should be looking at. AB view just seemed a neater, faster and more expressive way to get at the problem at hand. 
My use case for “a lot of agents” is to pull key terms, regulations, and technologies references from attributes in a book chapter and to use the agent to list these reference terms and their descriptions at the end of each chapter.
Thanks so much for that explanation. It’s very helpful…