Technically, there is such a system. The file system. An aliased folder hierarchy is kept “updated”.
So software that works with aliased folders located in the file system such as PathFinder, etc., might be useful. (Maybe emacs, but I’d have to think about that.)
That said, the use case discussed in this thread is far too sophisticated for me to comprehend. 
It strikes me this is about the difficulty faced when one only has experience of being allowed a single ‘tag’ bucket and the narrowness of analytic vision this creates. Outside the narrow niche of controlled vocabularies, nested tags/keywords is a sticking plaster over the ’ tag-only’ metadata limitation.
As I recall ‘tags’ crept in around because the Web 2.0 hipsters didn’t like the (controlled) keyword approach common at the time. Keywords were for squares, the cool kids were into folksonomies of ‘tags’. Meh, they are actually all just search/indexing terms. Indeed, understanding the latter is key to breaking out of the ‘tag-set’ mentality.
When analysing/annotating your data, what are the strands you need to later recall/revisit? These strands are worth capturing and, if discrete groupings exist, placing in discrete stores (in Tinderbox’s case in attributes). If you started with data from a tags-only app, when arriving in Tinderbox let go of that limitation. You can keep the original tags data (in $Tags - or another attribute of choice), but still tease out the strands with the overall tags into discrete attributes.
Imagine an address book where name, street, zip, etc. were all just tags for a given record. How much easier to use if the zip code is in a $ZipCode attribute, etc. This is an overly simple metaphor but I hope it helps explain the process. So if you have tags like “Organization_United_Nations” and “Organization_DEA” likely you want an $Organization attribute, allowing you to search by organisation and to find ‘United Nations’ as discrete from ‘DEA’, etc…
Just as our tagging styles differ, ‘tags’ is a loosely defined term and thus implemented differently in different apps, even if some sub-groups of apps take a similar approach. In years of migrating data around apps (and from before the dawn of the ‘tag’ approach), really the only thing to bank on in the source data is that you have a list of values. Certainly, a big issue back when keyword hierarchies were popular was that no two vendors used the same method for saving/sharing the hierarchies.
Another thing I’ve seen is note titles used as proxy keywords. Whether you stick with your original imported titles or edit once imported, don’t forget to properly capture the metadata in the titles that isn’t also yet in a tag (attribute!).
Tags are the shallow end of understanding your data; do make use of the extra flexibility Tinderbox offers. Tinderbox isn’t a magic tool that turn your tags into structure, some assembly is required—and rightly so as that way lies greater understanding.
Anyway, I offer the observations above which draw on my own initial experience of Tinderbox and subsequent longterm use in case it helps people getting started.
[edit for typos and easier reading]
Yes, correct --but I thought he was talking about a hierarchy of notes or other info, as opposed to files themselves. If just looking for hierarchy of file names, problem solved!
I keep lurking in thy shadows’ thread and I always want to add a thought and I never do… It’s been soem time since dabbling in Tbx and I feel I can make a more objective analysis of this subjective argument…I will not use the term Alias here as to not fall in teh technical “rebuttal” trap; I will use the term Clone instead. A Clone is a container that appears in more than one place in the Tbx document - Outline, Chart view, etc. Unlike an alias, a clone is not a real container pointing to another container (usually the original); rather it is a second entry in the table of contents for the very same container. Consequently, there is no original; when you clone a container you’ll end up with two. It is essentially a tag; a multiple sublevel “group tag”… Even NeO, an oudated ouliner, has this concept as well. Prototypes can give me exactly what I want, conceptually and what i don’t want objectively – cost of data size. A 100kb single container prototyped will turn into a 200kb Tbx document.
KEEP IN MIND THE ARGUMENT HERE REALTES ONLY AND ONLY WITH THE IDEA OF CLONES AND DATA SIZE EFFICIENCY IN MIND!!! PLEASE DON’T GO FAULT-FINDING AT EVERY SINGLE PHRASE (there are plenty analogies out of the ass, I know) AND COMMENT ON THE OVERALL THEME, AFTERALL, THIS IS A DISCUSSION. THIS HAS BEEN A VERY DIFFICULT TOPIC FOR ME TO PUT INTO WORDS. I AM IN A VERY SPECIAL RELATIONSHIP WITH THIS THING YOU CALL TINDERBOX AND I ONLY WANT TO HELP IN ITS EVOLUTION OTHERWISE, WHY THE EFFORT?
For Instance a vehicle has a roof, chasis, and tires in that order when going top to bottom. However, the roof is part of the chasis/framework (same “substance” component) and a tire has rubber all around it and metal in between (same abstract object but different “substance” component"). While anyone is free to create their own methods and taxonomic “melodramas” categorizing and naming all of these concepts, abstaractions, objects… - think WordNet, Roget’s Thesaurus - one needs to reacreate that exact same object (our vehicle in our case) in order to grasp how that object can be improved or reinvented from ground up. Aliasing alows you to see multiple versions of the same container (vehicle) as many times you’d like. But it can only allow you to go as deep as seeing only the paint color of the roof, the shape of the body and the shine of it’s tires. Attributes in the Attributes browser is limited in the very same way. Accessing information in the attribute browser is nontheless brilliant. Buidling information to accurately present it in the AB requires deep hierarchial analysis.
The vehicle scenario is a case of creativity and the inevitable escape of a hierarchical system. But also think of this scenario. I have 10 sources on the same topic. I want to compare and contrast those sources for reliability of factual information, and that topic, structures knowledge and all of its branches with all of its concepts - let’s assume 15 levels only. I want to have a category named: “10 sources on same topic requiring analysis for accuracy” and I want to clone each source within its category but I also want a category named “references by its original source”. Prototypes can do that but they will also double the size of data each time a note inherits it prototype. Imagine having that category in 50 different places (before you’d figure out it needs only live in 4 places). Analytical processing is the step before the final presentation and delivery of information; and I feel that objects such as the A. Browser and concepts such as aliasing are limiting in the sense that it only alows you to present taht final information or process taht information from the view of somone with a specific expertise.
Chart view alows horizontal and vertical view of information at the same time, by definition that’s it’s pupose. Outlien view allows grouping of topic & whatever information. A good way to view an Article besides viewing it on the same page. Attribute Browser alows horizontal and vertical view of categorized -minimal level -container information arranged in special ways.
If I live in 4 seperate countries throughout the year, the taxman will bill me once and only once, it will not tax my investment income in all 4 different regions. A clone will alow me to view the same information while taxing me 100kb vs 400kb of data size.
It’s very easy to doom the need of hierachial structure of information when somone’s expertise is very specific. For instance, an accountant, a doctorate student studying the behavior of automated process behavior of ceratain social websites , or somone doing an analysis on the upcoming elections. The structure, teh form, and the level of knowledge is not as dense and as complicated compared to somone working on a taxonomic system based on the whole world of knowledge while considering all ontologies and all its components e.g., think WordNet, Roget’s Thesaurus (40 years to complete), LOC, Wikipedia (millions working on it) ; i.e. knowledge structure on a differrent dimension.
While Tinderbox alows me to fiddle with “nuclear” size information in so many and better ways than any other product out there, I believe, it’s also important that Tinderbox alow me do so in the most eficient way, the CLONE and the MARKDOWN (to be discussed some other time) way
[I’ll avoid using all caps, but note that I’m responding because I don’t understand the use case presented and no just for the sake of push-back. 
]
The vehicle straw man offered above seems to cry out for use of prototypes, so I’m wondering if it really illustrates the case you are making. Why do you believe using a prototype adds so much data? If you look at a document’s XML, you’ll see that data inherited from prototypes isn’t stored. If 100 notes use a common prototype, the value for a given attribute is stored once (for 1001 notes) - unless any inheriting note sets a local value for that specific note. But, to my reading, using prototypes reduces ‘data’—at very least in terms of stored XML.
Although a TBX offers a Map-view tab as its default, it is worth bearing in mind that the underlying structure of the doc (and stored XML data) is as an outline - see here. All the other ‘view’ types are just different visualisations/reports of the same underlying outline. I’m not sure how the clone object fits into that. What is intrinsic to the close and what to the original (canonical) object of the group of clones? Tinderbox covers a range of uses, care needs to be taken that in servicing one use case that (many) others aren’t broken. Tinderbox generally balances this quite well and I’m unclear where a ‘clone’ object would fit in the current structure. Overall, the clone concept feels to me like a view (visualisation) challenge rather than one of the actual data structure. I’m happy to be wrong - I may just be misunderstanding.
To get best leverage on one’s analysis, I find it best to put as much data as possible out of free text ($Text) and into attributes. It is in the latter you can make best use of both the different views. It was this epiphany that has kicked up a notch the value of my work in Tinderbox. Then again, work styles vary - for instance I’m doing research not writing long-form text (though if I could figure a good Tinderbox->LaTeX route I might do more writing in Tinderbox itself).
With hindsight, the most productive interactions I’ve had of late when helping users (mostly outside the public forum - so no links) have been assisting them to abstract their meta-data into attributes. I think treating notes like virtual scraps of paper only gets one so far.
HTH. I remain open to the fact I may be misunderstanding the issue.
lol
The case for use of " Clone Prototypes" 
But are Container notes considered attribute values ? Maybe I’m missing something otherwise you’ve solved my problem. On the other, if attribute values can store data only once why can’t containers store taht data in the same manner when using other notes’ prototype? And not to mention the prototype couldn’t even duplicate the entire outline of Rogers Thesaurus - I’m sure that’s due to some limit of prototype notes
Cloning would treat these notes as if they didn’t exist. They would simply function as visual ornaments. It’s engine would work almost at the same rate whether the document had only it’s original note or another 100 cloned notes.
And that I can absolutely understand.
“feels to me like a view (visualisation) challenge” That is exaclty my point. If you go back to the source scenario (4th paragraph) in my previous post tell me a better way to achieve that purpose, prototypes? Sure. But not data-less prototypes.Incremental formalization? … Sure, but what if I already have in mind what I want and know with certainty how that needs to be done or what if I am working on a purely creative project?
An agent/adornemnt cannot perform its duty if it doesn’t know what to do. You have to visualize your data before your structure that data. An the more you visualize, the more creative your analysis can be . Of course this depends on what project youre working on and the degree of creativity required – music track production vs. a sentiment analysis of an interview vs. coming up with a new classification system.
It is not an easy concept to grasp, especially if things Like WordNet, Roget’s Tehsaurus and the like does not make your eyes glow or if you don;t wake up everymorning thinking about ontologies, it’s components and it’s systems. You’d soon realize that hierarchial structuring is impossible to escape when sorting thorugh knowledge and structuring information. Once you’ve come up with a solution, than you can make your own system. Mark has made the Attribute Browser and everything else in Tbx becasue that was all there was needed to accomplish his own system.
I agree, in teh sense of quickly browsing information, Atb is BRILLIANT!!! God, I would wan’t anymore sublevels than one or two. Building up, analyzing, comparing and all that so you get to the end result would really benefit from Atb allowing me to switch from quick browsing to categorical browsing?
Also, in my opinion, Tbx would be great if it applied as much emphasis, on the $Title concept as it does on the $Text concept. This would be difficult to understand unless you find yourself in my situation
And with this one you’ve hit the nail in the coffin. I wish it would serve my workstyle more :))) In retrospect I beleive you’ve gotten a general sense of my dillema. I wholeheardetly believe, this would benefit most syles of research.
what do you mean no links? :)))) jk, I think you do enough.
Hmmm, IIIIIIIIII don’t know.
In a way, yeah; in a way, naah. A musical song can be from a different era, have a certain style, and use a specific musical form and be structured…get the point.
would be great if Text notes and Title notes could behave like $Text and $Title attributes where yo ucan have a 100 and apparantly take no data size? Now, that would be amazing. Cloned notes? :)))
So, I haven’t used NeO for a while, and so I just checked this out on a small scale document. What NeO does is what I’d say Tinderbox does with aliases**. The NeO clone has the same name, color, text, etc., as the “original”. Change the clone, the “original” changes. Change the “original”, the clone changes.
Tinderbox aliases behave the same way except for a limited number of “intrinsic” attributes. E.g., a note on a Tinderbox map and its alias have different X,Y coordinates on the map.
** ‘alias’ in the Tinderbox sense, not the file system sense, or the FBI Most Wanted List sense, etc.
You are correct but aliases in Tinderbox go no deeper than 1 level. NeO aliases all levels within that container. If I want to alias a category that has 5 levels, Tbx cannot do that. It would be great if Tbx could alias the entire container.
Again, to show that Tinderbox thinks mostly in $Text terms.
Btw I’m surprised NeO has caught the dust it’s by far the best outliner I know of.
I don’t think anybody is arguing against that. Eastgate has said this is hard to do, so it hasn’t happened yet. It might never happen.
It makes up for everything else it offers. It’s not that I’m an ungrateful shait. But this is a “must”!! Even though that’s about all they do, they all do it - Scrivener, NeO, and so on.
Just to make sure we’re all on the same page as far as the significant distinction between a duplicate and a replicate goes in Devonthink (=DT) – Devontechnology’s software which seems to be the inspiration of @john999’s inquiry … if I am not completely mistaken:
In Devonthink one either duplicates or replicates data (i.e. files, groups [=DT’s well chosen metaphor for folders] etc.).
Duplicate = copy and paste = with the result of the exact same copy (!) of the source (!) as long as neither source nor Duplicate are altered/modified at all.
Replicate = is sort of a Duplicate-Alias-hybrid (by the way: without (!) increasing the storage space).
In Devonthink, one, indeed, can replicate the entire sub-group-structure of a parent-group.
But the main point and Pointe is – in distinction from Aliases in Tinderbox – that replicates do carry all the functionality of the Tinderbox Alias but do live on even once the supposed source (of the replicant) is deleted. And this behaviour really comes in handy especially if working with Tinderbox-Documents over a long course of time within which one particular note might be needed in different contexts (i.e. in different Containers on different levels) and will eventually be deleted in one or the other context while still being relevant in other contexts. There will be times when one does not want to care about the source of an Alias anymore.
Not being tight to a particular source to which all Aliases do intrinsically relate but being free to either delete (even the supposedly source) or to replicate at will is the real strength of replicates and, to my taste, justifies this wonderful discussion in this thread I’d like to thank anybody contributing to so far.
addendum
In other words: Aliases are meant to always (!) remain related to their respective source. Replicants can function as Aliases but are actually original entities though bearing the functionally – besides others – of Aliases. That makes replicants so cool!
So – let me ask: Are we technically on the same page or do I miss the central point entirely?
I think I see why. Part of the straw-man example above post’s containers for being able to show different arrangements of the same data. If different clones show different arrangement’s of their descendants, which is the canonical version. I suspect it might be less hard to make a ‘clone’ show all (aliased) descendants if they were only displayed in the arrangement as at source and not allowing deletions or addition of extra descendants. However, I think the latter goes against the strawman example - but this is where I get lost. I’d like to see a visual mock-up illustrating the problem.
My hunch is the way around this is actually via links - stepping outside outline hierarchy whether used or not for note storage - and showing the link-based relationship. My showing discrete link types for a doc - or a buried sub-set of items, alternate interrelations of the same objects could be shown without the need for clones and the problems described above.
This essentially takes us back to a feature request that’s been around for a long time (and which I thus suspect is complex). I think another issue is that, other than as ‘lines’ in our maps, we’ve moved away from (link-typed) links and perhaps that’s another thing to dust off.
Wouldn’t it be great if we could more easily create multiple alternate trails** through of notes that we’re easily and interchangeably useable?
** Here, especially sections 6, 7 and 8.
No. A container is simply an object (note or agent) containing other objects be they other notes or aliases. An adornment is an odd Map-view-only case where it has some container-like features with regards to objects placed on top of the adornment.
I’m not sure I follow. If you’ve not already seen them, I’d commend taking a look here at the articles on inheritance and setting prototypes.
Any note can only store one value per attribute (or set of values if a List or Set). Aliases share attribute values with their original with an exception in the case of intrinsic attributes, as explained in the linked article.
Aliases always share the originals text and web links - as $Text is shared. Basic links are little more complex. An aliases shares the originals basic links unless/until the user creates links attaching directly to/from the alias rather than the original. There’s some back-history to this status quo that I won’t dive into here but suffice it to say it’s not a accident, so change in behaviour would need to not break existing alias-based link logic.
I think this is an issue of practice. I now normally do much of the map work in my mind whilst actually working in outline. Though the latter choice is largely pragmatic rather than stylistic as my large docs push the app hard at times and I’m careful to balance load. Plus, even with a 27" screen I can’t get everything on screen. Thus I’ve had to learn to abstract. IOW asking myself: “is this a discrete facet of the object I need to reference (in the general sense) later on?” If so, put it in an attribute, making a new attribute if necessary as an everything-bucket of ‘tags’ is little use for detailed exploration. But the move away from the latter to the former can be gradual in pace and sophistication. Tinderbox’s support for incremental formalisation and ongoing experience will aid the process. I accept I’m writing this informed by many years use of Tinderbox (since v2.3.4) as my primary thinking space.
I’m a bit confused by WordNet, I searched for a few English words but got no results. Is the tool only for a very limited core vocabulary? That’s not to disparage it, I just didn’t get any results!
As in my earlier response, I think the missing visualisation here is one based on links as these are agnostic to the underlying hierarchy of the canonical outline.
As regards AB view, don’t overlook columns which are allowed as in Outline view (another reason I use Outline view a lot!). AB view+columns definitely increases data density on view and is a force multiplier for analysis.
With AB view and agents, there is a tendency to build these out a permanent structures (though each discrete AB view needs its own tab). However, such an approach doesn’t scale. I think people cling to keeping these structure built out as there isn’t an easy way to store/restore such views, i.e. like database stored reports. But, practice (and prototypes) help here, e.g. making an agent whose query is defined in whole/part by attribute values stored in the agent’s KA and accessed via the ‘agent’ designator.
I think it is in the nature of most (all?) of us to start with a mental picture of what something should look like and then try and work towards it. this is partly why the map view is so good, especially with small sets of notes. But scale demands some abstraction and that’s not an easy or intuitive leap. My observation is that most don’t ‘get’ this from generic examples. But when walked through in their own data, it’s much clearer. Of course, in support/tuition terms that scales badly too! 
Bottom line, do be open to using what’s present rather than measuring the differences from a desired but not (currently) available outcome. Generally there’s more than one way. I’d generalise that as … abstraction, whilst recognising that’s not something many of us like or for which we have an affinity.
I hope that gives you a few more ideas.
Close. Precisely, from DEVONthink’s Help file glossary:
Replicant: A document or a group that appears in more than one place in the database. Unlike an alias in the file system, a replicant is not a real document pointing to another file (usually the original); rather it is a second entry in the table of contents for the very same document. Consequently, there is no original; when you replicate a document you’ll end up with two replicants.
Except in a very rare case not worth mentioning here, DEVONthink replicants are solely cosmetic. The file appears to be in more than one place, but it is only in one place. Groups in DEVONthink, which are are not physical storage containers, and only exist in the user interface, can be replicated without taking any physical space.
(Users frequently confuse DEVONthink replicants with aliases and duplicates – they are neither, and are not a hybrid mix of them. )
@PaulWalters You’re perfectly right. Hybrid is definitely not the proper way to describe replicants since the duplicate-part of the supposedly hybrid would definitely use up space. And this is not the case as far as replicants are concerned. Thanks for your substantial clarification!
That is also emphasised by the fact that DEVONthink uses the group-metaphor instead of speaking of folders.
Could we, @PaulWalters, go so far by saying that in the end a group in DEVONthink is ultimately just sort of a smart group, although DEVONthing offers – besides the “real” groups – explicitly “smart groups”.
Groups and smart groups in DEVONthink also do not exist as physical locations in the database or anywhere else. Smart groups are saved searches – there’s nothing there until you look at the smart group; regular groups are index entries.
Please do take a look at the updated comments below. Hopefully I ahve made myself a bit more clear.
Mark, I absolutely agree with this. Links have somehow got deprecated, which I find strange as they are the most (for me) powerful tool we have. We don’t even have the old Nakakoji view any more, which was reassuring, although I had big issues which I bored Mark B with until his eyes watered.
I always thought that links, plus a rewritten Nakakoji, would give us exactly those interrelations and alternative connections. But they didn’t.
Suppose, then, we had a link type called “Refutes”. We could pick any note or collection of notes and say, in effect, “Show me everything that refutes this.” Brilliant.
What we had was the ability to say “Show me all the notes which refute something. Doesn’t matter what they are, just that they REFUTE stuff.”
Big difference, and the clue is in the old name, which was “Path”. Fine for hypertext fiction, but not so much use for making sense of connections which may have been developed over many months or even years.
(It was a feature of the wonderful old bibliographic program called… hell, I forgot. But when it finally stopped working, I shed many tears for the end of my 20 year bibliographic network.) (Papyrus. That was the fellow. RIP.)
EDIT: I don’t mean to say Tinderbox deprecates the idea or the techniques of linking, just that it seems to have sidled to the back of the room.
Actually, composites (or simple multiple selection) give you a new Nakakoji view.
Came across this post while seeing if someone had answered this query. It seems that TBX aliases sort of do allow children after all? Has something changed since you wrote this?
