I’ve come a long way since last month - brilliant product – Kudos to Mark, aTbRef is indispensable - however, I have one simple question. In Devon Think you can take the topmost parent container and replicate it in any location as many times you desire. The only method I can conquer at the time is the “click create note alias”. Is there a way to alias a container note and have all the children come along as well (like a duplicate basically but without the data consumption, like Devon’s replicates)? I’ve also tried aliasing each note individually but it won’t let me indent it under its top container note. Can anyone give me a “teeny” hand?
Tinderbox aliases don’t allow children. Some query methods (I don’t recall which as I write) allow testing of implied descendants, i.e. the original note’s descendants. It’s not a matter of deliberate difference but simply each app’s own design.
Tinderbox aliases always share the original’s text links. Basic links (note-to-note) are shared unless links are made to the alias itself, in which case it essentially has it’s own discrete basic links.
If interlinked notes are duplicated, the copy’s links still point to the original to the original target. Thus assume note ‘AA’ links to ‘BB’. If I select both notes and duplicate them, we get ‘AA copy’ and ‘BB copy’. But, ‘AA copy’ links to ‘BB’ and not ‘BB copy’. Depended on what you desired this may or may not be the expected outcome.
Tinderbox design draws on past hypertext systems. Hypertextually, it makes sense to have a canonical source to which aliases point, thus you only need one set of descendants as going from an alias you get to them via the descendant. IOW, context follows the links. Having everything replicated reverses this, by pulling extra content into the current context. There’s no right or wrong, they’re different approaches. I merely make the comparison to avoid the presumption that Tinderbox may be doing things the ‘wrong’ way.
This is a very important point. An alias in the file system, a replicant in DEVONthink, and an alias in Tinderbox might look the same but are all significantly different under the covers.
2 Likes
Nope. One thing you might find helpful is setting $DisplayExpression to show the number of children:
$Name + " (" + $ChildCount + ")"
Then when you see an alias suffixed with a number in parentheses, you have an indication that it’s a container. Select the note, right-click and choose “Show Original in New Tab” there you are.
1 Like
Here is a rough-and-ready workaround, which I think might do what you want:
- You have your original parent container, whose name (let’s say) is “TopContainer”
- You set up an agent to find either the immediate children, or all the sub-child descendants, of that container. The query would (I believe) be either inside(“TopContainer”) for immediate children or descendedFrom(“TopContainer”) for all sub-descendants.
- Then that agent, itself, becomes a “container” that includes aliases of all the items you are looking for.
- This is clean-and-neat if you’re working with a container with only one level of immediate children. Thus you’ll have a one-to-one matching of the items in the original container, with the aliases your agent collects. If you’re looking to have aliases of a multi-tier container structure, it’s not as neat. The agent will show you aliases of all the items, but they won’t have the same tier structure of the original container. But you can find ways to work around that.
- And if you wanted to get more rococo, you could have the Action for this agent do something else about displaying, collecting, or organizing the aliases in some way you want. But even with no Action at all, simply creating such an agent will assemble the aliases you are looking for – it seems to me.
Would a simple agent do the job? Or am I mis-understanding (and perhaps under-estimating) what you are trying to do?
which would be just fine in Map view…“there’s some conceptual similarity there”. what would be the point of going from container to container - in outline view - while loosing sight of the other ? Plus, Tinderbox is a tool for notes, and the current aliasing scheme seems to be a tool for linear content, more precisely, for reading story, to which not much analytical processing is really required…it’s all structured data?!
In the outline view, my intention is to remain in the same place while seeing as much information as possible - even if the information is exactly the same - in order to make sense of all sorts of relationships and speed the workflow. What’s the point of all this automation if I have to duplicate, let’s say 15 descendants, to get to the oldest one where there’s 100 siblings. In a deep hierarchal structure (in my case here) aliasing isn’t very useful. The current aliasing approach seems to be created with the idea of note body text in mind. What If I want to structure all my data to no more than a topic sentence? wouldn’t it be better to have no body text at all and have all the information as container notes?
I have yet to figure out the aliasing approach using the agent query method. Can it alias deeper than 1 level descendant using this method? Sorry, I need a bit more time to really grasp tinderbox. Heck, I most likely don’t even know what I’m talking about. Assuming my mistakes will be corrected … the complex stuff will eventually make sense. Just spent around twelve hours testing and testing and testing; it is time for na na.
1 Like
Yes, that was my point in mentioning above that inside(“ContainerNote”) gives you aliases for only the first hierarchy level, whereas descendedFrom(“ContainerNote”) gives you all descendants, no matter how many layers down.
Not sure whether you realize that you actually can see multiple containers and their contents while working in outline view.
Here’s a simple example: What you’re seeing in this shot is actually nine different notes (all in red), which are part of 8 different containers, but you can see them and work with them all at the same time. The top level containers are in blue; sub-containers are in green.
In a map view, you would not be able to see the originals of these notes all at the same time, because they’re not in the same container. You would have to make aliases of them, either manually or through an agent (which creates a new virtual container to hold them). But outline view actually allows you to see multiple hierarchy-levels at the same time, and to expand or collapse the detail view of each container so that you can see its contents, or not.
As long as the agent duplicates the container notes with the exact same structure - hierarchy & sort - than it should be fine.
The agent query method would create an an alias for the top container note and all its descendants? Will it alias even if there’s more than, let’s say, 15 hierarchical (not same level) descendants?
As long as it aiases from:
A
B
C
C1
C2
D
To
A
B
C
C1
C2
D
then i should be good to go
Oh God, it looked indented on my phone. Each letter should be a sublevel of the prior letter except the numbered ones which are siblings.
I think the easiest way for you to get the big picture here will be simply to experiment around with some agents and some aliases. It’s obvious once you see it and a little trickier to get across via explanations.
The TL;DR summary of the notes above is:
- The agent-query process will let you create aliases of either (a) the notes just at one hierarchy level, or (b) all the notes at all levels in a given hierarchy. The first you get (as mentioned above, with links to explanatory info) with inside(“ContainerName”). The second you get with descendedFrom(“ContainerName”). These processes are explained in more detail at the linked aTbRef sites.
- But that process will not create an alias for the entire hierarchical structure, for the fundamental reason that in this program aliases cannot be containers. They can’t have children or descendants. So if you want to duplicate an actual structure, you have to duplicate it – but you can do that with Cmd-C/Cmd-V for the parent note. (And that will create another version of the structure, not an alias of it.)
- If you want to work with contents of multiple containers, you can very easily do that in an outline view, as illustrated in the screenshot I just posted.
- You cannot work with the original versions of notes in multiple containers in a map view. A map view shows you notes within one container. So it shows you either originals in one container, or aliases you have manually added (or brought in via agent).
By far the easiest way to see these things is to spend half an hour creating, moving, copying, creating agents, etc. Once you try it it becomes much more obvious. Also please check out the linked references above, about inside(xx) and descendedFrom(xxx)
Is there a practical reference for this - or something we can look at. What are these 15 levels of things? The starting problem here is a common one, trying to learn Tinderbox whilst trying to build data structures predicated on experience using apps with different design/vernacular. I recommend @JFallows’ suggestion of general experimentation to understand the generalities before zeroing in on a particular task.
If you want a new container to spawn a whole lot of child counters, this can be done using prototypes (see here, re ‘bequeathing children’). Note this is a once-only operation on first setting the prototype (if the latter is set to bequeath children). Content changed in the original of the bequeather notes are not replicated. It is useful for building out complex container sub-outlines but doesn’t attempt to deal with issues of update/sync.
The semantics of aliases are exceedingly tricky; in the new edition The Tinderbox Way, I believe I recount how the initial implementation was finished in an afternoon and the refined over the Cours of a decade.
It’s not casual or arbitrary.
2 Likes
Indeed. Here’s a sample passage from the (extended and interesting) discussion of how aliases work, and why they are more complicated (from the developer’s point of view) than they may seem, from the latest Tinderbox Way:
Aliases seem to be a simple concept, and their initial implementation was finished in an afternoon. Nevertheless, a number of tricky issues soon arose.
• Objects that Tinderbox creates must eventually be deleted once, and only once. When deleting a note, Tinderbox automatically deletes the note’s aliases. Suppose several notes are selected and then deleted; some of the selected notes are aliases and other notes are their originals. Tinderbox must delete the aliases before deleting any of the originals; otherwise, deleting an original note might delete an alias that we had selected, and then Tinderbox could attempt to delete that selected alias a second time.
• Similarly, when Undoing a deletion, it is essential to restore the original notes before restoring that note’s aliases.
• Deleting a container that holds an alias incurs the same perils that deleting a mixture of aliases and original notes presented.
1 Like
Mark -
Do tell. 
Having sat through many requests & expectations for ONE “name” for a thingamee across the enterprise, I can offer this observation (not mine)…
“Do not let the constraints of our tools—relational databases in this context—with their need for ‘unique primary keys’ to constrain your solutions. The brain—clearly a magical form of hyperlinking—files by related concepts… where water={H2O, ice, fog, rain, hail, snow…} are a single, related package.”
I’d expect you’ve come across this gem… http://www.kurzweilai.net/ambiguous-words from George Miller, the author of WordNet?
REPLICANTS (DT) vs. TAGS (DT/TBX) vs. ATTRIBUTE Browser (TBX)
I will eventually have a response to all matters above. I have been working really hard to understand all concepts of Tinderbox so I can make objective comments. I’ve been tinkering and experimenting and really putting enormous amounts of time into the tool. A Few more questions before I get a clear picture of how it all works (I believe I am almost there).
DEVONthink Replicants / TAGS (DT/TBX) / ATTRIBUTE BROWSER
They are essentially tags and have nothing to do with Aliases, mistake on my part. I always new the intricacies of Aliasing and coding. Can Tinderbox then display these tags in a hierarchical manner? if I tag a container and everything in that container, is there a way to see it in its original structure? I assume these tags cannot be shown in a hierarchical structure in the outline view as you can do with aliases. How about the attribute browser, can it be set up where you can see your original container (with many sub levels) in many other categories. IF that’s possible, how can I achieve this ?
In an Outline view, if you display columns (View > Use Columns) you can show the Tag(s) for each note in a column. That container can also be set up to sort by Tags. You can also setup this sorting for all child containers of the parent.
No. You could make a note for each tag and nest those but I don’t think that yields the result that’s wanted. However, you could make each of those notes scan (e.g. via an edict) and show the number of notes using it via a display expression:
▾Components (12)
▸Sprockets (26)
▸Widgets (5)
Aliases can’t have children. So whilst they can be used in an outline they can’t be used to contain other content.
Attribute Browser (AB) view shows all notes in/descended from the container selected (in the AB configuration toolbar) and then groups those notes according to the their value for some selected attribute. Thus using $Tags you’d see an grouping for every discrete value of $Tags under which notes with that value would be listed (meaning some notes may appear in multiple groups if they have more than one tag. Using column view with AB view allows other attributes’ values to be displayed for each note even when not selected (i.e. not showing in the text pane). I’m still not clear quite what’s in your mind’s eye here.
Mark,
All I am trying to accomplish here is an exact replica of a container that has multiple sub levels, that updates itself from any one of the same exact note (living in any location at any one time), and has essentially 0mb size value.
- Aliases
… can’t do more than one level
- Tags
…DEVONthink has replicants, which can be tags or group of tags which can all be viewed in one window (no matter the number of tags or sublevels) — I think this is brilliant and this is what I am looking for really
- A way in Tinderbox?
Any way this can be achieved in tinderbox? the original container of, let’s say, 6 levels that takes up 16mb duplicated with the same hierarchial structure and essentially a 0mb size? and of course that can automatically update itself from the original or any other note with the same exact content?
- I understand I can duplicate these notes btw…I think someone tried to explain that I could duplicate, they completely missed the point.
I fear we’re going in circles. Put plainly, Tinderbox does not have this feature! I’m sorry but it doesn’t. It sounds like the best place to keep these lists is in DEVONthink and perhaps watch that folder? I’m not to expert in DT, but others here are. Perhaps one will de-cloak and fill in the gaps here?