Something along these lines would be a big help. I suspect it would not be easy to implement, though, since it creates a risk of lost focus,doesn’t it? I mean, everything in your database is related in some way to everything else, so you don’t want to see all possible associations. OTOH I wouldn’t want to have to live next year with groups I create today – I expect to improve my understanding and make changes. And of course the same data can support many different schemas.
So there’s a tension in this kind of application between the urge to build walls (this goes here, that goes there) and the urge to build tunnels (this and that have a connection). This has been driving me nuts for years, but maybe I’m easily confused.
I guess the point of replicate and duplicate is to let the same information be part of different groups, while keeping the groups quite distinct. Right?
You can create such a net in Tinderbox. But the price of that flexibility, in my experience anyway, is that you have to do everything yourself – all the things DT does for you, like import, classify, concordance, see also, export in various ways, relate the database to Finder files. I don’t know if this is inherent to the great flexibility or if it’s a matter of the personal style of the guy who wrote the app, but there it is.
Nah, as usually I would want any kind of documents be linked - even PDFs or pictures. With text documents this is a good thing, I only wished I could create the link automatically when using the wiki-auto-generation of files. But I guess there are some different approaches that would work:
Table of Content files that link the related files together
Using replicates
Using RTF Documents that contain the non-editable document as an attachment…
Well, perhaps the current group system could be there for for users’ basic hierarchy and all the AI functions, but an additional system of (say) “associations” could be added. Here’s what I was trying to fumble towards.
Suppose you have a group “poetry” under a group “literature”, and a group “world war I” under a group “history”. You’ve just written a content on the first world war poet Wilfred Owen. Since it applies to both sub-groups, you replicate it - no problem.
But now suppose you’re writing an article on literature (not just poetry) about war (not just WW1). You could make another group, and collect replicates from all the rest of your database - it’d be hard work, but you could do it. But where do you put that new group? Under literature? Under history? At root level? In a new group dedicated to collecting sub-groups of content used in articles you’ve written? Nothing seems right. See, replicates don’t seem to be appropriate in this case - they’re at the content level, not the group level.
What I was thinking of was more an extension of the label… a simple way of “associating” content from all over your database, on the fly, and that doesn’t affect DT’s auto-classify and the rest. You’d need a pop-up list of all these “associations”, and (gulp!) a way of organising them into hierarchies… no, you’re right. It’s absurd.
It’s not absurd. It’s the classic dilemma all librarians face day to day. There is not perfect way of organising knowledge. Librarians use a hierarchy (called classification) and keywords. Indian librarians use something similar to what you suggested, the “facet” classification based on the different types of energy a book contains (no joke!), but that completely unusable by non-Indians
We already have something on our to-do list that’s called “categories”. We’re still not certain about how they will physically look like, but they may be at least an approach to what you’ve been thinking about.
That’s good to hear. I hope these categories can be user-defined, that there can be as many of them as the user needs, that each note can have multiple categories, and that this function will be included in DN as well as DT. Until then, I guess I’ll use labels and groups and the regular search function, which should probably be sufficient.
I’m not sure what should happen when you search by category – would new, temporary category groups be formed? Or would it look more like the current search function? When I did this in Hypercard, I didn’t have groups – only keyword categories – so I can see how this poses a challenge for you developers. But I’m sure you’ll figure out something clever, as usual.
May I respectfully ask if there are new developments regarding this matter since?
I now have a use case where these questions boggle me a bit.
In the Summer Fest sale I bought EasyDataTransfer. Nice tool that saves the transformations applied to a data set (.csv et al.) as a separate file and therefor is able to reproduce the results on different sheets given.
So when it comes to store them it seems imperativ to at least save a master sheet with it. Otherwise the transformation.file is useless.
In practice on the other hand I may get only interested in the trans.file when I read the output file. Maybe because I want to update the data.
So I would appreciate to (at least) make a stable connection between those three files:
Input.xlsx + trans.file + Output.md
I could leave a set in a folder and leave as is, but for different reasons I don’t feel well with it.
At the moment I am unsure to create custom meta fields since a transformation can grab its input from different files as well it can have an x amount of output files.
My best guess of a handy feature for DT would be something like:
“create see also for selected files” so each document would have a custom “see also”.
Since devonthink can not read the trans.file, I am in need of somehow “hard links” that are easy to establish. Are there new suggestions?
