Tinderbox Forum

Automatically append attribute values to existing text of notes

Dear all,

I have created the following user attributes:


I was wondering whether there is a way to append their values to the existing text of existing notes. So far, I was able to create a stamp with code:

   $Text = "Inbound Links: " + $InboundLinks + "\nOutbound Links: " + $OutboundLinks + "\n";

That adds the desired attribute values if notes are empty, but that does not do anything if notes already contain text.

I also tried to add the following rule to a prototype:

$Text = "Inbound Links: " + $InboundLinks + "\nOutbound Links: " + $OutboundLinks + "\n"

But when the prototype is applied to a note, it replaces the existing text with the attribute values I would instead like to append to the existing text.

Could someone please be so kind to help me out by pointing me in the right direction? Thank you for your consideration.

Best regards,

What about:

   $Text = "Inbound Links: " + $InboundLinks + "\nOutbound Links: " + $OutboundLinks + "\n";
} else {
   $Text =  $Text + "\n\n" + "Inbound Links: " + $InboundLinks + "\nOutbound Links: " + $OutboundLinks + "\n";

Beware of using this as a rule/edict as every time the action is run, the links will be re-added to the existing $Text. I’d suggest using the above only as a stamp unless you develop some sort of guard filed attribute to log whether the note has link information already added.

Note too, that this approach won’t let you, even with a stamp, correct/update existing link info. You will need to delete the latter before applying the stamp.

Dear @mwra,

Thank you very much: that works perfectly! Thank you very much also for the very helpful warnings: sometimes it’s difficult (at least for me) to predict the differential behavior of rules, edicts, stamps, etc., so I particularly appreciate your input.

Am I correct in assuming that it is therefore impossible to append the value of an attribute to the existing text of a note and have that in-text value updated automatically as the value changes with the growth of the document? Perhaps I should explain the reason for this question and for that in the opening post.

Having the name of the notes that link to and from a note displayed at the end of the text of the note seems useless, but eventually I would like to turn them (manually) into text links that link to the notes with those names. This seems just as useless because Tinderbox has already built-in tools that allow doing that (Road Map and Browse Links come to mind); so why am I doing that?

The reason is that I would like to “Publish” my notes “To DEVONthink”, using @pat’s workflow. I mostly use DTPO for its “See Also” feature when I search through references (the PDFs in my Bookends library are indexed in DTPO); I would like to be able to use that same feature with my notes, which only exist in Tinderbox, and it seems the Artificial Intelligence underlying the “See Also” feature takes links into account. Unless I am mistaken, the “Publish To DEVONthink” workflow does not “Publish” Tinderbox’s basic links; hence my workaround: turning basic links into text links. Further, by having “clickable” links in the text would allow me to interact with a copy of my Tinderbox notes using DEVONthink To Go on my iPad/iPhone.

Do you think there would be a way of achieving all this that is better than that I am currently pursuing?

Thank you for your consideration.

Best regards,

In short - Yes. You are adding a string (of text) to another string. Tinderbox can’t ‘know’ what those strings represent (unless you inform it). You may know you want to ‘just’ update a list of linked note names, but that knowledge exists outside the app.

This is the issue. different apps have quite different design assumptions. Trying to make app X work like app Y, or vice-versa is complex (i.e. likely expensive to engineer reliably/sustainably) and likely offers little ROI to both apps’ developers. See also: false consensus effect.

Surely it would be better to adjust the script to add the linked notes’ titles (assumes the $Name values are unique) when exporting the data rather than use the ugly kludge of adding the info into $Text within the app as this can’t allow for the implied need to update the data if links change.

I do understand the desire/attraction of cross-app work but having spent many years consulting at the coalface of data transfer, it is usually far more complex than assumed.

Thank you very much for your helpful feedback, @mwra, and for sharing what your experience as consultant has taught you.

Unfortunately, I currently lack the necessary skills, but I will certainly keep that in mind as I expand my areas of expertise. My, perhaps unorthodox, approach derives from a professional interest in Evolution, which works with whatever building blocks are available, more like a bricoleur than a designer; for better or for worse, that professional interest often informs how I approach issues.

I hope you were not implying that I overestimate the extent to which my own opinions or preferences are representative of others’; if anything, it’s the opposite: because I realize how niche my needs are, I would never think of asking Tinderbox’s or DEVONthink’s developers to integrate such needs in a new version of their software or, worse, expressing my frustration because those needs are not taken into account or, even more ludicrously, anticipated! :slightly_smiling_face:

Again, thank you very much for your continuous support!

Best regards,

Far from it! I’m simply surfacing some of the inconvenient facts about the difficulty of moving data between apps. Plenty of people use Tinderbox closely alongside another (or several apps) but which apps those are and how exactly they are used varies. This creates a lot of similar-but-different tasks, or so some 14 years of helping fellow users has taught me!

I totally understand the frustration of being able to describe the desired outcome but being unable to effect oneself; I regularly encounter the same. Perhaps if you were to post the script you want to use and indicate where/how a change is needed? This makes it easier for someone to help without having to spent a lot of time trying to figure out the entire process. It can also help to post a specimen TBX document to provide a common point of reference.

Thank you very much, @mwra, for your kind and understanding words; I just wanted to clarify my position because I am very grateful and feel very fortunate to be able to use software like Tinderbox (and DEVONthink): the passion and pride their developers put in their work shines through and comes across, and I have the utmost respect for that.

Thank you very much for the valuable suggestion: I will work on a post and accompanying TB file for that purpose. On a related note, I gather you never had any reason to move to DTBO your TB interlinked notes to, for example, take advantage of DTPO’s AI or DTTG’s portability?

Again, thank you very much for your continuous support.

Best regards,

1 Like

Dear @mwra,

An update to show you that I did take your suggestions into full account even though I never posted on the TB forum the message I referred to in my previous post in this thread.

I have learned from DEVON Technologies that, contrary to my assumption, DTPO’s AI (e.g., “See Also” and “Classify”) does not take into account links between notes (i.e. documents in DTPO); therefore, my idea to turn TB’s basic links (which are not supported in DTPO) into text links (which are supported by DTPO) serves no real purpose, and I have thus abandoned it.

The other reason why I wanted to turn basic links into text links is that I wanted to create a sort of in-text Roadmap view, but the new Roadmap view in TB8, with its ability to refocus on selected notes, makes my idea obsolete. I am sure many users requested that feature, but I know I was one of them; I could not believe that the feature I had requested was actually taken into account, so I have, if possible, even more respect for TB’s developer and the quality of his support for TB.

Finally, I included your comment:

different apps have quite different design assumptions. Trying to make app X work like app Y, or vice-versa is complex

in my reflections, and I have come to the realization that I was erroneously trying to duplicate my Mac on my iOS devices, instead of taking advantage of their respective strengths; this ludicrous attempt of course included trying to replicate TB on my iOS devices. I hope my naivety will be forgiven, if only because it stems from the central role TB has in my workflow.

In conclusion, I was wrong on multiple fronts; this does not bother me — being wrong is the best that can happen to a scientist — but it disturbs me that I may have wasted your time, and for this I apologize.

Thank you very much for your patience.

Best regards,

1 Like

Thank you for that kind follow up. Please don’t feel you’ve wasted anyone’s time. The more questions people ask the more Tinderbox community learns and aTbRef is constantly being added to and improving as a result of what I learn asking questions.

I’m busy preparing a v8 aTbRef and I hope it will be up in the next few days. That will include more info about the new hyperbolic view, that allows you a link-based view of your document. I too am very excited to see this new addition to Tinderbox.

Every day is a learning day. :grin:

Dear Mark Anderson,
I am looking forward to v8 aTbRef and comment on new hyperbolic view.

I hesitate to ask you but … ,
it would be nice if you explain about new hyperbolic view,
clarify differences between Tinderbox8 and TheBrain.app.

thx and regards, WAKAMATSU kunimitsu

I bought new Tinderbox 8, yesterday.

Unfortunately, I have heard of TheBrain is but I have no experience of actually using it.

Any users of TheBrain out there who could help?

Dear Mark Anderson,
How about Mr. Dominique Renauld ?
Could not I put a question to him in a roundabout ?

Dear Dominique Renauld,
Coud not you give us a piece of advice ?

thx and regards, WAKAMATSU kunimitsu

Thank you very much for your understanding, @mwra: that’s most gracious of you!

I look forward to the updated version of aTbRef, and I once again thank you for all the time you selflessly donate to help users like me, whether through the aTbRef or your thoughtful answers to our questions.

Best regards,

On the hyperbolic view:

I’m hoping to write a longer discussion of this too, in the not-too-distant future.

One way to think of it is: it’s a super-duper version of Roadmap.

Roadmap shows you the notes that are linked to this note, and the notes to which this note links.

Hyperbolic view shows that, too, but also gives you information about notes to which those notes link!

Just for fun, here’s the Afghan COIN map in hyperbolic view:

Before anyone says, “it doesn’t make much sense”, the joke here is that the original source diagram made no sense. It was a complex policy briefing slide with two inputs (money, weather) and no outputs. Your tax dollars hard at work!

On a more serious note, hyperbolic view isn’t AI-like ‘magic software’ that somehow finds sense in the chaos. Rather is is another tool in Tinderbox’s toolbox to help make sense of emergent structure. The key point is it is looking at linked notes. So the underlying outline (as in outline view) is not pertinent, nor is the single container scope of map view. It you don’t (yet) use links in your documents, the gain may be apparent. If you don’t, do give them a try as Tinderbox is at heart a hypertext app.

Don’t look at the view like a map where position does have some meaning - things go where you put them. Hyperbolic view visualises what could perviously only be traced via Roadmap view, unless you’re good at mentally spinning a lot of plates. Look beyond where things are in this view. Revel in being able to see everything to which they link, or from which they are linked.

1 Like

Dear Eastgate,
I am interested in discussing your propositions further about hyperbolic view,
let us branch out “hyperbolic view” as topical incidents.
Does the proposal meet with your approval?
thx and regards, WAKAMATSU kunimitsu

fwiw, my experiments w/ DTPO show that with markdown documents, links can inform the AI because the link UUID is a unique string. So if you want to go down that route, give markdown documents a try.

That said, my own experience has been that the serendipity suggested by DT’s AI is simply not as useful as the serendipity that results from following my own links and organization w/ TB notes. DT works on a fairly naive principle – documents are related to each other because they have words in common – whereas TB notes are related because they have a meaningful relationship to me.

The TB serendipity comes when I view a note and follow its link to another note I wasn’t thinking of, or I link one cluster of notes to another cluster.

I guess you can have both when linking within DT… I just personally find TB’s visual aspect more useful than DT’s formless presentation (even more so now with hyperbolic view).

Eheu, the tragedy of AI. I’m surprised at our ability, more so amongst tech folk, to assume 'computer knows best. In my youth, when colour TV arrived the saying was “It must be true, it’s in colour”. Algorithms may be great for spotting patterns (especially if the AI is trained, ironically by humans), but I’m mystified at how little tech vales human insight.

A reason Tinderbox lives close at hand for me is that it neither privileges brute force pattern matching nor does it feed our human instinct for order**. Rather, it is supportive of incremental formalism, which is an academic way of saying don’t enforce structure you don’t yet understand and which may be a false trail. In doing so, Tinderbox supports human intellect in a nice un-database-y way. Long may it do so, and help support human insight in the face of the AI onslaught.

** If you’ve ever felt it necessary to apologies that your Tinderbox maps are messy, this is that effect at work. Resist it—knowledge discovery is not graphic design.

Thank you to both of you, @pat and @mwra, for sharing your insights and experience.

From your words — but please correct me if I misunderstood them — it seems to me that the three of us — and probably, from the threads in this forum, many, if not most, of TB’s users — are interested, for perhaps different reasons, in how patterns of knowledge seem to emerge from our interaction with a set of notes.

That’s why I always find very interesting to learn how different people interact with their notes. Following existing first-order links (e.g., note 1 to note 2) is straightforward. And the changes to Roadmap view and the Hyperbolic view in TB8 now facilitate following higher-order links (e.g., note 1 to note 3 through note 2). But what I find even more interesting is the process of creation of new links; for example, how do you, @pat, decide to link precisely that cluster of notes to that other cluster of notes? And how do you, @mwra, implement “incremental formalization” in your notes? And of course, how do other users interact with their notes?

I realize describing this in the necessary detail may be too time consuming; moreover, for various reasons, you may not want to share this information. Nothing can be done if the latter is the case, and I would of course respect your choice; if, on the other hand, time is the limiting factor, as it often is, may I make to @eastgate the friendly suggestion that it may be time to bring the TB community together for a meetup, a workshop or a conference where we can meet and discuss our common interests?

Thank you for your consideration.

Best regards,

My main Tinderbox-based ‘work’ at present is mixed-methods research as part of my PhD. Pat of that is essentially a qualitative discovery process of the source material—in my case mainly hypertext aspect of Wikipedia. The scale of the work, with thousands rather than tens of notes, precludes a map view based approach, if only as one would need a massive screen to lay everything out. Thus the visual affordances of visible links are lessened.

However, Tinderbox’s flexible method os adding attributes as/when needed and action code allowing me to easily back-fill values new attributes in pre-existing notes makes it easy to add structure as it emerges. If doing exploratory work, whilst you may have an overarching hypothesis, crystallising that too early in the process is self-defeating. I’ve learned from experience that it can be useful to capture emerging strands as list values, not necessarily in a single attribute, and as clarity emerges to split these out into discrete new attributes. This is both for more detailed analysis and structure, but also for the later phase of reporting and quantifying of data. Capturing single strands within multi-value (i.e. list or set type attribute) data into single value attributes can make later querying or export of the data easier.

Also, I try to leverage prototypes. How does this help?

  • Querying. For example, even if you do no customisation of the prototype, have all your source notes use the ame prototype makes a query of all your sources as simple as: $Prototype=="some_prototype".
  • KAs. Prototypes make it easy to set, and alter, the KA set-up across a large set of notes. Indeed, I sometimes set up prototypes for the same intended set of notes but having different KAs for each. This makes it easy to swap our KAs appropriate to the task at hand rather than try and show 10s of KAs at once (as they will overflow the visible KA space).
  • Actions (especially edicts). When doing things like getting individual notes to find other notes with a particular value, whether to create a link or capture as an attribute value, you will often find it necessary to run per-note find() queries that have a regex-based method such as .contains(). Running these as rules isn’t needed as generally you only need one pass to effect the outcome, but each note’s run of the code is quite CPU intensive. Rule or edict choice regardless, a prototype makes it easy to insert, run and then remove the code. You could use an agent, with 000s of notes making an alias of each (i.e. 000s more objects in the document) can also clog things up.

In summary, even if I don’t use Map view so much due to pragmatic constraints, I think in those terms. Even if I don’t always create an actual link between objects I often store metadata (i.e. attribute values) which allows me to work as if the link did exists. My own journey with using Tinderbox has been to internalise the map process allowing me to use it on a larger canvas than my screen space would allow.