1.I have all my data under the “/Data” container and at times I do have agents running under this container. I therefore commonly use descendedFrom("/Data") to find all my notes but I am also returning some agents I do not want.
Along the same lines, how do I exclude an alias note and keep only original documents?
You were probably looking for an $IsAgent, as there is $IsAlias, etc. But, as only agents have a query, using $AgentQuery!="" Works fine. OK, it might find an agent created but with no query set but that can’t match anything so isn’t a difficult edge case to manage.
If you’re looking for an agent that will find and collect the original versions of notes, then (based on my understanding ) that can’t happen. The reason is that agents, by definition, create and collect aliases of the notes that meet their search criteria.
You can go to those aliases and use the command that says “show original” or “show original in new tab.” Or you could have a column view that displays the container-location of the original notes, matched to each of the aliases. But one of the design-fundamentals of the program is that agents always display aliases of the relevant notes.
To look at the originals, you need to see them in situ in their outline, map, or attribute browser etc views (as far as I understand things).
Update It’s possible that I misunderstood your question, and answered something you were not asking. As @mwra points out below, you can craft your query so as to exclude matches with an alias-only, where for some reason the original itself would not match. But the results of an agent-query will be displayed as aliases in any case.
I commend the approach @PaulWalters suggests. In my own research projects I invariably have a root container akin to the OP’s ‘Data’ and this contains only the source content I’m analysing (in much data the odd $Text-less container for organisation purposes. All the prototypes, templates, codes, agents, etc. have their own root containers so are always out of scope for queries looking inside ‘Data’.
In my experience, this sort of separation increases in value once the number of notes rises. With a few hundred notes, nothing is far from hand with 000s or 0,000s of notes some structure pays off quickly. Of course, styles vary, so there’s no one ‘right’ way.
In all my files, the top-level containers are “Data” and “System.”
Descended from Data comes everything that is the “substance” of the file.
Descended from System comes all the plumbing. Prototypes. Agents. Templates. And so on. Essentially System holds everything that I wouldn’t want to search, have displayed, etc - but would just rely on for functioning. (Probably should rename this Infrastructure, but more characters.)
Thank you to all. Great advice on multiple levels.
I think from an organizational perspective it makes perfect sense to better organize the inherent structure and have all my agents live outside of the true “/data” directory. I do not have many agents under /data so they will be easy to find using the attribute browser.
Mark: thank you for your suggestion: “Add & $IsAlias==false to the query” I had never used this, but nice to add to my tinderbox coding list. I am always a “tinderbox student”
James: I like this,"In all my files, the top-level containers are “Data” and “System.” Q: are there times when Prototypes/Templates especially are being looked for at the “/” root level and give you an error message? Is there a setting than needs to be set to tell the system, “hey, look for all the configuration files over here instead of at the root level”? I would think tinderbox would figure this out, but this question has crossed my mind more than once. I typically use smaller, more focused documents on short projects however do a couple of longer documents I keep as a commonplace/journal for work and personal.
FWIW, I used to use a /System folder - aTbRef’s TBX had own for now. But now Tinderbox’s built-in prototype/template/composite/etc features all create root level notes I’ve found it easier to leave those folders at root (avoiding having a /Prototypes and /System/Prototypes). I’d commend this to a new starter.
To those long-term users with already-acquired and understood ways of doing things then it makes more sense to continue on as in the past. Once again, a choice!
What it shows is as long as the ‘data’ is under a single top container, the back-of-house stuff is easily pushed out of sight.