For sure. One discussion to have, as the view matures is to scope the view, in terms of how far out you plot. Unless you want to explore the whole, it may you might want to just look N links out from focus which inherently reduces the number of notes/links to plot. In this regard, I think hypertext tools in general are lacking.
Back in v5, I built a TBX for a client that was an 8 level outline with c.35,000 items IIRC. The performance issue is long outlines. IOW, the whole outline—as currently expanded—that usually extends beyond the part of it seen on screen and which we generally want to be able to scroll up and down at speed.
Where there is some nesting (e.g. aTBRef’s source doc) I find keeping branches folded helps—as the overall expanded outline remains smaller. For big projects, I work out of a root level container, i.e. such that all the ‘content’ (as opposed to templates, prototypes and general notes, etc.) can be ‘folded’ away in one place. Indeed, by hoisting that container (Focus view) in outline view it inherently reduces the immediate maximum scope (outline size) of the piece upon which you are working. sometimes it works better (in performance terms) if one uses several tabs scoped to different parts of the outline instead of scrolling around the whole thing. I’ll admit, the latter is my natural behaviour but I’m learning the the former so as to help not overload the view visualisation.
What are you doing with the WordNet corpus that is specific to Tinderbox? I ask out of genuine interest. Tinderbox isn’t a formal concept mapping tool in that it lets its user map out relationships but doesn’t intend to provide some formalisms of CM such as might be expected in a formal CM tool.
I’ve found Tinderbox is best for discovering structure. Once so discovered, it can be that —especially for large datasets—that some more specialised tool is a better place to build out the full data structure.
It is. I wonder if out terminology/frame if reference is aligned? The $Name attribute is the ‘title’ of a note. It is used to title items in the view pane (more strictly, $DisplayName is used) and it is used as the title at the top of the text pane ($DisplayName is not used here, as sometime you need to be able to see the actual $Name). So $Name is metadata. If doubting, add $Name to a note’s key attributes table.
$Name has a different role when it comes to linknig within Tinderbox. Although, under the hood, a link uses note $ID values, generally we either drag links in the UI or use action code. Action code uses a note’s path (IDs were invisible to the user until c.v5+), i.e. $Path or its $Name as a proxy. An implicit assumption is that $Name is unique within the current TBX, otherwise the full $Path is needed). A confusing factor that the linking code doesn’t allow for escaping† certain common non-alphanumeric characters such as parentheses and semi-colons, as these are misconstrued as code rather than content. Not a problem if planning your novel, more of a problem if the note title ($Name) is a reference to something like a scientific paper. You can bowdlerise the $Name to aid automated linking, but then you need to ensure you retain the true title (normally in a separate user attribute) for all other purposes. Of course if a note becomes a container its $Name is now part of its childrens’ $Path, so the same care needs to be taken.
† Sadly, I’ve yet to ascertain and document the true full set of ‘bad’ characters for $Name/$path value with respect to links.
Most won’t trip across this issue of titles and link-safe characters, but when you do (as in my own personal research work) it is a bit of a headache. But as an edge case, it’s not what the majority of users face so can’t be presumed to be high up on a fix list (as I suspect it involves code very much at the guts of the app and so not the area for light surgery).
Amen. I didn’t mean to appear to disparage them, not least as I work primarily in outline for my personal research work (due mainly to the size of the datasets).