actually, i’ve tried this approach as well. it’s a good fix, but it only goes so far with helping me with my situation. there are two limitations with this approach: (1) i create many many specific tags per projects, so while it helps cull those tags by prefix, it’s still bloating a central tag taxonomy with a ton of tags, and (2) the space within the drop down boxes - in the dialogue box interface - is rather narrow, so it’s very hard to navigate to the right tag. it is even more difficult to do so with so many tags, i’m afraid.
yes. i certainly appreciate the reminder. i almost wish there was manual about how you approach your tag system (beyond your post on page 1 of this thread), since incredibly useful - and i feel like i’m missing certain aspects of how i ought to be using this tag-annotation approach. it’s revolutionized the way i annotate, and even note-take, actually. kudos. seriously.
i understand. just in case you missed my most recent query, i was asking is there’s a way to tweak the script so that it can to create separate tag layout per project, within groups (i.e., database->project assigned to group → tag layout for project). if so, it seems like that would enable the kind of control over creating a tag layout per project and allowing users to still replicate. thx.
i tried to see if i could create separate tag layout per project, within groups - but i failed. it seems tags can only reside in the “root” section of a DTP database. is that correct?
is there another, possible solution here that i’m overlooking - i.e., is it any way possible to create different tag layouts within the same database - but within separate groups? thx.
In DEVONthink, groups and tags are similar, so much so that File > Database Properties by default has an option named “Exclude Groups from tagging” that is checked. Unchecking that option makes groups a form of tags, and these tags will show in the right column if View > as Tags is selected, but will be colored differently from “normal” tags. If that option is checked (the default behavior) groups will no longer be listed in the right column of the Tags view, and will not be searchable as tags.
Groups and tags both provide metadata about documents, but we tend to think of groups as “filing locations” of documents, and tags as descriptors or characterizers of documents or their information content.
As you discovered, tags cannot be stored within groups. Both groups and tags may be hierarchical in structure, but the “top levels” of groups and of tags are independent and occupy the root level of the database.
Try an experiment. Create a new tag (that you may later delete) and give it a hierarchical structure, so that it contains sub-tags. Now drag a sub-tag out of that tag to the root level of the database, or into a group. What happens? Is it still a tag, or something else?
Think of hierarchical groups or tags as taxonomies. A taxonomy is a structured approach to describe, identify, name and classify things. For example a taxonomy of living organisms might have branches such as carnivores and herbivores (both falling under the category of mammals). Under carnivores we might find branches for canines and felines, etc. Under canines we might find branches for wolves, foxes and dogs, and under each of those we might find other branches. In that structure.
In DEVONthink parlance, groups “contain” documents, or more precisely, are filing “locations” of documents. Actually, though, the digital files underlying documents are not located in those groups, but in the case of Imported files, are in the Apple filesystem in a folder inside the database, named Files.noindex. Indexed files are stored outside the database and may be seen in the Finder. And tags do not contain documents, but are assigned to documents. It would be improper and could cause problem if one filed a document into a tag.
As in the example of a taxonomy, we might create a hierarchical group structure with the top level group named “Animals”, a sub-group named “Mammals”, under that a sub-group named “Carnivores”, and under that a group named “Wolves” (with parallel branches for “Dogs” and “Foxes” – and perhaps others as well). Where should we file a document about wolves? The proper location would be in the sub-group named “Wolves”. The document would automatically inherit the descriptors of the groups above the “Wolf” subgroup, that is, we would know that it is about carnivores that are mammals that are animals. This is similar for a hierarchical file structure using the same descriptors. We should assign the “Wolf” tag to the document about wolves, and it would automatically be also tagged as a carnivore, a mammal and an animal.
To tackle the issue of tags for different projects (some or all of which might have hierarchical structure), one could add those new tags for each project, and assign them to project documents (at appropriate levels in the tag structures). To avoid confusion, for example in results of searches by tag, each new tag should have a unique name.
To expand on Bill’s note. If groups-as-tags is enable (i.e., turn off “Exclude Groups from Tagging” in database properties:
Then a hierarchy of “normal” groups can be used on a per-project basis. In the example below, all the groups shown are enable for tagging, the “original” document “I am a text” was created in the “Group 1” group, and I gave it a tag “Grandchild” in the tag bar. DEVONthink took care of the rest: it automatically replicated the document to the Grandchild group and assigned tags for each of the parent groups of Grandchild.
The point of my example is that one can by-pass the Tags group and roll one’s own tag hierarchy elsewhere in a database. From this starting point, Frederiko’s script or mine could be modified to make use of this project hierarchy.
i’ve finally had a moment to try out this approach. i made a dummy database, created two groups in it - project x, and project y - outside of the root database hierarchy; that is, database->project x, and project y->and then… i created tag-folders inside of both groups.
my objective was to replicate a tag, and therein its contents. for instance, when i’m working on disparate projects, there are often some common themes - points of convergence - lets call them “global” issues. anyway, the point is, i was able to replicate the “global” tag-folder (and its contents) between different project-groups in the same database. hooray!
so, questions…
having done this, i don’t quite understand why this is an option instead of a standard modality. like i said, i’m relatively new to devonthink, so perhaps there’s some kind of functional or organizational features i’m missing. can someone kindly explain this to me? or, what are the features that make the tag-folder set up desirable as opposed to the standard tag set up?
apart from the different folder icons, what are the other effects of turning off “Exclude Groups from Tagging” in database properties? are there any downsides to this approach that i might be overlooking? (by the way, i assume that all folders are affected - by having a different color - by unchecking “Exclude Groups from Tagging,” correct?)
how does this approach affect other tag-organizational approaches? and right on cue…
right. so, if i use this tag-folder approach, i’d do so with the “Make an Annotation with Links, Notes, Tags v2” script (of course). to that end, the only hierarchical tags i’d use would be those that come with the script, i.e., “Issues” and “People” (as well as “Follow up”). my fear is that if i use the tag-folder approach with the “Make an Annotation with Links, Notes, Tags v2” script, it would replicate all of the parent “Issues” and “People” tags, correct? it seems to me that would create many, excessive and extraneous tags. would there be any way to fix this this? thanks.
also, one quick question…
forgive me, but i fear i’ve gotten lost in this thread, and i’m therefore confused. i thought Frederiko’s script was the same as yours, but just with a different interface. is that correct? or is there a crucial difference that i’m missing? it would be nice to have different “Make an Annotation with Links, Notes, Tags” scripts, provide they offer different features / approaches. please let me know whenever possible.
One major challenge with group tags is when the user creates groups (non-replicated) with the same name. Take your example where you have project x and project y, and then you create a ‘global’ tag group under each project group. If you then assign the ‘global’ group tag to a document, it will not appear in both ‘global’ tag groups. Likewise, if you view your database with the tags view, you will also see multiple ‘global’ tags in the list. Finally, it is possible still to also have a standard tag named ‘global’, which can further complicate the issue.
None of these conditions make the group tags unworkable, but it can be confusing for a new user. Which in part explains why it is an option rather than the default tagging behavior.
There are different interfaces and other tweaks. Try each script in this thread – they have evolved over the nearly two year history of this topic – and use the one you like.
i think i follow you. but let me ask this: instead of reproducing the same group in different tag - folders, why not just create one “global” in one tag - folder, and then replicate it in other tag - folder taxonomies? wouldn’t that work - and avoid the clutter you detailed? thx.
Replication of group tags may work just fine. I was offering an explanation to your question as to why group tagging is an option rather than the standard modality. Group tags were enabled by default when tagging was first introduced, but were later made optional as they can be confusing, and unpredictable, for the new user. Or even the experienced user.
My own experience over the years of working with group tags, as well as assigning regular tags to regular groups, is that it is a less than ideal means of document classification. As a result, I’ve done away with both as I’ve found it preferable to organize related documents by groups using the AI in DEVONthink, and manually assign additional metadata about the documents with tags. That keeps my number of tags to a minimum, which makes it much easier for me to actually use tags when searching and organizing relationships among documents.
The database organization that works for me may be very different from what works for you, and it’s great that DEVONthink has so much flexibility to accommodate a variety of organizational strategies.
thx. i think i follow you. just to clarify, i was only planning to use tags as part of this annotation process - i.e., one thought, one tag (or theme). otherwise, i agree: using tags would otherwise seem dangerously extraneous.
ok, bottom line, i’m def. interested in trying this group - tag approach with the scripts in this thread. is it possible to make the modifications you mentioned as a way of doing this? (right now i tend to use Frederiko’s script more regularly - just thought it was the same as yours, but i’m trying out yours now.) thx.
@korm, Can you explain why you moved onto Highlights? I like the app very much as well, but it doesn’t have the ability to use the tag / note / link features in your script and @Frederiko’s script. Or is there a way that you use Highlights - and then use these scripts?
Thanks for your input. It just helps inform the best approach for me!
understood. so, how would you suggest i make the necessary modifications you suggested? i don’t have any experience writing scripts/code. i defer to you and other users. thx again for your help and input. hope i can find a solution.
b) very carefully describe the behaviour you want, preferably with screenshots of the expected end results; and
c) describe how you would achieve the results manually;
so that you understand very clearly how you want DT to perform the task and how DT would actually perform it.
I will have a look and see if its doable in a reasonable amount of time.
Defining what you want to do and how to do it, is often 80% of solving the problem. You need to understand your workflow very well before you can map it out in this way.
A good way to start, is to look for other tools that may have elements of what you want. In my case I played with casemap and watched various training videos to decide what were the most important features for me to replicate.
first of all, i want to thank you very much for your work, and korm’s work, creating this script. it’s a tremendous contribution, and it isn’t lost on any of us.
second, thank you for considering my requested modification. i really do appreciate it.
i honestly don’t think your dialogue box interface should be changed at all - that’s not at all the issue for me. really - i’d only reproduce what you’ve already created. i’d only add two wishes to the interface, if they’re all achievable: 1) a longer drop down scroll length for the drop down bars (as there a bit tight on width), and 20 instead of having the “Annotation name” auto-fill with the file name, it would be great to have it auto-fill with the first few words of the citation. again - just wish list ideas, but i think they’d be great enhancements.
anyway, i’d use the same hierarchical tags that already come with the script, i.e., “Issues” and “People” (as well as “follow up research” and other research-related task i’ve created under your Annotations tag).
i’ve attached the following screen shot of what i’m seeking, per your instructions.
the process is actually identical to yours, with one difference: instead of using the tag taxonomy located in the the root database hierarchy (i.e., the default setup for tags, for DTP databases), i’m trying to create tag taxonomies located in different groups within the same database - so that i can replicate certain tag - folders between groups.
in the screen shot, i’ve assign a project to its own database to create distinct tags per groups - where there are unique “Issues” and “People” for a given project. but…there are some crucial instances in which a person or issue would overlap elsewhere, and should belong to (or be replicated to) another project. for instance, when i’m working on disparate projects, i sometimes find common themes / points of convergence (specific “global” issues that should be replicated between projects). or, if i’m writing a book, i’d like to have focuses chapters with particular “Issues” and “People,” per chapter, but certain “global” themes that run through the whole book.
we’ve established that one cannot replicate tags between databases, so…i made a dummy database, and created two groups in it - Project A and Project B - which are located outside of the root database hierarchy (that is, Dummy Database->Project A and Project B), and then i created tag - folders inside of both groups by turning off “Exclude Groups from Tagging” in database properties. as you can see, i manually created the same hierarchical (or parent) tags that already come with your script: “Issues” and “People” (as well as “follow up research” under your Annotations tag).
my objective was to replicate a tag - folder, and therein its contents, for “Issues” and “People” that have “global” significance, and therefore ought to be replicated elsewhere. through my setup, i was able to replicate the “global” tag-folder (and its contents) between different project-groups - Project A and Project B - in the same database. again, this allow users to have distinct tags per groups, while also providing an option to replicate certain tag - folders.
so, the modification seems to boil down to trying to figure out how to make your script work with a tag - folder set up (as opposed to DTP’s default tag set up) by turning off “Exclude Groups from Tagging” in database properties. btw, i tried using your script with this setting, and it didn’t work…
the only thing i fear is that replicating tag - folders with this approach could also mean replicating all of the parent “Issues” and “People” tags. if possible, it would be great to eliminate all other such parent folders - since it would seem to create a bloated system of extraneous tags.
i think that about covers it. i will say that the script is amazing in its current form, and (again) we’re very grateful. i’ll tack on one more to the wish list: it would be great if there was a way to also create something like this for the iPad as well, since i do most document annotation on the iPad - and it would therefore speed up my work process considerable to add in tags during that annotation process. (think TagNotate - but for an app that actually works, syncs with DropBox, has been annotation, and interfaces with DTP!)
i thank you again for your amazing work, and for even considering this request. as alway, i’m happy to consider different suggested modalities. thx!
Too costly, and I’ve moved on to Highlights.