Hierarchical Tags
Posted: May 2, 2011 Filed under: essay 8 CommentsLike many other Web 2.0 systems, Piggydb supports tagging to classify knowledge fragments.
While tagging is simply for classifying a piece of information and allowing it to be found again by browsing or searching, in the context of folksonomy, its simplicity (non-hierarchical keywords) enables organizing information by many people collaboratively, known as “collective intelligence”, and connecting like-minded people.
Piggydb is not a social networking application, so it concentrates on the classifying nature of tagging. In terms of classifying, tagging has many advantages over existing systems such as directories/folders and categories. Tagging is generally more flexible and less brain-racking, and is used to resolve the “Bat problem”.
The ‘Bat problem’ was coined by Japanese economist Yukio Noguchi to describe a problem which arises when classifying information and goods. Material things and information can have multiple attributes that are used descriptively depending on the context (Bats have the properties of both birds and beasts – http://mythfolklore.net/aesopica/milowinter/43.htm).
Bat problem: http://data.lullar.com/%E3%81%93%E3%81%86%E3%82%82%E3%82%8A%E5%95%8F%E9%A1%8C
However, tagging also has its own problems. One of them is losing the grasp of the entire set of tags when the number of tags is growing. Piggydb offers hierarchical tagging to tackle this problem.
Hierarchical tagging allows you to classify a tag through other tags, exactly like knowledge fragments, and the classification is transitive; that is, if there is a tag “cat” classified with a tag “animal” and you classify some fragments with “cat”, then those fragment will be classified as an “animal” also. The hierarchical tagging feature allows you to classify fragments more naturally, and drill down a large number of fragments more easily and smoothly.
If you search fragments with the “animal” tag, all the fragments classified as “animal” will be selected, as shown:
Piggydb 
Hi Daisuke
You’ve mentioned that in a future major release of Piggydb, tags would become part of the fragment hierarchy. This suggests they’ll come to share the same user interface routines. That’s an excellent direction for the program.
At present, the UI for fragments is somewhat more well developed than the one for tags. For example, the slider enables fragments to be displayed in several columns, with a pop-up toolbar, while tags occupy a single column. Also, the fragment tree can display fragments at all levels simultaneously, while lower levels of the tag tree can only be hoisted, to the exclusion of higher levels.
Axiomatically, the more tags at all levels the user can display and activate at once, the richer the tagging. So I’m hoping you’ll look into the idea of a dropdown tag palette that shares some interface capabilities with the multi-fragment display screens, as a step toward their eventual merger.
An alternate approach would facilitate fragment-to-fragment linking, as well as tagging. That would be a toolbar option to force any query into a dropdown panel within the existing tab.
Right now, connecting two fragments pretty much requires an existing relationship between them. To get them close enough to connect may require giving them a common tag, a common update date, or a temporary common parent.
Suppose we have a set of business principles under one fragment branch, and a set of incidents or examples under another. We can see those sets in different browser tabs, even juxtapose them on a split screen via the Tile Tabs extension to Firefox. But icons dragged to connect the fragments will not traverse the tab boundaries.
It would save the user several steps if he could click on a toolbar icon to have the resulting query not displace the old, but build instead in a dropdown pane, whose fragments and drag icons were recognized by the existing query within the same tab. It would be like right-clicking on a link and selecting “Open in New Tab” or “Open in New Window” except that the dragging icons would be recognized bidirectionally across the boundary.
The ability to open a link in a secondary dropdown display would facilitate both rich tagging and fragment relationships, which are also bound to become more complex over time. I hope you’ll think about this approach as well.
Exciting future plans for Piggydb, from what you’ve revealed!
Warmest Regards
Jerome
Hi Jerome,
Thank you for your feedback as always.
Most of the problems you pointed out will be resolved when tags become part of the fragment hierarchy. With this change, fragments and tags can share the same user interface as you wrote.
Currently, I’m thinking about whether I should apply this change by extending the current program or rewriting it from scratch with a whole new model. I haven’t come to a conclusion yet.
I’m going to clean up the existing code, fixing bugs, adding features that don’t affect the current models and see how it’s going.
But I think your suggestions as below should be in consideration during V4.x branch. Especially, the inconvenience of creating relationships should be reduced or eliminated.
1) a dropdown tag palette that shares some interface capabilities with the multi-fragment display screens
2) open a link in a secondary dropdown display
Daisuke
Thanks, Daisuke. Another very useful attribute of Piggydb tags is that they can appear in multiple spots within the tags hierarchy. This proved extremely useful in tagging several thousand imported fragments, because it was necessary to work in passes, for some fragments, from the general to the particular.
Thus, if I could not tag a fragment adequately using top level tags, I’d drag the tag “_secondary” in. When going through those fragments later, I’d hoist a list of secondary tags in the Tag Palette, for richer tagging. Similarly, if the fragment had an outside author, I’d drag tag “authors” in from top level, then go through that subset later with a hoisted branch of author tags.
Because of the transitive property of tags, it’s sometimes helpful to put detail tags in a branch separate from their primary parents. To use your example: since a fragment display for the tag “animal” will turn up a fragment display tagged “cat”, we might want to keep a separate tag for “animal (unclassified)” with no sub branch, to identify properly those animal-related fragments that require more tag detail.
Since the same tags can appear in multiple posititions within the hierarchy, it’s easy to keep some of the most popular tags available at all times, even when the tag palette is hoisted to an outer or specialized branch.
Regards
Jerome
Hi Jerome,
Thank you for your valuable feedback.
>it’s sometimes helpful to put detail tags in a branch separate from their primary parents.
I thought the same thing before. When you search fragments by “animal” tag, you want the fragments classified with “animal” itself to be separated from the subordinate fragments in a certain way.
I just added this issue as a ticket: http://piggydb.lighthouseapp.com/projects/61149-piggydb/tickets/13
>it’s easy to keep some of the most popular tags available at all times, even when the tag palette is hoisted to an outer or specialized branch.
I think I should update Tag Palette to cope with a large number of tags as you kindly posted a related issue as a ticket: http://piggydb.lighthouseapp.com/projects/61149-piggydb/tickets/9
Best regards,
Daisuke
[…] Compared to these applications, Piggydb has powerful tools: Fragment Relationships and Hierarchical Tags. […]
Why are tag hierarchies to “top” are shown as a tree, but to the “bottom” only you can see one level? Also, why is the tag palette not in tree form?
Hi,
> Why are tag hierarchies to “top” are shown as a tree, but to the “bottom” only you can see one level?
Because the number of nodes would be predictable (should not be too many) when you look to “top” from a node while it would be possible for a node to have a huge number of descendant nodes when you look to “bottom”.
> why is the tag palette not in tree form?
That is due to the issue of the display space (fixed width). As a matter of fact, there is a tree view available through clicking on the “Tag Palette” title on the sidebar.
> Because the number of nodes would be predictable […] huge number of descendant nodes when you look to “bottom”.
> That is due to the issue of the display space (fixed width). […]
Both problems can be addressed in two ways:
1. show trees locally/partly, e.g. only two levels to top and bottom and only five subelements. For full view user can click on a button and go to a full tag tree view (tag palette full view)
2. make the frame scrollable
Tag hierarchy is for me the most important feature of PiggiDB. I want to organize different information types in tags and tag groups. Therefor I need to see the tag hierarchy overview very often. It would be helpful to see the same structure everywhere.