Tagging Turned Out to Be Not So Flexible
Posted: August 1, 2011 Filed under: essay 9 CommentsI’m about to start the development of V5.x after deciding that V4.23 is the final version of the V4.x branch except for bug fixes.
As I wrote before, as of V4.23, Piggydb has not achieved its most important goal yet. In the V5.x branch, I’m going to update the core model to aim at the goal I originally set. Some of the old features you depend on might be broken in these changes, so until the new features are fixed and stable, V5.x versions will be released as experimental.
Although there are many things to do in the plan of V5.x, I’d like to write a little about one of the most important things.
I think that the biggest design failure of the current Piggydb is “tagging”. I had a preconception that tagging would be unconditionally useful and flexible, and didn’t think much about it and actually I’d not been a heavy user of tagging. And I thought the problems of tagging would be solved with Hierarchical Tags.
Tagging, or classifying, works well if the whole system of classification won’t change much. For example, Table Tennis Videos is one of the Piggydb demo sites and it shows a good example of a tag hierarchy: country, player, date, event, play style, etc. These kind of hierarchies would be relatively stable as you could easily imagine.
I guess most of the users use Piggydb in more or less the same way. But this kind of usage, applying the known (ordinary) system of classification to your knowledge fragments, would not lead to the goal I originally intended. I want to focus on knowledge that will be changing in the course of a learning process.
The problem is that tags are mainly used to search information, as a mere index of content. If your system of classification has changed as time goes by, you have to modify the existing taggings according to the change. The maintenance cost will increase as the database grows and finally it would be out of control.
But still, I think the concept of tags is important for Piggydb.
Suppose Piggydb doesn’t have tags. You can structure your knowledge like Mind Maps, Outliners, or Wikis just by connecting knowledge fragments to each other. But, as the number of fragments increases, you will gradually lose the grasp of the whole picture of your knowledge. Tags would provide you with the overview of your knowledge in that situation. Yet you couldn’t rely on tags as a perfect index for your knowledge for the reason mentioned above.
With all these issues in mind, how should I change Piggydb?
Although I don’t have any decisive ideas, there are some that I think are important. One of them is to change the tag model so that a tag becomes a specific form of a knowledge fragment. As your knowledge base grows, at some point, you can turn a knowledge fragment which you feel is important into a tag as an important concept and it can be related to wider range of fragments to research it further.
An important theme of Piggydb is how it encourages users to create their own tag cloud based on their knowledge fragments, not on their known system of classification. This goal isn’t impossible to achieve with the current version if there are some instructions, but I believe that it is meaningless unless a software itself has an affordance to convey its philosophy to users.
Piggydb 
Hello Daisuke,
I realy like to help you with this development, so I’ll give a quick rundown of how my tagging-system:
1. I currently use tagging mainly to link stuff to filters. I have set up several filters that act as my main menu to enter the database through several scopes.
2. My tag-hierarchy is based on the NASA taxonomy (http://nasataxonomy.jpl.nasa.gov/), I used this so I have a broad taxonomy that might leverage my use of tags in the future.
I would like to see tags to become a special item in the hierarchy-view of snippets; right now I have to add ‘organisational snippets’ under a main snippet to organise the connected snippets. Example: I have a snippet for a scientist, below that I have a snippet for research-papers by this scientist, another snippet to hold all the related projects for this scientist, and so on. I have to create the same organisational snippets for all the scientists in my database.
But I have also tagged ALL research-papers with a tag ‘research paper’ so I can find all research-papers through a filter. Now if that tag would also behave as a ‘special snippet’ in the hierarchy, I could do away with the organisational snippets. The ‘tag-snippet’ would collect all linked snippets to a main snippet, filtered to that tag. Just by tagging stuff, the hierarchy would organise itself.
The other thing (towards your goal) would be if each ‘tag-snippet’ would be able to open a popup with all snippets listed and we could drag-drop links to add snippets from this list to the specific item we are working on. Linking a new snippet to the main snippet would add the new snippet to the specific tag-snippet for which we opened the popup.
One last suggestion is to somehow be able to expand the tag-hierarchy from that ‘tag-snippet’ and be able to open the popup with tagged snippets from a tag in the hierarchy.
I would seriously suggest that you keep a clear distinction between a tag and a knowledge fragment, otherwise you’ll end up with the model I use currently (organisational snippets). It is workable but certainly not an improvement.
I hope I made it clear, I’ll elaborate further on your request.
Regards,
Hans Peter Willems.
Thinking a little bit further along on this issue, I see one problem rising with the ‘special tag snippets’ I suggested; with the organisational snippets I’m able to link such a snippet to anothe hierarchy. E.g. linking the collected research papers for certain scientists to a specific project for review. The only thing I now have to do is to collect the organisational snippets for those specific scientists together under my project, under another organisational snippet ‘project-name: papers for review’.
Going from this, the ‘special tag snippet’ should also need to be able to link to other hierarchies. So I can see a ‘special tag snippet’ to inherit certain functionality that a ‘normal’ snippet already had (i.e. linking to other snippets). This would also mean that we could link between ‘special tag snippets’ them selves.
Hans Peter.
Hi Hans,
Thank you for your comment and sharing your thoughts.
I think your idea is not so different from mine: a fragment can be used as a tag.
The concept of a tag is essentially all about a relationship between nodes, not a node itself. So rather than regarding it as introducing a new type of fragments (‘tag-snippet’ in your term), it should be regarded as a new type of links called “tagging” in addition to normal links between fragments. In this context, a tag itself is just only a piece of information, not different from a knowledge fragment at all.
Best regards,
Daisuke
I also agree that our ideas are very close. However, the way you describe it in your reply here is almost identical to how I use fragments now instead of tags to group things. Currently, as my dataset is growing, I see myself replacing tags with fragments more and more to organise things. This is fine and perfectly usable. One could replace the tag-system entirely with a top-fragment named ‘tags’ and a complete hierarchy of tags below it al just defined as a fragment. Then, just link those tag-fragments to wherever you like.
The problem with this scenario is that a tag-fragment would link stuff together this way that does not actually have a relation. The whole difference (at least for me) with tags is that they group things ‘in context’ within a certain hierarchy. This is what I currently miss the most.
I do not want ‘research papers’ under one scientist linked to papers under another scientist, as that serves no real purpose. I do want the ‘research papers’ under one specific scientist to be grouped together based on a tag ‘research papers’. So basically a tag should group things, but mainly within the context of the hierarchy where the tag is used.
Hans Peter.
Why do you think all your knowledge fragments should be in the same hierarchy? Tag-fragments can be separated from the fragments they classify (are attached to as tags) and form an independent hierarchy.
My description of the new tag-fragment model might have been misleading because of the abstractness. But the important thing is that the old semantics (or function) of the model (fragment and tag) will not be broken by the change. You are concerned about losing the current function of tags, right?
No worries Daisuke, I’m not concerned in any way as you already made PiggyDB the incredible tool it is right now. I’ll welcome any new implementation and see where it will take me in using the program 😉
I was just describing how I use the tags and, more importantly, that my use of tags is already shifting to other ways of using them. I’m using tags less and organise more and more by creating fragments to group other fragments inside a specific hierarchy.
I’m looking forward to see where you take this. I’m pretty sure that whatever you do will work for me on one way or another as the underlying philosophy of PiggyDB (as you describe elsewhere on your blog) is very much in line with my own ideas about knowledge management.
So keep moving and I will tag allong 😉 Thank you again for an incredible tool.
OK, Hans. I might have not understood the whole point of your posts, but thanks for your kind words anyway 😉
That is interesting actually. Have you ever experienced a situation where it was difficult to choose between a tag or fragment to group some fragments together? I’ve been thinking about this issue for long time.
>Have you ever experienced a situation where it was difficult to choose between a tag or fragment to group some fragments together?
Well, I started out with a large taxonomy of tags, thinking that would let me organise stuff easily. But as I go I find that because of the current implementation of tags being ‘global’ and there is currently no way to filter on a tag ‘within’ a hierarchy if fragments, I’m replacing certain tags with organisational fragments.
So it is not so much a difficulty in choosing, and more an ongoing exploration in how to use PiggyDB to my maximum advantage.
>because of the current implementation of tags being ‘global’ and there is currently no way to filter on a tag ‘within’ a hierarchy if fragments
Right. That is one of the problems caused by the role separation of a fragment and tag. I hope it will be resolved in the V5.0 branch.