Hi
I have ignored the tag system in DTPO for a long time and made do with the groups and replicants if need be. This creates a lot of overhead though and I am beginning to realize that the groups = tags approach would let me do this much quicker by simply treating the tagging system inside DTPO as a convenient and quick input method for much the same information. I use a very similar system in Aperture and it just works.
I am constantly running into a brickwall by the way DTPO interprets its own tags, though.
Just about every other tag-related program interprets tags as pieces of descriptive information that are primarily self-contained. The power they convey is not so much derived from the actual information they themselves contain but in their combination with other such pieces of information.
DTPO is the only exception I know that insists on taking the context of a tag into consideration. To be very clear, the difference here is that each tag in and by itself has a context in DTPO, whereas all the other, more set-theory minded programs, would derive context from the combination of tags.
By way of an example of the differences between the two approaches borrowed from this thread: [url]Tags .... aren't - #3 by Bill_DeVille]
If you wanted to view the photos taken in Paris from this structure of nested folders
History
Paris
Photos
Paris
you would simply combine the tags Paris (which would by itself combine photos and excerpts about the history of Paris) and Photos whereas in DTPO you would simply choose the tag Paris BUT you would need to make sure to pick the right one from among the many Paris tags in your tag list to achieve the right thing, namely the one that has as its parent the tag/folder Photos and not the tag called Paris that had History as its enclosing group. Difficult task BTW because all the Paris tags look absolutely the same in the tag list.
I know that this is a contentious issue and I am not debating if the DTPO approach is right or wrong. What I am asking is whether implementing the second and arguably otherwise widespread approach to tags could be implemented as an alternative to the current and rather idiosyncratic take on tags. I respect the fact that some people are happy with the way tags currently work in DTPO but others (including me but also people migrating to DTPO) just can not wrap their heads around this new approach when all they want to get to work is a tried and true approach to tagging they are used from elsewhere in their computing or professional lives.
More precisely: I would love to keep tagging as a convenient way of placing new items inside a moderately hierarchical folder structure, this far I concede that the DTPO approach of treating groups and tags as equals (at least almost equals…) indeed makes sense. What I would like to see altered at least as an alternative is a different interpretation of tags when retrieving information from said structure using tags.
Thanks for taking this into consideration and sorry for the long post.
Prion
to illustrate my point, here is a screenshot of trying to get the example in the above post to work. In short, it is impossible to create this structure in DTPO or to correct the tags inserted in DTPO. The problem is that DTPO memorizes the context in which tags have been used and will assign tags preferentially to known contexts (see picture).
I am not saying that what DTPO is doing is wrong, it just does not do what I intuitively expect. If that could be remedied without altering DTPO’s tag behaviour I would be just as happy.
BTW assigning the two combination of tags in Journler works with no problem but for various reasons I would not want to use Journler for this project.
not sure myself, perhaps it is me who is missing something that’s what I am here to find out.
The quick sketch below is a fair representation of what I think the above example should work like which is totally fictional but that is beside the point. Let’s just assume that some of my Paris-related entries have to do with History and some others are best described as Photos. I would assume that the combination of the tag Paris with either the tag History OR the tag Photos would deposit these items (and allow me to later find them) the intersection among red/yellow and yellow/green areas.
DTPO confuses me because (1) it would not allow me to use the Paris tag in any other combination other than the one I originally used it in insofar as it secretly adds the History tag (which it knows has been used with Paris already)
(2) even when I go back to the tag list and delete the unwanted History tag, it keeps adding it back again and (3) if groups and tags were the same thing I would still expect to find the items with the tags Paris and Photo in the intersection between yellow and green. Certainly NOT in the intersection between Red and yellow which is where DTPO is happy to put them.
As you can see, I am pretty much expecting DTPO to interpret tags in a set -theory related way.
It works in the expected way in other programs or even with Smart folders in the Finder but they are just too cumbersome to set up to be usable on the fly. DTPO is much better in the usability regard, at least in principle, but if tags and groups were really indeed the same thing then I don’t understand why there are grey and blue variants of tags and why the above example does not work the way I expect it to in DTPO. I guess I am seriously confused, I am not even sure if there is a logic behind the behaviour of DTPO that I am unable to understand or if it is simply a bug.
I’d appreciate help here, thanks
Prion
The challenge that you have with this setup is that multiple folders in a database with the same name is fine. However, having multiple tags with the same name does not work well, and that is the problem that you are seeing. If you switch to the Tags view, you will see that you have at least 2 Paris tag groups.
Documents in the database will inherit the parent tag of a tag group, but will only do so reliably when the sub-groups are uniquely named. The reason that you don’t see this issue in Finder Smart Groups is that the filesystem, and every other tagging application that I have worked with, do not allow a tag name to be used more than once. Some of them will allow the user to mix and match lower/upper case to make unique tags, but they will not allow more than one ‘Paris’ tag.
tshanno has suggested one solution that will work, and I’ll offer another. If I were setting this up, I would have just the History group and just the Photos group, and I would have a regular (blue) tag for Paris. Then when you search for Paris and Photo, you’ll get the intersection that you want. You’ll also get more flexibility for tagging, and searching, should you have the need to tag a document ‘Paris’ that you do not want to be filed in the History or the Photos groups.
I complained from the beginning about DT’s definition of tags (i.e. not being based in set theory). Photography apps that support tagging have it right. “Paris” can be inserted in a tag hierarchy multiple places, even placed at root level. The idea is that if you use the hierarchy to quickly add tags, choosing “Paris” at any one location will also add the parent tags. If you manually insert “Paris” in the tag field and nothing else, then this would equate to using the root-based “Paris” tag. However you add tags to an item, doing a tag search on “Paris” alone should result in all records that include “Paris”, regardless of any other tags each record may have.
Another approach involves mixing tags with classification keywords. Many times, when creating a tag hierarchy, the higher level “tags” are frequently not meant to be tags, just categories for storing collections of tags - the idea is to be able to quickly find tags. There’s nothing worse than have 2,000 tags, say, all listed at the root level and trying to find a tag you know you have previously defined but forgot exactly what it was. Using hierarchies is a way of classifying tags for easy searching.
