This release introduces Tag-Fragment, which allows you to use a knowledge fragment as a tag. It is simple to say, but it enhances the flexibility and expressiveness of Piggydb quite a lot.

In comparison to the impact on the internal model, the change of the user interface is trivial, just one magical button:

If you activate the “As a tag” toggle button when creating/updating a fragment, the fragment will be created/updated as a tag:

↓

You may notice the tag icon at the head of the tag-fragment title instead of a number link.

The tag-fragment page shows the information of both tag-side and fragment-side of a tag-fragment.

You can attach an “as a tag” attribute to a fragment anytime you feel necessary and remove it from a fragment just by deleting the tag:

I have been thinking about this update since last year, and finally released it as V5.0-dev2. Altougth it may seem like a trivial update, I expect that it will change the process of knowledge creation dramatically.

The releases of the V5.0-dev branch are experimental. So the default download remains version 4.23. If you want to try out V5.0-dev2, please download it from the links below:

This release is a preparation for the development of the next generation Piggydb: the features planned in V5.0 were not implemented in this release, only prerequisite changes were made.

The title field in the fragment form has been moved to the top:

The Quick Edit feature has been updated to support editing a fragment title and a minor edit option as below:

The releases of the V5.0-dev branch are experimental as I wrote in the previous entry. So the default download remains version 4.23. If you want to try out V5.0-dev1, please download it from the links below:

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.