Tagging Turned Out to Be Not So Flexible

I’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.