Tinderbox Forum

Hard Links and Tinderbox++

One use case for Tinderbox is storing information, then applying techniques to traverse that information to produce certain outcomes, e.g. a book, an article, a web page, a conference, a dashboard, a dynamic list of tasks, etc. Many applications could do this, but Tinderbox offers a flexibility in the structuring of that information that seems to me unmatched. It handles irregular information, as The Tinderbox Way highlights, while offering automations that can impart degrees of regularity.

The use case I have in mind is as a prosthetic for thinking. Here there is no outcome in mind except better thought, because clearer, more refined, more profound and so on. In this case, we use Tinderbox to create relations between elements. Again, The Tinderbox Way highlights this feature of Tinderbox, noting the variety of relations that can be created such as containment relations, hierarchical relations, spatial relations, contrastive relations, a/symmetries, commonalities, derivation (e.g. parent/child). And these relations can themselves be related, thus creating orders of relations.

To make this use case somewhat more concrete, we can imagine that what we are engaged in is conceptual topography. We can create or discern a map of the concepts (or ideas) where a map is simply a set of inter-relations between elements, just as an ordinary map is a set of spatial inter-relations between buildings, streets, hills, streams and so on. We can conceive ourselves as reviewing our information (ideas, concepts) so as to discern their actual inter-relations and then represent these in Tinderbox. Or we can conceive ourselves as creating their inter-relations which we represent in Tinderbox. In fact, this distinction between conceiving and discerning will not last, because even where we imagine that there are actual inter-relations, our representations creates new ones. If I represent a passage through a countryside (map) in one direction, some things (e.g. houses) appear on the left and some on the right. If I represent the route in the other direction, the same things appear, now reversed with respect to left right. This is so for any map and a perspective on it. So how I represent things is very important to how they are presented, to the relations that appear to me, to how I think about them.

Again, to make this more concrete, we can use a historical example. The Austrian philosopher, Wittgenstein, was unable to arrive at suitable presentation of his later philosophy because he felt that what he needed to do was criss-cross the conceptual topography he wanted to present, over and over again, because each route across the conceptual landscape would produce different intellectual illumination. The linearity of a book worked against this. Tinderbox may or may not offer a solution to the problem of presenting or publishing a conceptual topography, but it certainly offers a powerful tool for doing the thinking involved. (Wittgenstein resorted to obscure parallel numbering schemes, or to cutting up copies of his ideas and re-/arranging them with glue–none of which satisfied him.)

The key idea from these examples is that each route through the concepts (ideas) is a distinct set of inter-relations between them, where inter-relations are those that can be represented in various ways using Tinderbox.

This is how I am using Tinderbox to the best effect. However, I have found a shortcoming, and I believe that fixing this shortcoming would permit an additional, powerful way of using Tinderbox.

The shortcoming is with aliases. Creating an alias creates a de facto relationship between the original and the alias, which is hierarchical or asymmetric because the two are not duplicates in the right sense. But really I do not want to create that relationship, I would like something that is self-identical in almost all ways. I do not want to have to make decisions based on whether I am using the alias or the original, because the relationship is not meaningful in relation to the content of the notes, that is the idea (concept) with which I’m working.

Again, let me give a specific example. I may have a note whose content ($Text) is the idea that evil is the privation of good. This note has my current thinking on that idea, which, as clarity comes to me, I will augment with further thoughts about that idea. Now I want to use that idea in several places in my conceptual topography. I would like to relate it to the metaphysics of good and evil; to the asymmetry of doing good and avoiding evil; and to the content of moral thought. The relations may not all be the same, however. In one I may want to place it in a container. In another I may want to put it in a web of links. In the third I may want to position it spatially near and above some other ideas. No one of these inter-relations is primary, so none is the natural place for the original, or indeed the alias. Why should I have to make this choice? Why should I have to remember this choice? Why will any automations (e.g. rules) have to take account of whether this is the original or the alias? There are consequences too, if I delete the original, my aliases disappear too; though not the reverse. Parent child relations are degenerate between originals and aliases, for example.

The solution, it seems to me, is to have duplicates of notes that are self-identical (in the relevant sense) so that there is no implicit hierarchy between them. In DevonThink this would be called a replicant. In some UNIX-based filesystems this is what you get with a so-called hard link. In my case, I’d like one idea to occupy two (or more) places in my structures of thought as represented in Tinderbox. In the file system case, there is one content (the file) but more than one “address” or entrypoint to the content, viz. places in the filesystem directory structure. The directory structure is really just a space of names and there is no problem if two names (e.g. /a/b/c.txt and /a/e/f.txt) refer to the same thing, just like there is no problem if Clark Kent and Superman refer to the same extra-terrestrial. Obviously there is a difference if he is introduced to you as Clark Kent or Superman, but that is the point: each name provides a different re-/presentation of that person. That is what I would like to capture in my thinking as represented in Tinderbox.

There could still be an indication in Tinderbox that a replicant had a counterpart (i.e. the replicant with which it was self-identical just as the italics indicate aliases). In DevonThink the names of records are shown in a different color, but you could also have a flag or replicant count appended to the note name.

The point of a replicant, like an alias, and unlike a duplicate, is that when you add to or amend the content (i.e. $Text) you are changing it for all replicants. So if someone asks whether I cannot achieve my multiple routes through the same conceptual topography in Tinderbox by simply putting one set of relations into a container, duplicating the container, and then changing the relations in the new container, I reply that I cannot because then when I edit the note in one container I have to edit in all the other duplicate containers.

–> Have I missed something? Is there some way to achieve the functionality of replicants as I described them in Tinderbox today? Is there a good way to meet the use case I’ve set out without replicants? (I should say in advance that I do not think tagging will work here or, if it does, the overheads thus created are not worth it.) I say this also having reviewed the discussion around John Weiland’s mention of replicants in January on this forum, in which I never quite understood the use case. That is why I’ve tried to set out my use case (or cases) more clearly. I also noted Mark Anderson saying Tinderbox does not currently do this: I get that, which is partially why this is in Off the Wall and also is a kind of feature request.

While thinking about this problem and the obstacles to implementing it in Tinderbox, I realize that there was a kind of mismatch in my thinking that might (or might not) be reflected in Tinderbox, which is what leads to aliases. Aliases are tricky to implement because, as the design note on them in The Tinderbox Way notes, it is unclear which attributes should be essential to the alias and which should be shadows (i.e. duplicates) of the original. However, if you think the content (of the idea) that the note contains is fundamental, this problem goes away. All that matters is whether the content of the note is identical. If it is, then two notes are replicants. You can conceive the content as $Text or $Text+$Name without consequence, though you do have to choose either one or the conjoined pair. These are the essential attributes that determine the identity of notes, all the other attributes are inessential or accidental. Tinderbox, I believe, treats the note, rather than the content, as fundamental, which is why so many more attributes have to be considered essential. If that is right, then it seems to me that one way around this is to think of a note as a container for a content. Content is identical irrespective of the notes in which it appears. Notes could be made more or less identical according to various sets of attributes taken as essential, so there could be a variety of alias types or the current one.

I’m not arguing for getting rid of aliases. I see their value in agents, where the agent effectively synthesizes references to notes, rather than notes. No doubt there are similar places where an automated operation is best done with aliases.

If replicants existed for content, then I think we could be looser with notes. A future Tinderbox could offer what I will call “possibilities” which is at root, the same content with different structures of notes. Another way to put this is that a Tinderbox document would contain content (as I’ve described it above) but many possibilities for how that content is distributed into notes. Again, to give an analogy, over time, the world contains the same individual people, at different points in their lives. Those lives have different possibilities, but for most of those possibilities, whichever become actual, the people remain, i.e. they are the same person–Tom may get that job or not, but he is still Tom whether he does or not.

The idea is that in Tinderbox (version 8?) a document would have different organisational structures–i.e. the same content in two maps or two outlines, all four different, differing perhaps even in the numbers of notes in each–where each collection of relations is called a possibility. The number of contents would be constant across all possibilities. At the UI level, you could tie each possibility to the same window, i.e. each window contains solely views on one possibility. Leaving aside implementation complexity, why not? I think we’re talking about different logical spaces for the same entities.

One “cheap” way to implement this would be to permit the creation of inter-document replicants. Then each document would be a possibility, though you would still have to make sure that the totality of entities (i.e. all the entities), where, on this approach an entity is a content, was the same between documents. This means synchronizing entity creation and deletion, which might be ugly in terms of user consent and notification.

At any rate, the implementation difficulty is not something on which I can speculate, nor whether this feature would be of value to more than a few users.

–> I would be interested in other people’s thoughts.

I apologize in advance if there is something rather naïve about my discussion and proposals. I have been using Tinderbox for only about a year, and I do not have much grounding in the hypertext movement out of which it originated. I believe that might urge a presumption of directionality to the thinking behind Tinderbox. So it could be that this is an amateurish re-hash of some well-trod ideas. If so, I’ll welcome directions to concise presentations of these ideas. Mainly though, I’d like to make better use of Tinderbox for my own thinking, so I welcome suggestions of any kind in that regard.


The point in concise form was that aliases imply a relation between the original and the alias, which is not there with a replicant. This relation is not meaningful in relation to the content of the note, yet it has to be tracked by the user because it is important to software. For me, Tinderbox is at its best when your focus on the content of your notes is not encumbered by thoughts about software.

I defer to other’s expert knowledge of DEVONthink (hint: ^^^^^^^),. It certainly chimes with feedback I’ve heard about replicants. The fact such a thing doesn’t exist in a long-lived and well-picked over app as Tinderbox (which dates back to 2001, with even older '80s lineage from Storyspace) might be because the concept of the ‘replicant’ is hard to implement in useful form.

I don’t think it’s hard to build a ‘replicant’ in Tinderbox (let’s punt the mechanics to a separate thread someone can start if interested in the practicalities). I believe most (all?) things needs are present. All the user has to do is to pick the subset of features to clone.

And there’s the rub. Indeed, as is laid bare with existing aliases and their considerations of intrinsic attributes & links, there isn’t a simple central common truth (no one right ‘way’).

This sounds like an argument “don’t make me think”, which seems inapposite for knowledge work. That’s not snark, I’ve trodden this path in my own use of the app. The joy of using Tinderbox—reflecting on 14+ years of use and the journey therein—is that a need for ‘some assembly (of ideas) required’ to implement one personal desired feature set is a good thing. A lot of the work I do here in the forum is, in hindsight, helping people realise that what they are doing is personal and not a behaviour dictated by the app: one-size-fits-all is the enemy of nuance. But, nuance matters.

I think aliases—whether in agents or created manually—do, with prior consideration, meet most of the needs stated. The Devil is in the detail, not the $Text but the links and key attributes and that’s not really fleshed out enough in the opening post.

In closing, I’m not trying to be contrarian or shill for the status quo. I’m just no clear, in design terms, what the ‘replicant’ is really doing.

1 Like

The remark on replicants in Devonthink (which I have also used for years) seems to me a red herring. There is no conceptual problem with replicants in Devonthink of which I am aware. There may be an implementation problem which leads to inconsistencies in the database, but the idea and the feature have proved useful to me. But Devonthink is not Tinderbox, it is more like a database because the range of relations that can be represented is very limited and the records are quite regular in their forms.

In any case, I just used replicants as a way to refer to something familiar. Hard links illustrate the same point more neatly.

Don’t make me think is a good principle of user interface design, but that is not what I mean. I want to think, but about my ideas, not the software.

So far responses to my post seem to be saying that the difficulty I’m describing is not an actual difficulty. I’ll try once more, because the difficulties I’m having are actual (thus necessarily possible).

When I add a note that will occupy more than one place (i.e. in a map, in a container, in an outline) in my Tinderbox document, I have to ask myself the question, “Where should I put the master and where the aliases?” That question is mostly irrelevant to the content of the note since the master/alias relationship is almost always irrelevant to the content of the note. So I have to think about the software and not the note. The replicant obviates this question and protects me from possible consequences of forgetting which is the master and which the alias.

If you don’t find the difficulty compelling, that’s fine. I’m not saying Tinderbox is useless without this or Tinderbox is broken.

After a year of using Tinderbox with increasing seriousness and commitment, this difficulty is an itch that I wanted to scratch. The length of my post was partially thinking my way into a precise diagnosis of what was bothering me. Conceptual topography (≠ information modelling) seemed also of relevance to Tinderbox and Tinderbox users. Hence, why I put it in Off the Wall which seemed like the right place for it.

Proofing fail - I meant ‘inapposite’. Now corrected. Reading the rest of your last…

I think you’ve misunderstood me Paul. I know that replicants are one and the same, or more precisely that they are all self-identical. That was the point of my likening them to hard links. It was also a point I emphasised at length in my OP.

I am sure you’re clear on the difference between the logical idea of replicants and the realisation of them in the software implementation. Many people are not, which is why DT users often misunderstand them. That being so is not a reason to think that somehow it is a bad feature unless you also want to keep the software simple for a large number of users. That seems a valid goal for DT and its market. Tinderbox and Tinderbox users are a different kettle of fish, or so I infer from lurking on this forum. Serious knowledge work–as opposed to information collecting–in my experience almost always depends on making distinctions regarding levels of abstraction of which logical/realisation is just one pair. These were premises in my discussion.

Well the note has to live somewhere. As, @PaulWalters points out, the DT replicant is just a programming sleight of hand. However, I’m not sure the same holds true in Tinderbox which also has to cater to its hypertextual element: links (can) matter. If I link to a replicant, to which instance am I linking? Whilst that might be moot within a Tinderbox document, it certainly isn’t when it is exported, and thus the linkage status quo. Usability of Tinderbox-gernerated output like aTbRef leans heavily on this facet of aliases and linkage.

“why should I have to…” is always seductive in the moment but in any but an evanescent project I find it does matter: I do need to understand my thought process and as opposed to what the app does. So the initial gratification, is just make-work for later.

Maps work well if all is in one map and not too large. After that it makes sense to continue thinking in spatial hypertext/map ways, but storing/reading your work in outline form (trust me, that transition gets easier with practice). Once you move off a single map, this throws into question how you capture the nuance of your work. Map (visual) links might as easily become (attribute) ‘tags’, etc. Most instrinsic attributes are positional (in either map to outline sense) in nature so won’t affect your 'thinking metadata.

If you edit $Text of an alias you edit the original $Text. However, an alias shares ‘basic’ links (i.e. note-level, not $Text-level) links by default. ‘Text’ links (from withini $Text) always have the same target - as aliases share the original’s $Text. But, if desired, an alias can have its own in/outbound basic links. The create link dialog enables this. For instance, if either source/target are alias(es), for you to chose if the link is between originals or aliases (here both source/target are aliases):


Action code linking similarly now offers alias/original link anchoring choice.

However, unless I mis-understand, the residual issue here is that you feel Tinderbox asks you to remember where the original is, and that such a task is unduly onerous. Except the app doesn’t do that - an alias always has some form of subtle visual distinction. Also, a selected alias offers methods to find the original;

Might I ask, if have you fully tried using aliases? If so what are the practical (as opposed to theoretical/conceptual) problems encountered?.

I ask this simply because I’m not sure I see correctly the real benison of a ‘replicant’-type feature apart from the mental comfort of conceptual alignment. For a small artisanal shop like Eastgate with an already complex tool, where is the ROI? (disclaimer: I’m not connected to the company, just a long-time user of Tinderbox).

Mark, thank you for your reply. You are, as ever, very generous with your time and effort.

It has become clear to me that the distinction between the two use cases I set at out at the beginning of my OP did not come through. And, my elaborations of the second use case have not had the intended effect or clarity. No doubt, I have got the balance between length, time spent, and precision wrong when writing the OP.

I appreciate the suggestions you made for how to use aliases. I do use aliases. Simplifying, I put all my notes for a particular bit of thinking into one container. I arrange them just so in the outline and in the map. Then I make aliases of all of them. I Edit:Cut those aliases and paste them inside a second container. Call the containers Possibility 1 and Possibility 2. In Possibility 2 I arrange things just so, in some way that is different from Possibility 1.

Now I have a new idea. I create a note. The first thing I have to do is make an alias, then I have to put the original in Possibility 1 and the alias in Possibility 2. Of course that means remembering which is for which, or not remembering and getting a mixed population of aliases and original in each of Possibility 1/2. Scale up for several possibilities. Then when using some automations, make special cases for aliases behaving differently than originals. This is just friction for me.

What is the real world analog? Before Tinderbox, when trying to understand things, I would write/draw lots of maps inter-relating the same basic concepts from the domain in which I was working. This was good because I can then easily survey, say, three maps. And seeing the same concepts set out in different ways was illuminating. However, there were some big problems. First was consistency in using all and only the same concepts with the same descriptions. Second was editing maps because if I made a change to one, I’d have to make a change to the others. Tinderbox fixes these problems. It can do so in part because it has so many ways of expressing/indicating relationships between notes–so it is not limiting the way mindmaps or outlines are–and the richest variety of these are on maps, which I think is what is shown in chapter 7 of The Tinderbox Way. To be concrete, in Possibility 1 I cluster things one way, in Possibility 2 I cluster them another way.

So, to be clear, Tinderbox is great. It really is a remarkable piece of software because you can build things from a toolkit of highly expressive relationships. So I am already ahead, because Tinderbox fixes many aspects of my analog approach. (I often start the first map in analog, but that is to do with psycho-somatic limitations.)

I believe, from what you write, that you are thinking that the ultimate goal is to arrive at one single structure for the information. That might be because your analysis is now complete or because your model now satisfies your aims or because what you have is now in a form that can be output to an article draft or web page, etc. So when you say that I’m making work for myself by not deciding at the time of creation where to put the alias, I believe you’re missing the point. There is no single structure at which I am trying to arrive, and so there is no first, best effort to get it in that spot now. It is important to think, where would this idea go in Possibility 1; where in Possibility 2; and so on. That process is, for me, the process of understanding something, well enough, let’s say, so that I can see the “moving parts,” the different ways the ideas inter-relate.

You might be thinking, “OK, but what is that in aid of? Don’t you want to do something with it eventually?” Understanding is its own end, but I’d agree this would look rather contemplative if that is all I wanted to do. In my case, I usually want to write an article. But the article will not be built out of the elements of those maps, so it is not a matter of now using the notes in those maps and arriving at one true order or structure or even outline (outlines are just one limited form of structure, as you know). Writing an article is a different problem, for which outlines are good eventually, but that is because an article is one presentation (of many possible) using elements and responding to limits that may be peculiar to the article (word count, readership, a particular example as the orientation for this discussion, and so on). The conceptual topography (which is the conjunction of all the Possibility x maps) is of enduring value, for the next article, for the next bit of thinking.

I’ll gesture at one more real-world analog to this. There are many ways of modelling the business logic of some part of a business. Some of these will lend themselves to one software system architecture and others will lend themselves better to others. Which one you choose that year will depend on other constraints (budget, skills on hand, timeframes, appetite for risk, etc.). It is not a perfect analogy, but it is similar to analyses I have had to do before where you want something that can generalise well. The example I gave about evil as the privation of good in my OP was also a real world example from one of my Tinderbox documents.

As for your question about ROI, you might be right. Maybe no one else thinks like this or would find the benefit of a “hard link” (not going to call it replicant, since plainly there are those who want to retire the skin jobs) greater than alias. I was stimulated by the kinds of discussions in The Tinderbox Way and I guess I meant my discussion as a sort of segue.

Sure, but I still don’t understand how this is not possible using aliases. I ask because as things stand ‘hard links’ are essentially a feature request (if someone actually makes a request) and not here today. Today we do have aliases so we should properly investigate them as there limitation, for you, might be conceptual rather than practical.

If the item in ‘Possibility 1’ is an original and in ‘Possibility 2’ an alias - or if both are aliases why does it matter - in a practical sense?

If you’re worried about deleting an original by mistake, put your originals in one part of the doc and only use aliases for your map. also, in case assumed otherwise, making an alias of an alias creates a new alias of (i.e. pointer to) the original and not the alias used to create the new alias. IOW, you don’t have to find the original to generate a new alias. Indeed, if desired you could make an agent that finds all your
concept notes, thus making an a single alias of each of those original notes. If you drag an alias out of the agent and put it, for example, map ‘Possibility 1’ then the agent will replace that alias with a new one. Perhaps less intuitively if you copy an alias in the agent and paste it in the map you generate a new alias (based on the same original note). Essentially, you’ve created a ‘tear-off’ pad of aliases for your map-building.

Alaises can’t nest - though in some context the originals descendants can be accessed via an alias**. However, I don’t see an expectation that replicants should allow nesting. Indeed, I suspect supporting the latter would complicate things.

** As I write I forget the exact details so won’t guess detail from memory.

Rather than type past one another here, could you perhaps upload a small TBX that exemplifies what you can’t do? Ideally, with note(s) in the TBX whose text explains what you want to do and what you can’t do. Having a real rather than a conceptual example might get us to the meat of the issue more quickly.

  1. Let me begin by saying that this is a very interesting (and very rapid-moving!) discussion, and that I have read it with attention and interest.

  2. It may be helpful to distinguish meanings that are clearly present in the construct from those that we attribute to them. An alias is deleted when its parent is deleted: this is the nature of aliases. Whether this makes an alias subordinate or subsidiary, on the other hand, is not entirely clear. In particular, if we never delete notes (and I argue in The Tinderbox Way that we should only delete mistakes), are aliases still subordinate?

  3. Web Squirrel, a predecessor of Tinderbox, implemented replicants but called them aliases.

  4. Changes in Tinderbox can originate from the user’s direct actions or from rules, agent actions, OnAdd/OnRemove actions, edicts, or network updates. Two different replicants might be changed by two different actors. If the changes conflict, how to we reconcile them?

  5. Replicants that are containers pose special difficulties. If we delete a note in container C, does the note remain inside C’s replicant rC?

  6. I am not asserting that the semantics of replicant containers cannot be defined, but it is not clear to me that they can, whether those semantics are unique, or if not unique, which semantics we ought to choose. This may be known — the network database community might know it — but I believe that nobody in the hypertext research community knows the answer.

  7. There’s a perfectly good PhD dissertation to be written around this.

  8. One workaround for the subordinate status of aliases is to keep all your original concepts segregated in their own container, and work exclusively with their aliases. The container of original concepts thus becomes the place where Platonic Ideals reside.

  9. The next major release will make it easier for a rule to refer to a note without knowing its name or path; that should help you make rules that copy $Name and $Text among a family of notes.


Thank you again Mark, for the effort to help me and for the offer to look at a Tinderbox file of mine. I’d rather not draw further on your time or attention, at least in part because my whole approach seems to me now somewhat idiosyncratic and probably of limited use to others. Your suggestion to have a reservoir of notes from which all “working” notes are aliases mitigates a significant aspect of the difficulty I’m having. I wish I’d thought of that. Thank you.

Thank you (other) Mark for your notes and for expression of interest in point 1. The promise in your point 9 for the next release is appealing and looks likely to help me, as you suggest.

Your point 8, like Mark Anderson’s suggestion, is very helpful to me now. (I must note, pedantically, that the container cannot strictly contain the Platonic forms of my notes, since the forms are immutable.)

No doubt you’re right that the semantics for this question are non-trivial. My confident tone arose from only superficial thought on the topic I’m afraid, but I feel that with sufficient, consistent varieties of the relation of identity or self-identity it seems possible. Some of these problems have been solved in the implementation of hard links, which can be hard links to directories (re: your point 5). I have no allegiance to the term replicant, in many ways alias (in the sense of another name for someone) makes more sense.

Your point 4 looks a tricky one. Maybe different actors could have different lexical priorities so that one supersedes the other. That is probably very hard to present readily to users though.

If the discussion has been any kind of stimulation to your work on Tinderbox, I’ll be glad.

Thank you also for The Tinderbox Way which has been peculiarly stimulating for me.

That’s generous, but don’t feel obligated. I aAsk because you’re asking interesting problems and it’s entirely probable I’m wrong. In my own current PhD I cleave to the notion that self -doubt is as useful, if not more so, than the critique of others. If my comments read as rebarbative, that is my failure not yours.

As ever, MB has turned up with a wealth of polite argumentation I can only guess at. This stuff is hard - if it wasn’t it would be be another poorly implemented feature in MS Office.

Please don’t feel that discussion this far is a wave off. I, for one, have been thinking about this (instead of working on my thesis) if that’s any sort of measure. I too find #9 interesting. I think I know from whence is stems. I need to go away and tinker.

But, please, don’t for a moment feel the underlying question is being rejected. This is interesting stuff, pertinent to hypertext and the sort of study you are describing. Indeed, why I remain engaged here is because there are always new approaches and insights as well as the technical landscape moving under our feet. Apart from MS Office—and its necessary age-related pile of creativity-smothering kludges—I don’t think anything in my Apps folder apart from BBEdit is older than Tinderbox (and Storyspace predates both).

Disclaimer/note: my current PhD is centred on Hypertext. I’m someone who is genuinely interested in the issues you’ve raised. :slight_smile:


I appreciate your comment regarding self-doubt and it usefulness in working on a PhD, or any kind of research effort. It took me a while to realize it’s importance, but when I did, I found it to be a very important realization.

1 Like