My suggestion is that you set aside some time to read how the app works before experimenting further. most of your problems stem from simply assuming that all apps are alike. Easily done, that’s not to judge.
This has, in fact recently been suggested albeit for a different purpose. A non-trivial ask at is has nothing, in common, bar attribute values, with the current Map view.
Meanwhile, I’ve taken a first crack at a dynamically alterable map. There’s a bit more to do to make the demo usable to a general audience. I’ll post it when done.
I think, that my general assumption atm is, that TBX is capable of anything I’d ever want. Stuff like this is not there in any of the other apps I’ve tried neither.
Nothing I’ve used previously even has the nested maps (does anything capable of that even exist, besides TBX?).
On the forum or elsewhere/private? If on the forum, I’d like a link
I forget. It’s scattered over various conversations. The genesis was making a map and being able to ‘preserve’ a certain presentation. The problem is that as a doc moves from map-based (flat outline) discovery to the likely export phase, where structure (outline) is needed, nested items disappear form the map. Yet the original map (withi visible link lines) is often still desired. This circle is still being squared.
Thanks, I’ll put it in a separate thread (and drop a link here). Almost there, just doing the ‘read me’.
Responding to the OP, I have wanted to do exactly the same thing for some time. I raised the issue twice I think in the forum, but in the context of having “replicants” or “hard links” that were upgrades from aliases, because they were handles to the same note. On the view I advanced, you could have Map A with a mixture of notes and replicants x,y,z placed in such and such a structure and Map B with a mixture of notes and replicants a,b,c. The key idea was that x,y,z and a,b,c all refer, respectively, to the same underlying note, call each p,q,r. A change to x would be reflected via p in a and vice versa. This is why I say they are a bit like hard links in some Unix file systems.
There was not much support for my idea. One, to my mind valid, concern was that you would still need to mark a difference between intrinsic and extrinsic attributes as you do with aliases. So the implementation would have to draw the line of demarcation differently and whatever that new demarcation it would have to offer enough additional value over aliases to make it worthwhile.
The second concern was that few people saw the use cases. In my case, the use is and was, the desire to make maps of conceptual inter-relations, and more specifically to arrange the same sub-elements in different ways to think about different potential inter-relations. (You could call these different or partially different holisms, if that term helps.)
At the time there was no action script way to create notes, so I trialled an approach in which I had a master container of notes, which several other containers monitored. When a new note was added to the master container, a new note (a copy) was made in each of the other containers. Then I could arrange the map for each container as I liked. It did scratch the itch a bit but the system proved very fragile. Moreover, I had wanted to edit the notes’ text in whatever view I was in when some new insight occurred. Replicating these changes to the original or derivative notes proved far too difficult. I’m not sure it was impossible, but I felt the effort involved would be like trying to eat soup with a wrench.
So for this particular purpose I am back to using paper and pen, which is no great hardship.
Useful exposition here, though you’ll also understand why I placed caveats as to intent on the linked demo above. It’s not because I disagree with the other contingent ideas but because they aren’t tractable in the app as currently designed. For instance, until/unless Tinderbox gains a notion of ‘replicants’ (orriginally a DEVONthink notion?)
The kludge my demo uses is to save, for all affected attributes (the demo only uses some of that possible range), the attribute value(s) per map version in a separate attribute. This allows the a ‘set’ of saved values to be read an applied to the notes in the current map view, bearing mind that for a given container there can only be only one map visual variant at a time. IOW, my demo doesn’t mean you can have N tabs/windows open showing at the same time differently rendered maps of the same notes.
This is very interesting aspect of PKMs. Are map variants each a full-blown thinking space or are we really looking to save diagrammatic snapshots for export/comparison/… ? I don’t claim to know the answer here, thus the question. Plus, despite my moderator/admin role here I say that as just one of many users of the app. It’s different to explore this subject as most PKMs are text-based so, experientially, many users have little by way of practical example from which to work. What’s imagined is not necessarily easily made manifest.
This is not—I think—bad or ill-observed. However, it does start from a different view implementation that the current map view. An entirely innocent error in a lot of map view ‘improvement’ is to misunderstand that the proposal is in reality not an improvement to an existing but rather a whole new view. There’s nothing wrong with the latter, but it better exposes the degree to the work for the developer to ‘just’ manifest the desired change. Most PKMs are not made by corporations and time/resource are finite, which as users of an app we easily forget: what we don’t understand is inherently how easy/simple to those changes are to effect.
I’m not sure if that moves things forward, but is my understanding and I hope the (linked) demo is an indication that new ideas are not ignored here and users are exploring the envelope of what is possible.
BTW, RE this, I agree. I backstage I’ve been calling for a new view “Diagram View” to accomplish exactly this idea. @eastgate, @mwra, @PaulWalters have been contributing to the refinement of the feature request.
Note my linked demo doesn’t address the latter, or being able to display two different maps of the same notes at the same time. These are all discrete use cases/requests.
Thanks Mark, I pretty much agree with everything you said. You’re right that as currently implemented, what I am thinking of is more like a new view. But the differences may go deeper than that and my own ways of putting it and thinking sort of obscured the difference.
The current way that Tinderbox works I’d say is roughly that there is a single large structure of notes with attributes. Each view offers particular affordances in relation to some attributes of the notes in that structure. So the Map view focuses on spatial attributes and renders those visually. Outline view disregards spatial attributes and gives priority to the order attribute and the hierarchy attributes. And so on. The note is the atom and it is its attributes that are fundamental.
(This is one reason that links do not have an independent existence, each is an attribute of a note. This point has come up in past forum discussions where I suggested they might be made “first class” or independent entities because they were themselves a kind of semantic content.)
What I described and which I think the OP described would imply some kind of duplication or overloading of some attributes which would be indexed to a particular view. So map view A on notes p,q,r would show them according to some spatial attributes (e.g. xpos,ypos). Map view B on the same notes p,q,r would show them according to different spatial attributes. But a note can only have one set of spatial attributes at a time in the present implementation. So what is implied for this to work is that note p in fact has a two-dimensional array of spatial attributes roughly like this p:{[A(xpos,ypos)],[B,(xpos,ypos)]} where A and B stand for map views. In fact, it would have an array whose first dimension was as large as the number of relevant views in which it appeared. My point is that this is non-trivial and in a way more than just another view and there is a serious question to answer about which attributes should/could be indexed to views of any kind. (You can see that replicants as used in Devonthnk are there to solve part of this problem because they facilitate the presence of the same entity in more than one containment hierarchy.)
This connects to your well-observed points about PKM software and thinking-assistance software. If you think of Tinderbox as a PKM tool, then the use case I described is probably out of scope. DevonThink seems to me a clear-cut PKM tool: it stores knowledge and facilitates finding, managing and annotating it. Somehow I’ve never really thought of Tinderbox that way, which I know is a personal view, even though it can be thought of that way. Tinderbox’s appeal for me is that it is a kind of “doing” space where you can do things: think with them, think through them, make connections, and create in a surrounding of contextual content. To make a crude analogy, Tinderbox can be in thought like one of those exoskeletons that people can wear to enhance their strength, reduce their fatigue, even increase their reach.
At any rate, that is a kind of personal hope for Tinderbox (and I am not aware of any other software close to doing what TB does). I’m a second-rate user of TB compared to some people on the forum and its first appeal to me was that it reminded me of Hypercard because of how one could “automate” notes. Hypercard was great but was still mainly, in my view, about traversing a body of content with some dynamism in the content and the traversal. Tinderbox can do that, but seems to me also to hold out the promise of augmenting the thinking about that content.
Note quite! The outline is actually the primary view and represents the stored XML structure of a TBX (see The XML TBX format). The order of notes in the outline ($OutlineOrder) is key to a number of behaviours in Tinderbox, e.g. selecting a single match from several where Tinderbox uses the first match as sorted by $OutlineOrder.
Meanwhile, a map only ever maps a single container within the outline. See more on map vs outline considerations.
Actually, this is not so. Unlike many apps that ape the Web style of embedding links into documents, Tinderbox cleaves to the older, more powerful, hypertextual notion of a linkbase. Links are stored entirely separately from the note data. Open a TBX with links in a code editor like BBEdit and look for the <links> element. It will contain a series of <link> elements, 1 per tag.
Thus links are essentially first class objects, even if not obviously so. A mis-presumption likely arises as the app applies/renders any Text/Web links to the $Text area and, in (map view) any Basic or Text links to the view area.
Please forgive my apparent pedantry here: that is not my intent. But, mistaken assumtions can derail well intentioned ideas about possible new uses.
In Tinderbox links are discrete and (uni-)directional. However, they can be traversed/computed across either way or traversed visually in Hyperbolic view. The latter essentially shows those notes in the whole TBX that can be reached from the current note by traversing any type of internal link in any direction (disjoint , unlinked notes are thus omitted). Although not formalised to the extent, say, of Roan, it is possible for basic or text links to link to anchor text. It is little done/seen as Tinderbox design concept is many small notes rather than notes with long screeds of text that inherently require closer addressing to find the needle in the (textual) haystack of the target note’s text. Unstated assumptions both note size and linking can derail our thinking.
A structural limitation for internal links is they fun between two objects. If note BBB has an alias BBB and note AAA links to BBB that link cannot go to both BBB and BBB. At least it can’t without an extra switching function where the human user would need to indicate which of the two possible targets was intended. Such an approach would damage the current powerful ability to query/reason across the network.
Notes and aliases share all outbound links (basic/text/web). However an alias may be given discrete outbound basic links—though this is rarely seen. When exporting, the logical endpoint for much analysis, a link to an included note (i.e. where a note forms part of the exported content of another note) is not sustained. In theory it might be done (i.e. if were to be engineered so) but currently this in not the case.
In principle, Hyperbolic view ought to cover much of what is being sought but it:
controls layout
does not plot notes not reachable via link traversal.
Yet, in map view we may often build rich layouts with some/no links and using deliberate ‘manual’ placement of notes (i.e. a structure really only reflected by building of {x,y} positional data.
For me Tinderbox is both a PKM and a thinking space. Indeed the two blur. I’d add from context that to me the ‘P’ in PKM releases to scale (desktop vs enterprise), sharing (single-user space) and privacy (personal vs. public). Apart from fixing other people’s TBXs I primarily use Tinderbox for exploring new problems where the structure is as yet unclear, so Tinderbox’s flexibility and support for incremental formalisation are second to none (at least for me). Still, almost 20 years of looking at/trying to understand other people’s TBX documents shows there is remarkably little commonality in the way we individually use the app. If there is a degree of concordance it tends to be conceptual which thus hides often significant difference and creates confusion in discussion: i.e. we’re doing the same thing … differently.
I think a contemporary problem is we tends to view programs in terms of what they let us do. I think that’s the wrong way round. Rather our tools for thought should assist us. Then as in any collaboration we may need to calibrate pragmatically our approach within the constraints of the possible
Too harsh! We use what we need. Few if any need to use every tool in the box. Though we see some complex/niche things here it is generally because they butt up against the known edges of what the toolbox can do. By comparison, doing close/reading annotation can be both rewarding in Tinderbox but yet use only a few of the tools in the box.
I think you may have misunderstood what I intended or imputed more emphasis to certain aspects of what I was describing. That’s not very important.
I disagree though with the idea that links are first class objects logically speaking (and how they’re stored seems to me irrelevant since it is completely contingent). There is no way to traverse the “linkbase” at present except by traversing the notes first. Up until recently, there was almost no way to get at the attributes of links. And there is no way to extend the attributes of links as one can with notes. Indeed, if links were richer, we might have one to many links.
A linkbase sounds a great idea and if it is already latent under the hood of Tinderbox, let’s get it out and have at it.
To clarify further, there definitely is a link base. Here is a random TBX on my system—In BBEdit (with XML syntax colouring)—with all except the link type and links collapsed:
Have you tried all the above and found them wanting? If so, how? I ask not in combative tone but out of a desire to improve/explain. Clearly, few individual operators answer a complete complex question but rather they must be used in consort to achieve the desired aim.
How are you expecting to interrogate the link base? Put another way, what sort of question are you trying to ask. My hunch is the blockage may be as much approach as it is any functional limitation.
The operators for this were first added in v9.0.0, see here, in December '21. As I recall the feature was added as people asked for it (and indeed not asking for it before then) … and there’s the rub. A lot of possible features aren’t in the toolbox because no one has actually asked the developer, directly, for them. In v8+ there has been a big expansion in the degree to which code can interact with more than attribute values. Doubtless more could be added. But with finite resource it makes sense to effect first those which people have actually asked for with a believable use case (i.e. more than “it would be cool if…”).
Beyond the concept of such affordances, what to you want to add to your links and why? In which PKMs do you currently make such link changes? (Examples help understand the actual need vs conceptual possibility) requirement).
What I enjoy about Tinderbox is it makes me think about my thinking. Indeed, helping with other people’s problems, even more so. Why am I using this approach and not that one? Why did I think this arrangement view would tell me more than that one? Why didn’t this query give me anything useful, against my expectation? Can I structure my view/attributes differently to get more traction on this topic? As so forth…
Fascinating discussion. A few very brief notes might be useful.
I myself don’t think that outline view is privileged or primary. I think of Map and Outline as coequal, and Chart really ought to be — but has never caught on.
In very early Tinderbox, Outline View was given a small boost in priority because new documents opened as an outline, in contrast to Storyspace where new documents opened as a map. This all became academic in Tinderbox 6, with the introduction of tabs.
Tinderbox links are not quite first-class objects. The late Rosemary Simpson (Lisp Machines, then Brown) was a tireless advocate for making Tinderbox links first-class entities. Most notably, you can’t link to a Tinderbox link.
The mention of multi-way links takes us back to Aquanet, whose influence on Tinderbox seems to grown every year.
One important aspect of Tinderbox that we take for granted is that each note really is concrete. It’s a thing, which you can find at a particular place. You can pick it up and put it somewhere else. Bolter calls this “architectonic”, and its importance has been obscured because we’re accustomed to it. In a database, the data aren’t palpable in this way: their Platonic ideals that we perceive through reports. I worry that p:{[A(xpos,ypos)],[B,(xpos,ypos)]} might interfere with p’s thingness.
I also worry that lots of people have a hard time with vectors and matrices.
This fun 1983 paper, with an all-star cast (just look at the list of authors!) wrestled with the idea of filtered, reconfigurable views in an amusing way. https://www.ijcai.org/Proceedings/83-1/Papers/034.pdf. I currently think that the core problem of the reconfigurable, customizable diagram view is actually the problem of telling Tinderbox which notes you want to put into the diagram.
Sorry if I mis-spoke re views & primacy. Nonetheless the (root) outline it the easiest place to see the structure of overall document and unlike the map is is key to understanding (HTML) export. Just as early Tinderbox files opening into an Outline view gave that more apparent standing amidst other views, the Map has the same effect now. My observation is that users, especially those less comfortable with abstraction, can get confused ‘mapping’ the map onto the outline, compared to going the other way. Arguably, it matters not, until/unless one needs to figure out where things are (which isn’t everyone’s problem). Point taken re links. I do think the concern #6 is valid,.
A way to preserve the thingness could be to keep only one set of attributes in the note itself (as in current TBX) – the alternative xpos,ypos do not have to be inherent to the note, they can instead be attributes of that new thing we are discussing.
When using the new thing, it pulls in everything from some container and overwrites the attributes for which it has its own version.
An analogy to this behaviour would be a mostly transparent cape, that you can throw over your item, to dress it up. You mostly see the original item, but on a few spots (where the cape is not transparent, but has some print on it), it covers the properties of the thing we dressed up. Any changes that happen to your original item can still be seen through the transparent parts of the cape.
When f.e. you color notes through the cape, you “paint on the cape” not on the original items – i.e. those changes become new/update values for attributes saved in the cape.
This is also similar to the way CSS is based around some idea of separating apperance/styling and content. There you can also cover the styling a page has on its own by injecting some custom CSS that will cover parts of the original styling. We could limit the attributes a “cape”/“diagram view”/“empty shell” (…whatever we want to call it) can have. Color, positions, shapes etc. can be saved in there – but anything that is more content-like in nature is not.
some thoughts on "real content" possibly being encoded in attributes considered "styling"
the line one can draw between what is styling and what is content is kind of tricky – one might have encoded content-like information in an attribute we’d consider styling, for example making all notes that represent objects of a certain class one color. Nothing one can’t get around using Prototypes for such distinctions instead however?
A bit more towards keeping ideas well-defined and seperated:
What I was going for in my original and also this post is different from what @entropydave was describing earlier here:
What he described includes changing the set of notes(or replicants of such) seen on the 2d-canvas. Though this could be worked into my “cape” idea as “well adding another note, or a replicant of one to the canvas is equivalent to painting that addition onto the cape” I did not intend that. I in contrast thought that the set of notes you see on the 2d-canvas is given by the original container – with that given, replicants are not needed.
Maybe this is a useful distinction.
Yes, this is an interesting alternative way of thinking about it. One way of conceiving it is that containers could have a modalising context, i.e. that they put the thing into a mode in which its properties are transformed. Within the mode that the container sets, some properties would be different.
If you want an analogy and perhaps a use case, consider three containers: Past, Present, and Future, in each there is the same entity, but some of its properties would be different in each container. These might be spatial (e.g. its home address) or they might be other ones (e.g. its age in years).
This is an interesting point Mark, but it does mean that you are thinking about a (software-based) entity as being a real thing because it has a spatial place. But place is not conceptually a spatial notion, there is also a place in time and a place in a hierarchy (and many other logical notions, e.g. a place in a sequence). If we take real people as an example of a thing, we can imagine that someone has three places, e.g. in the hierarchy of his genealogy; in the hierarchy of the org-chart of the job he has; and in the hierarchy of the Army Reserve in which he serves. None of these is primary I’d submit.
I would argue that the minimum you need for thingness is non-identity, namely that it be possible to distinguish one thing from another, and that seems only to require that two entities do not have all and only the same properties.
But you’ve been wrestling with these issues in Tinderbox for a long time and there is likely some other consideration I’m overlooking.
Thanks for your other comments. By the way, I love Chart View. Feature request: Now that we can select a series of notes in the Outline and edit any of them while they’re all shown, could we please have non-contiguous selection in Chart View plus editing of any one of the notes. I tried that in TB recently and it did not seem to work.
Perhaps we’re talking at cross purposes, maybe because I’m not conceptualising things hypertextually. If it were possible to address the linkbase in Tinderbox, e.g. LinkBase.contains(“inhibits”), then I would agree that there was one. The fact that they’re stored in one place in a file seems to me of no consequence: if TB were to store all the images that occur in the $TEXTs of notes in one place in the file there would not then be an “ImageBase”.
I have used most of the operators you’ve listed. Indeed, I may have been among those whose input shaped some of the demand for and implementation of those operators. See: How to create a label for link without creating link-type
Suppose I have a link type “inhibits” that describes an inhibiting relation between the ideas in two notes. And links of this type are used in various places. Now suppose I’d like to find all the inhibiting relations in my TB file. So far as I understand, I’d need first to collect all the notes with links using linkPath, then I’d need to iterate over all the notes returned, calling eachLink on each note, and iterating over each link to find those whose link type was “inhibits”. If there were a linkbase, I could query it directly, as in my imagined syntax above.
The first requirement is to be able to keep notes related to the link itself, for example explaining some details about what the link is describing apart from its link type. Today, we can do this with link notes, but so far as I understand it is still not possible to access or set the note text programmatically. We talked about it a bit in the thread above. Link notes are good, but just as $TEXT is better with attributes, so too would link notes be better with attributes. Again, searching against the notes in the link base is not possible.
If links were solely to facilitate hypertext, then there would be no need for what I’m describing. But it seems obvious from how others speak about links, link types, and the properties of links already existing that they are using links to encode information, knowledge, relationships, etc. not just connections to other notes. To give an example, suppose that you want to indicate that x, y, and z, are jointly sufficient to inhibit A (by jointly sufficient, you might substitute, A is inhibited only when x, y and z are present) it will not do simply to put a ‘sufficient’ link type between each of A and x,y,z because it is ambiguous in its meaning between any of x,y,z is sufficient for A and the case when they’re jointly sufficient. Moreover, suppose that A is jointly inhibited by x,y,z and a,b,c then six links of one type will fail to capture what is intended.
Now as Mark B noted, if you had links to links, you could then have inter-link links of type ‘jointly’ between x, y, z to indicate this. Or you could have an attribute jointWith of list-type that would hold the paths of the other notes (to include potentially those in other places in the outline hierarchy).
The problem can be generalised to any part-whole relation where as it were the whole adds up to more than the sum of the parts. In that case, simply knowing that x,y,z and are parts of A is not sufficient to know under what conditions A has the property of being whole. As I say, this can be generalised in more than one way. This is important for sequences too, e.g. x is only an inhibitor of A when y has been previously operative on A and then only when z has been operative on A.
There are lots of use cases for modelling the interactions of elements in a system, for when someone could or could not have known something, and more besides. I think I described some more I think in the thread linked above from message #32 onward. I believe I described some of the original use cases for replicants et al in this thread Hard Links and Tinderbox++
I’m not saying that one cannot bodge or kludge around the limitations of TB to do much of this, one mostly can but in ways that are fragile and require remembering how you did them rather than encoding their structure into the structures TB offers. You ask which PKMs permit what I want. None so far as I know.
At cross-purposes (unintentionally!)? I think perhaps so, as a lot of interesting suggestions need to start from a different place. Hypertext certainly doesn’t, generally, use anything but node to node links so branching/joining links might need a quasi note at the join and a means to map a link though that node.
Much of what’s being discussed better fits a drawing tool like Visio or Omnigraffle, or something more multimedia (in terms of content). Part of the problem, is we’re often working backwards from an imagined outcome to a non-existent start place, and (cross-purposes!) one then might not easily exist. Most make sense if the view is a diagram holding a user- (query?) defined scope of notes. There are unaligned/conflicting desires there. For instance, some want a diagram that doesn’t/can’t change except by deliberate user action on the diagram (essentially a re-editable snapshot). Others want same content/different render. Some want multiple visible renders of the same source notes but again with different styling, etc.
None of those, from what I know of the app, lend themselves to starting in a Tinderbox Map view, in terms of the underlying objects and how a map works. A map might look like what I’ll term a ‘diagram’. But, if I nest a note on a map it disappears off the map, something that is not wanted in a diagramming context.
I very much agree with it being desirable to ‘address’ (interrogate/edit in some facets) a link. Essentially links lack a GUID so that we know, especially in code, exactly to which link we refer. It’s actually doable today without such an ID with some code (except if there are two links between the same two notes and in the same direction and of the same type (which though possible in Tinderbox is functionally meaningless). Which isn’t to say it couldn’t be made more simple, but action code has strengthened markedly which makes me positive in this regard.
Good to hear of someone using those linking operators as all to often links seem to get treated only as drawing lines missing their greater potential.
linkPath("inhibits") returns a list all notes that have at least one in or outbound note of link type “inhibits”. Want to know inhibited notes only? Use linkedFrom("*", "inhibited"). Want to know inhibiting notes only? Use linkedTo("*", "inhibited"). I guess which you want depends what you intuit to mean "find all " as and how you imagine the resulting data to be presented to you. If you don’t want to use code, you can use Hyperbolic view and select the “inhibited” path. This causes only link paths of that type to be highlighted. Not possible at present but and already requested feature is being able to hide/filter out notes not on the ‘path’ (i.e. the link type that is the type selected). Hyperbolic view will be less useful if there are lots of “inhibited” links between links not otherwise linked to each other as the view’s original design is optimised for displaying (only) notes reachable via a link from a selected note. Unconnected notes or other link network with no connection to the current one are not shown in the view.
Effectively correct. eachLink() can read/report but not write a link comment† but as you note eachLink() is a cumbersome route to the info in this sort of context. This leads to a chick and-egg that such link-comments are little used as they are (programmatically) hard to access. Of course this is small beer unless it’s a key thing you are after!
Not quite, as linkPath() gives you all notes on the link type path whilst eachLink() iterates the links and can test for type. Given that now Tinderbox has functions you can parameterise this such that you likely only need to write the main code once and then use it as a custom action operator. I’m not suggesting this is the imagined answer or even an answer from your perspective but it might be interesting if you posted a small TBX including links with comments and a description of what you think you can’t do. Adding bespoke UI does need time/engineering cost (so ROI consideration likely apply) whereas I’ve seen additions/tweaks to action code appear quite quickly (for those on the backstage with beta access, very fast).
The don’t facilitate hypertext, they essentially are a hypertext. So, the type of link use you mention is conceptually very different. But it’s still PoV. Note A is capable of knowing if the list of notes linking to it (by specific linkType(s) if needed) contains x, y and z. Same outcome, it’s just assessed in the affected note rather than assessed in the link. This might also be usefully unpicked with a test TBX; not shirking the task but you’d need to make the TBX to ensure the scenario has the conditions for the assessment you believe can’t be made.
Aside, you might want to take a look at Flying Logic. It comes out of a very different place (enacting concepts from Goldratt’s Theory of Constraints) but it does have the sort of link annotation you want. Data interchange is poor IMO as the dev assumes [sic] his customers are mainly corporate with a programming department down the hall to do import/export in Python. But, FL might just fill a hole for you: the link joins and such might outweigh shortcomings elsewhere.
One bridging notion here, as has been posted before is that the join would be a special form of note: forget how it looks but think function and communication with the join. The issue isn’t the look but how the join is represented. In context, an agent is a special form of note [sic] but functioning quite differently from notes, a link join/split node doesn’t seem a big leap. I think the roadblock is as much about misaligned perspectives about the task. If the outcome is possible and can be archived with significant damage to other forms of use of Tinderbox, there seems room for improvements in the areas. Note I write this just as a fellow user, albeit with some deep knowledge of the app and how it currently works. I suspect a challenge in this area no one has touched on—as we all assume [sic] it ‘just’ works—is the signalling task and speed of response. I tend to be more cautious: I’d rather be surprised by a solution than disappointed by it.
Indeed. Whilst it is a thing we wish to know, is it a natural fit for an app that centres more on textual annotation and analysis. System modelling is a loose fit, though please don’t read that as being negative in intent.
I do think there are couple of things that may be more do-able (well, as described here) than supposed but really need a a reference document to anchor discussion (I suggest new threads if following up on that).
HTH
†. [Later edit] Comments will be editable via eachLink() from v9.6.0.
