Tinderbox Forum

An agent for $NewAttribute=$Name?

I will place a new attribute in a prototype. I want it to simply take its value from the name I enter for the note. Is there any way to achieve $NewAttribute=$Name in TB without creating an action, an edict or an agent?

The problem I foresee is that many notes will be assigned that prototype. Therefore, if I create an edict or a rule in the prototype, this will mean hundreds of them running in the document.

Would it be more efficient to create an action in an agent, in this and in similar cases? Is there any other way to achieve this?

I think that the point of an Edict is that it runs only occasionally. It’s designed to have minimal processing burden. Some options:

  • Make this an edict – $NewAttribute=$Name – and not worry about the processing drag. It would be minimal.

  • Create a slightly more complicated rule or agent, that would notice whether or not the new attribute had already been set. Eg:
    if($NewAttribute=="") {$NewAttribute=$Name}
    That would work only on notes that had no value for $NewAttribute, and assign them properly.

  • OR you could create a new Boolean attribute called, say, $Processed, and have a sequence of rules or actions that would set $NewAttribute to the value you want, and also set $Processed to “true” – and then have some follow-up rule that looked only for notes that still had $Processed set to false.

In any case this seems like a solvable challenge.

According to @eastgate, all things being equal agents use less computational power.. If it’s not possible to identify one attribute with another one, I think this simple operation will will be taxing as an agent for the performance of the document because it will be applied to many notes:

($Prototype=="pTheme" & ($Theme =="" | $Theme!=$Name)) {$Theme=$Name}

I wonder if it would be less taxing just to eliminate most of the checking:

($Prototype=="pTheme") {$Theme=$Name}

I think what’s being overlooked here is Tinderbox’s (unusually) forgiving approach to incremental formalisation. Put another way, if you use and agent when a prototype turns out to be a better choice, it’s very easy to correct that. Given this, it’s actually a waste of available time to over-think use of (presently) unfamiliar features compared to actually trying them. It’s hard to comment generally on how issues work at scale without seeing a document plus use may change. This is why so much advice here is on understanding the techniques and letting workflow develop from that.

The unasked, but important question here is “is this a on-off task?”. For instance, might the note title ($Name) change after first being set and thus the $NewAttributeName need to be updated too. If so, is this occasional or frequent enough to warrant ongoing automatic monitoring?

Don’t overlook stamps for one-off tasks. Obviously, they are manually invoked (thus not automatic) but they run only once on each currently selected item - i.e. that is no ongoing load from the task.

Rule overhead. Putting a rule in a if(){} clause only makes sense if the action is complex, e.g. doing regex-based .contains() searches. A simple $NewAttribute=$Name is likely a quick to do as to test whether it needs doing.

Prototypes. All items using the prototype will run any rule/edict set in the prototype. Note too that before creating such actions you should consider whether you want the action to run in the prototype itself as both rules and edicts can be disabled and if needed in the prototype you want to do that before you start adding the actual code. All notes using the prototype inherit rules/edicts and each note runs this code as do every one of their aliases. Thus if using lots of aliases (don’t overlook those created by agents) you may want to ensure that your rules/edict only run if in the context of the original (or a specific alias), noting the the previous paragraph re whether conditional clauses help.

If confused by all the choice at this point, I’d return to the opening point about just trying things rather than getting caught in a fear of missing out on the best solution. If you’re doc isn’t running slow, don’t worry about optimisation you don’t need.


This is not a criticism, but I’m not grasping why one would want $NewAttribute to always have the value of $Name. Or, perhaps, why $NewAttribute is needed at all, if it is merely a sort of clone of $Name?

Without knowing the context, of course, it seems like an unnecessary redundancy to do that.

Here’s an example from my (admittedly extremely limited!) experience.

I have a protoOpportunity prototype note modelling a sales opportunity. In it I have an $Amount field which is a number but I want to view it formatted as currency in the Attribute Browser which I use for reviewing my monthly pipeline.

I need a rule that generates the Amount$ string attribute from the Amount number attribute quickly, so I can see the immediate effect after a change (this effectively eliminates using an Edict). However, I have 856 Opportunity notes - past and present - plus many more aliases since I slice and dice them by Practice, Pipeline Status, Year etc. If I put the logic in a rule then I have thousands of them being executed over and over, and what’s worse, many of them are unnecessary.

The solution was to realise that the history is fixed so those amounts will not change. I’m only ever going to update amounts on current sales opportunities, of which there are a much fewer number. I therefore took the logic out of the rule and placed it into the Agent that collects current pipeline opportunities.

So far this looks ok to me, but I’m still new to Tinderbox so I might have missed something.

1 Like

To our original poster @jmm, I think there is a lot of wisdom in these past three suggested answers, from @PaulWalters , @mwra, and @Nick . The essential point I’d distill and emphasize from the posts is:

  • Start with any solution you can find that works, in terms of producing the desired info or result;
  • Don’t worry for the moment about differences in processing speed or of possible coding inelegance. The speed factors would show up only when the file is huge, and the imperfectly set up code or data structure remains very easy to change as you go along and as improvements occur to you.
  • By the time these other issues arise, you’ll have a clearer sense of how you can refine the structure, the queries, etc to do what you want – eg with @Nick mentioning his realization that he only needed to apply the update code to the newest items. I’ve had similar realizations, when I figured out that rules I’d had running in items old and new really needed to apply only to items I edited or changed.

In short: find anything that works for now, and move on from there. By the time you’re aware that some other solution might work better, you’ll be in position to figure out what that better solution might be.


There are a few fields it is not clear to me if I’d better use them as prototypes or as attributes. Theme, location and character among them. The latter two I have chosen to make attributes.

Theme I was tempted to make it both. I would find it easier to apply and modify theme as a prototype, but more useful at a later stage as an attribute. I foresee no problem with TB’s outline view, but I haven’t grasped yet how to integrate map view and the attribute browser. Now I find the latter most useful, but I think abusing it would lead to using TB as a database.

It can be both, but you don’t need to over think this. It is very easy to ‘convert’ use of a prototype to an attribute (i.e. ’ database field’) value. Or vice versa. This is how Tinderbox is unlike a normal database, it’s very forgiving of structural mistakes and supportive of incremental formalisation. IOW, adding structure (attributes/prototypes/etc.) when it becomes and not before (as is the case with a ‘normal’ database).

If you’re used to (relational) databases, it help to unlearn the notion that you have to figure out the structure in advance, and thus ensure you’ve tables full of never-used fields.

If Tinderbox is like a database, it’s closest to a flat-file database or a rollodex. The data is stored as an XML outline (see more) and only non-default attribute values (i.e. set local to the note and not inherited) are stored in the note’s data.

You just answered your own quandary, I think :slight_smile:

Attributes are similar to “fields” or “properties” – a single characteristic of a note – a characteristic that has a single value (except in the special cases for sets and lists).

Prototypes are collections of attributes. I.e., a collection of related characteristics. (Related in any sense you mean – the data are yours and their meaning is yours alone.)

So, theme, location, character would be attributes – and those attributes could be included in one or more prototypes.

1 Like

Good to know. I guess a relational database would allow more features, but would be a daunting task to design it for future uses right from scratch by an end user like myself.

I realize your valuable advice comes from a competent use of TB, and I am forcing myself to put it into practice.

To follow the path you kindly advice in this thread, I have to overcome previous negative experiences. The features I look for seemed to be in CAQDAS applications, but in the long run it proved impossible for me to tame first Atlas.ti and then MAXQDA, for the purpose of connecting and digging back effectively into my notes. The point in which I had no choice but to admit it took several years.

I am now left with an exported XML I am unable to handle, and the task to input manually my data -at least what I have time to rescue before my license expires in mid January. I still remember with disgust the previous time I performed this task years ago. This is to explain that there are users who are not exactly fresh starters, but already burnt about outputting and inputting data.

Therefore, I wish to have a clear picture of my final use of TB from the start. On the other hand, it is the versatility of TB that attracts me.

FWIW, I’m using Tinderbox in my current PhD research precisely because it doesn’t force me down a certain path when doing qualitative work. Whilst I have to use action code to generate some bits of info (e.g. person to event links, abstract list of unique people, etc.) I like that I have to think about what info I chose to log and why. Admittedly it’s fairy niche use and because I have 000s if data points maps are less practical. Even so, I’d far rather use this than something like NVIVO.

If you have old XML data I suspect folk here could help figure a way to import it into Tinderbox where you can then re-arrange it. It might not be a simple quick task but rarely have such things proved impossible given that it’s just XML.

Since MAXQDA was the last app in @jmm’s list, and you seem to have an active license until January, then perhaps there is an opportunity to use MAXQDA’s export-to-Excel feature (or CSV). A range in Excel that has a header row can easily be copied from there and pasted into Tinderbox as notes – and Tinderbox will create new attributes based on the headers. (There are numerous posts in this forum and the old forum explaining.)

Plus Excel is a more tractable form for some data than XML, if you are not much familiar with XML.

I’ve had good results hiring a freelancer on Upwork (formerly Elance) to do XML transform work – e.g., building CSV or OPML that is Tinderbox-ready. A few hours from an XML expert saves a lot of aggravation from learning a skill you’ll only need once.

1 Like

Since you mention Atlas.ti, I couldn’t resist going off-topic a bit to say that I’m a “false beginner” with the programme. Converting to it from NVivo, I’m still at the stage of being wowed by how Mac-like it feels compared to its competitor, and how smooth all the operations seem. I’m sure I have many hurdles to come, but so far I’m very happy.
I’ve also in the past downloaded a trial of MAXQDA. Again seen from the perspective of a former NVivo user, I was pretty impressed. It’s not as smooth as Atlas.ti, but the text analysis and quantitative functions in the Plus and Analytics Pro versions look pretty impressive.
But yes, I agree with your general point that Tinderbox is more flexible!