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.
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:
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.
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.
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.
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.
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!