This release adds Two-way Relationship Creation and Display.

The “Create a relationship” dialog has been updated to provide you with more options for creating a relationship: the direction of a relationship, one-way or two-way.

The display of fragment relationships has also been updated to support two-way relationships.

In the above display of the previous version, the relationships are displayed respectively as one-way while the new version provides a cleaner display for two-way relationships:

The user-related actions (“Change Password”, “Logout”) in the main menu have been moved to the pull-down menu at the login user name.

The tag cloud has been updated to exclude system tags that start with ‘#’ in order to focus on the concepts derived from user content.

The first step of V5.x development was to introduce Tag-Fragment, which was an attempt to upgrade the role of tags from a mere index to representation of important concepts in a database:

The cloud view also supports drag-and-drop tagging.

The Tag Palette on the sidebar has been updated to save the selection of the view type (tree/cloud/flat).

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-dev5, please download it from the links below:

• Standalone Package
• Browse All Packages

This release updates the fragment part of the tag-fragment page to have a full-fledged feature (to create sub-fragments and reorder them, expand the fragment tree, etc):

I think this screenshot represents what V5.0 is all about pretty well.

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-dev4, please download it from the links below:

• Standalone Package
• Browse All Packages

The edit button is shown on the tag page if the tag has no content. Clicking the button converts the tag into a tag-fragment and opens an editor for editing its content:

↓

The Tag menu in the main menu was removed. Though the tag tree and tag cloud in the menu are not available in this version, they will be re-implemented to be more accessible in a later version.

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-dev3, please download it from the links below:

• Standalone Package
• Browse All Packages

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:

• Standalone Package
• Browse All Packages

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:

• Standalone Package
• Browse All Packages

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.

The left is old “tree” view, which allows you to find tags through the tag hierarchy, and the right is new “flat” view showing all the tags in a flat list. This feature was inspired by the feature request. Thanks to Jerome.

When tagging, out of sight means out of mind. Thus tags that are not at top level on the Tag Palette will tend to be underutilized.

The Quick Edit feature, which was added in the previous version 4.22, was extended so that it can be used via the edit button (pencil icon) on the fragment toolbar. Which means, you can quickly edit fragments that have contents hidden or no contents.

↓

The Fragments View slider was updated to have a new variation of fragments display as below:

Double-clicking on a content area turns it into an editor:

↓