This is a good example of my earlier point about feature optimisation: link traversal/content display is one of Roam’s main features )or at least appears so from my albeit limited experience of the app).
Note that Tinderbox does not require links to have any notes to other notes. Consider a map view and doing some initial investigation. We might cluster notes about topic A separately from those on topic B. The spatial hypertext of map view now shows two discrete clusters of no notes without any links being used. Separately, Tinderbox’s hyperbolic view shows only the notes that are linked to the currently selected note. So, a map in the example would show no network. this shows a simple example of how different views allow different ways to look at notes in the document.
. Here I’ve 3 notes which link to Note : Miraaya birthday Party
Below I’ve created an agent which allows me to see all notes containing the same link from different places. I also see all text notes on the right side.
Agents aren’t a big deal. You can create them, and if they don’t turn out to be useful, or if you’re finished with them, just delete them. (Years ago, agents could create performance issues and so old-timers like me are sometimes worried about them. Nowadays, don’t worry until the document tells you to worry!)
As this is a discrete task, I’ve chopped to to a new thread (no censure implied!) as that helps later readers find potentially useful content. You can always add hyperlinks to your posts to cross-refer to other threads (or answers within threads).
I’ve added the build-in 'Person" prototype† and made a ‘People’ container that sets that prototype. In there I’ve made notes for our specimen callers so we can fill in things like phone numbers. I’ve then linked the call to each person in the $Callers list using a custom link type ‘call’. This is we know why there is a link; I could have as easily used ‘caller ID’ or such. Use what makes sense to you as Tinderbox doesn’t force a single answer upon you.
Now we can also look at the call in terms of who was involved using the Hyperbolic view:
†. Note that built-in prototypes don’t use atypical naming styles. So, with them I tend to either use the app’s name or duplicate the prototype and give the latter my own distinctive name. I can see ‘Person’ as a being a name of a note a user might create (‘pPerson’ or ‘*Person’, etc., less so). Here, I’d kept the system name for easier process copying by those using the TBX)
Thank you again fro taking time out to explain some of these concepts to me.
Once a custom link has been created “call” in this case , we can create an agent and do a query to filter, correct? If yes how?
Using people:name as an attribute is such genius move to capture existing people defined in dB.
Hyperbolic Looks wow but I’m not clear with it. Does it work due to each person being explicitly connected to it or due to our attribute of Callers where’ve manually put down their names ?
Hyperbolic view is used to explore links between notes – explicit links you have created between Note A – and → Note B, and so on. It is not about “persons” or “callers” by default, unless you have defined those types of links in your particular document.
#1. Filtering on link type is possible for action codes link links(), linkedTo(), linkedFrom(). The latter pair are simple boolean-resolved queries asking if the currently assessed note is linked to/from other notes as defined by the link direction and (optional link type filter). The best think is to try the code and ask if you get stuck. Your questions are more open-ended than you perhaps intended. I suspect this comes from recently using tools optimised for a small range of functions some of which I’m sure may not be possible—at least in the same fashion—within Tinderbox. Then again trying to understand this app from the perspective of some other app is not helpful to learning as it starts from a set of false assumptions (i.e. how the other app works) as to how Tinderbox is designed.
#2. User attributes are a very powerful and a great way of abstracting metadata whether from the noter’s $Text or just as further annotation. That said, some people perfectly happily write title+text notes and touch hardly any of the more powerful features. Tinderbox doesn’t try to set you on a particular path. this is why I think some find it hard to to get into as they are some used to the app telling them what that can (or as often can’t do. Getting back into the habit of thinking about what you want to do is useful. Of course, if that is simply trying to copy the limited behaviour in some other app then that’s not really engaging with the problem as one is still entombed is a set of workflow assumptions which are not longer pertinent. You will find those who get the most out of the app look at the nature of the task rather than the exact detail as to how it is achieved.
#3.Hyperbolic view shows all notes linked directly of indirectly from the current selection (at time of view selection - the note with a read border. Clicking another note selects it in the text pane and rotates the view (on the underlying spherical plane) so as to centre the selected note. Double-clicking a note makes that the centre node (terminology not established?) for the view.
Put another way, two notes that cannot be reached by traversing links (which excludes the document outline’s hierarchy) cannot appear on the same map. In a large document it is perfectly possible to have discrete networks of linked notes in the document with no common links—I.e. the two networks cannot be viewed at once as they have no interlinked. IIRC Obsidian shows a database-scoped force directed patters where individual or small clusters are pushed to the edge., which is a similar looking (box-and-line) graph but arrayed for a different purpose. The nature of what the note represents is irrelevant in therms of the view construction which is link centric.
I’ve added some more data to my test doc (see new prototype example3.tbx (100.1 KB)) Example 4 has no callers in common with other calls, whereas call 1 2 and 3 do share linked callers. This should help you to experiment.
I thoroughly commend @PaulWalters’ recommendation to just try things. Tinderbox is quite happy to make lots of documents. Making a new small doc to test just one small thinking is a really powerful way of moving forward, not least as it makes one figure the inputs/ needed/outputs expected thus refining understanding of the process. The temptation is to make one document and try and both make a clean working doc and lear the app all in the same place. That’s possible but making life harder than it should be.
I’m hoping to experiment a lot with this week with link() and linkedto() . You re right questions are open ended , I will be focusing them slowly over a period of few weeks. My understanding is indeed coming from the apps I’ve used before, TB is just such a different type of beast. Only thing in my favour is some clarity in the outcome I want to achieve. Issue here is to figure what all TB can do , I’ve to read more / view more use cases to figure this.
This will require a long(ish) topic but I did move out of Roam when after 2 month of using it , i was going nuts in trying to connect back the information , queries are highly recommend in Roam world and MOCs(Memory of content) where each note is excessively tagged , both solution I find “hack-ey” , with 2 hours of using TB I figured USER ATTRIBUTE is the clear answer .
Hyperbolic view is clear(ish)
Learning to create ‘multiple’ new files to try and do things is something I’ve innate fear of and struggling with , I’ve a fear that I will “loose” things and not be able to find items, it’s ridiculous but only when I start trusting TB (which I expect will take time) i will figure this.
A benefit of Tinderbox vs. the web-only thingies is that everything in a Tinderbox document is in plain sight. There’s nothing hidden offline in someone’s cloud. True, in a longish document discovery might be a bit of a challenge, but there are tools – Find, agents, etc.
For what it’s worth, I’d advise experimenting elsewhere. Both of these are fairly “advanced” in practice, and they’re not very usual approaches to Tinderbox. It might be better to get a firm handle on idiomatic Tinderbox first. (Normally, I might say “Sure! Go for it!” But earlier discussion revealed a previously-unknown bug in using unlink actions in map view, and there are other developments on the horizon that might make this easier.)
If I may, as a long-time on-and-off-then-on-for-good TB user, get the Winterfest discount anyway, let it grow on you slowly, there’s a lot (as I painfully learnt) in the “things I don’t know I don’t know but I wish I could have but was so sure would never exist that I didn’t even ask anywhere” bucket.
If you end up using it a lot, great. If you end up using it a little, great. If you end up not using it, but learn more about how you like to use things, great.
