Another thoughtful comment on filters from Igor:
I am tinkering a bit with Piggydb, as I am looking for a replacement for BasKet which stalled at KDE3, and my favorite Wiki on a Stick that is on its way to discontinuation of development for some years now (unfortunately, pretty common in one-man-developement FOSS). So far, Piggydb looks extremely promising. To get to know it, I wrote a little knowledge base of its user interface, parts of which are undocumented, and that made me read the documentation base thoroughly.
Concerning redundancy of filtering, I can only confirm it from the standpoint of purity of concept. However, Piggydb is just a tool, so the true concept is its projected usage. I see filters as saved searches, and when the base is growing huge, one needs every help in finding fragments. Using tags, that is, concepts for this purpose makes tags themselves impure, or rather misused. Besides, no matter how do we approach tagging, possibility of tagging overflow is luring all the time, the more so as one pays more attention to structuring one’s knowledge base. We learn about it from almost any science, particularly from humanities, as the extent of conceptual superstructure might seriously challenge any basic influx of data, and the literary criticism is a very good example.
So, the only thing I feel is wrong with filters is impossibility of filtering by keywords. In other words, I’d like to see the filtering tool as another search tool with additional naming and saving. This, of course, can be an option added to the main search tool.
As for the third, the left frame or column, in the beginning it seemed to me as wasting of precious page space, once there is this very fine quick preview available. But I very soon learned to appreciate the possibility of viewing simultaneously entire single fragment and the list of other ones. Particularly in the initial phase of looking for regularities it is good to have as few limitations as necessary. So I’d prefer not having the list (or the tree) in the central frame automatically filtered by the chosen fragment tags, because instead of sparing few clicks it is often forcing few extra. I am regularly comparing the fragment to various sets of other fragments, so I am doing some searching in the central frame, having the focused fragment exposed in the left one. Of course, when one already knows one’s base hierarchy and has it built, then present behavior is perfectly OK, but as I got it, Piggydb is about finding a structure rather than documenting it, and about relation network rather than hierarchical tree.
Actually, the only thing I believe Piggydb is missing at this moment is graphical, vectorial presentation of relations network on demand, with fragments represented by their names (possibly links) interconnected by arrowed lines, maybe some sort of SVG. It would make a huge help in examining (and possibly even editing?) already established relationships. But again, bearing in mind probable number of fragments of any serious base, I am fully aware this might be too much to ask for. Pity, because this one feature would make Piggydb a killer app.