I have all sorts of strange and sometimes unnecessary ideas, and this is one of them in the process of coding other stuff. This one is for those who want to avoid creating too many tags on the same subject (which I think is making tags to become less meaningful) or having fat fingers (wrong/fast entries creating unwanted tags).
1st post is for the demo, 2nd post is the script and reminder.
(1) Click on button “cTag Public”. A list pops up and showing the entire tag-tree in the current database.
Multi-level tag-groups is supported. In this demo, “/Tags” is setup as the top group, “C.Content”, “D.ResearchDesign”, etc are the main tag-groups under “/tags”, and other tags are their child-tags respectively. User can config their top-tag in the script. You can choose one document, or a list of selection for tagging.
(2) Multiple selection is supported by using cmd-click. No selection is accepted by using cancel button. All main tag-groups need to be excluded for tagging in the database, so don’t choose them. Else the script will create additional tags with the same name to those main tag-groups.
(5) All newly created tags will be placed under a group “New Tags”. You can choose any group to gather the newly created tags before reclassifying them. But the gathering location must be specified in the script.
(6) The document. You can see that there is a tag named “New Tags” which you haven’t input in the process. This is the name of the group for all new tags and it serve as a reminder that you still need to classify the new tags. If you don’t like showing a “New Tags” in the document, exclude the group “New Tags” from tagging.
There are three things to be configured in the script:
(*Initial Settings*)
property cardTagging : "CA" -- "C1" for 1 level of tags, "CA" for all levels of tags
property topTagGp : "/Tags"
property theNewTagsLocation : "/Tags/New Tags/"
(1) "cardTagging ": CA- show all level of tags under the main tag-groups, C1-show only the immediate level of tags under the main groups.
(2) “topTagGp”: where you want to start. This one needs more consideration. If you only have 100+ tags and a reasonable updated computer, CA will show all tags reasonably fast. If you have thousands of tags, perhaps u should consider moving the groups that u want for using this script under another top group, e.g. “/Tags/Commonly Used/”, or shouldn’t consider using this script at all. You have to test it on ur own computer to get a feel. C1 option doesn’t have performance concern.
(3) “theNewTagsLocation”, where you want to collect the newly created tags. Imagine that it is an “inbox” of new tags waiting for reclassification. This tag group must be created before using the script.
(4) As usual, use test database, I probably won’t be able to help in the debugging unless I see problems in my own usage. Please accept my apology in advance.
If someone can come up with some sort of optimisation to speed up the recursive handler I used, please let me know and post it! Thank you in advance.
EDITED 2019.08.22 the script: (a very small change in script that improves the performance of “CA” quite a bit, especially for database that have many items under tags. A bad choice was made in the coding of loop in earlier version) cTag Public v1.01.zip (521.2 KB)
(1) I can see the whole hierarchy knowing which level I want to tag (2) multiple tag selection at once instead of type and match (I only focus on 50-60 tags in four main groups in my personal version) and (3) collect all newly add tags in one place instead of searching them somewhere in the tag structure.
Nice. I did something similar for keywords in iTunes ca. 2007. There’s a lot of value in using a limited set.
Rather than generate the tag cloud anew each time (it was 2007 so there HAD to be a tag cloud!!!) I cached the list in a text file and had a script to manually refresh. That sped things up a lot.
That’s a great idea. The list of tags can be generated and written as a list in a .plist file under user script library. The trade-off between performance and the accuracy of the tag list can be resolved by either
(1) using smart rule with custom script to update the .plist’s list on regular time interval.
(2) use a property in script (just learnt that property is persistent in Mac OS as long as the script is not recompiled) to reserve the last updated time, if last update time is too far away (say one day) from now then use live tags list and save to plist again.
This script is an element of my pet project and I will attempt to implement the idea in the next stage (function before optimisation…).
sed -e 's/ /\/g' enumerated_tags.txt | sed -e 's/%//g' | sort | uniq -c | sed 's/\(...\) /\1|/g' > tags.txt
to go from a text file with every tag (including many duplicates) to a list of unique tags. I used iTunes AppleScript to produce the text file but here (as always) it was way faster to use a compiled command-line tool for the actual processing. I haven’t ever tried managing a .plist in AppleScript but I’d guess it’s not the fastest option.
Thanks. I’m just a beginner in scripting and using shell script is probably my next stage of learning in leisure time (unix command is still looking like alien’s language to me at this moment). .plist is fast enough for this particular purpose even for a list with several hundreds of tags, and it serves as an data object for me to access other parameters of my pet project.
A brief test by using debugger shows that the time for referencing the properties of tags in the recursive loops vs retrieving a saved list (300 tags/items) from plist is off by about 200+ times (2.5 sec vs 0.02 sec). Time for running the recursive loops directly in DT3 will probably shortened to <1 sec but it is still an improvement of over 50 times. Thanks for the suggestion again.
using shell script is probably my next stage of learning in leisure time (unix command is still looking like alien’s language to me at this moment).
Just a caution: Be prepared to take responsibility when using the shell. I once lost three years of data in less than thirty seconds by misplacing a single forward slash.
Thanks for the kind reminder! If I am ever going to use shell script it will be limited to value within variables. I never have the urge to work on anything at inter-apps or OS level … perhaps with the exception of writing to the plist of custom-script.
Thanks for the kind reminder! If I am ever going to use shell script it will be limited to value within variables. I never have the urge to work on anything at inter-apps or OS level … perhaps with the exception of writing to the plist of custom-script.