In my maps, I make a practice of annotating most of my links to conceptualize the relationships between the concepts I’m learning and often I want to link from the link annotations. I’ve made a brief demonstration video using CMapTools here:
We can’t do this with the current version of TBX, right? (I do realize I could kludge something together with note styles.)
You can annotate links using link types, either using types already defined (#1) or adding new ones (type the value in at #2):
Any new types so defined, on the fly, are then added to the current documents list of already defined link types (which are then added to the list of already defined links):
in Tinderbox, links can only link two notes, so a branching 1-to-N link as shown in your video aren’t possible. That said, in all but the visuals this seems the be the same—in linkage terms—as your concept map:
If you want to use the map just visually, you could make one of the notes have no link type and move the label of the other link:
Of course, be aware if you use action code to compute across the links in the latter case, only one of the two is of type ‘can be’.
This scenario highlights the issue of trying to make two apps from different design intent/methodology behave the same. most often we users do this where we want the less used app to be more like the app we are more familiar with as it would lessen our need to learn. In this case the underlying methodologies treat (visual) link (lines) differently. In the CM map, they are part of the argumentation/semantics. In a Tinderbox map they show the hypertextual relationship between objects. Any note my link one or more times to another note and those links can be of any link type or none. Links are not first class objects and have no discrete (textual) metadata beyond the link type. However, action code does allow computation across the hypertext (network) to some degree.
Bear in mind that if you want to fine tune the map visuals, if you export the map as a picture, if you post it into a vector-based image editor, you can make further edits. Here’s our map pasted into Affinity Designer (so, similar to using Adobe Illustrator):
Same Tinderbox map data pasted into Mac Preview:
Items are selectable but Preview isn’t really an image editing tool. I also tried OmniGraffle (Pro) v7. Oddly that imports the data as vector artwork but as a single object that can’t be ungrouped.
I hope that gives a few ideas.
Specific instances of links have a few rarely-used fields available to them that can be seen in the links info popup – press the “i” next to an actively selected link. These fields, especially “Target”, “Title” and “Class” can be repurposed for notes about that link between these two notes.
These fields are intended for HTML export and nothing is harmed by using them if you are not interested in their use in exports.
In addition you could use Captions or Subtitles or Hover Expressions to annotate the links related to a note.
All of these ideas are kludges.
What we need in the links popup on maps is a “Link Note” field for annotation text, and an option to have that note appear when the link is hovered – so that it is a “Link Hover Expression”.
FWIW, and going back to the derivation of features, the Target/Title/Class inputs relate to one of Tinderbox’s original uses being for blogging, and the HTML export that entailed; these inputs populate those attributes of an HTML <a> link element.
The general utility of these features is lessened slightly by the fact it’s hard to auto-populate these values. Now web pages are more capable, being able to pass a links link type (or a CSS/JS-safe version of it) to the class box would be useful as it would allow for more powerful (formatted) export of hypertextual data. I think it’s chick-and-egg. It’s hard to see the ROI on making this better integrated when people don’t (manually) use the feature yet without non-manual insert of exported HTML values it’s hard to show the ROI.
If you look under the hood at aTbRef’s TBX, most links are typed which is a legacy of an original plan to try and indicate link purpose via a CSS class. The latter doesn’t have to have any visual effect but can be parsed from the DOM and used in other ways besides the page’s visual render. As we move to an era when code (software) will be as much a ‘reader’ of our docs as human, being able to embed more metadata as to your thought process is good. At a simple level it’s it easier to tell some ML/AI process why a link has relevance rather than force it to guess the same info.
