Is there a way to create a new tag for a document that allows you to determine where in the tag hierarchy it goes, or at least automatically put the tag in the document’s current level (without having to drag the newly-created tag afterward)?
I’m using tags as provenance (source info) and have multiple levels of tags, e.g. Primary>Published>Letter>Hare correspondence. So let’s say I have a document that I want to create a new tag for, say …Letter>Edison correspondence. Rather than drag it to the Inbox, I drag that Edison file into DT to the Letter tag (i.e. lowest child level). I’d like to then create a new tag (e.g. type ‘Edison document’ in the tag bar), which I’d think should appear as a child of the Letter tag, on the same level with Hare.
But if I drag a document into a nested child tag and then create another tag for that document from the Tag Bar, the new tag appears at the top-level of the tag hierarchy, rather than in the parent folder where the document resides. If you create a new document, tag or folder with the New command at a specific level of the hierarchy it places it in that level, so why are tags acting differently?
Is there a way to achieve this? Right now I can drag the Edison doc to the parent Letter tag, select a child tag (e.g. Hare), create a new Edison tag with New Tag command at the same level as Hare, click back to the parent Letter tag to see the imported Edison doc, drag the doc to the new child tag (or assign it in the tag bar), and then delete the old Letter tag in the Edison doc so the Edison doc doesn’t appear in the parent tag. There are a couple other possibilities, but I think they all require dragging and deleting old tags.
Are you creating documents in the Tag Groups? If so, I would highly suggest you don’t do this.
The Tags Groups are essentially for visual searching by Tag. I suggest using Groups for data segregation and Tag files through the Tags bar available in some views or the Info pane.
Can you explain why it isn’t a good idea to store documents in tags?
I’ve been doing it for months without any problems. I store the original documents in tags (often non-OCRable PDFs) and then any RTF notes I take are put in groups. From my experiments and from the manual, it’s not clear why this would be a problem.
Thanks.
The intended design of tags, the way they have been implemented in DEVONthink, is that the groups that are children of the Tags group hold replicants of documents stored elsewhere in your database. Adding a tag automatically creates a replicant in a child of Tags that has that name.
If you mix replicants and “original” document in Tags it can get odd. That’s not necessary a bad thing, though you might want to be aware of the downside: If a future version of DEVONthink comes along that expects your legacy Tags group to behave one way (i.e., contain only replicants) but you’ve set it up a different way. Let’s say that Mavericks tagging leads to a scenario where the current “replicant as tag” design is tossed out. That might cause problems with your databases.
And, it might not of course. Who knows? Using software in a different way than it was designed (as expressed in Help, the Manual and lots of posts here) is your choice of course. It’s your data, your copy of DEVONthink. Just be cognizant that what seems like a little tweak might turn out to be a headache.
OK, that makes sense. If DT had an easy way to batch edit the metadata (or something similar), I would’ve kept the tags for more ‘normal’ use, since it is admittedly a kludge.
Fortunately, it doesn’t look like it’ll be too dangerous. If the OS or DT changes, I should be able to just roll back, create a Sources group (and turn on Exclude from Classify), and just move all the tags to that group in a step or two.
Can I repeat a request for a way to include more ‘metadata’ for documents (even if it isn’t technically stored in a file’s metadata fields)? As a historian I have literally several dozen metadata-ish ‘attributes’ for each original document, and I need to keep track of all of them separate from my notes on the original sources (which definitely need to go in groups). To mention just a few: a document could be a letter published in a book, which includes among other things an editor, an author, a recipient, a place book published, a place letter written, a book page number, a book letter number, an archive reference, date letter written, date letter received, year book published… Relational databases made it easy to make separate tables and link them, but I don’t see how to do that with DT.
Any child group dragged out of the Tags to someplace else in the database turns into a “normal” group, with the replicants (or anything else) stored there intact.
I agree with your request for custom metadata fields.
Something I’ve used in the past is a Tagging system like “author:Neumann, James” or “model:Countach LP5000”. This allows for some more contextualizing of Tag data (one of the inherent weaknesses of Tagging systems, and and overlooked issue when working with Tags). This method allows for more focused Tagging like “actor:Paul Newman”, “entrepreneur:Paul Newman”, and “driver:Paul Newman”.
You can use a simple seach of “author* AND James” or create a Smart Group with: Tag is modelLP", etc.
You could attempt to create this as a hierarchical Tag structure with an “author” Group and a “Neumann, James” Group but the typical Tag display doesn’t show a familial connection between the Tags. Without this visual connection, how do you know what parent of a “Paul Newman” Tag is applied??
Also note, an inherent weakness in any Tagging system (though I can’t speak of Mavericks (though I’m doubtful)), is the Tags are merely strings-based. This means numerical sorts are not implicit. It also means that you can fake this out to some degree with non-numerical data but you should decide up front how to structure the Tag. For example, I could make the Tag “Neumann, James:author” so it sorts by last name. (I’m disregarding any scripting methods to cull this info too.)