Forgive me if my request has been made before, was shot down, or somehow already exists.
My request is for a way to bundle files together into a package. This is pretty much what a group is. Except I would like to see these held together and listed as a single file would. For instance, I collect book citations, scanned book excerpts, book reviews, my own notes, and information related to the author. I would be nice if I could clip these all together so when I search for the book I get one hit–the bundled file–rather than the book citation (which I keep as a text file), the notes, etc. For me each book is one item and the ancillary pieces are but components of the one item. Of course, if want to have the ancillary files searched separately I could replicate them outside the bundle. But since I won’t be searching for the book review on its own (it functions only as an adjunct to the book itself) I’d rather it not turn up in search results (it would only crowd the result).
Of course, you might say that I could do this already with groups and mark the files as not eligible for search. Fine but my point is that every time I access book X, I want all the ancillary material readily available. Also, some books have ancillary materials and others just the citation. I’d like them to both me legible on the same file list when browsing, rather than split into folders and groups which are listed separately and for me serve different functions.
I don’t think such a thing as bundles already exists but if it does, please let me know. If it doesn’t exist, any chance it could be implemented?
Hi. Smart groups work great for this kind of thing. Also, creating a table of contents file can be handy (select all things in a group and right click to get the menu item). I tend to use lots of groups, though, and replicants (awful similar in practice, if not in theory, to tags) because the ios app is best organized with them (tags, note links, etc. aren’t recognized).
“Bundles” are groups – so you just want to use existing features to group documents. For that, the smart group idea is great.
Here’s an alternate, enable your bundle group for tagging and then tag the component files with that group name. Replicants of those files will appear in that group. If you need to export your bundle, just drag it to the destination in Finder, or drag it to another database – the replicants will be turned to duplicates at that point. Replicants are the same file – there’s only one instance of the file in the database and replication makes that instance appear wherever you choose.
In a similar vein, I have a group in every database named “Work in Progress” and a little shortcut script that toggles (add / remove) the tag Work in Progress to the files I select – they are replicated to that group, which is a lot easier than navigating through a database to find current work. Entire groups can be tagged and replicated (as subgroups) this way.
I could have used a “normal” tags for this, but in my databases tags are qualitative attributes, groups are “hardscape” projects and tasks. Also, normal tags are bound as children of the Tags parent and I like to rearrange groups at will.
I understand your suggestions and I agree that what I’m looking for is a sort of group function–but a smart group is a limited substitute for it. What I want is a sort of fixed group but one that exists under the hood so to speak. Above the hood it can be manipulated and searched for as an individual item (with the option of replicating the component files out of the group). This is valuable for two reasons.
First, it ensures that the component files always travel together (with the caveat above). For instance say I have an article pdf and notes on it in rtf. I might not remember 6 weeks from now that I wrote notes on this particular article. If I have them bundled together then everytime the article comes up in a search both the pdf and rtf appear together. Or I might want to bundle several article pdfs together because they are on the same narrow subject and so I don’t want or need them stored as separate items (it would clutter the database and be confusing to see the files out of context).
Second, I want to view the bundle in the database the same as I would a single file. Right now DT displays groups and files separately (which I like). In the 3 panel view, you see folders on the left, files on the top right and the contents of a single file in the bottom right. In my scheme a bundle would live in the top right with the files. The alternatives you have proposed is for a smart group that lives on the left side. But there I have (to take one example) functional groups (say, separate groups with secondary sources on topic A; secondary sources on topic B; primary sources on topic A; etc.).
One way of bundling files together is to put various files into an rtfd. But this isn’t elegant and doesn’t let me replicate some files out of the bundle. What I’m looking for is perfect for the DT platform because it excels in organizing files through virtual groups (like tags). This is just one more kind of virtual group with some distinct properties.
I’ll give you one more example where this bundle scheme would be useful. I’ve conducted a bunch of interviews, each of which involves an mp3 recording, a transcript, notes, and a vita for the individual. Ideally these components would always travel throughout my database as a unit; never as distinct files. It would be great if each set existed as a bundle in the name of the person interviewed.
I hope this makes sense.
Cheers,
Eduardo
PS - The following is redundant but maybe also clarifying. I see the database as a collection of items, which are then organized into various groups. What I’m asking for with bundles is that the notion of an item be expanded beyond an individual file; sometimes several files are components of a single item. Those component files are not items in themselves. If they are organized as groups (e.g., smart groups), this scheme is violated. By way of analogy: separate pages in a pdf file. You wouldn’t suggest that the pages be broken down as separate items and held together with smart groups. A pdf, then, is a bundle of pages. Now you could suggest that I just merge my component files together into a pdf but this isn’t very satisfying (rtfs might continue to be added to, etc.).